Re: [rdiff-backup-users] Repair repository

[Dominic Raferd]

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 <address@hidden> 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...