Comment by LeoPanthera

17 hours ago

Is that a big deal? You should probably be doing this with zfs immutable snapshots anyway. Or equivalent feature for your filesystem.

The purpose of the append-only feature of borgbackup is to prevent an attacker from being able to overwrite your existing backups if they compromise the device being backed up.

Are you talking about using ZFS snapshots on the remote backup target? Trying to solve the same problem with local snapshots wouldn't work because the attack presumes that the device that's sending the backups is compromised.

There's not much sense in using these advanced backup tools if you're already on ZFS, even if it's just on the backup server, I would stick with something simpler. Their whole point is in reliable checksums, incremental backups, deduplication, snapshotting on top of a 'simple' classical filesystem. Sounds familiar to any ZFS user?

  • Are there any good options for an off-site zfs backup server besides a colo?

    Would be interested to know what others have set up as I'm not really happy with how I do it. I have zfs on my NAS running locally. I backup to that from my PC via rsync triggered by anacron daily. From my NAS I use rclone to send encrypted backups to Backblaze.

    I'd be happier with something more frequent from PC to NAS. Syncthing maybe? Then just do zfs sync to some off site zfs server.

I'm also completely confused why this was at the top of my hacki, seems completely innocuous

  • Ideally a backup system should be implementable in such a way that no credential on the machines being backed up, enable the deletion or modification of existing backups. That's so that if your machines are hacked a) the backups can't be deleted or encrypted in a ransom attack and b) If you can figure out when the first compromise occurred, you know that before that date the backup data is not compromised.

    I guess some people might have been relying on this feature of borgbackup to implement that requirement