Re: [Duplicity-talk] How it works document

[Kenneth Loafman]

Richard L. Houston wrote:
> Hi Ken,
> 
> Thanks for the response. 
> 
> The big question I have is, on an incremental run, how does duplicity 
> determine if a file needs to be backed up and on recovery how does it move 
> through
large amount of date to find the file you may have requested to recover?
Does it look through all the diff files?  In the case of recovery for a
file in the past using the -t how does it reassemble the file. Sorry if
these are noobish questions but it would be great to know when I am
pitching duplicity.

The way duplicity saves bandwidth and space is by using librsync to
produce incremental backups that contain only the changes made to the
individual files.  There is a good paper on the algorithm at:
http://rsync.samba.org/tech_report/.

The bottom line is that the original full backup and all incremental
backups may be involved in rebuilding a file if that file changes
frequently between the last backup and the restore.  Its not all that
bad since the manifest tells us what has changed, the signature files
tell us what the current file looks like and what blocks are different,
and the diff files are used to store the blocks that have changed.

So, yes, if you are using the -t option frequently to restore files to
the state they were in at time T, your time to recover will be related
to two major factors:
  1) How many incremental backups between Full and time > T
  2) How frequently the file change in between those times

Since there could be a fair amount of IO involved, regardless of the
backup system used, I recommend always that a local backup be made for
quick recover purpose and that rsync be used to copy that local backup
to a remote site for disaster recovery.

Hope this helps.

...Thanks,
...Ken

signature.asc
Description: OpenPGP digital signature