Hi Eric, * "Eric L. Zolf" <ewl+rdiffbac...@lavar.de> [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