2

I am in the middle of a failing drive data recovery process (see How can I find out which files are lost through a ddrescue recovery atempt?). I must say that I have no experience with disk management at this level. Following the accepted answer there, I have done this:

  1. Made a copy of the failing disk with ddrescue and processed the mapfile to use with testb in debugfs. I counted 248 block checks.
  2. Upon running all those testb commands I found that 236 were "not in use" and 12 "marked in use". This was the first surprising result, since the disk was almost full.
  3. I did icheck on those 12 blocks and found, to my greater surprise, that 8 of them gave a "block not found" output. I haven't been able to find out what this means, since people mention reading errors and whatnot, but I am doing all this on the new disk.
  4. Of the remaining 4 blocks, I obtained the inodes and with ncheck found the 3 supposedly corrupted files (two files were the same because two bad used blocks had the same inode).

Assuming that my code and calculations are correct (you can find the data and Python code in https://filebin.ca/3KZLnN60uZrl/rescue2.7z if you are curious), is the final result of 3 corrupted files correct? Or at some step things don't mean what I thought and there may be other files that I can only locate with a different procedure?

  • Was this on the data where you already ran e2fsck? If yes, and if a block with metadata was corrupted and corrected, something like this may happen. Use hexdump to make sure you have the right address for the bad blocks (assuming ddrescue fills bad blocks with zeros), and read up on the filesystem layout to get an idea which parts were damaged. Also, you can try to ddrescue just the partition, to avoid the partition offset problem. – dirkt Apr 28 '17 at 5:37
  • 1
    Yes, I did e2fsck before. The output of that (see previous linked question) indicated that something happened to 9 blocks, that I could also try to check. Another idea I had now is to try the whole debugfs thing on the old disk, I will report on the two things in a couple of days. – David Sevilla Apr 28 '17 at 10:01
  • I tried hexdump on one of the files. I assumed there would be 512 bytes or 256 times 0000 in hex; but when I did grep "0000 0000 0000" to the output of hexdump I only found a few lines, far from such a long chain. – David Sevilla Apr 28 '17 at 17:09
  • On the other hand, I did the whole procedure of testnb+icheck+ncheck with the old disk, and although most of those blocks were now "marked in use", I got exactly the same "block not found" ones with icheck, so exactly the same three files as before. I doubt they are very wrong; when the disk started acting weird I run a few GParted checks and one of the files that was problematic is in my list of three. – David Sevilla Apr 28 '17 at 17:10
  • 1
    Please note that hexdump by default "compresses" identical lines by showing only an excerpt. If you grep, be careful on what you are filtering. :) – Andrea Lazzarotto Apr 28 '17 at 22:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.