11–20 of 26 posts
My solution is to pick a few random files (plus whatever is new), and compute their hashes on both local and remote versions. But it's slow and probabilistic. ZFS also helps, but I feel it's too transparent to rely on (what if the remote storage changes filesystem).
Why not rsnapshot? I've been using it to backup servers to servers for a lot years.
rsnapshot uses centralized rsnapshot.conf, saf has git style .saf.conf per each backup source location.
Apart from using rsync, there are more differences than similarities between rshapshot and saf.
How do you automate the checking if the backup worked correctly, in face of saf bugs, rsync bugs/misconfiguration, or bit rot? My solution is to pick a few random files (plus whatever is new), and compute their hashes on both local and remote versions. But it's slow and probabilistic. ZFS also helps, but I feel it's too transparent to rely on (what if the remote storage changes filesystem).
Lately, in last few years, I am leaning towards using many cheap backups instead of clever and more expensive ones, with the idea that many of them can't all break at the same time. Yes occasional checks are good but safety in numbers seems as a good strategy.
It is not an accident that saf tag line says "one backup is saf, two are safe, three are safer" ;)
Have a look at restic for a good alternative to this.
Typical HN to immediately tell everyone to use something else when someone posts something they spent time and effort on making, just because it's not 100% unique
How do you automate the checking if the backup worked correctly, in face of saf bugs, rsync bugs/misconfiguration, or bit rot? My solution is to pick a few random files (plus whatever is new), and compute their hashes on both local and remote versions. But it's slow and probabilistic. ZFS also helps, but I feel it's too transparent to rely on (what if the remote storage changes filesystem).
Those same questions always bug me, and I did try all from very smart to very brute force solutions. I love ZFS but then we can question ZFS and OS bugs in the same manner as saf or rsync -- that rabbit hole is deep and quickly becomes expensive since ZFS may need ECC ram and other more expensive components. Lately, in last few years, I am leaning towards using many cheap backups instead of clever and more expensive…
On top of many cheap backups, I am also trying not to rely on any single peace of technology (I know, it is not ideal that hardware and OS remains the same on any computer no matter what backup is used). If I use saf as my preferred rsync based solution I will also use Borg or duply/duplicity as a additional backup to avoid rsync bugs.
Having two or more rsync based backups, so they all go trough the same rsync pipe, makes much less sense than mixing completely different backup solutions, right?
Have a look at restic for a good alternative to this.
Resric is great but the lack of empty passwords, and the response by the developer about it is very grating: https://github.com/restic/restic/issues/1786
This is a backup tool, not a security one. The fact that the author does not understand this is a real problem and a red flag.
Earlier quoted context omitted.
Typical HN to immediately tell everyone to use something else when someone posts something they spent time and effort on making, just because it's not 100% unique
I didn't mean to detract from the post. I use both rsync and restic and this looks interesting. Just wanted to provide a recommendation for an alternative that does very similar things; I hope that's okay.
Can it automatically prune backups older than N days?
I don’t see anything about encryption.
Have a look at restic for a good alternative to this.
Typical HN to immediately tell everyone to use something else when someone posts something they spent time and effort on making, just because it's not 100% unique
How does it deal with interrupted backups? Can it automatically prune backups older than N days? I don’t see anything about encryption.
Many prefer to deal with encryption separately, encrypting the volumes being backed up to rather than relying on the backup system to manage that.
Of course this adds a consideration to your system: how to backup your encryption keys, and use them to remount the volumes when needed, in a way that does not render the whole thing pointless by accidentally exposing your keys to the wild. Then again, the encryption included in many backup systems has these issues for you to resolve too.