# Best practices relative to reliability checks? Lately? **URL:** https://kopia.discourse.group/t/best-practices-relative-to-reliability-checks-lately/3871 **Category:** General Topics **Created:** [April 5, 2025, 6:29pm UTC](https://kopia.discourse.group/t/best-practices-relative-to-reliability-checks-lately/3871 "2025-04-05T18:29:32Z") **Posts on this page:** 1 **Showing post:** 5
### Author: ![97b4958b055b](https://avatars.discourse-cdn.com/v4/letter/9/47e85d/32.png) [@97b4958b055b](https://kopia.discourse.group/u/97b4958b055b) #### Post date: [April 7, 2025, 7:59am UTC](https://kopia.discourse.group/t/best-practices-relative-to-reliability-checks-lately/3871/5 "2025-04-07T07:59:34Z")
Yeah, I’m aware of Zabbix. I don’t bother monitoring any more. I just write policies for Monit re: CPU, RAM, I/O, hosts, etc. checks & fail/restart states for services/daemon groups. Like Kopia’s _actions_ are suppose to provide, Monit can also pass the results of conditions to/from external programs (eg: a shell script) if I really need to. I’ll check the logs while waiting for the coffee. In the case of Kopia, I find I really do need to automate intervention… just in case. Well, I’m a full Linux env so I can’t give you any insight re: Windows beyond that I loath Powershell (never again!) but more to your concern is that Kopia does seem to heavily rely on POSIX-based file systems. IDK how compliant NTFS is there. Reading over the docs & scattered posts on this board, you can manually test consistency on demand. I’m also going to use its ECC before automating weekly tests. > [@Linwood](#): > > I’m also worried a bit about maturity as I use this more. > [@Linwood](#): > > This thing is super fast and feature rich. But in terms of trusting it… well, not there yet. Agreed. The cryptography & modern checksumming algos attracted me but it’s Kopia’s actions that’s really the only thing keeping me from walking away. Being able to pass _pre_ and _post_ conditions to jobs very much fits in with my ideal requirements. To the former there’s also this: > [@Which is better: WebDAV or kopia server on remote NAS?](https://kopia.discourse.group/t/which-is-better-webdav-or-kopia-server-on-remote-nas/3248/4): > > Basically, yes. As long as Kopia server or client has direct accesss to the repo files, the connection to/from the client does only matter , when it comes to actual data transfer while creating a snapshot. We are doing that even between cities, e.g. between Vienna (Austria) and Hamburg (Germany)… and there are at least 20 or so TB in the repo. That’s about 744 km (462 mi) ‘as the crow flies.’ > [@Linwood](#): > > I should note I’ve been in IT pretty much since it started, and still do consulting for larger organizations on DR planning and networks. Nice. I’ve been doing something similar since it was ATDT & not HTTP. I’d be incredibly hesitant to putting this into production without taking addn’l steps. As related ITT I’m also speaking of the fact [endpoint credentials are stored in cleartext](https://github.com/kopia/kopia/issues/4115) regardless of the OS. That may not be as much of a concern if FDE is in use but FDE doesn’t protect against malware siphoning/RATs. I’m accounting for this ATM by ensuring the remote endpoint is isolated to its own container (chroot, technically), storage pool strictly for repo storage. Clients will have a private certificate authority installed to help control TLS access. Said endpoint is to be mirrored offsite. Then there’s the default logging to debug annoyance to address: > [@Bug: v0.19.0: CLI: Logs default to debug](https://kopia.discourse.group/t/bug-v0-19-0-cli-logs-default-to-debug/3824): > > Near 1000 lines written… plus ten (10) more multi-line, supposed log files and I haven’t even taken a snapshot. Almost ten years and this software still defaults to ‘debug.’ $HOME/.cache/kopia/cli-logs/kopia-20250320-064117-220796-server-start.0.log 2025-03-20T06:41:17.469576Z INFO kopia/cli Server will allow connections from users whose accounts are stored in the repository. User accounts can be added using 'kopia server user add'. 2025-03-20T06:41:17.472158Z INFO kopia/server Repository … > [@Linwood](#): > > And actions that are disabled by default? Why? I’d speculate the average SOHO user could get themselves into trouble quicker if it were. > [@Linwood](#): > > So my expectations for “trust” are perhaps unreasonably high for a home use free product, […] But is it? Backing up isn’t exactly a frontier in IT, even SOHO, regardless the monetary aspect. What’s being asked to be put up/at stake can easily be consider priceless, situation dependent of course. Otherwise why bother backing up at all? > [@Linwood](#): > > […] , and I mean no offense. I do: > [@PLEASE READ: Don't use --safety=none for routine maintenance](https://kopia.discourse.group/t/please-read-dont-use-safety-none-for-routine-maintenance/1199/36): > > So this is what your kind does when they can’t refute the points, huh? I make no apologies for calling out those who coddle advertent negligence. Here’s something far more on topic than obvious, sophmoric attempts of muddying the waters & obfuscations: did it not occur to anyone ITT the -safety=none switch should have the requirement of being followed by --YESIKNOWWHATIAMDOING before accepting & executing? It’s gobsmacking I have to point any of this out. Now go ahead; false flag this post. P… * * * > **[Verifying Validity of Snapshots/Repositories and Trying to Repair Any Corruption](https://kopia.io/docs/advanced/consistency/)** > > Fast and Secure Open-Source Backup Software for Windows, Mac, and Linux > **[Error Correction Algorithm](https://kopia.io/docs/advanced/ecc/)** > > Fast and Secure Open-Source Backup Software for Windows, Mac, and Linux --- _[View the full topic](https://kopia.discourse.group/t/best-practices-relative-to-reliability-checks-lately/3871)._