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> 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
