On 11/17 11:13 , Les Mikesell wrote:
> The remote rsync doesn't send the hash matching the backuppc naming
> scheme, so it can't identify matches that aren't in the previous
> tree for that host. 

oh. I thought that the backuppc pool heirarchy was just based on the md5sum
(or similar hash) of the file in question; and that the file on the remote
end would naturally hash to the same value.

> Even if it did, the hashing isn't perfect so
> additional checks would be needed that a stock rsync at the other
> end can't do.  

oh. my understanding was more imperfect than I thought.

> It should be possible to merge in the incrementals
> in the files that are checked, but currently only the last full
> is used.  

it might be nice to have a tool to do this; but it's probably only useful in
corner cases like mine; where an incremental has a *lot* more files than
the last full. (Unless we wanted to fill all the old incremental backups,
so that each new incremental is done against the last incremental, rather
than the last full....hmmm... this is how the other rsync backup tools tend
to work, since they don't make a distinction between full & incremental
backups when using rsync).

> I've gotten by pretty well by just starting a manual full
> from the web interface before going home if I know there are big
> changed on one of my remote hosts.

that's how I normally do it... not always possible tho, when the blackout
period starts sometime after I leave work. :)

> > > And you can add the -C option to the ssh
> > > command to save more.  
> > 
> > This option really should be mentioned in the notes in the config.pl file.
> > For old machines with slow CPU and lots of bandwidth it might not be
> > worthwhile; but for fast machines with slow links, it would be worth
> > reminding us of it. :)
> 
> For slow CPUs it might also be worth adding -c blowfish to get the
> more processer-friendly encryption.

I ran a few tests today, doing incremental backups against my workstation,
with the -C option on or off, and the -o CompressionLevel=9, and the -c
blowfish option in various combinations. At least for this backup, done with
a fast link (100MBps) on a moderate machine (dual 550MHz Xeon), the
difference seems to be lost in the statistical noise.

I'll see what difference it makes when backing up my 80GB server over the
T1... once I get all the data transferred.

> Note that ssh also has a config file where you can specify
> CompressionLevel from 1 to 9 (default is 6).  See man ssh_config.
> You could also enable compression there if you want it for every
> host.

thanks for the hint. I knew that option existed, but I never looked into it.
The only time I do compression with ssh, is for remote X displays, where it
improves responsiveness notably. Otherwise I tend to do it at a lower layer.

-- 
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

Reply via email to