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?

David Sevilla
  • 303
  • 2
  • 9
  • 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 05: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
  • Try something like `dd if=image_file_or_device bs=512 count=1 skip=position_in_bytes | hexdump -C` to check for contents of (bad) blocks, position in decimal. It's entirely possible a block with inodes is damaged, possibly resulting in *block not found* for `icheck`. One need to read up on the exact layout of the filesystem, and compare with the bad sectors. – dirkt Apr 29 '17 at 06:32
  • I did `hexdump -v` to one of the files and indeed there are large chunks of zeros. So those three files are damaged for sure. Next I will try to find out about the damaged inode block thing. – David Sevilla Apr 29 '17 at 09:09
  • I found this: http://unix.stackexchange.com/questions/176988/can-i-find-out-if-a-given-ext4-block-is-in-the-inode-table-and-if-so-can-i-pic but I don't understand much of it yet. Unfortunately it's time to move on (the computer has been on hold for more than a week), so I am going to reformat the new disk and reinstall Mint because I don't want the risk to have future surprises due to unknown corrupt files or missing blocks of inode information. I will keep the old disk around for future tinkering (but I don't know when) or until I figure out some use for it. – David Sevilla Apr 30 '17 at 08:24

0 Answers0