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
lesmikes...@gmail.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@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
