Closed liblit closed 1 year ago
Thanks for reporting, @liblit
What bothers me most is how your repo could get into this corrupt state, as this should never happen during normal rustic operation. Can you give me more information about what happened? Which kind of repo are you using? Which rustic versions did you run on the repo? Did you run some specific command which turned the repo into this state?
About the repair index
command: Seem I need to improve the error handling here. My first guess is that you have some empty packfile (which, of course, shouldn't happen). Can you rerun repair index
using --log-level debug
?
About the repair snapshots
command: This is intended behavior. Unless you specify --delete
, only new (repaired) snapshots are saved while the original (broken) ones are still kept. Therefore your subsequent check
run still complains about broken files in the original snapshots. You should see some extra snapshots (having the tag repaired
) which allow you to see the impact of the repair.
But note: If the index doesn't reflect the actual pack files, repair snapshots
cannot work properly, so make sure that repair index
succeeds before!
Thank you for the speedy and detailed reply, @aawsome!
What bothers me most is how your repo could get into this corrupt state, as this should never happen during normal rustic operation.
You will be relieved to know that Rustic did not cause this corruption. This repository has been built up over years of using Restic. Furthermore, it was originally stored in a cloud storage service (pCloud) with which I have recently had data-integrity problems. This repository has never been modified using Rustic. I only started experimenting with Rustic as a Restic alternative quite recently, to see if it could do a better job of repairing whatever damage Restic + pCloud have caused over the years.
About the
repair snapshots
command: This is intended behavior.
Ah! Shame on me for not reading the documentation more carefully. Thank you for clarifying. I look forward to using repair snapshots
with --delete
once we've figure out how to get repair index
working.
About the
repair index
command: Seem I need to improve the error handling here. My first guess is that you have some empty packfile (which, of course, shouldn't happen). Can you rerunrepair index
using--log-level debug
?
Done. There's not much to it:
17:27:27 [INFO] repository .: password is correct.
17:27:27 [INFO] using cache at /home/liblit/.cache/rustic/6f6b61809f47f5987114f22dfe8db5dfb31df2bde574d545cfdbefca6360492b
17:27:28 [DEBUG] (1) rustic::commands::repair: reading pack 49205189...
The pack in question is present and non-empty:
% ls -l data/49/49205189
-rw-r-----. 1 liblit liblit 10698752 Dec 14 11:29 data/49/49205189d56ed447e3dd42ccc574f3721c14bb5c171ab83ba91eeb5c9afbd417
I just merged #369 which improves the error handling. So it should give better error output by default and ignores pack files in repair index
which cannot be processed. It is also available in the latest beta build.
About your pack 49205189...: I fear that this will still not work, most likely this pack file is corrupt. The reason could be a partial file being saved or some kind of bit flip. About both I was already thinking of methods how (try to) to repair (better said: try to salvage as much data as possible) them, but they are not yet implemented.
Anyway, please give it a try and report the outcome! If packs are not processed by repair index
please try to run a sha256sum
on the pack files and check if the result matches the filename!
Using Rustic v0.4.2-5-g53c5fd2
, the rustic repair index
command consistently reports problems with five packs, no matter how many times I use repair index
:
[WARN] error reading pack a2e0e110 (not processed): Header is longer than file? Header size: 1445089623, file size: 8912896
[WARN] error reading pack aebe7dfe (not processed): Header is longer than file? Header size: 1713880441, file size: 9764864
[WARN] error reading pack de494bfa (not processed): Header is longer than file? Header size: 2143406542, file size: 7798784
[WARN] error reading pack 5534aea9 (not processed): Header is longer than file? Header size: 3488278857, file size: 7536640
[WARN] error reading pack 49205189 (not processed): Header is longer than file? Header size: 2266810390, file size: 10698752
For each of these five files, the contents' SHA-256 checksum does not match the name:
% sha256sum data/*/{aebe7dfe,a2e0e110,de494bfa,49205189,5534aea9}*
1264a6e32e305b91c9563c4c08e9ccd3a584f3d2d764387beb18078661d42b9b data/ae/aebe7dfe7fa6fe6312c229c95627831369676efc52d6e47d3952769fa3301ae2
119122727fe035cc8080661082dfa11ebcdb64aeaa8031162d6109915aaf9101 data/a2/a2e0e11095d3d26271a5d911015334e061b9f03dc506b7e7e3bb02b83ad17254
c5d4b4e6203cfe50ca909f8696a7cd14a5f559a466909fa39523f25058ecee06 data/de/de494bfa7e6f7a8c474e3e493ab19adbb6e71d62564991019d4204d77ee072b2
5f5f9cabef2d3fdd33231366e1c0925f5b2acba12f37388acea1d5272abd2bc1 data/49/49205189d56ed447e3dd42ccc574f3721c14bb5c171ab83ba91eeb5c9afbd417
e791491672a0037a469cae5a35a2230fca88e41c2306573fb641aaf03d28d73b data/55/5534aea91023728424198b60729aee48d924abbc8924ba2a1ecf332ff85ab954
Presumably these five files are irrecoverably corrupted? If that's the case, should I remove them entirely, then see what else can be partially repaired and recovered? Let's try that and see what happens:
rm data/*/{aebe7dfe,a2e0e110,de494bfa,49205189,5534aea9}*
rustic -r. repair index
completed in under one second, producing no warnings or errors.rustic -r. repair snapshots --delete
completed in 46 seconds. It warned about many files with missing contents and created many modified snapshots.rustic -r. repair snapshots --delete
run a second time completed in 43 seconds, producing no warnings or errors.rustic -r. check
completed in 22 seconds, producing no warnings or errors.rustic -r. check --read-data
completed in 20 minutes, producing no warnings or errors.So it seems that I now have a best-effort recovered repository. Yay! As for the missing data, eh, I'm OK with that. This repository holds automated backups that are unlikely to actually be needed. Of course I want that data if I need it, but if some pieces of it have gaps, that's unlikely to ever matter in practice. I am satisfied with what I got back. In a case like mine, where some file data has been corrupted, I greatly appreciated Rustic's ability to create modified snapshots from whatever subset of files were still available and valid. Nicely done, Rustic! :+1:
I'll close this issue now, since the repository is now recovered to my satisfaction. Thanks you for the hints and help, @aawsome!
@liblit Thanks for your report! So, yes your packfiles are all corrupt - most likely truncated. To salvage at least some data from truncated pack files, we basically would have to go byte-per-byte through the data and check if the so-far read data is an correctly encrypted and MACed blob (data chunk) - if yes, it can be salvaged and saved to another pack file. But with a very high probability, some blobs are already lost forever.
Good if you can live with the modified snapshots - this is exactly, what the repair snapshots
command is for!
A Repository in Need of Repair
I have an existing Restic repository with some damage to repair. Log output from
rustic check
consists of:Index Repair Fails Immediately
Unfortunately,
rustic repair index
quickly fails, reportingError: failed to fill whole buffer
. The log output fromrustic repair index
is uninteresting:Snapshot Repair Does Not Persist
Perhaps I should be using
rustic repair snapshots
instead? That command appears to do much more work, according to the log output:However, any changes this command made do not seem to persist. Running the same
rustic repair snapshots
command again reports and repairs the same problems, no matter how many times I run it. Runningrustic check
again afterrepair snapshots
reports the same damage it found when I started.What Next?
What can I try next to recover and repair as much of this repository as possible?