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
  • 139

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
  • 139