4 ms·

Or just use ZFS and send/recv over the network? It's super simple, guarantees reliability, and very easy to replicate, e.g. offline backups.

cyphar 8y ago
The nice thing about restic is that you don't need to have a smart server, you can store your backups anywhere. And it doesn't require a particular filesystem on your host. Not to mention that deduplication is very cheap due its design (and unlike extent-based dedup, content-defined dedup also helps dedup some file changes a lot better). ZFS, while it is definitely a great project, doesn't provide those features.
- cryptonector 8y ago
  You can store zfs send output as a file. You don't need a ZFS filesystem to receive into if all you're doing is backups.
  - bpye 8y ago
    I've never considered doing this, can you do it differentially?
    - cryptonector 8y ago
      Do you mean incrementally? Yes, zfs send sends the contents that's different between snapshots (or the entire dataset up to a snapshot, if you want).
      - bpye 8y ago
        Hm, I think I understand. So you could save the entire dataset up to snapshot x, then for x+1 you would save just a diff. Might have to play around with this. I currently use ZFS snapshots to protect against accidental data loss and I have daily backups off site but these are managed independently. This might make my life easier.
        cryptonector 8y ago
        Yes, zfs send can do both, "the whole thing [up to a snapshot]" and "diffs between snapshots". And it's fast. Perfect for backups.
  - akvadrako 8y ago
    That's not a complete solution unless you have infinite storage. You need the ability to store 1 snapshot per month without missing any files, but they may only be contained in one hourly diff.
    - cryptonector 8y ago
      This is true of all incremental backup systems.
      - cyphar 8y ago
        restic stores files as a Merkle tree of blobs, with snapshots just being a particular root of the tree. This means that all snapshots are "full" (in the sense you don't need any others to reconstruct the filesystem) but are also "incremental" (in the sense that data isn't duplicated if it wasn't changed). 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.
        cryptonector 8y ago
        ZFS is a Merkle hash tree. zfs send uses this.
        cyphar 8y ago
        Yes, but if you are storing the output of zfs send for each snapshot (incrementally) you won't get the benefit of it using a merkle tree on the storage side of things (obviously it's used among other neat algorithms to figure out what the delta between snapshots is). 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.

cyphar 8y ago

The nice thing about restic is that you don't need to have a smart server, you can store your backups anywhere. And it doesn't require a particular filesystem on your host. Not to mention that deduplication is very cheap due its design (and unlike extent-based dedup, content-defined dedup also helps dedup some file changes a lot better). ZFS, while it is definitely a great project, doesn't provide those features.

cryptonector 8y ago
You can store zfs send output as a file. You don't need a ZFS filesystem to receive into if all you're doing is backups.
- bpye 8y ago
  I've never considered doing this, can you do it differentially?
  - cryptonector 8y ago
    Do you mean incrementally? Yes, zfs send sends the contents that's different between snapshots (or the entire dataset up to a snapshot, if you want).
    - bpye 8y ago
      Hm, I think I understand. So you could save the entire dataset up to snapshot x, then for x+1 you would save just a diff. Might have to play around with this. I currently use ZFS snapshots to protect against accidental data loss and I have daily backups off site but these are managed independently. This might make my life easier.
      - cryptonector 8y ago
        Yes, zfs send can do both, "the whole thing [up to a snapshot]" and "diffs between snapshots". And it's fast. Perfect for backups.
- akvadrako 8y ago
  That's not a complete solution unless you have infinite storage. You need the ability to store 1 snapshot per month without missing any files, but they may only be contained in one hourly diff.
  - cryptonector 8y ago
    This is true of all incremental backup systems.
    - cyphar 8y ago
      restic stores files as a Merkle tree of blobs, with snapshots just being a particular root of the tree. This means that all snapshots are "full" (in the sense you don't need any others to reconstruct the filesystem) but are also "incremental" (in the sense that data isn't duplicated if it wasn't changed). 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.
      - cryptonector 8y ago
        ZFS is a Merkle hash tree. zfs send uses this.
        cyphar 8y ago
        Yes, but if you are storing the output of zfs send for each snapshot (incrementally) you won't get the benefit of it using a merkle tree on the storage side of things (obviously it's used among other neat algorithms to figure out what the delta between snapshots is). 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.