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

[Joe Beda]

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.  This incomplete state can be cleaned up in either
on the next backup or explicitly.

I've come up with two approaches to making incremental backups work:

1) Leave current backup mostly as it is today.  On the next backup
don't clean up but instead merge metadata, undo any changes not in the
metadata (or recover from the FS?) and continue forward.  Any changes
from the incomplete backup would be moved forward and there would be
no increments at that incomplete backup time.

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 like #2 because the mirror tree will most always be a consistent
snapshot -- even if there is a long backup going on.  However, it is a
more fundamental change.  Any thoughts or advice before I start
writing code?

Joe

On 7/9/07, Dave Kempe <address@hidden> wrote:
> 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 the FUSE filesystem for accessing previous backups for
> > rdiff-backup
> > (http://code.google.com/soc/2007/gentoo/appinfo.html?csaid=54C92C8CD707C04D).
> >
> > This looks to be a Google SoC project and is very interesting.
> >
> > So -- questions to the group: Are these features welcome?  Is anyone
> > already working on these?  Is there a development mailing list?
>
> Hi Joe,
> you should check out the wiki - these features are probably all the most
> requested ones on the mailing list as well.
> the sneaker net backups are probably already supported - we do this with
> usb drives - copy the entire source to a usb drive, and do to the
> datacentre, then do an rdiff-backup from usb-source to destination.
> rdiff-backup doesn't distinguish between sources as such.
> Now this behaviour might need to be broken to track moves, not sure.
>
> Most likely, to track moves you need to finish (or expand) the sha1
> hashing support introduced in the CVS version.
>
> Recovering dropped or lost backups is a good feature, however its
> important to preserve the certainty the current design gives about the
> destination being intact and accurate copy of the source at all(backup)
> points in time.
>
> I hope you can contribute some code - if you need access to savannah I
> think I can set you up, please post patches to the mailing list to start
> with.
>
> thanks
>
> dave