ridiff backup failers
Tue, 22 Jan 2002 16:26:43 -0800
Content-Type: text/plain; charset=us-ascii
>>>>> "mw" == mike wolman <firstname.lastname@example.org>
>>>>> wrote the following on Wed, 23 Jan 2002 00:42:34 +0000 (GMT)
mw> But if you just delete the most recent backup (ie the last one
mw> which has failed) why would this effect any previous backups?
Because rdiff-backup updates the mirror directory as it goes along.
Let's take the earlier A B C example again. Suppose there is a file
in state C on the source directory, B on the mirror directory, and in
the rdiff-backup-data directory there is a diff file from a previous
instance that brings B->A.
Now suppose you run rdiff-backup, and it processes this file
first. When it is done with this file, the version in the mirror
directory will be in state C (same as the source dir), and there will
be two diffs in the rdiff-backup-data directory. The new one will be
C->B, and the old one is B->A. Then suppose rdiff-backup fails after
processing this file.
If you just delete the most recent diff file, C->B, then you will
have lost the ability to get to version A (or to version B). You
might as well delete all the diffs and treat the backup only as a
Instead what rdiff-backup tries to do if it thinks it was aborted
last time is look at the timestamps of the various diffs and make a
new diff chronicling the aborted attempt. However, if the timestamp
of the diff is before the last completed attempt (as it was in the
example you originally mentioned) rdiff-backup can't figure out when
the aborted attempt took place and thus can't preserve the integrity
of the incremental data.
mw> Is it possible to produce a list of all the new rdiff files
mw> created in the rdiff-backup data directory during a backup so if
mw> it fails you have a list of the new files which can then be
mw> easily removed and the backup re-run?
Well, this wouldn't be a good idea because you'll lose some
incremental data, and (unless you kept a list of the files deleted)
you wouldn't know which data was lost. If you restored to time T you
may get versions of files as they were after time T.
If you need a workaround, find the file called
current_mirror.2002-01-22T04:22:01-07:00.snapshot in the
rdiff-backup-data directory, and rename it by bumping up its time by
one second. For instance:
mv current_mirror.2002-01-22T04:22:01-07:00.snapshot current_mirror.2002-01-22T04:22:02-07:00.snapshot
After that the next backup attempt should work fine and plus you don't
lose any data (maybe this is what rdiff-backup should do automatically
instead of trying to get fancy with the file mtimes which can't be
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001
-----END PGP SIGNATURE-----