1

I have an SSD with damaged NTFS (probably due to the old age, although SMART doesn't mention "near failure" state anywhere and still gives it 31% or resource).

I was able to recover most of the stuff by cloning it (creating an image) under Linux and using testdisk.
Some files are missing though.
I can see them with ntfsls (ntfsprogs) but I can't print them out (file system errors).

ntfsprogs also refuse to do any fix and recovery routines it supposedly provide, tells the disk is marked for chkdsk and recommends to do that first.

Now, if I try to connect this disk to a Windows machine or boot into Windows recovery mode and open the command prompt from there - I can't get any access to this disk - diskpart and mountvol don't mention it.

Is there anything left to try?
Either to persuade Windows to recognize this disk or to use some 3rd party tool that can do chkdsk's job. Or maybe there is something else that can be done from Linux.

Killy.MXI
  • 141
  • 7
  • You don't want to be running any 'disk fixer' of any kind on a failing drive. You want to be copying off with dd & examining what manages to copy. The rest is now junk, or income for a data recovery company. The 'fix' for this is a reliable backup strategy… saves all this worry. – Tetsujin Dec 23 '20 at 18:15
  • Back in the day we used SpinRite https://www.grc.com/sr/spinrite.htm but I don't think that will work for SSDs. There are many recovery tools but they all require the drive to be seen by the OS. If the OS can't see the device you need to contact a professional data recovery specialist. – HackSlash Dec 23 '20 at 18:51
  • I had found this:https://superuser.com/questions/518634/running-chkdsk-on-a-disk-partition-without-a-drive-letter, try the second answer, run chkdsk with hardware ID, and it should do the trick. – Ξένη Γήινος Dec 26 '20 at 13:09
  • @xeнεi-Ξэnвϵς Nope, as I said, the disk is not present in `diskpart` and `mountvol` listings. Unsurprisingly, it also isn't mentioned in `diskmgmt.msc`. This means Windows gives up on it before Volume ID is assigned. – Killy.MXI Dec 26 '20 at 13:54
  • Then you are in a worse situation than I thought; Try hdwwiz.cpl and see if you can find your SSD, if you can find it, you should be able to find its hwid by yourself. – Ξένη Γήινος Dec 26 '20 at 14:51
  • @xeнεi-Ξэnвϵς, Device Manager wasn't useful in this case either. I've additionally checked whether I can find it with [USB Device Tree Viewer](https://www.uwe-sieber.de/usbtreeview_e.html) and [USBLogView](https://www.nirsoft.net/utils/usb_log_view.html), but nothing there either. I think I also tried to have the disk inside the SATA slot while booting to recovery from USB, in order to exclude the possibility it isn't detected only via USB. Anyway, it's solved now. I'm only curious whether this disk will become visible again after format, but that's besides the question. – Killy.MXI Dec 28 '20 at 13:57

1 Answers1

2

Solved it.
The key was to realize I don't have to run chkdsk on a physical disk.

1. Create a disk image under Linux

I did this already but mention it here for completeness.

Depending on the nature of the failure, simply dd might work, or ddrescue might be needed instead.

2. Convert raw image to VHD

This will allow to mount it under Windows.

Tools that can do this:

  • qemu-img;
  • VBoxManage from Oracle VirtualBox.

I'm using qemu-img for Windows with the following command:

.\qemu-img.exe convert -O vpc -p .\image.dd .\image.vhd

-O vpc sets the VHD output format. Use -O vhdx for VHDX.

-p prints the progress in %. Useful since it may take a while.

3. Mount image.vhd

This can be done via file context menu or diskmgmt.msc, "Action → Attach VHD" menu item.

NTFS partitions of the disk will get letters assigned.

4. Run chkdsk

Assuming V:\ is the volume we need to check:

chkdsk V: /X /R

chkdsk documentation.

This will take a lot of time.

5. Done

That's it. Checked volume is remounted automatically and can be accessed. I can see the files that testdisk didn't find.

In case the damaged disk was a system disk and now accessed from a different/new Windows installation, it might be difficult to access user files due to ownership/permissions. But that's a different story.

Killy.MXI
  • 141
  • 7