Hello, everyone. I've been lurking on these forums for a while now, and thanks to all of your expert advice that I've read in your answers to other people's questions, I've learned a lot about data recovery. I'm sure I still have a lot more to learn, though, so here's my first post and my first direct question to you all.

I have a 120GB SATA HDD (Seagate 3.5" ST3500418AS) that was used as a boot drive for a Windows XP system, and I am trying to retreive data from it. The NTFS filesystem is trashed, and the main partition will not successfully mount on a Windows or Linux system. There are bad sectors, and the drive is physically failing.

I used ddrescue on a Linux box to create an image of the main partition, and the operation was largely successful:
Rescued: 117259 MB
Errsize: 253kB
By my own math, that's 99.99999% of the total sectors successfully recovered, which I'm pretty happy about.

I made a copy of the image file that ddrescue created, and now I'm playing around with this "copy of a copy" just to be safe. Still, the image does not mount in Linux or in Windows. (On Windows, I'm using ImDisk Virtual Disk Driver for image file mounting, which works well on healthy images.)

I'd like to learn a little bit about data recovery best practices at this point, before I go any further. I've already grasped the concept that you should never try recovery tools other than "smart" imaging software directly on the failing drive, hence my use of ddrescue.

What's the best course of action from here? Here are my two ideas. I welcome your comments and advice on them:

POSSIBLE NEXT STEP #1: In Windows, run chkdsk on the copy of the image file. On the plus side, now that the failing drive is out of the way, I would expect that chkdsk would have a good shot at repairing the filesystem to the point that it would be mountable. If it succeeds, then a mounted filesystem would make the rest of the data recovery trivially easy. On the downside, my concern is that chkdsk is a filesystem repair utility, not a data recovery utility. I worry that it will do everything it can to repair the filesystem back to consistency, which could very well include "disposing" of some of the files that get in its way.

POSSIBLE NEXT STEP #2: Instead of going to chkdsk, jump straight to using a data recovery tool. I have an old copy of GetDataBack NTFS that I purchased ages ago, but it seems to still run under Windows 7 (as long as I force it to "Run as Administrator"). The pros of this approach are that the image itself will not be modified, although this is not a big deal because I will be working from a "copy of a copy" and could always go back to the original ddrescue image file if necessary. My concern with this approach is that it might miss a good chunk of the data in the image because GDB is bypassing the filesystem map and trying to guess about the filesystem itself. Maybe this concern is unwarranted, but I don't know enough about the inner workings of GDB to know for sure.

Which of these two approaches would you recommend next? Is there a third option that I should consider? (For example, I know about Photorec, but I'm guessing that it's a little too early in the process to jump straight to a file carving tool.)

Thanks so much for reading this, and I look forward to your responses. Of course, if I've left out some key details, please let me know, and I'll do my best to fill them in.

Basically all you have to do is this:

If you image your HDD and can not repair the partition table then you have few choices. one is to use Rstudio and do raw recovery or like you said use GDB and do raw recovery the program are designed to do what is necessary to find the data on the hdd that is not corrupted

Just image this HDD and run your recovery software

_________________
Iorana Haraharaini

Ven,

As the file system doesn't mount on its own, you are best to scan the image with a data recovery program. You can run GetDataBack or R-Studio and should be able to recover most of the data from the volume.

Good luck!

_________________
Luke
Recovery Force Data Recovery

For the sake of learning, I would say try both and make note of the differences. There may also be some simple problems, such as boot sector was unreadable but can be replaced by backup boot sector, etc. You can look more in-depth with WinHex or similar and try to see where the damage is; if WinHex is able to interpret the partition, try examining $MFT for bad sectors (does ddrescue fill unreadable sectors with a pattern?). With 506 unreadable sectors, your image shouldn't be TOO bad off, unless something else happened to the filesystem before you started imaging it.


Quite true. It will usually make an attempt to "recover", but in my experience this is rarely helpful.

_________________
You don't have to backup all of your files, just the ones you want to keep.

Or it can complicate things further (.chk files etc).

I agree with the above advices given, go ahead and scan your copy of the copy with R-Studio or GDB and check the files recovered.

By the way, the steps you took so far to recover your data are quite right.

_________________
http://www.northwind.gr
SandForce SSD Recovery
Ransomware Reverse Engineering - NoMoreRansom! partners

First of all a ST3500418AS ain't a 120 Gb drive.
So do a clone of all of your 500Gb drive, and then use R-Studio or Get Data Back to logically find your files!

Cheers
Bosse

_________________
Rescue IT Datarecovery service Sweden
Rescue IT Dataräddning Göteborg AB
http://www.rescue-it.se

It is possible that your drive has a translator problem (not the common translator problem that is on the internet) that ddrescue is unable to address. This would make sense explaining why the image is only 120GB in size.

Unless you mixed up models with another drive, your drive is a 500GB indeed.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

Nice catch, Bosse! Yes, a ST3500418AS is in fact a 500GB drive.

I got things mixed up as I was typing my post: the ST3500418AS is the good drive that I am using to store the image files and the recovered data! It just so happens that it is sitting right next to the other (troubled) drive on my desk, so I grabbed the model number off of the wrong drive when I went to create my post. The problematic drive in question is actually a Samsung 2.5" HM121HI, which is indeed a 120GB hard drive. Luckily for me, the problem is not a translator problem but a classic "user error", as Labtech hinted at.

Thanks to everyone who replied here with advice for me. I didn't get a chance to play with the drive image over the weekend, but I'm in the middle of running GetDataBack right now. I've taken the chkdsk option off of the table, since you all have confirmed my suspicion that it's not the right way to go. If I have time, I may investigate it later to compare the results, as Drc suggested.

I am comfortable using GetDataBack and have been satisfied with its results before. I have never used R-Studio. Can anyone recommend one over the other? Is there a compelling reason for me to try R-Studio if I already have GetDataBack?

Thanks to all of you for your invaluable advice.

I just wanted to follow up here and say that GetDataBack worked very well on my disk image file. As far as I can tell, I have recovered everything that actually mattered from the bad drive, and the files seem to have good data intact.

Thanks again to everyone for their advice.

I'm still curious if anyone thinks there's any reason for me to check out R-Studio in the future. I like GetDataBack and I find it very reliable. Does R-Studio have anything to offer above and beyond GDB, or is it pretty much the same?

When possible, it builds tree right away compared to GDB where scanning is necessary.

GDB can give better results in some cases.

It really depends on what you really need the tool to do for you.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts