Re: [BackupPC-users] tar vs. rsync benchmark and limitation test results

[John G. <jgo...@co...>]

Les Mikesell <lesmikesell <at> gmail.com> writes:

 >
 > On 2/24/11 9:34 PM, John Goerzen wrote:
 > If you rename a directory, you won't get the old contents
 > underneath in their
 > new locations either.  You'll still have the backup in the
 > old path but might not know where to find it.

That is a good point, and probably true.

 > You might do better with the --whole-file option on rsync if your 
server is
 > slow doing the delta/merge operations.

Is that permissible?  There is a big fat warning against mucking with 
rsync options.

Anyhow, the problem I'm referring to is this one: http://bit.ly/hIxTqE

In short, rsync on the remote end is slow doing the delta operations, 
but only
when it's BackupPC talking to it.  If it's regular rsync talking to it, a
10-hour operation shrinks to a few minutes.

 > >    * The rsync backend for BackupPC is probably not useful unless
 > > Internet backups or small backup sets to fast disks are involved.
 >
 > That's perhaps an overstatement. But you do need
 > relatively fast hardware on the server side.

That is true.

 >
 > >    * The "limitations" of the tar backend have been exaggerated,
 > >  at least
 > > for backing up Linux systems with using POSIX-obeying filesystems
 > > with GNU tar.  (vfat under Linux may still exhibit the limitations
 > > documented, for instance.)
 >
 > I think the docs combine the smb/tar description for this, and you
 > would see
 > the effect as described when using smb or tar on a client filesystem
 > that doesn't support different mtime/ctime values.

Yes, indeed.  That's why I inserted a few qualifiers into my statement ;-)

-- John