Recover NTFS filesystem after DISKPART CLEAN

data-recoverydiskpartfilesystemsntfs

I managed to run the CLEAN command in DISKPART on the wrong disk (disk 1 instead of disk 3 in LIST DISK). Now it shows up as a "Healthy (Primary Partition)". If I assign a drive letter to the partition Windows just tells me its not formatted.

I'm guessing the damage is not too great. I could use R-Studio to recover the MFT-tables and get some files out. But its not optimal, will produce some false data and will take a long time. I'd like to just recover the drive and get on with my day.

Anyone have a clue how? Can I copy some initial bytes from a working NTFS-partiton? For example using dd if=/dev/hda1 of=/dev/hda2 bs=512 count=1 in Linux.

Exactly what did CLEANdo to my partition? I know disk layouts/NTFS very well so more details = good. I don't mind HEX-editing the bootsector.

EDIT:

My disk has MBR.

From http://technet.microsoft.com/en-us/library/cc766465(WS.10).aspx :
Removes any and all partition or volume formatting from the disk with focus. On master boot record (MBR) disks, only the MBR partitioning information and hidden sector information are overwritten. On GUID partition table (GPT) disks, the GPT partitioning information, including the Protective MBR, is overwritten; there is no hidden sector information.

Best Answer

I rebooted and reinstalled the operating system. Drive came back.

This was probably not related to the reinstall. Since only the MBR was cleared on a non-boot-disk I guess the damage was nothing. Windows just needed to re-read the information on disk.

Related Solutions

Bad sectors, S.M.A.R.T., SpinRite, firmware on platter and drive id questions

Smart records a large number of values on the disk. For each value there is a limit before errors are reported. If you are getting smart errors your disk is most likely in a bad shape, but smart is not guaranteed to give a warning. Some types of abuse (starting and shutting down the disk very often) can give early smart errors.
I don't know what interface SpinRite uses against the disk. There are on some disks a factory interface used when producing the disks, but I don't think the disks exposes this without special hardware. Otherwise it can only read/write the standard drive parameters, and not easily access blocks marked as bad by the firmware.
No disk (after IDE) stores the whole firmware on platter. Because it needs a firmware to read the platter. Disks before IDE/SCSI some times did not have firmware. I see no reason to store firmware on platter.
The information about the disk geometry and such is stored in firmware on chip. Failure to report it can be a sign of a dead disk, but also communication problems with the disk (for example a master/slave conflict).

If the disk can't report geometry you will usually not be able to read it anyway. In those cases I typically recommend restoring from backup... Because you do have backup, right?

MDADM RAID 5 data recovery

i had a similar case and i just used the command with exact the same parameter i used to create the raid with the --assume-clean parameter and this worked for me

the disk order is vital, if your drive letters (sd[a-l]) get messed up e.g. my unpluggin and repluggin in different order you can use

mdadm -E /dev/sd[a-l]1

to examine the the "RaidDevice" number. this tells you the order in which to specify the disks when invoking mdadm -C ...

Related Topic