On 3/11/11 3:08 AM, Cesar Kawar wrote:
>
>> Rsync'ing is all fine and good until your hardlinked filesystem (I
>> don't know the proper term for it, as opposed to the pool") gets "too
>> big". It's a RAM issue, and an unavoidable consequence of rsync's
>> architecture - I'm not faulting rsync mind you the kind of filesystem
>> that BPC (and rdiff/rsnapshot etc) build over time is a pretty extreme
>> outlier case.
>>
> That is not a problem anymore with latests versions of rsync. I've been using
> this technique for a year now with a cpool of almost 1Tb with no problems.
It is the number of files with more than one link that matter, not so much the
total size. But the newer rsync that doesn't need the whole file tree loaded
at
once besides the link table and lots of RAM may permit it to scale up more.
> Don't expect it to run on a celeron machine as it requieres big processors.
> Rsyncing 1Tb of compressed hardlinked data to a new filesystem is a very cpu
> intensive task. But it does not leak memory as before. You can relay on rsync
> to mantain a usb disk for off-site bakups.
I'd expect disk speed to have more impact than CPU as you traverse all the
directory entries, inodes, and data blocks in mostly-random order.
--
Les Mikesell
lesmikes...@gmail.com
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
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/
