4 ms·
I'm using zfs-auto-snapshot[1] and zfs send/recv to backup my work desktop machine to a remote server. The naive approach of just doing 'zfs send -R -I snap1 sn
by mhw 12y ago
I'm using zfs-auto-snapshot[1] and zfs send/recv to backup my work desktop machine to a remote server. The naive approach of just doing 'zfs send -R -I snap1 snap2 | ssh remote zfs recv -dF pool'[2] has a number of drawbacks:
* Assumes remote is available 100% of the time. Recovery from downtime at the remote probably requires some manual intervention to get things back in sync.
* If the remote is in a different physical location with limited bandwidth between the hosts, compressing the stream on the fly isn't going to be particularly efficient with bandwidth.
I've built some scripts to help[3], dumping the necessary incremental streams into a local directory and then compressing them with lrzip[4]. This decouples the host and remote systems and the zfs streams compress really well: a 33Mb incremental stream I have here compresses to 4.4Mb with lrzip. Once you have a directory of compressed streams you can push them wherever you want (a remote server where you convert them back into zfs snapshots, giving you a live filesystem; S3 buckets etc.) You also are able to restore using standard operating system tools.
I'd assume btrfs is comparable, but haven't tried it myself.
[1]: https://github.com/zfsonlinux/zfs-auto-snapshot https://github.com/zfsonlinux/zfs-auto-snapshot
[2]: see https://github.com/adaugherity/zfs-backup https://github.com/adaugherity/zfs-backup for example
[3]: currently in my local fork of zfstools at https://github.com/mhw/zfstools/blob/master/bin/zfs-save-snapshots https://github.com/mhw/zfstools/blob/master/bin/zfs-save-sna...
[4]: http://ck.kolivas.org/apps/lrzip/README http://ck.kolivas.org/apps/lrzip/README