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.