Re: what to do if --check-destination-dir ends in traceback?
Hi Eric, * "Eric L. Zolf" [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
Re: what to do if --check-destination-dir ends in traceback?
On 06.07.21 01:46, griffin tucker wrote: the latest version is v2.0.5 - debian is slow with stable builds so buster doesn't include v2.0.5 with apt-get The idea behind Debian stable is that it should be stable. Therefore Debian stable won't get major software updates. However: https://packages.debian.org/buster-backports/rdiff-backup *t
Re: what to do if --check-destination-dir ends in traceback?
Hi,
the version 2.0.5 won't help here IMHO, there are two issues:
1. the "Unknown field" errors hint at the fact that the file system
issue has corrupted the metadata of the repository. This will be
difficult to impossible to fix, more on this later.
2. the traceback is actually due to an error in the error handling,
still present in v2.0.5 (but fixed for the next version).
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?
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.
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.
KR, Eric
On 06/07/2021 01:46, griffin tucker wrote:
On Tue, 6 Jul 2021 at 07:47, Gregor Zattler wrote:
Dear rdiff-backup users and developers,
lately I had to do a fsck.ext4 -y on the filesystem which
hosts my rdiff-backup. Then I had tracebacks when I
attempted the next backup. What to do in such a case?
Is there any hope to revive this rdiff-backup?
This is rdiff-backup 1.2.8 on Debian 10.10 (buster):
the latest version is v2.0.5 - debian is slow with stable builds so
buster doesn't include v2.0.5 with apt-get
you could install v2.0.5 from source on debian 10 (recommended) or
otherwise install debian bullseye (NOT recommended) but either of
these options won't help you recover your data
sorry i couldn't be of more help, can anyone else help recover data?
$ sudo rdiff-backup --check-destination-dir
/mnt/usb-backup/rdiff-backup/durable/
Unknown field in line '9e r1ons000'
Unknown field in line '9e 10a595828229'
Exception 'RORPath instance has no attribute 'path'' raised of class '':
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in
error_check_Main
try: Main(arglist)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in
Main
take_action(rps)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 282, in
take_action
elif action == "check-destination-dir": CheckDest(rps[0])
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 872, in
CheckDest
dest_rp.conn.regress.Regress(dest_rp)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 71, in
Regress
for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/rorpiter.py", line 281,
in __call__
last_branch.fast_process(*args)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 274,
in fast_process
else: rpath.copy_with_attribs(rf.metadata_rorp, rf.mirror_rp)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 243, in
copy_with_attribs
copy(rpin, rpout, compress)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 121, in
copy
else: raise RPathException("File %s has unknown type" % rpin.path)
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 30, in
rdiff_backup.Main.error_check_Main(sys.argv[1:])
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in
error_check_Main
try: Main(arglist)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in
Main
take_action(rps)
File
Re: what to do if --check-destination-dir ends in traceback?
Hi,
the version 2.0.5 won't help here IMHO, there are two issues:
1. the "Unknown field" errors hint at the fact that the file system
issue has corrupted the metadata of the repository. This will be
difficult to impossible to fix, more on this later.
2. the traceback is actually due to an error in the error handling,
still present in v2.0.5 (but fixed for the next version).
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?
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.
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.
KR, Eric
On 06/07/2021 01:46, griffin tucker wrote:
On Tue, 6 Jul 2021 at 07:47, Gregor Zattler wrote:
Dear rdiff-backup users and developers,
lately I had to do a fsck.ext4 -y on the filesystem which
hosts my rdiff-backup. Then I had tracebacks when I
attempted the next backup. What to do in such a case?
Is there any hope to revive this rdiff-backup?
This is rdiff-backup 1.2.8 on Debian 10.10 (buster):
the latest version is v2.0.5 - debian is slow with stable builds so
buster doesn't include v2.0.5 with apt-get
you could install v2.0.5 from source on debian 10 (recommended) or
otherwise install debian bullseye (NOT recommended) but either of
these options won't help you recover your data
sorry i couldn't be of more help, can anyone else help recover data?
$ sudo rdiff-backup --check-destination-dir
/mnt/usb-backup/rdiff-backup/durable/
Unknown field in line '9e r1ons000'
Unknown field in line '9e 10a595828229'
Exception 'RORPath instance has no attribute 'path'' raised of class '':
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in
error_check_Main
try: Main(arglist)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in
Main
take_action(rps)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 282, in
take_action
elif action == "check-destination-dir": CheckDest(rps[0])
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 872, in
CheckDest
dest_rp.conn.regress.Regress(dest_rp)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 71, in
Regress
for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/rorpiter.py", line 281,
in __call__
last_branch.fast_process(*args)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 274,
in fast_process
else: rpath.copy_with_attribs(rf.metadata_rorp, rf.mirror_rp)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 243, in
copy_with_attribs
copy(rpin, rpout, compress)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 121, in
copy
else: raise RPathException("File %s has unknown type" % rpin.path)
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 30, in
rdiff_backup.Main.error_check_Main(sys.argv[1:])
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in
error_check_Main
try: Main(arglist)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in
Main
take_action(rps)
File
Re: what to do if --check-destination-dir ends in traceback?
On Tue, 6 Jul 2021 at 07:47, Gregor Zattler wrote:
>
> Dear rdiff-backup users and developers,
>
> lately I had to do a fsck.ext4 -y on the filesystem which
> hosts my rdiff-backup. Then I had tracebacks when I
> attempted the next backup. What to do in such a case?
>
> Is there any hope to revive this rdiff-backup?
>
> This is rdiff-backup 1.2.8 on Debian 10.10 (buster):
the latest version is v2.0.5 - debian is slow with stable builds so
buster doesn't include v2.0.5 with apt-get
you could install v2.0.5 from source on debian 10 (recommended) or
otherwise install debian bullseye (NOT recommended) but either of
these options won't help you recover your data
sorry i couldn't be of more help, can anyone else help recover data?
>
>
> $ sudo rdiff-backup --check-destination-dir
> /mnt/usb-backup/rdiff-backup/durable/
> Unknown field in line '9e r1ons000'
> Unknown field in line '9e 10a595828229'
> Exception 'RORPath instance has no attribute 'path'' raised of class ' 'exceptions.AttributeError'>':
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in
> error_check_Main
> try: Main(arglist)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in
> Main
> take_action(rps)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 282, in
> take_action
> elif action == "check-destination-dir": CheckDest(rps[0])
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 872, in
> CheckDest
> dest_rp.conn.regress.Regress(dest_rp)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 71,
> in Regress
> for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/rorpiter.py", line 281,
> in __call__
> last_branch.fast_process(*args)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 274,
> in fast_process
> else: rpath.copy_with_attribs(rf.metadata_rorp, rf.mirror_rp)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 243, in
> copy_with_attribs
> copy(rpin, rpout, compress)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 121, in
> copy
> else: raise RPathException("File %s has unknown type" % rpin.path)
>
> Traceback (most recent call last):
> File "/usr/bin/rdiff-backup", line 30, in
> rdiff_backup.Main.error_check_Main(sys.argv[1:])
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in
> error_check_Main
> try: Main(arglist)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in
> Main
> take_action(rps)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 282, in
> take_action
> elif action == "check-destination-dir": CheckDest(rps[0])
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 872, in
> CheckDest
> dest_rp.conn.regress.Regress(dest_rp)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 71,
> in Regress
> for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/rorpiter.py", line 281,
> in __call__
> last_branch.fast_process(*args)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 274,
> in fast_process
> else: rpath.copy_with_attribs(rf.metadata_rorp, rf.mirror_rp)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 243, in
> copy_with_attribs
> copy(rpin, rpout, compress)
> File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 121, in
> copy
> else: raise RPathException("File %s has unknown type" % rpin.path)
> AttributeError: RORPath instance has no attribute 'path'
>
>
> Thanks for your attention, Gregor
>
>
