[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] rdiff-backup features?
From: |
rdiff |
Subject: |
Re: [rdiff-backup-users] rdiff-backup features? |
Date: |
Mon, 9 Jul 2007 15:39:44 -0700 (PDT) |
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
- [rdiff-backup-users] rdiff-backup features?, Joe Beda, 2007/07/09
- Re: [rdiff-backup-users] rdiff-backup features?, Dave Kempe, 2007/07/09
- Re: [rdiff-backup-users] rdiff-backup features?, Joe Beda, 2007/07/09
- Re: [rdiff-backup-users] rdiff-backup features?,
rdiff <=
- Re: [rdiff-backup-users] rdiff-backup features?, Steven Willoughby, 2007/07/09
- Re: [rdiff-backup-users] rdiff-backup features?, Andrew Ferguson, 2007/07/09
- Re: [rdiff-backup-users] rdiff-backup features?, Matthew Flaschen, 2007/07/10
- Re: [rdiff-backup-users] rdiff-backup features?, rdiff, 2007/07/11
- Re: [rdiff-backup-users] rdiff-backup features?, Joe Beda, 2007/07/11
- Re: [rdiff-backup-users] rdiff-backup features?, address@hidden, 2007/07/11
- Re: [rdiff-backup-users] rdiff-backup features?, Joe Beda, 2007/07/11
- Re: [rdiff-backup-users] rdiff-backup features?, address@hidden, 2007/07/11
- Re: [rdiff-backup-users] rdiff-backup features?, Andrew Ferguson, 2007/07/09
Re: [rdiff-backup-users] rdiff-backup features?, Andrew Ferguson, 2007/07/09