>
> I thought about this a little a year or so ago -- enough to attempt to 
> try to understand the rsync perl modules (failed!).
>
> I thought perhaps what would be best is a berkeley db/tied hash lookup 
> table/cache that would map rsync checksums+file size to a pool 
> item.    The local rsync client would request the checksum of each 
> remote file before transfer, and if it was in the cache and in the 
> pool, it could be used as the local version, then let the rsync 
> protocol take over to verify all of the blocks.
>
> I really like that BackupPC doesn't store its data in a database that 
> could get corrupted, and the berkeley db would just be a cache whose 
> integrity wouldn't be critical to the integrity of the backups.   And 
> the cache isn't relied on 100%, but rather the actual pool file the 
> cache points to is used as the ultimate authority.
>

Sorry -- to develop my idea further, the cache would be created/updated 
during backups, and a tool could be written to generate them in batch.   
A weekly routine could walk the cache and remove checksum entries that 
no longer point to pool items.  Small files (size user configurable) 
could also be excluded from the cache to minimize overhead/space.

Rich

------------------------------------------------------------------------------
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/