On Tue, 7 Oct 2014, James Harper <james@ejbdigital.com.au> 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" <Petros.Listig@fdrive.com.au> 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/