I'm delighted it worked for you - good work! I guess it is because
deleting the increments files tricks rdiff-backup into thinking that
there are no later backups than 2015-08-21T01:12:31-04:00, and in your
case this was ok because all the subsequent backup attempts hadn't
really changed any of the repository data (except metadata)?
Can you successfully verify the repository back to
2015-08-21T01:12:31-04:00 or (better) one backup earlier?
Dominic
On 23/09/2015 23:48, Patrik Dufresne wrote:
I finally manage to repair the archive ! I've browse the code to
determine where it's failing. I add some debug log for my self to
determine where the error was coming from. It look like recovery was
failing because some "increments" file was left over by failed backup.
I've search them and delete them.
This might be something to add to your script. Basically, when trying
to restore 2015-08-21T01:12:31-04:00, we need to delete every newer
file from increments directory. Then --check-destination-dir is working.
--
Patrik Dufresne
On Wed, Sep 23, 2015 at 1:44 AM, Dominic Raferd
<domi...@timedicer.co.uk <mailto:domi...@timedicer.co.uk>> wrote:
Hi Patrik
On 22/09/2015 22:00, Patrik Dufresne wrote:
I've tried the script. I had issues with it.
It searchs 'current_mirror' file recursively. For some reash,
the backup contains files named 'current_mirror'. I add
`-maxdepth 1` to fix this.
Good point, I have updated the script with this, which speeds it up
Regression also failed:
$ ./rdiff-backup-regress.sh ikus060-rdiff
...
I'm afraid I can only conclude that, as Robert suggested, your
archive is beyond repair, sorry.
I realise this suggestion is a bit late for you, but I do a daily
verification of all* my archives (repositories) and only proceed
with offsite synchronisation if they all pass. Very occasionally
one of them fails verification (coincidentally, one failed last
night) and then I fix it with --check-destination-dir, or
rdiff-backup-regress, or recover it from offsite backup. For each
archive, I verify the latest backup (the one stored 'in the
clear') and the one preceding it (which uses diffs).
* Actually there is one archive that takes too long to verify so
in this one case I just wing it, which is not ideal...
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
