Johan Ehnberg wrote:
>> OK. I can see now why this is true. But it seems like one could
>> rewrite the backuppc rsync protocol to check the pool for a file with
>> same checksum  before syncing. This could give some real speedup on
>> long files. This would be possible at least for the cpool where the
>> rsync checksums (and full file checksums) are stored at the end of
>> each file.
> 
> Now this would be quite the feature - and it fits perfecty with the idea 
> of smart pooling that BackupPC has. The effects are rather interesting:
> 
> - Different incremental levels won't be needed to preserve bandwidth
> - Full backups will indirectly use earlier incrementals as reference
> 
> Definite whishlist item.

But you'll have to read through millions of files and the common case of 
a growing logfile isn't going to find a match anyway.  The only way this 
could work is if the remote rsync could send a starting hash matching 
the one used to construct the pool filenames - and then you still have 
to deal with the odds of collisions.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/