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.
> 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.
--
Les Mikesell
[EMAIL PROTECTED]
-------------------------------------------------------------------------
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/
