On Tue, 7 Oct 2014, James Harper <[email protected]> wrote: > So you would: > . snapshot source > . rsync to snapshot to backup medium > . snapshot backup medium > > right?
That's what I do. > I think I could do that too, if send/receive does turn out to be broken. > The send is just so much faster it would be a shame not to stick with it. Rsync is quite fast if you don't use the -c option and the average file size is reasonably large. > Although if I was backing up to an external location where network > bandwidth was my biggest constraint then the performance of rsync would be > less of a problem. That's a large part of my backup. Another significant backup issue for me is some of my relatives who have 120G SSDs. Rsync from a SSD is mostly limited by the seek time of the backup disk, and when it's only 120G of data I don't need it to be really fast to complete before I leave. On Tue, 7 Oct 2014, "Peter Ross" <[email protected]> wrote: > Means: Make rsync work like btrfs send/receive;-) and put filesystem > specific code in it. > > I am not sure whether this is a great idea. I think that modern filesystems are getting complex enough that backup tools just can't operate properly without FS specific code. > Most of the time you will have the same filesystem on both ends. Then you > can use zfs/btrfs etc. tools. Or rsync if it's not a COW system. True, but that adds difficulty in migrating. For example my Internode quota is now 250G (was 150G last month), but I'm doing a backup of >400G of data over the Internet. AFAIK I couldn't change from using rsync backups to ZFS send/recv (even if I wanted to use ZFS at home) because I can't catch up with the backlog of data in any reasonable amount of time/money/effort. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
