Re: what to do if --check-destination-dir ends in traceback?

Hi Eric,
* "Eric L. Zolf" <[email protected]> [2021-07-06; 07:31]:
> My recommendation would be to throw away the backup repository and start
> a new one, preferably on a different disk drive if you don't know why
> the file system was corrupted in the first place. You don't want to keep
> your backup on hardware you can't trust, do you?
--text follows this line--
thanks.  I'll do so.  I have a second backup on a second
drive for such circumstances.

> If you want to try to fix the repository, it's a purely manual thing and
> there is a high chance to fail; it really depends how much your file
> system got corrupted, and what.
>
> First, you should fix the 2nd issue in order to get a more meaningful
> error message:
> 1. edit /usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py (as root)
> 2. go to line 121
> 3. replace `rpin.path` with `(rpin.index,)` (don't forget the comma)
>
> You can then try again to fix the repository with
> --check-destination-dir -v9.

I did both but it did not help.  Rescuing would be much
error prone guesswork.  Therefore I will copy the file
system of the second backup onto the partition of the first
one, backup to both and see what happens.


> This might allow you to more easily identify which
> rdiff-backup-data/mirror_metadata.[...] file is corrupted, you might
> even be lucky and rdiff-backup finishes the regression with only warnings.
> If it isn't the case, you can try to identify and patch the faulty
> mirror_metadata file by replacing the strange looking fields with
> meaningful values (or remove them altogether); the mirror_metadata will
> need to be uncompressed and re-compressed. The issue is that if it's a
> not so obvious field (e.g. the size), it'll become difficult to find the
> correct value (I would look at the mirror and assume the file hasn't
> changed since then, but it might not help).
>
> As you see, it's not easy, and it might only be the first corruption in
> a row of other corruptions, some might not get detected immediately.
> If you succeed to rollback, you should also run a --verify. But IMHO
> you'll never be 100% sure that your backup repo is fully correct.
>
> Hence my strong personal recommendation is to forget about it and start
> a new repo, you can still keep the old one if you think you might need a
> file from it at some point in time.
>
> Nothing is worse than a backup you aren't sure you can trust.

Yes.  Thanks for your attention and help, Gregor