Les Mikesell wrote: > Joe Krahn wrote: >> >> If you are willing to trade disk space for bandwidth, you could dd a >>> snapshot of the partition to a file locally, then rsync the file to a >>> remote copy. You'll need twice the space on the remote side if you >>> use rsync's default behavior of building a complete new copy before >>> replacing the old. >>> >> Is it possible to just rsync the raw disk device? > > Most unix-like systems treat devices as much like files, but rsync has a > special check to make sure it is only working with files. It also > normally builds a new copy, then renames when complete, but there is an > option to override that. > >> I don't see the point >> of a dd snapshot, unless you can't get rsync to read from a block >> device. It certainly can't write to a block device, which is why rsync >> really won't work. > > Rsync theoretically could read/write to block devices, it just refuses. > But, you'd have to keep the filesystem unmounted for the duration and if > you don't let it build a separate new copy you'll end up with your > remote copy corrupted if the live system dies mid-run. I guess the right approach is to have two remote filesystems. There's no reason that the 'temporary' copy not also be a block device. You could have one remote system unmounted, and clone it from the unmounted system. You could then clone the 1st and 2nd remote devices. That way, one of the 3 would always be accessible.
> >> But, why do you really need to clone a raw disk instead of just rsyncing >> the content? A raw device copy means that you will end up synchronizing >> deleted file fragments, and you will need to have the filesystem >> unmounted. > > In the context of backuppc, the number of files and hardlinks often > makes it impractical to rsync the archive contents. > OK; Many files shouldn't be too hard, but I can see the problem when combined with large numbers of hardlinks. If it is only for BackupPC files, the most efficient approach would be to build a feature into BackupPC. Any other tool is going to have to hunt for hard links. Joe ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
