Need help with Recuva on corrupt unmountable NFTS

[1eax]

Last week, I had a 120GB internal slave single partition HD die on me. Windows and OSX say that the NFTS file system is corrupt or unreadable. I used Test Disk on Windows and Salvage on OSX and have determined that all of the old files/directories are supposedly intact, but the file system is busted and preventing me from mounting the drive.

 

I downloaded Recuva a couple day ago and first tested it on an older corrupt drive and able to recover things. I definitely liked Tree Mode where I can use the existing directory tree to recover files.

 

However, Recuva cannot mount the 120 GB drive so I can't do anything in Windows to try and recover files. Is there a way within Recuva to rebuild or restore the NFTS file system so that I can use Tree Mode in Recuva to recover?

 

The other thing I've read, but I'm thinking I might have gotten this wrong, is that I can set up a separate HD that's equal or larger than 120GB that I can set up a NFTS partition and then it's just a case of copying data on every cluster directly to the new drive. Is that an oversimplification of the recovery process?

 

I like how well Recuva works, so any method that I can use Recuva's simplicity would be preferred.

 

Thanks!

[Augeas]

The usual advice with a corrupted file system is to select the Recuva option of Scan for Non-Deleted Files. However if you can't see the disk in Recuva then that's not a lot of help.

 

I don't know what you would use to copy data to a new disk at cluster level. Considering that there are 25,000,000 4k clusters in 100 gb then this must go in the category of thankless tasks.

 

I don't know if there's any mileage in formatting the disk. This does not overwrite the old data, apart from the system files. You then should be able to see the disk in Recuva and run with both Deep Scan and Scan for non-deleted file selected. You really need a second opinion before dashing away to do this.

[redhawk]

Have you tried running: chkdsk.exe /f /r d: (assuming d: is the problem drive)??

 

Richard S.

[Aethec]

Have you tried running: chkdsk.exe /f /r d: (assuming d: is the problem drive)??

 

Richard S.

 

The /F parameter is not needed if /R is specified

[1eax]

Have you tried running: chkdsk.exe /f /r d: (assuming d: is the problem drive)??

 

Richard S.

 

Does running chkdsk on the HD end up writing to the disk though?

 

Right now, there haven't been any new data written to the drive, which is why I've been able to recover files through Test Disk & PhotoRec. Like I said before, the bad part is that both programs doesn't keep the original file names or the old directory system.