On Fri, 2006-01-20 at 13:54, Dan Pritts wrote: > > > > I don't think it will be practical to let one backuppc system > > back up another, although I've always wished it could for > > a similar scenario where the 'sub' levels are in remote > > offices. I think it could be made to work but would require > > extra code in the server to not copy the pool, understand > > that the files are already compressed, and use some efficient > > method to only copy updated files on each run. > > Hmm. it would require lots of ram due to the huge number of files/links, > but otherwise, what's the problem with just using rsync to replicate one > to the other? Don't worry about backuppc at all, just shut it down & > let rsync do its thing.
The number of hardlinks makes rsync (or other file-oriented) copies impractical if the archive is large at all, plus you'd end up not being able to access the copy unless you have configured an instance of backuppc that understands the layout. What I ended up doing is a scheduled rsync at the remote offices to a linux box there, then the central backuppc server archives that copy over a WAN or VPN connection. This wastes some disk space since the intermediate copy is not compressed and only keeps one copy locally, but everything else works out pretty well. -- Les Mikesell [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ BackupPC-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
