I'm seeking assistance regarding my 8TB NTFS drive, which may have been affected by CHKDSK. The drive is almost full and contains a vast collection of memories. I would greatly appreciate any help in recovering the data.

In summary, it appears that Windows auto-ran CHKDSK during startup and potentially formatted my disk without my consent. Previously, the drive was displaying the error message " You need to format the disk in drive X: before you can use it. " Now, after the CHKDSK process, the drive appears as a blank disk with only a few initial system files, including "bootsqm.dat." I'm wondering how I can recover all the data from the NTFS drive.

Before today, I thought I was an experienced user. I have a few questions:

1. CHKDSK is the evil?: Why would the automatic CHKDSK at startup format my disk? Most sources claim that CHKDSK won't cause any harm. However, I found one source mentioning that CHKDSK left the user with a blank partition, which is similar to my situation. Why would CHKDSK behave this way?
   
   
2. GPT vs File System?: May I ask if the GUID Partition Table solely contains partition boundaries and information? Does GPT have no relation to the filesystem or folder structures? If I were to recreate the GPT by knowing the partition type and boundaries (as I have another disk of the same model), would the file system remain intact, and would the files and folder structures be revealed as normal?
   
   
3. Linux testdisk Undelete finishes promptly?: While I guess that recovering the GPT might be hopeless, now I am trying to retrieve the files from the drive. I was surprised that Testdisk's Undelete function didn't perform a thorough byte-by-byte analysis to locate the files. Instead, it quickly loaded with only a few initial blank system files. I assumed that Testdisk > Analyse > Deeper Search was used for analysing boundaries and restoring partitions, while Undelete was used for file recovery. I am confident that there are millions of files on the drive, as approximately 80% of them are backed up on its twin 8TB hard disk. Why didn't Undelete scan for files?

=======================================

Detailed situation:

The affected drive is an internal 3.5" 8TB NTFS drive that has been formatted by and for Windows 7. It is stored in a protective foam case. I always handle it with utmost care, and it has been in use for approximately three years. The power cycle count is only 440 times, and it has accumulated 7021 hours of usage.

When I connected the drive using a SATA to USB (powered) connector to a Windows 7 system, I encountered the error message " You need to format the disk in drive X: before you can use it. " Of course, I did not proceed with formatting the disk.

In an attempt to resolve the issue, I followed suggestions from various websites, such as

• connecting the drive to different USB ports,
• connecting it to another Windows 7 computer, and
• changing the drive letter in Disk Management.

Unfortunately, none of these steps resolved the problem.

In hindsight, I regret not trying to connect the drive to a Linux computer before proceeding further.

Following recommendations from various websites, I connected the drive directly using SATA cables. As I started my PC, before entering Windows, the command line console prompted for an automatic CHKDSK. Since CHKDSK was suggested as a potential solution, I did not skip this CHKDSK automatic run.

After the automatic CHKDSK and it got loaded into Windows 7, the 8TB drive appeared as a blank disk with only a few initial blank system files. All the files that were previously stored on the drive are no longer visible. It seems as though the drive has been formatted, most likely due to the CHKDSK process.

To explore alternative options, I powered off Windows 7 and booted the PC using Linux. The drive still appeared as a blank NTFS formatted drive in Linux. I attempted to fix the GPT using Testdisk's quick search, but it was unsuccessful. Strangely, Testdisk's Undelete function quickly loaded without recovering any files. Currently, Testdisk is undergoing a deeper search, which is at 35% progress and counting. However, based on my understanding, both the quick search and deeper search functions are primarily used to recover the FAT or GPT, and not specifically for file recovery.

If the Testdisk's Deeper Search finishes and fails to recover any file, aside from options like Photorec and Foremost, what other alternatives can I explore?

Of course, the primary goal is to recover the GPT in order to restore the files with their original folder structure, rather than recovering each individual file and having to arrange them manually. Consider that the total data size is nearly 8TB.

I forgot to mention that the last successful read/write was quite recent:

The affected drive is an internal 3.5" 8TB NTFS drive that has been formatted by and for Windows 7. It is stored in a protective foam case. I always handle it with utmost care, and it has been in use for approximately three years. The last usage was around one month ago, and there were no signs of any issue at that time. The power cycle count is only 440 times, and it has accumulated 7021 hours of usage.

Can we get actual drive model? If uncertain UFS will tell, and so will SMART tools like CrystalDiskInfo. A screenshot would be nice.



There's too much to answer everything.

Chkdsk: Yes, chkdsk can be 'destructive', you should regard it a tool which sort of considers a consistent file system it's primary goal. One way to achieve this under certain conditions is get rid of conflicting or corrupt data that's part of the file system meta data. I am cutting corners here, but that's the basic idea.

Undelete tools: Yes, these look for files flagged "deleted" in current file system. Since chkdsk annihilated the file system such tools will not find data and finish quick. You'd need a serious data recovery tool like UFS Explorer, forget TestDisk.

But first you'd need to check SMART (see what the drive tells about it's condition) and if the drive's condition allows for it, clone/image the drive. It is considered a bad idea to work with the original drive.

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

Dear Joep,

Thank you for the reply. Here is the disk information.



Thank you for confirming that CHKDSK can be destructive. I now hate Windows so much! I deeply regret not trying to mount it on Linux before allowing CHKDSK to run. If CHKDSK hadn't destroyed the GPT, I believe Testdisk could have restored the GPT from the backup in an instant.

Just now, Testdisk's Deep Search completed. You were right; Testdisk cannot recover my data.

I understand that I should have worked on a clone. Unfortunately, I do not have an extra 8TB lying around. I simply didn't expect CHKDSK, a well-known Windows disk repair tool, to be destructive.

I am currently trying to use Photorec and Foremost. They can recover some files but do not preserve the filenames and folder structures.

Some Windows software (both paid and free) can preserve filenames and folder structures. Are there any Linux software programs that have the ability to recover filenames and folder structures?

DMDE runs under Linux. It will try to recover the file/folder names, if the metadata still exists.

_________________
A backup a day keeps DR away.