ntfs - Any way to recover a file with bad blocks (CRC error in Windows)?
2014-04
Camilo Martin
What I see is this:
- Windows complains when reading a file because the CRC for it mis-matches its calculated CRC.
- This means NTFS has a CRC for the file.
- I expect the offending block/sector can be known, or at least guessed.
- I also expect that "wrong data" can be read from the disk.
- If the bits of "wrong data" were inverted one by one, by brute force we could find the correct data.
- A file could thus be recovered using statistics and brute-forcing bits to match the CRC.
My question is, does any software do this kind of thing? Any way I could do it (I'd be happy enough to get the CRC, the drive's "wrong" data, know which is the offending block/sector there, and write a script to brute it myself, if relevant directions are given).
By the way, this is a mechanical HDD.
Edit: After taking a look with hex editors and such, I noticed that a bad block appears as garbage, such as filled with zeros or a copy of the last block (this seems to depend on the program), so in order to get the "real data" that is corrupted, we'd have to disable some hardware-correction that refuses to read a block which is bad. I believe this is called ECC. Also, I expect that if just a few bits are marking a block as "bad", then some 32-bit checksum from Windows could be used to brute force a match.
So this question may be answered simply with guidance to do this by myself.
Camilo Martin
Unfortunately, what I wanted to do is not possible (NTFS does not store a CRC, the hard drive does).
However, I recommend SpinRite, as it is in the process of recovering a hard drive (with a painfully slow speed of some GBs per day, occasionaly I mount the filesystem to see how's the state of the files).
It may or may not work for you, so if the data is worth a few thousand dollars, go to a specialized hard drive recovery place. It's terribly costly but sometimes experts get data out of unlikely situations.
Oh, and one last recommendation: if the data is worth a few thousands, DON'T touch the drive. Don't mount it anymore, don't dare to boot from it, don't run chkdsk, don't do ANYTHING. It might compromise the drive's chance to being recovered.
But if it's a drive with songs, movies, or other non-important content, don't miss the chance to play with it to your heart's content! :)
Macbook-Recovery
The hard drive in my Macbook recently gave up while using it on the plane (dual prop, lots of vibration unfortunately). I have a backup of its contents from a few weeks ago, but there are files that aren't included in it that I would like to recover.
As it stands right now, I have it plugged to my macbook by USB. Snow leopard recognizes it, but can't mount it. Therefore, tools like Diskwarrior and Techtools do not work. I started doing a clone of it with Data Rescue 3, but after 7 hours of activity (20% through the drive), it has copied 130 GB of the drive but reports all of the data as "bad blocks". My question is this:
- Is any data recoverable if the clone is completely composed of bad blocks?
slhck
One possibility (a bit similar to @KCotreau's suggestion) is to use ddrescue to clone it to either another drive (at least as large as the original) or to a disk image file.
What ddrescue does is to copy the contents of the drive, skipping over any sections that don't read successfully; then it goes back and retries the sections that got errors on the first pass. The longer you leave it running, the more data you'll get (unless the disk is completely unreadable).
You can even let it run for a while, then mount the recovered volume (it must be read-only -- if it's an image file, just lock the file before mounting it) and see if your files are there. If not, dismount it, unlock, and rerun ddrescue to see if it can get any more. You could also run filesystem repair tools on the recovered disk/image, but if you run anything that modifies the volume (at all), you will not be able to continue the recovery (you'd have to restart from the beginning).
Using it will be a bit unintuitive on OS X, since it wants to work with the unix-level device file, not a mounted volume. There's a procedure on tinyapps.org for how to use it to recover a Mac's internal drive; in your situation you'd just skip step 1 and use USB instead of FireWire in step 4.
There is ddrescue as a compiled binary for OS X on TinyApps. The important thing is that their download links require an account/password. The account is the first line of text in their logo (case matters!) and the password is the second line of text in their logo (see the TinyApps.org FAQ for an explanation).
The TinyApps.org Instructions on using ddrescue
(Note: this is a mostly-copy of my answer to this earlier question.)
KCotreau
First, if is highly unlikely that the drive is "completely composed of bad blocks", but if it is, your chances would not be very good.
The reality is that your data may not, and very likely, is not necessarily in the area of the bad blocks base on the laws of probability. If you can finish the clone of the drive, you have a decent shot at getting the data back.
I am not a MAC guy, so I do not know that software Data Rescue 3, but I know that with software like Ghost 2003, you could use switches that would allow it to ignore bad blocks and continue on. Finding such options with your current software, since we know it works with MACs, would be my first choice. If your software does have such an option, you might want to try it since it could take forever to go through those bad blocks.
I suspect that even though it is PC software, that if you could get a copy of Ghost 2003, and run it with the following switches, you might salvage your drive: ghost -ia -fro (the I believe this will work is that it is just copying the disk sector-by-sector with the -ia switch, and the -fro switch tells it to ignore the bad block errors).
You may need other switches if trying to clone to an external drive: http://www.symantec.com/business/support/index?page=content&id=TECH130961&key=52023&actp=LIST
Seno
The answer is obviously, no. Unfortunatly, if data are not backed up correctly, it is not possible to restore sucessfully.