On Mon, 9 Jul 2007, Andrew Ferguson wrote:
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
On Wed, 11 Jul 2007, Joe Beda wrote:
(Having code to move the mirror forward and backward in time might be
interesting too at some point -- that way you could undo bad backups
by moving the mirror back in time and removing forward diffs).
I rather like this strange option. Can anyone think
Joe Beda wrote:
To make rdiff-backup work for me, I'd have to add the following
features initially:
1) Support for recovering dropped or lost backups.
2) Support for handling moved files.
3) Add sneaker net type backups.
In addition, I'd be very interested in hearing anyone's experience
with
Hi Dave,
I was going to start with the recovering dropped backups. My current
understanding (from reading code and experimentation) is that
rdiff-backup will go through and modify the destination tree in place.
If the backup gets dropped then the dest tree will be left in an
incomplete state.
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
Joe Beda wrote:
Hi Dave,
I was going to start with the recovering dropped backups. My current
understanding (from reading code and experimentation) is that
rdiff-backup will go through and modify the destination tree in place.
If the backup gets dropped then the dest tree will be left in
[EMAIL PROTECTED] wrote:
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
Dave Kempe wrote:
Most likely, to track moves you need to finish (or expand) the sha1
hashing support introduced in the CVS version.
Another idea that was floating around about tracking moves was to keep
track of inodes on systems that have them. (ie, they are useless if user
is backing-up
[EMAIL PROTECTED] wrote:
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
Andrew Ferguson wrote:
[EMAIL PROTECTED] wrote:
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
10 matches
Mail list logo
