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 <[EMAIL PROTECTED]> 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
_______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
