Date rescue
November 9, 2012 2:41 AM Subscribe
A friend of mine gave me a damaged portable hard drive to see if I can rescue some of his data. It has a SATA connector and it gets recognized by the BIOS, although it tells me that the SMART readings are bad. I can't access it under Windows but I booted to a Linux image and I could mount the drive and look at the contents. The Files are still there but they are all the same size, 4kb. I don't know anything about data rescue so I didn't want to experiment too much as not to damage the drive further. I downloaded some Linux Boot images, Knoppix, SystemRescueCD and UltimateBootCD, which all have various tools for hard drive diagnostic and repairs. Now what would you suggest to try first?
The longer a bad drive is running, the more likely you are to lose the data on it, as the data loss may be due to damage to the platter from contaminants that have got into the drive enclosure.
If I had the space, I would use dd_rescue to copy a raw image of the drive to a known good HD and then I would make a copy of *that* and start futzing around with it with loopback file mounts (which make the copy of the disk image look like a mountable disc to the system).
The reason for using dd_rescue is that it will (eventually) skip over unreadable bits of the drive and copy the rest, whereas ordinary dd will abort the transfer if it hits an unreadable sector on the broken drive.
posted by pharm at 2:55 AM on November 9, 2012 [4 favorites]
If I had the space, I would use dd_rescue to copy a raw image of the drive to a known good HD and then I would make a copy of *that* and start futzing around with it with loopback file mounts (which make the copy of the disk image look like a mountable disc to the system).
The reason for using dd_rescue is that it will (eventually) skip over unreadable bits of the drive and copy the rest, whereas ordinary dd will abort the transfer if it hits an unreadable sector on the broken drive.
posted by pharm at 2:55 AM on November 9, 2012 [4 favorites]
Response by poster: So I will use
dd_rescue /dev/sda1 /dev/sda2/backup.img
to copy all of the data to a new drive (and copy it again). And then I mount this image with daemon tools in Windows and try to repair the probably damaged partition table? Would daemon tools mount a image with a damaged partition table?
I am not familiar with Linux so I would rather try to deal with the problem in Windows.
posted by SweetLiesOfBokonon at 3:39 AM on November 9, 2012
dd_rescue /dev/sda1 /dev/sda2/backup.img
to copy all of the data to a new drive (and copy it again). And then I mount this image with daemon tools in Windows and try to repair the probably damaged partition table? Would daemon tools mount a image with a damaged partition table?
I am not familiar with Linux so I would rather try to deal with the problem in Windows.
posted by SweetLiesOfBokonon at 3:39 AM on November 9, 2012
minor point: /dev/sda2/backup.img isn't valid; /dev/sda2 is a partition and not a mounted filesystem. You'll want something like /media/mount_point/backup.img. You can use the df command to show where devices are mounted.
posted by qxntpqbbbqxl at 5:37 AM on November 9, 2012
posted by qxntpqbbbqxl at 5:37 AM on November 9, 2012
pharm is right, this is the way to do data recovery. It is disk-space intensive, but allows you to experiment with different methods of recovery without damaging the original source.
qxntpqbbbqxl is also right- ddrescue, like its predecessor dd, copies raw blocks. You are copying from a raw device to a file (which you'd then mount as a loopback device). So you need to put that file on a filesystem. You should also probably copy the whole drive rather than just the partition(s). You can then split the image file into partitions if you like, but you'll have the whole image if you need it.
So on a normal machine, it would look more like this:
Where /dev/sdb is the bad drive, and /path/to/backup.img is the path to the directory on a mounted harddrive where you want the image to go.
If all the files are showing as 4k, the file allocation table is probably messed up. As it stands, files that are < 4k will be easily recoverable. Files greater than 4k are likely missing the data > 4k. It depends on the filesystem, but what is likely missing is the data that tells the OS where the subsequent fragments of the files are at.
There is a recovery tool that might work called testdisk. It is not intuitive, but works pretty well.
posted by gjc at 6:27 AM on November 9, 2012
qxntpqbbbqxl is also right- ddrescue, like its predecessor dd, copies raw blocks. You are copying from a raw device to a file (which you'd then mount as a loopback device). So you need to put that file on a filesystem. You should also probably copy the whole drive rather than just the partition(s). You can then split the image file into partitions if you like, but you'll have the whole image if you need it.
So on a normal machine, it would look more like this:
ddrescue /dev/sdb /path/to/backup.imgWhere /dev/sdb is the bad drive, and /path/to/backup.img is the path to the directory on a mounted harddrive where you want the image to go.
If all the files are showing as 4k, the file allocation table is probably messed up. As it stands, files that are < 4k will be easily recoverable. Files greater than 4k are likely missing the data > 4k. It depends on the filesystem, but what is likely missing is the data that tells the OS where the subsequent fragments of the files are at.
There is a recovery tool that might work called testdisk. It is not intuitive, but works pretty well.
posted by gjc at 6:27 AM on November 9, 2012
It's normal for directories to show up as occupying 4K, by the way.
posted by flabdablet at 7:05 AM on November 9, 2012
posted by flabdablet at 7:05 AM on November 9, 2012
And yes, it absolutely is best practice to image your failing disk and run recovery tools against the image. If you have a spare drive at least as big as the dying one lying around, it's easiest to ddrescue straight from the damaged drive to a whole spare, like this:
Being a block-for-block whole-disk copy, the clone will end up with the same partitioning as the source if the blocks holding the partition table are still accessible.
Newer versions of GNU ddrescue require --force before they will overwrite an existing destination file or device, and support --direct so that the original drive gets read without using the kernel's block device cache; this decreases the amount of lost data, which can then occur in chunks as small as the source device's physical sector size (usually 512 bytes) rather than the block cache's cluster size (4KiB). Adding a log file name at the end lets ddrescue keep track of what it's done, and pick up where it left off if you need to interrupt it (which you can do with ctrl-C).
Whole-disk rescue images are usable with any general-purpose damaged-data recovery tool under any OS. If there's too much missing for Windows's inbuilt chkdsk to deal with, I've had quite good results with ZAR.
posted by flabdablet at 7:18 AM on November 9, 2012 [1 favorite]
ddrescue --force --direct /dev/sda /dev/sdb sda.log
Being a block-for-block whole-disk copy, the clone will end up with the same partitioning as the source if the blocks holding the partition table are still accessible.
Newer versions of GNU ddrescue require --force before they will overwrite an existing destination file or device, and support --direct so that the original drive gets read without using the kernel's block device cache; this decreases the amount of lost data, which can then occur in chunks as small as the source device's physical sector size (usually 512 bytes) rather than the block cache's cluster size (4KiB). Adding a log file name at the end lets ddrescue keep track of what it's done, and pick up where it left off if you need to interrupt it (which you can do with ctrl-C).
Whole-disk rescue images are usable with any general-purpose damaged-data recovery tool under any OS. If there's too much missing for Windows's inbuilt chkdsk to deal with, I've had quite good results with ZAR.
posted by flabdablet at 7:18 AM on November 9, 2012 [1 favorite]
One other thing: if you are going to give chkdsk a whirl, make another clone of your recovered image to do that with. Chkdsk is an in-place filesystem repair tool, not a data recovery tool per se; the filesystem will be stable and suitable for further use after it's done its work, but you might well be missing a whole lot more data than you would had you started off with a proper read-only recovery tool like ZAR.
posted by flabdablet at 7:27 AM on November 9, 2012
posted by flabdablet at 7:27 AM on November 9, 2012
« Older Send resume, cover letter, and salary requirements... | Can making a tiered tipping system ever be ethical... Newer »
This thread is closed to new comments.
posted by humboldt32 at 2:44 AM on November 9, 2012