4 ms·

Regarding atomicity, do you rsync from the live filesystem or from the hidden .zfs/snapshot dir? My impetus for swapping to a send-based approach from an rsync

Regarding atomicity, do you rsync from the live filesystem or from the hidden .zfs/snapshot dir? My impetus for swapping to a send-based approach from an rsync-based approach of running an incremental (just from the normal non-snapshot filesystem view) then taking a snap on the far side was encountering corrupted encrypted containers. If rsync ran while a container was mounted and being written to, it'd get an inconsistent view of the underlying file and produce a nonsense diff, resulting in an unmountable container in the backup. This doesn't happen with send because it has a consistent view of the blocks it needs to replicate, but as I was writing this I realized that running rsync from zfs's view of the snapshot might get around that. Of course, at that point it's probably easiest to just use send.

toast0 3y ago
My rsync backup goes from the live filesystem (and then does some snapshot-like things on the other end with hard links and what not), but it's for my househould's shared network drive, so atomicity isn't super important. Mostly there's not many changes, and if there are, it's ok if it takes a couple snapshots to settle. I didn't originally have that area as its own zfs filesystem, and it wasn't even originally on zfs, but I moved things around when setting up a new, offsite, backup system... Just haven't gotten around to redoing the old backups. I don't think I'd spend any more time on rsync based backups, given how I use things now; incremental zfs means no need to compare, which makes me have good feelings.