On Tue, 29 Apr 2014 20:53:48 Les Kitchen wrote:
On Wed, Apr 23, 2014, at 16:13, Craig Sanders wrote:
dd would perform an exact byte-by-byte duplicate of the *entire* disk *every* single time you performed the backup. rsync only backs up the files that have changed since the last backup.
I haven't tried this, but I wonder what would happen if you ran rsync directly on the block devices, rather than on files in the mounted filesystem. There's no reason in principle why rsync's rolling-block algorithm wouldn't work on a block device. Of course, this would require a full read of both devices and then writes of just the changed chunks, so it's not as good as it might seem. But there might be some scenarios in which it could be beneficial -- remote device at the other end of a slow comms link, where the time would be dominated by transfer of blocks down the wire.
https://lists.samba.org/archive/rsync/2010-June/025164.html There are patches to rsync to allow this. In the default mode of rsync it creates a temporary file, writes all data to that, and then renames it back. That process breaks the ability of filesystems like BTRFS and ZFS to share data between snapshots and also breaks the copy of the amount of free space in the filesystem is less than the size of the file (think of having 1G of disk space free and wanting to rsync changes to a 5G DVD image). The --inplace option to rsync fixes that. Copying a block device will be much the same as copying a file with --inplace.
of incremental device backup -- just like a raid or crypto device sits on top of physical devices, or even LVM.
In a way, it's such an obvious idea, that I'd be surprised if it hasn't been tried somewhere already.
Yes it's been implemented before for LVM. But as Trent and Criag noted you can just use the send/recv functionality built in to ZFS and BTRFS. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/