Jonathan Dill wrote:
> partimage is another efficient tool that I have used for cloning disks,
> it skips blocks that the filesystem thinks are free / not in use,
> supports a network mode, but the filesystem can't be in use, although it
> could be read-only. If you use xfs, you could use xfs_f
partimage is another efficient tool that I have used for cloning disks,
it skips blocks that the filesystem thinks are free / not in use,
supports a network mode, but the filesystem can't be in use, although it
could be read-only. If you use xfs, you could use xfs_freeze to freeze
the filesyst
Tim writes:
> Some time ago, someone e-mailed a script that performed a dd/netcat in
> an rsync-like manner: it hashed blocks of the disk and if they matched
> between the two sides they were not sent. If they didn't, the block was
> sent. The idea was to limit the amount of data that would be
Les Mikesell wrote:
> Joe Krahn wrote:
...
>> 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.
>
> Backuppc doesn't really know anything about the hardlinks either once
> they are
Joe Krahn wrote:
>> 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.
>
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 bui
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 cop
Joe Krahn wrote:
> I did some searching and found that several people have expressed
> interest in a block-device feature for rsync, but nothing has come of it
> yet. I also found DRBD (Distributed Replicated Block Device), which
> probably does exactly what you want.
>
I just found this interes
Timothy J. Massey wrote:
> Hello!
>
> Some time ago, someone e-mailed a script that performed a dd/netcat in
> an rsync-like manner: it hashed blocks of the disk and if they matched
> between the two sides they were not sent. If they didn't, the block was
> sent. The idea was to limit the am
Les Mikesell wrote:
> Timothy J. Massey wrote:
>
>> Some time ago, someone e-mailed a script that performed a dd/netcat in
>> an rsync-like manner: it hashed blocks of the disk and if they matched
>> between the two sides they were not sent. If they didn't, the block was
>> sent. The idea wa
Timothy J. Massey wrote:
>
> Some time ago, someone e-mailed a script that performed a dd/netcat in
> an rsync-like manner: it hashed blocks of the disk and if they matched
> between the two sides they were not sent. If they didn't, the block was
> sent. The idea was to limit the amount of
Hello!
Some time ago, someone e-mailed a script that performed a dd/netcat in
an rsync-like manner: it hashed blocks of the disk and if they matched
between the two sides they were not sent. If they didn't, the block was
sent. The idea was to limit the amount of data that would be sent in a
12 matches
Mail list logo
