Need advice recovering deleted partition on failing drive
 

Hey all,

I am helping a friend recover data off of her dying Mac drive, and things have gone sort of haywire. I first checked her HFS+ drive in Linux Mint, and the Disk Utility has confirmed that the drive has bad sectors, hence why recovering it using the Mac Finder won't help. The Finder errors out at the first sign of I/O, and with a lot of data to recover, it would be very tedious to begin a transfer after hitting a bad file.

I tried using a Live Linux CD on a Windows machine, and hooked up the problem drive to it via USB. I began to run the ddrescue program, so that I could copy the files from the drive to the Windows machine. Unfortunately, since I'm not very good in the command line, I accidentally reversed the locations, so the ddrescue began to copy the Windows machine to the Mac drive!

Thus, I'm at a loss. The drive will still mount, and I can access it, but now the Mac partition is gone, and I'm worse for the wear.

Should I try to use ddrescue on the drive again, copying everything to an empty drive, and then attempt to recover the deleted Mac partition that way? Or is there a good partition recovery utility that I should use to recover the partition first, and then pull off the data?

I'm open to any kind of suggestions!

try once using tiny core linux live cd. once check with that as it can mount any type of partitions. it may be helpful to you.

Thanks for both of your helpful replies! However, the situation is not that simple. When I overwrote the partition on the Mac drive using ddrescue, I copied data from a Windows drive that was larger than the Mac drive. This has lead to several issues:

1.)The partition size doesn't match, as the Windows drive had a 320GB partition, and the Mac is only 160GB in size.

2.) The Windows partition is formatted NTFS, with a MBR partition scheme. This overwrites the Mac's HFS+ and GPT setup.

3.) When I try to run a data rescue program, such as TestDisk, I get the error that the partition is too large! It also makes the drive unmountable in both Windows and Mac OS X.

I can try Macintosh Data Recovery, but I believe that is for HFS+ formatted drives, which won't work, since the partition was partly overwritten using ddrescue.

While I would just ignore TestDisk's "partition is too large" message and brute force a search anyway chances are slim you will be able to recover meta data let alone actual (and coherent, usable) data. You see, when you overwrote the disk completely like you did you overwrote the GPT, file system meta data (HFS boot blocks, volume header, allocation and catalog files, etc, etc) and file system contents. And using ddrescue (or dd, dd_rescue, dcfldd or linen for that matter) by default doesn't do sparse copying of data but the dependable, trustworthy bit-for-bit type of copying. Should file system contents be thought invaluable then your only chance is a professional recovery service. I doubt however they would even given you a guesstimate if, let alone what coherent and usable, data they may be able to recover.


//Unfortunately davegeeit was an account solely used for spamming LQ. It's a %deities-darn shame so-called recovery software help posters prey on victims of hard disk trouble.

Thanks for your comprehensive reply, unSpawn! Yeah, I figured that it was a scam, because after I checked out the program he mentioned, my Web of Trust addon started giving off alarms about how the site wasn't trustworthy.

Also thank you for explaining the specifics with the hard drive: I don't know much about hard drive erasure and recovery, so it's nice to get help from someone who knows more than I do. I was hoping there would be data, because I didn't do a complete overwrite with ddrescue, I started and then stopped after I realized my mistake. Since it's only done a partial transfer, do you think it may be possible for me to pull off some of the data with ddrescue, and then use a deleted file program like testdisk to bring it back? I know my chances are slim, but as I didn't let ddrescue complete the operation, maybe there is just a drop of data left.

If you did only a partial overwrite Photorec (which is a part of the testdisk package) may be able to recover some data from the disk.

While I can't hold it against you, obviously somebody should have asked you questions first, you've posted valuable information but spread out over three posts. For next time please try to give an as accurate and complete account of things in your OP, it's just more efficient that way.


Sure is but to what extent it's recoverable, valuable, usable remains to be seen. For next time also make it a Standard Operating Procedure to always make a copy of the disk to file before doing anything else. In some cases you might get only one chance at powering up a disk to get data off, keeping a backup ensures you have a copy you can work on safely and you don't need to keep the original "victim" disk powered up (which can downgrade performance considerably wrt device errors). If you don't have a spare partition on your 320GB disk then use another disk, or buy one, they're cheap (plus you owe her that much for fscking up IMHO). Since the disk has errors at the start I suggest you use (a Live CD that contains) dd_rescue because it can image a drive back-to-front. The invocation should be something like this:
where:
"-l /path/to/logfile" is a path and (nonexistent) file name of the log file,
"-o /path/to/badblockfile" is a path and another (nonexistent) file name to store bad block locations in,
"/dev/victimdevice_fulldevicename" is the existing full device name of the victim drive (as in "/dev/hde" or "/dev/sdc"),
"/path/mountpoint/filename" is a path and (nonexistent) file name of where the image will be written to, and
"/path/to/teefile" is a path and (nonexistent) file name of the log file that 'tee' will write stdout and stderr to.
If you (can) have multiple physical destination disks (masters, not slaves) then I suggest writing "/path/mountpoint/filename" to file on one disks partition and the logs to another. If you don't then you could opt for writing the logs to a mounted USB stick or to the Live CD you run and copy them over later but remember it holds a risk wrt free space (RAM).

Do read the manual page to check suggested invocation and do ask before invocation if you have any questions.


Once you have the disk image (which tools like testdisk and photorec can work on) I suggest you first run (a Live CD that contains) md5deep on your 320GB disk. If you have an approximate idea of transfer rates and duration of the ddrescue overwrite you don't have to hash the whole disk but the size of the checked area should exceed the size of the overwritten part to be sure. Then verify saved hashes against the victim disks image. This lets you find out how much data was overwritten and could help decide adapt recovery strategy.
Invocation should be like:
where:
you know block size (or use blocksize.c),
"/dev/320GB" is the full device name of your Windows drive (as in "/dev/hda" or "/dev/sda"), and
"/path/to/log.md5" is a path and (nonexistent) file name of the file to write the piece-wise hashes to.

The invocation for checking then should be:
"/path/mountpoint/filename" is the path and existing file name of the previously image, and
"/path/to/md5.result" the file to write the result of the check to.

HTH

(solved!)
 

Great news everybody! This hard drive tale of woe has a happy ending after all!

I had run a scan on the bad drive with Data Rescue 3, before I had tried using ddrescue. Miraculously, when I reattached the now partially overwritten drive to my Mac, I opened DR3 and checked my saved scans. It still had the saved scan of the bad drive, including the original folder hierarchy and partition layout. As a result, I was able to recover the files from the drive using this saved search with DR3, and the files still worked (mostly).

Now it did take a long time to copy everything, because of course due to the damaged nature of the drive, some of the files literally took hours to pull off, with one directory taking over two days! But I had the Mac run nonstop, and I ordered DR3 to ignore any read delays it encountered while reading from the dying drive.

Naturally, it was a risky proposition, as all that reading could have killed the drive, and ignoring read errors can damage files further, but I didn't really have any other option at that point. Fortunately, nearly all of my friend's files were recovered, and the ones that were not were replaceable. Some of the files were naturally corrupted, but at least my friend now has a working list of what was damaged, so she can go about replacing the files with better copies. For example, part of her iPhoto library was toast. However, she still had most of the pictures on her camera's SD card, so she was able to check the photo's names against the pictures on the card, and copy over the ones that couldn't be opened from the bad drive.

It took probably almost a week to recover the drive, which had about 120GB of personal data on it, including pictures, documents, music, and more. I'm really pleased that DR3 was able to pull through in this situation, and the fact that it was able to recover most of the data from a drive that was not only damaged, but also partially overwritten with ddrescue, and recovered using an older, saved scan really says a lot about this app. It may not be the best option to recover data from a bad drive, but in my case - and fortunately for my friend - it really saved the day.

With regard to your admonishment unSpawn, I did not attempt to "spread out" my information across three posts. I'm sorry that it turned out that way, as I was simply adding more information as I was questioned about the situation, rather than outlining every detail in the OP, which would have been much more effective.

I do really appreciate your complete write-up of a comprehensive command-line approach to rescuing the data from a bad drive. Thanks to you, I know now more about using ddrescue then when I first started this project, so it will be a valuable resource for me if and when I am faced with a similar situation next time. I'd also never heard of md5deep, but it looks like an incredibly useful command as well One thing I'd like to note is that cloning my drive wasn't an option right away, for a couple of reasons:

1.) I didn't know about using ddrescue at the time, and I hadn't installed it on the Mac I was using to troubleshoot my friend's drive. Even if I had, I still might have messed it up like I did when I tried to use it.

2.) I tried using Carbon Copy Cloner, but since the app is useless when it comes to damaged drives, it couldn't help me clone the drive. As soon as the app encountered read errors from the bad drive, it immediately stopped the clone process, and there was no way to force it to continue.

So while I agree with you one hundred percent about the idea of cloning a drive that is dying unSpawn, in my case I simply hadn't known enough about cloning, and didn't have the right tools to do it properly. But as you said, it is an excellent learning opportunity, and I won't make the same mistake next time.

Thanks again for everyone's help, and I'm marking this thread as solved!

Nice that you were able to solve the problem. Some recommendations for the future:
- Now would be the perfect time to go and setup a good backup plan with your friend.
- Try and learn more of data recovering before the next event occurs, don't take what you have learned now and wait for the next problem.
- Next time when a problem occurs and you are inexperienced in solving that kind of problem, ask first, double check anything and only then take any actions. Especially when valuable and irreplaceable data is involved.