ridiff backup failers

[Ben Escoto]

--==_Exmh_-845250354P
Content-Type: text/plain; charset=us-ascii

>>>>> "mw" == mike wolman <mike@nux.co.uk>
>>>>> 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
mirror.

    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
relied upon..).


--
Ben Escoto

--==_Exmh_-845250354P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001

iD8DBQE8TgM7+owuOvknOnURAmRNAJwMCjAzYcDkt5zGooIKab6r+LTC4gCgh9YJ
yCpXEu1GuO7UMmrNH+upIts=
=1wd+
-----END PGP SIGNATURE-----

--==_Exmh_-845250354P--