ridiff backup failers

[mike wolman]

Hi Ben,

Is it possible to delete a backup taken at a particular time rather than
before a set time,

as i am having to wade through a load of files on some of the
failed backups and rerunning rdiff-backup to see what else needs
to be deleted - it would be nice to simply delete any files created by the
"last" backup.

Mike.

On Tue, 22 Jan 2002, Ben Escoto wrote:

> >>>>> "MW" == mike wolman <mike@nux.co.uk>
> >>>>> wrote the following on Tue, 22 Jan 2002 18:07:33 +0000 (GMT)
>
>   MW> Hi Ben, Once in a while the backup fails due to connection
>   MW> errors - like a bad isp, normally when i re-run rdiff-backup it
>   MW> works fine and completes the backup, however on a couple of
>   MW> occasions on the re-run it dies with a similar error message
>   MW> like below:
>
>   MW> Excluding /home/db Incrementing mirror file
>   MW> /home/customers/us/home/jon/.bash_history Looks as if previous
>   MW> backup, dated 2002-01-09T17:44:55+01:00, created the
>   MW> file/home/customers/us/rdiff-backup-data/increments/home/jon/.bash_history.2002-01-09T23:58:55+01:00.diff
>   MW> and then failed or was aborted!  Some data may be lost...  Fatal
>   MW> Error: Times out of order, expecting prev time < inc mod time <
>   MW> current time, found instead (1010620735.0, 1010598295L,
>   MW> 1011717465.7931809)
>
>
>   MW> Inorder to continue the backup I have been manually removing the
>   MW> files it has been complaining about, is there a "correct"
>   MW> procedure to recover from a failed backup?
>
> Well, the correct thing would be for one of rdiff-backup's failures
> never to cause another one...  Is there something weird about the
> timestamps on .bash_history?  Supposedly rdiff-backup recovers from
> errors like the one you mentioned by examining the timestamps of the
> files from the failed backup.  But in this case it got confused
> because the modification time of .bash_history was before the previous
> (unaborted) backup time, so it seemed the .bash_history file shouldn't
> have been backed up in the aborted attempted (it hadn't changed since
> the previous one).
>
>     But maybe this system of looking at timestamps isn't very robust
> and I should think of a new way...
>
>
> --
> Ben Escoto
>