Re: [rdiff-backup-users] rdiff-backup features?

[rdiff]

On Mon, 9 Jul 2007, Joe Beda wrote:
> 2) Change the main flow of the backup.  Instead of modifying the dest
> tree in place, instead write forward looking increments out.  When all
> of the forward increments are written out then patch the mirror tree
> to move it forward.  Care would have to be taken to be able to recover
> if the process was stopped during this forward patching.

I love this!  It is reminiscent of journaling system, and the idea that I 
have complete access to a backup tree during the backup is very appealing. 
It can then be made to recover from where it left off from a failed backup 
since it can compare against the forward increments at reconnect, and 
COMMIT the good backup to the repository.

I am imagining the following process, please let me know your thoughts:

Step A, Backup Sync:
  1. Write changes as diffs against the current repository into 
something like $REPO/rdiff-backup-data/scratch/.
  2. Simultaneously, write changes as rdiffs against the will-be new 
version for placement in $REPO/rdiff-backup-data/increments/.

Step B, Commit of Sync; may be done offline (CRITICAL SECTION):
  1. Patch all of the current $REPO against rdiff-backup/data/scratch/ 
diffs
  2. Move rdiff increments in part A2 into their proper location
  3. Update metadata upon completion to reflect changes.

During step B, restores can not be performed since live data and metadata 
are being changed.  Some amount of locking should be performed here to 
keep restores (and backups!) from happing during this step.

It might also be a good idea to use rdiff-backup's existing rollback 
methods (--check-destination-dir) to fix the repository if a Python 
exception is thrown somewhere in the middle of step B (ie: out of disk 
space), in order to roll-back and try step B again.  Of course if step B 
continues to fail, one might blow away the scratch directory and resync. 
This would certainly be better than blowing away the entire increment 
tree!

Your thoughts?

-Eric