[Dirvish] Full backup every time
jon at radel.com
Sat Mar 22 23:52:20 UTC 2008
Jens Lang wrote:
> Jon Radel schrieb:
>> Number of files: 155036
>> Number of files transferred: 942
>> Total file size: 60891647542 bytes
>> Total transferred file size: 208591096 bytes
>> Literal data: 13875619 bytes
>> Matched data: 194715792 bytes
>> File list size: 3239140
>> File list generation time: 54.763 seconds
>> File list transfer time: 0.000 seconds
>> Total bytes sent: 686805
>> Total bytes received: 8768410
>> sent 686805 bytes received 8768410 bytes 3080.38 bytes/sec
>> total size is 60891647542 speedup is 6440.01
>> And which version of rsync is /usr/local/bin/rsync-new anyway?
> There is no file with this name. "rsync --version" gives:
Doug Hill appears to be using a custom copy of rsync; you don't.
> This is the output of "du -h --max-depth=1":
>> 58G ./2008-03-21_18.18
>> 35G ./2008-03-22_18.18
>> 12K ./dirvish
>> 67G ./2008-03-09_11.18
>> 36G ./2008-03-16_10.29
>> 194G .
> "2008-03-16_10.29" is a "--init" backup.
> Well, it seems to me that that not all the data is transferred but
> nevertheless most (but obviously not all) files are copied instead of
> being hardlinked.
Well, given that rsync claims to have transferred only 942 out of
155,036 files (is that reasonable?), it doesn't appear to be going wrong
on the client side (OK, so that's a guess :-). The question is whether
hard links are being created on the server side. Find a file that
hasn't changed between 3/16 and 3/22. Does it show as 3 times as many
links on the server side as on the client?
Or do you simply have about 22G of files which get ownership or
permission changes on a regular basis? That will keep rsync from doing
a hard link.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2890 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.dirvish.org/pipermail/dirvish/attachments/20080322/6110c042/attachment.bin
More information about the Dirvish