So the client machine can't change old backups. Ever. In addition you can lock your settings down with 2FA.
How do you store the data on your end?
The actual data lies on a plain vanilla RAID array.
Also: you still need to keep some data even under GDPR. Like billing data.
"One issue with most backup solutions is that an attacker controlling the local system can also wipe its old backups."
Their study on various cloud storage performance helped me decide tremendously.
I make backups using multiple implementations (restic and duplicacy) to avoid unfortunate case of an implementation corrupting encrypted / compressed data which may become unrecoverable completely or any other bug to partially corrupt it.
I hate it when backups don't work when I need it and it's not easy to do 100% verification on all backups regularly.
ZFS, while it is definitely a great project, doesn't provide those features.
Yes, ZFS internally stores things in a similar fashion but I believe you can't get that from zfs-send (which is totally fine -- that's not the use-case they were going for, and zfs-send is incredibly useful for lots of other cases). restic is also chunked using content-defined chunking which is gives you much better deduplication than extent-based chunking (which is what ZFS, or any in-kernel filesystem has) -- and ZFS deduplication is well-known to be very expensive to enable while restic's deduplication is (almost) free. Of course, restic doesn't get atomic snapshots without using a filesystem like ZFS -- so so there's obviously benefits to using both together.
If you are using zfs recv on the remote server you will get basically the same features as restic (minus content-defined deduplication, and full-repo encryption -- ZFS has extent-based dedup and its built-in encryption is not "full-disk" since it reveals ZFS-level metadata). And you get real atomic snapshots which is better than what restic can give you because it's a userspace tool (though you can always use restic with ZFS).
I'm not sure we're actually in disagreement on how ZFS works, it's a question of whether you can get the practicalities of the benefits without having a ZFS server which holds your backups. If you just store the out of zfs send then it's also hard to expire old backups, and restoring would require applying all of the saved send payloads rather than just doing one 'zfs send' from the remote server.
Again, I'm not bashing ZFS. My whole point is that restic is a neat and interesting project specifically because it doesn't require a clever server to provide its features -- that doesn't mean ZFS isn't a great project (far from it).
I use ZFS on my servers and love it, and I use restic for backups.
With ZFS snapshots, only blocks changed since the previous snapshot are included.
However modern (or, if you prefer, "real") backup systems backup systems" (like borgbackup and restic) aren't "incremental" in this traditional sense, they are a mix of both "full" and "incremental" backups such that you get the benefits of both without the corresponding downsides.
Time Machine might call itself an incremental backup, but this just leads to more confusion -- it's a next-gen backup system (that has the benefits of both the "incremental" and "full" approaches) just like restic, borg-backup and all other similar projects.
Yes, zfs send sends the contents that's different between snapshots (or the entire dataset up to a snapshot, if you want).
Perfect for backups.
For example: https://www.acronis.com/en-us/blog/posts/backups-and-gdpr-ri...