Issue with recovery from formatted hard disk

There isn't AFAIK such a "neat" distinction (between files that were deleted before formatting and those that were not).

There are a number of factors involved, you provided NO meaningful info.

What filesystem(s) were used? (both before and for the new formatting)
Which OS was used for the formatting?
And which OS was used for the original formatting?
Is it (and was it also before) a single volume spanning the whole disk?

In any case, when you are at Data Recovery, the "rule of the thumb" is to throw at the disk every tool known to mankind (+1) as each tool may have a slightly different method/algorithm that may allow (or completely fail to) recover a given file (no matter if deleted or not prior to the new formatting).

Recommended tools
DMDE
http//dmde.com/

Photorec
http//www.cgsecurity.org/wiki/PhotoRec

If the filesystem was NTFS (Commercial)
http//www.quetek.com/

More
http//www.msfn.org/board/topic/84345-data-recovery-tool/

jaclaz

Thanks Jac

Sorry for providing less information.

It was a USB HD without OS and had NTFS partition in it.

When the owner attached it with his LED TV, it asked for format option and the drive get formatted.

I will use tools recommended by you to explore more.

Regards

It was a USB HD without OS and had NTFS partition in it.

When the owner attached it with his LED TV, it asked for format option and the drive get formatted.

These may actually be "good news", in the sense that I doubt that "a LED TV" (here again providing Make/model may give further hints) has the capability to format with NTFS 😯 and so it is likely that a part of the original filesystem structures (the $MFT and hopefully also the $bitmap) has not been overwritten.

jaclaz

Thanks Jac

"and so it is likely that a part of the original filesystem structures (the $MFT and hopefully also the $bitmap) has not been overwritten."

So, do you recommend a way of recovering data in other way then using any recovery tool?

Thanks Jac

"and so it is likely that a part of the original filesystem structures (the $MFT and hopefully also the $bitmap) has not been overwritten."

So, do you recommend a way of recovering data in other way then using any recovery tool?

Photorec (as well as many other "file oriented" recovery tools), just like foremost, try to "carve" the sectors to find "patterns" that they can recognize as a given file type, tools like DMDE are instead "filesystem" oriented, i.e. they try mainly to rebuild a filesystem structure.

The advantage of the first over the second type is that if a given file is contiguous and of a known format it can be recovered even if there are not anymore filesystem structures addressing it.

The advantage of the second over the first is that (IF there is "enough" previous filesystem elements) also non contiguous or partially corrupted files can be recovered, including their filenames (which are instead "lost" in a "pure file oriented" recovery).

The issue here seems to me slightly different.

No offence intended, mind you ) , but you are in a Catch22 situation.

If you are familiar with data recovery procedures, with filesystem structures and a number of specific related tools, then you would not ask for them, but if you are not familiar with them and you have to ask, you will need to get familiar with them to expect to succeed in their use.

I mean, these tools (particularly Photorec and File Scavenger) are "automated" as much as possible, but there is no actual way by passively using them to know if *something else* can be recovered, DMDE, on the other hand, while provides also a "simple" "virtual reconstruction" which is also automated, allows for using different manual recovery techniques.

If you prefer, you should evaluate (with the owner of the disk/files) what the actual value of the lost data is, and consider if it is so low that an attempt by a non-expert is the only option or if it is high enough to make the intervention of a professional advisable.

jaclaz

I agree that it is likely that the disk has been reformatted as a FAT32 device

The approach I would take would be to scan the disk for $MFT entries and hopefully find the first entry pointing to $MFT. With this information you can determine the logical start of the partition. Data recovery can then be used to recover the files logically. If lucky, the FAT32 will not have damaged much of the NTFS data.

Another technique I use is to scan the complete disk for $MFT entries. This can find runs of MFT that may otherwise be lost, but at times it can also find many false positives.

A final part can be data carving, but there are always limitations on fragmented files. You do not say if there is a particular type of file you want go recover (docx, jpegs, mp4 etc). Also, not many carving programs give useful names or dates - just a sequential number. For photos, the name is often not required.

I agree that it is likely that the disk has been reformatted as a FAT32 device

The approach I would take would be to scan the disk for $MFT entries and hopefully find the first entry pointing to $MFT. ….

Yes, and this is actually the approach DMDE takes.

But the issue is also with HOW EXACTLY the disk was partitioned/formatted before.

The "traditional" address for the start of the $MFT was LCN 786432 (thinking in hex 0x000C0000 wink ), which on a "common" 8 sectors aka 4 Kb cluster size is around 3Gb from the start. (3,221,245,472, to be exact)

A FAT32 for a 500 Gb disk would probably use 32 kb sized clusters, so roughly (without taking into account the reserved sectors, which however will be at the most 32 or 64, if I recall correctly)
500,000,000,000/32,768=15,258,789*2=30,517,578
there is no risk that the $MFT has been overwritten, nless besides th eformatting the stupid LCD TV wrote also some 3 Gb of data 😯 .

The problem is that lately I have seen quite a few NTFS filesystems with the $Boot (as always) on cluster 0 and the $MFT with really low addresses, I seem to remember even 2, 3 or 4 😯 .

Cannot say if this happens in some cases on newish Windows NT versions (after XP) or it is the effect of using some "third party" utilities.

Just for the record, I have somehow managed to replicate the behaviour (for special reasons, obtaining a large contiguous image on a small NTFS formatted USB stick)
http//reboot.pro/topic/18022-error-60-file-for-disk-emulation/
the interesting part is that diskpart does not move the $MFT location when enlarging a volume.

jaclaz

P.S. added the part in red, that *somehow* remained in my fingers when typing oops

[quote="jaclaz
The "traditional" address for the start of the $MFT was LCN 786432 (thinking in hex 0x000C0000 wink ), which on a "common" 8 Kb cluster size is around 3Gb from the start. (3,221,245,472, to be exact)

Typical cluster is normally 8 sectors, 4K or 0x1000

Typical $MFT start is therefore sector 0x600000 + partition start. ie 0x60003f or 0x600800

I find remembering 6, three zeros plus 3F much easier than 6291519.. Partition start of 0x3F was typical XP, and 0x800 for Vista/7/8. Other values are also used.

Typo, corrected (the math is OK).
Of course the start is given with reference to the start of the volume, and for this kind of rough calculation 63 or 2048 sectors before don't make a difference.

jaclaz