[elgaton]

Hi all,
some days ago I ran diskpart clean on the wrong hard drive. Upon realizing what I had done, I immediately turned off the computer, so as to minimize the damage.

The partition map on my 250 GiB hard drive was as follows:

• Windows primary partition (filled the first portion of the hard disk)
• Linux partition with EXT4 filesystem (about 22 GiB)
• Linux swap partition (about 4 GiB)

Reading the technical documentation about the diskpart tool, I saw that the command I gave cleans only the partition table and the MBR, so I downloaded TestDisk 6.14-WIP, booted from a Linux Live CD and launched it. I needed to perform a deep search as the NTFS partition was not found with the simple one (it was found using the backup boot sector instead).
The tool finally found all the partitions, so I rewrote the partition table and restored the NTFS boot sector with the backup copy stored into the filesystem. I then rebooted and performed a read-only filesystem check on both partitions (using fsck.ext4 from a Linux Live CD for the Linux partition and chkdsk from a WinPE USB key for the Windows one).

While the EXT4 filesystem was clean and intact, the CHKDSK tool reported instead that there were errors in the MFT.

At this point, I imaged the NTFS partition, fearing that TestDisk had failed to recognize its start sector. The tool reported that the partition started at cylinder 0, head 1, sector 1, however I don't know if it's right given that:

• I had Adobe products installed and that they make use of the FlexNet protection, which writes to sector 32 of the HDD (it might have confused TestDisk);
• before writing the partition table, I checked the list of files in the NTFS partition, some were not listed and I attributed that to minor corruption.

Could anyone please suggest me what to do at this point? I don't know whether it would be safer to run CHKDSK, letting it fix the filesystem (but potentially causing data loss), or to manually inspect the first sectors of the HDD to check if the filesystems really starts on the first sector or not.

Thanks!

[jaclaz]

If the NTFS partition was originally made under XP/2003 (or earlier) and it was first partition, it's CHS address would have been 0/1/1, LBA 63.
If it was done under Vista or later, it's CHS address would 0/32/33, LBA 2048.
I cannot say whether diskpart clean would affect the hidden sectors (which include sector 32).
If - as I presume - you ran the diskpart clean from the BOOTED NT OS on first primary parttion, it is very likely that the $MFT corruption is:
a. "marginal"
b. "induced" by the effects of the diskpart clean command.

The good news are that there is no way on earth that TESTDISK may have found a "wrong" partition start.
The $MFT location is indexed in the bootsector as a relative offset to the volume start (LCN or Logical Cluster Number) so, if you had a "wrong" bootsector the $MFT would NOT have been found at all (i.e. you would see a RAW volume).
Compare with this thread:
http://www.msfn.org/...-after-bsy-fix/

The bad news are that in practice you have NO alternatives BUT running CHKDSK in "write" mode.

What I would personally do would be:

• image the disk "as is" with a dd-like or "forensic sound" tool <- you will need a disk bigger that the original, formatted as NTFS preferably
  
• run CHKDSK /F (on the original disk's NTFS volume)
  
• run CHKDSK /R (on the original disk's NTFS volume)
  
• verify that everything is OK (and nothing is "missing")
  
• if anything is missing, use DMDE on the image to attempt recovering the "missing"

Datarescuedd:
http://www.datarescu...cue/v3/drdd.htm
(under Linux you can use *any* dd-like program, BUT remember to also save the first 63 (hidden) sectors)

DMDE:
http://softdm.com/

jaclaz

[elgaton]

Thanks, I'll image the whole drive now (instead of just the first partition), then run CHKDSK; I'll tell you the results in two or three days (I'm a bit busy as exams are near).

[jaclaz]

OT, but not much there is something everyone should be aware of (when imaging NTFS volumes/partitions as oppsed to "whole disks").

The backup bootsector of a NTFS partition is by definition "first sector outside the filesystem indexed sectors" AND "last sector in partition space".

Not only it won't be backed up/saved when this is done by accessing the \\.\LogicalDriven (or the "drive letter") but ADDITIONALLY a number of sectors might be not present in the dd-like copy.

In practice there can be "orphan sectors" that are inside the filesystem sector count but outside the filesystem cluster count.

Since what is actually accessed are the clusters, many (almost *any*) program will skip these, with the result that the image will be a few (at the most <clustersize-1> sectors) smaller than the original, which is not normally a problem (as these sectors will anyway be 00's) but that can cause issues if you want to simply append to the image the backup bootsector (you need to insert the missing sectors).

See this for the (gory ) details:
http://reboot.pro/to...ated-with-dsfo/

jaclaz

[elgaton]

Hi jaclaz,
sorry if I did not reply before, due to my heavy workload I hadn't time to continue the recovery until these days.

I imaged the whole drive, then ran chkdsk - it worked perfectly, only two files (.NET Framework resources DLLs) were lost in the process, the rest stayed perfectly intact.

Thank you very much for giving me some advice and details about the inner workings of NTFS!

[jaclaz]

elgaton, on 03 March 2013 - 11:28 AM, said:

Hi jaclaz,
sorry if I did not reply before, due to my heavy workload I hadn't time to continue the recovery until these days.

I imaged the whole drive, then ran chkdsk - it worked perfectly, only two files (.NET Framework resources DLLs) were lost in the process, the rest stayed perfectly intact.

Thank you very much for giving me some advice and details about the inner workings of NTFS!

Good!
Yet another happy bunny in the basket :
http://www.msfn.org/...up/page__st__10

jaclaz