On 12/06 04:49 , dan wrote: > alternatively i think i may just break rsync up into smaller jobs and sync > each specific directory seperately with a 'for x in 'ls /'; do rsync $x > rsyncd://serveraddress/' script. that would help limit the number of files > in each rsync interation and work around the memory usage issue. i may have > to go a step further and omit the backuppc archive directory and run another > 'for x' script in the top of the hosts directory so i would launch a > seperate rsync for each host.
I think I've seen scripts posted to this list, which do just that. it's pretty kludgy, but the poster seemed to indicate that it works. does anyone have any idea how much bandwidth might be saved by replicating a backuppc server, as opposed to just having a completely independent backup done by a backuppc server that just happened to be offsite? if you're doing daily backups with both, your only gains from replication will be when you transfer aggregated files (and the above-described plan will explicitly break aggregation of files and they'll have to be re-linked on the target machine). so the only way I can see replication helping, is if you don't have time to do multiple backups in a given cycle. this is certainly the case in many situations; but if it's not, then it may be adviseable to not bother trying to build a replicant of your backuppc server. -- Carl Soderstrom Systems Administrator Real-Time Enterprises www.real-time.com ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
