Accepts stuff from pipe too so you can just pipe mysqldump or pg_dumpall without intermediate files
Very decent options for checking repo integrity, personally (well, at work too, we use it on few hundred user machines and servers) I also added "roll a dice for backup and try to restore it" test script to make sure it is working
Decent deduplication too so "store year's worth of weekly snapshot" is very sensible strategy once you exclude the "constantly changing and useless" (caches etc.) files out of it
can mount FUSE directory with all backups on sensible OSes.
https://kopia.io/ does the same +GUI but a bit worse on CLI front (it insists on keeping local config which makes scripting a bit more involved, but not much)
IMHO, the easiest way to perform a restore test is to use your production backups to refresh a lesser environment on a weekly cadence. Naturally this has to be appropriate to the type of data you're restoring, e.g., our E2E (end to end) testing environment has been built to the same risk tolerances of production so it's suitable for production data and the PII (Personally Identifiable Information) it hosts. If this isn't in your own risk tolerances, you can still perform the same test but ensure the data from prod is anonymised or alternatively destroyed, and perform a second restore after production restore with the dataset that preceeded it that has no PII data or similar.
With this the E2E tests confirm the backups are expected and you can tick a box that when shit does eventually hit the fan, data corruption isn't a problem. Normal caveats apply, you must make sure your backups are immutable so they cannot be modified or changed _after_ the tests have been ran.
I was using Restic + Backrest as well for my personal Windows machines and it was great. Then I found out that Backrest stores the vault password (among other things) in a simple plaintext file on your local hard drive. Not sure if this applies to all platforms but for Windows users that is a huge security hole in today's environment.
We actually do use some of our backups in anonymize -> test environment pipeline so it gets dual use on top of just testing restores.
We also use S3 versioning in case something gets the keys and just erases it. Then it's replicated to the cloud S3-compatible store to get the offsite location.
Only feature I really miss is "turn this restore into .tar", both for testing restores and for convenience when we get requests of "we need this directory from 4 weeks ago"
Kopia does not let you pipe into it without intermediate files, or at least not in a friendly way I could figure out.
Kopia seems quite designed around the backup server being the place where the config is set. IMO it's harder to configure if you have your own declarative config tooling (like Ansible, NixOS, etc)
The nicest way I found to ignore files declaratively is to configure a ignore-file pattern in the repository policy and then declaratively create `.kopiaignore` files.
The Kopia server is convenient if you have a server at home and want to back up laptops to it, with them being in a shared deduplicated repository without having to trust the clients not to get pwned and wipe out the backups. However I'm not aware of a nice way to then transfer those backups to aggregate them into a bigger repository. (So I just rsync them off-site and don't worry about getting deduplication with other backups)
Also learnt the hard way that you can't set a bandwidth limit when backing up to the kopia server, which can tank wifi performance on laptops during the backup.
I am thinking of switching to Restic as it seems like it is more suitable for people who want a tool at the complexity level of tar/git CLI with declarative config, rather than something imperatively configured.
We tested both and used Restic precisely because it was better in CLI/scripting department. Kopia is better for maybe less advanced user as it gives them GUI to click on
> he Kopia server is convenient if you have a server at home and want to back up laptops to it, with them being in a shared deduplicated repository without having to trust the clients not to get pwned and wipe out the backups.
Neither can do it well. We just used S3 + versioning for that reason, worst case we would just rollback the bucket
importantly, does your die have a side that corresponds to a multi-continental cataclysmic natural disaster of magnitude only known unknown to pre-recorded-history
Software like https://restic.net/ does a good job. Few choices of backend
Accepts stuff from pipe too so you can just pipe mysqldump or pg_dumpall without intermediate files
Very decent options for checking repo integrity, personally (well, at work too, we use it on few hundred user machines and servers) I also added "roll a dice for backup and try to restore it" test script to make sure it is working
Decent deduplication too so "store year's worth of weekly snapshot" is very sensible strategy once you exclude the "constantly changing and useless" (caches etc.) files out of it
can mount FUSE directory with all backups on sensible OSes.
https://kopia.io/ does the same +GUI but a bit worse on CLI front (it insists on keeping local config which makes scripting a bit more involved, but not much)