Can the $BadClus file hold recoverable data?

Question

I have an external hard drive that a family member dropped but however still functions perfectly other than the drive is not partitioned; the drive doesn't even click in the way a normal damaged hard drive does!

I cracked the case open and popped the drive into my computer, and ran a scan on it with Recuva (of which I've used before to recover data, so I know I can trust it).

The scan results are below:

The one file that stood out was $BadClus, with its file size equal to the exact size of the drive (1.81TB!).

While I've resumed the (Deep) scan for the missing files, it has not gone beyond 0% and 13 files (the files displayed) although it has been two hours now. I acknowledge that the capacity of this drive is large, but however is this behaviour normal for a drive of this capacity with a deep scan (two hours at 0% and not finding any additional files)?

I've searched up on the $BadClus file but haven't found anything other than it lists the bad clusters of the hard drive, but apparently it can contain files.

Is it correct that $BadClus can contain 'lost' files? If so, how can I recover these files?

Solution

$BadClus is a list of the sections of the drive has been marked as a bad cluster. If it were truly a bad cluster the internal instructions in the drive's firmware will automatically attempt to move the data to a reserved portion of the drive if it can. One or two bad clusters on a drive is no big deal and can be expected as the drive ages. However if the amount of bad clusters on a drive greatly increases over a short amount of time then the drive could be considered as a preemptive failure.

In order to find out if the drive had bad clusters, you would need to run a low level diagnostic on the drive. Most drive manufacturers provide that free of charge. Do note that a low level diagnostic is usually destructive to data on the disk.

If you wanted to see if it could be fixed you could try running chkdsk /b on the drive. In order to reset the $BadClus file so that the filesystem will attempt to use those clusters you would have to reformat the drive.

Comments

[AStopher]

Does the 1.81TB $BadClus file indicate that all sectors on the drive have been marked as 'bad'? If so, is there any chance of recovering the data that was lost in this case?

[psusi]

No; the drive's firmware attempts to reallocate bad sectors from the spare pool when you write to them. The $BadClus file simply prevents the filesystem from ever trying to use those sectors because chkdsk found they could not be read. If it has been added to the bad cluster file then it won't be used again, so the drive won't ever remap it.

[вʀaᴎᴅᴏƞ вєнᴎєƞ]

@psusi updated the answer to add clarification.

[AStopher]

Is it normal that the $BadClus file is the size of the drive's capacity?

[psusi]

Still not quite right... again, the drive can't try to relocate it if it is flagged in the bad cluster file. Also chkdsk /f doesn't look for bad clusters. You need /r for that, and /b to recheck clusters already in the bad cluster file.

[вʀaᴎᴅᴏƞ вєнᴎєƞ]

@psusi Good catch, I had the wrong command switch. What I'm saying is if the drive's firmware catches it as a bad cluster, not NTFS, then the drive should try to automatically recover the data in that sector and then NTFS will mark the block as bad in the $BadClus.

[AStopher]

Please could you answer my question?

[вʀaᴎᴅᴏƞ вєнᴎєƞ]

Sorry. The $BadClus file is a sparse file, so it is normal for it to be as large as the partition it resides on.

[AStopher]

@BrandonB Since I posted this question Recuvra has now found 27 files (in 3 hours, still at 0%), looks like this is going to take a long time. Would you have any idea how long a deep scan on Recuvra with the (2TB) hard drive should take?

[вʀaᴎᴅᴏƞ вєнᴎєƞ]

@cybermonkey Nope.

[psusi]

My point is that if the drive firmware corrects it, then it won't be in the bad cluster file... and conversely if chkdsk adds it to the bad cluster file, the drive firmware won't correct it.

[Ramhound]

It shouldn't take 27 hours to recover data, if the files were there, they would be identified nearly immediately

[Ramhound]

Even 3 hours is still awhile, discovery of a file that was marked for deletion, should be discoverable nearly instantly as the drive is read, 27 files out of thousands of files that were deleted indicates the data is gone