UpdateErrorRetry
From RdiffBackupWiki
My scenario:
I do backups of the mailboxes of a mailserver using rdiff-backup. Some (few) of many mailboxes will change while backup resulting in "UpdateError mailbox_xy Updated mirror temp file /var/backup/rdiff-backup.tmp.310 does not match source". Because of this error, the changes are not saved and the backups of these mailboxes are still that of the last successful run. I would like to have an option "--retry-changed-files" or something, that cuases rdiff-backup to process the files again, that could not be saved because the source file changed. The re-processing of these files should be done after the normal backup run (which takes usually some time). So the chances for a successful backup of the mailboxes will be much bigger. Maybe one could also specify how many times rdiff-backup sould try to process the file and/or if it should wait (sleep) a certain amount of time before it starts to re-process the files.
So, what do you think of this? Could this be useful to someone else than me?
-- Marco Steinacher <marco@websource.ch>
It certainly seems like a useful feature. However, implementing it looks like it could be tricky.
The patch and patch_and_increment functions in backup.py drive the two processes that can lead to these UpdateErrors. Both functions run as 'for diff in ...' The diff iterator is based off the sig iter, which calls the CCPP iterator, which in turn is based on the iterators that actually go over the files on the source and destination sides. Those iterators come from selection.py.
It would seem that simply appending the troublesome file to the source/dest iterators so they would be handled again would do the trick. However, the CCPP iterator caches files that have been seen "recently", and it could get very confused by a file that's in the cache twice (see shorten_cache function). Care would have to be taken to keep the cache in a clean state.
--AndrewFerguson 11:52, 16 June 2007 (EST)
If the source is using LVM (logical volume manager), then an LVM snapshot is a great way to handle this. Just before the backup, freeze the database server (if any), snapshot to a new device with lvcreate, and then let everything continue on the original while you back up the snapshot. When finished, lvremove the snapshot. I'm able to do this on one system and it works beautifully. On another system that doesn't (and can't) use LVM, I get plenty of UpdateErrors from log files that are updated during the backup. --Chris 23:32, 23 July 2007 (EST)
