CHKDSK Converted Critical NTFS Volume to FAT32, Can I Recover?
So I have no real idea what happened here, as this machine is one of my Media machines (HTPC similar), and is primarily hooked up to a LCD TV, however also hooked up to a monitor in another room. Due to the way I've set it up, BIOS and everything pre-windows logon screen are shown on the monitor, and then the login screen and everything afterwords is displayed on the TV.
Due to this setup, it was too late to figure out what actually happened here, but I'll sum up my actions.
I had MSDN Windows 7 Pro, but I've recently been ramping up my Unix / Linux experience and as such I've added multiple new servers to my collection that are only running Linux, one of those has 6x 1TB HDD's in RAID5 accessible via NFSv3. Due to the limitations of Windows 7 Pro, I gave up finding a free alternate NFS provider and just upgraded to Windows 7 Ultimate (which includes Windows Support for Unix and NFS Support). Sounds good so far, right?
Post install, I decided to restore my data. I have 2 primary external drives, a 640GB and 1TB, both eSATA. I plugged in the 1TB, copied over a large amount of data, and then the copy "crashed", that is to say, the transfer just stopped, and the drive appeared to have an error, and it was no longer visible in my system. I rebooted, the drive was recognized again, and I finished the remainder of the file transfer without issues and while appearing to recover the last file it crashed on. I removed the drive and then plugged in the 640GB, and continued copying items from the 640GB. I received errors on that copy as well, however the data on there is typically redundant, so I just decided to smoke the 640GB drive and I'll rebuild what was on it later.
Here's the kicker. I remove the 640GB after just leaving PS3 backup data on it, plug in the 1TB drive again. My computer thinks the 1TB drive is the 640GB drive. Acquired same drive letter, volume name, and file contents (however, if you try to view the contents of a file, you get an error as obviously the data isn't really there, nor is my 1TB drive FAT32, where as the 640GB is for PS3 comparability).
I found this really strange, the device manager recognizes it as WD10EADS, which is correct, but it is displaying the file system and contents of the WD640. Strange I thought, but after figiting around with eSATA and USB, I decided to reboot again with the drive in eSATA in an attempt to re-detect it's contents via BIOS. Big mistake.
I was on my TV at this point, wondering where my login screen was. After about 30 minutes, I gave up, went to the other room, and turned on the monitor. It's truncating files and fixing data chains like crazy. So like crazy, it takes roughly 120 hours (~5 days), with me insanely paranoid about canceling the process, as I believed it was legitimately fixing my volume. I will also add, this machine is the hottest in my collection, and with a broken A/C unit and a recent heat wave, life has been hell over those past 5 few days.
Chkdsk is complete, and I log into Windows 7. Open up My Computer, Hmm, it shows 709GB out of 1TB used space, looking good, double click the drive, well shoot, all it shows is my PS3 backup data and over 2.3 million chain files or fix files or files of those types (nothing but the PS3 data looks usable, though I'm sure that's not even the case). Right clicking the drive for Properties shows the partition maxing out at 192GB (if I recall correctly, the limit for FAT32 volumes). Windows 7 and CHKDSK have converted the drive somehow to FAT32 and basically re-written all my data. Awesome.
This, of course, was at my most volatile data backup stage. I have limited backups on the NFS share, the majority of my stuff was on these 2 external drives that I intended to back up to the NFS share once I had Windows 7 Ultimate going for the NFS support. My life was on that 1TB drive, which now only shows a 16KB PS3 data file and a few stray backup files from the FAT32 640GB drive.
The Disk Space Usage shows there is indeed 709GB of data on the drive, which makes me think it may perhaps be recoverable, at least partially. Does anyone have any ideas?
I've exhausted my brain. I've tried multiple versions of deep file scans to attempt to get back deleted or otherwise unavailable data, but I have come up quite poorly (I've managed to find recoverable files for all of my redundant data, but nothing I actually needed). I'm thinking this volume, for starters, will need to be converted back to NTFS before I can recover this, or at least, the partition type has to be changed to NTFS, but I'm not sure if chkdsk converted the drive or just changed the partition type, which I'm pretty sure will be detrimental to me recovering data.
I don't need everything off here, in fact there's about 600 - 700GB of replaceable data, but it's the important things I want back, like my Resume's, family photo's, documents and the like. Does anyone have any ideas?
I've also tried converting the volume back to NTFS without success. It does recognize the lost chains as actual files, but does not have the available space to restore the files, and if I say no to convert lost chains to files, the chkdsk portion fails:
C:\Windows\system32>conver
The type of the file system is FAT32.
Volume Serial Number is 7CA7-27C3
Windows is verifying files and folders...
File and folder verification is complete.
Windows found errors on the disk, but will not fix them
because disk checking was run without the /F (fix) parameter.
Convert lost chains to files (Y/N)? n
204257696 KB of free disk space would be added.
Windows found problems with the file system.
Run CHKDSK with the /F (fix) option to correct these.
312,416,256 KB total disk space.
672 KB in 4 hidden files.
330,736 KB in 20,001 files.
107,827,136 KB are available.
16,384 bytes in each allocation unit.
19,526,016 total allocation units on disk.
6,739,196 allocation units available on disk.
The volume may have inconsistencies. Run Chkdsk, the disk checking utility.
The conversion failed.
E: was not converted to NTFS
I will be forever grateful to anyone who is able to assist me in recovering some of my data here :) And although I'm sure this doesn't need to be said, everything will be much more backed up going forward.
Due to this setup, it was too late to figure out what actually happened here, but I'll sum up my actions.
I had MSDN Windows 7 Pro, but I've recently been ramping up my Unix / Linux experience and as such I've added multiple new servers to my collection that are only running Linux, one of those has 6x 1TB HDD's in RAID5 accessible via NFSv3. Due to the limitations of Windows 7 Pro, I gave up finding a free alternate NFS provider and just upgraded to Windows 7 Ultimate (which includes Windows Support for Unix and NFS Support). Sounds good so far, right?
Post install, I decided to restore my data. I have 2 primary external drives, a 640GB and 1TB, both eSATA. I plugged in the 1TB, copied over a large amount of data, and then the copy "crashed", that is to say, the transfer just stopped, and the drive appeared to have an error, and it was no longer visible in my system. I rebooted, the drive was recognized again, and I finished the remainder of the file transfer without issues and while appearing to recover the last file it crashed on. I removed the drive and then plugged in the 640GB, and continued copying items from the 640GB. I received errors on that copy as well, however the data on there is typically redundant, so I just decided to smoke the 640GB drive and I'll rebuild what was on it later.
Here's the kicker. I remove the 640GB after just leaving PS3 backup data on it, plug in the 1TB drive again. My computer thinks the 1TB drive is the 640GB drive. Acquired same drive letter, volume name, and file contents (however, if you try to view the contents of a file, you get an error as obviously the data isn't really there, nor is my 1TB drive FAT32, where as the 640GB is for PS3 comparability).
I found this really strange, the device manager recognizes it as WD10EADS, which is correct, but it is displaying the file system and contents of the WD640. Strange I thought, but after figiting around with eSATA and USB, I decided to reboot again with the drive in eSATA in an attempt to re-detect it's contents via BIOS. Big mistake.
I was on my TV at this point, wondering where my login screen was. After about 30 minutes, I gave up, went to the other room, and turned on the monitor. It's truncating files and fixing data chains like crazy. So like crazy, it takes roughly 120 hours (~5 days), with me insanely paranoid about canceling the process, as I believed it was legitimately fixing my volume. I will also add, this machine is the hottest in my collection, and with a broken A/C unit and a recent heat wave, life has been hell over those past 5 few days.
Chkdsk is complete, and I log into Windows 7. Open up My Computer, Hmm, it shows 709GB out of 1TB used space, looking good, double click the drive, well shoot, all it shows is my PS3 backup data and over 2.3 million chain files or fix files or files of those types (nothing but the PS3 data looks usable, though I'm sure that's not even the case). Right clicking the drive for Properties shows the partition maxing out at 192GB (if I recall correctly, the limit for FAT32 volumes). Windows 7 and CHKDSK have converted the drive somehow to FAT32 and basically re-written all my data. Awesome.
This, of course, was at my most volatile data backup stage. I have limited backups on the NFS share, the majority of my stuff was on these 2 external drives that I intended to back up to the NFS share once I had Windows 7 Ultimate going for the NFS support. My life was on that 1TB drive, which now only shows a 16KB PS3 data file and a few stray backup files from the FAT32 640GB drive.
The Disk Space Usage shows there is indeed 709GB of data on the drive, which makes me think it may perhaps be recoverable, at least partially. Does anyone have any ideas?
I've exhausted my brain. I've tried multiple versions of deep file scans to attempt to get back deleted or otherwise unavailable data, but I have come up quite poorly (I've managed to find recoverable files for all of my redundant data, but nothing I actually needed). I'm thinking this volume, for starters, will need to be converted back to NTFS before I can recover this, or at least, the partition type has to be changed to NTFS, but I'm not sure if chkdsk converted the drive or just changed the partition type, which I'm pretty sure will be detrimental to me recovering data.
I don't need everything off here, in fact there's about 600 - 700GB of replaceable data, but it's the important things I want back, like my Resume's, family photo's, documents and the like. Does anyone have any ideas?
I've also tried converting the volume back to NTFS without success. It does recognize the lost chains as actual files, but does not have the available space to restore the files, and if I say no to convert lost chains to files, the chkdsk portion fails:
C:\Windows\system32>conver
The type of the file system is FAT32.
Volume Serial Number is 7CA7-27C3
Windows is verifying files and folders...
File and folder verification is complete.
Windows found errors on the disk, but will not fix them
because disk checking was run without the /F (fix) parameter.
Convert lost chains to files (Y/N)? n
204257696 KB of free disk space would be added.
Windows found problems with the file system.
Run CHKDSK with the /F (fix) option to correct these.
312,416,256 KB total disk space.
672 KB in 4 hidden files.
330,736 KB in 20,001 files.
107,827,136 KB are available.
16,384 bytes in each allocation unit.
19,526,016 total allocation units on disk.
6,739,196 allocation units available on disk.
The volume may have inconsistencies. Run Chkdsk, the disk checking utility.
The conversion failed.
E: was not converted to NTFS
I will be forever grateful to anyone who is able to assist me in recovering some of my data here :) And although I'm sure this doesn't need to be said, everything will be much more backed up going forward.
You have massive damage, and will need a 1TB scratch disk, plus some commercial software just to potentially get a little more data.
Since it took 5 days, then you can bet your life you have a lot of unrecoverable, unreadable data blocks ... worse, the windows diag you ran cleared up some of these errors which are important to a data recovery process.
Considering you ran several deep file scans, and the amount of time it took, then bottom line, unless you are willing to pay somebody like ontrack $500 - $1000 for a partial recovery, I would just cut my losses and stop trying to recover. If you don't want to give up yet, which is understandable, run hardware diags on that HDD. You could have a large number of unrecorable blocks. If that is the case, cut your losses and give up on this disk.
Since it took 5 days, then you can bet your life you have a lot of unrecoverable, unreadable data blocks ... worse, the windows diag you ran cleared up some of these errors which are important to a data recovery process.
Considering you ran several deep file scans, and the amount of time it took, then bottom line, unless you are willing to pay somebody like ontrack $500 - $1000 for a partial recovery, I would just cut my losses and stop trying to recover. If you don't want to give up yet, which is understandable, run hardware diags on that HDD. You could have a large number of unrecorable blocks. If that is the case, cut your losses and give up on this disk.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Following up on what Rindi said, I say you need GetDataBack for NTFS. Try the "Systematic damage" mode first; if it fails, change to "Sustained damage". You will need another 1TB disk to copy to (or at least large enough to allow all data to fit on it).
From what you wrote, the current status o the drive appears to be as follows:
-There is a (hopefully unharmed) MFT somewhere on the drive. This holds your real file information.
-When you ran chkdsk, it wrote a FAT to the drive. This FAT contains utter nonsense.
-Because Windows is mistaking the drive for a FAT32 drive, it is reading the FAT, rather than the MFT.
I have recovered similar cases using GetDataBack previously (only in my case, it was another MFT, rather than a FAT, that was generated in error by chkdsk). It was "Systematic damage" mode that worked for me.
(It is highly unlikely that GetDataBack for FAT will find anything that makes sense, given that your drive didn't even contain a FAT until chkdsk mistook its file system, so any FAT currently on it is the product of chkdsk messing up.)
From what you wrote, the current status o the drive appears to be as follows:
-There is a (hopefully unharmed) MFT somewhere on the drive. This holds your real file information.
-When you ran chkdsk, it wrote a FAT to the drive. This FAT contains utter nonsense.
-Because Windows is mistaking the drive for a FAT32 drive, it is reading the FAT, rather than the MFT.
I have recovered similar cases using GetDataBack previously (only in my case, it was another MFT, rather than a FAT, that was generated in error by chkdsk). It was "Systematic damage" mode that worked for me.
(It is highly unlikely that GetDataBack for FAT will find anything that makes sense, given that your drive didn't even contain a FAT until chkdsk mistook its file system, so any FAT currently on it is the product of chkdsk messing up.)
I'll chime in with another recommendation for GetDataBack ( http://www.runtime.org ). It is my "go to" tool for lost files, won't write on the drive, and you can run it for free then pay if it finds what you want.
Beyond that, there are utilities which can inspect .CHK files, identify JPG's, DOC's, etc., and rename them back to the correct type; but, lets hope GDB does what you need.
Beyond that, there are utilities which can inspect .CHK files, identify JPG's, DOC's, etc., and rename them back to the correct type; but, lets hope GDB does what you need.
Create sector per sector image of the drive prior to trying anything.
I would go with this drive to recovery service if the data is really important for you.
I would go with this drive to recovery service if the data is really important for you.
One of the rare times I will disagree with noxcho. Do not do a raw sector backup. This is why.
1. The disk has gone through a great deal since the initial problems. You are past the point where you have to worry about a head crash or something unexpected to happen. This disk has survived the critical time between initial problem and inevitable catastrophic failure. So no need to perform another backup.
2. You will use this scratch drive as a target device for GDB to save the new filesystem (or what it can recover to).
3. Most critical ... when you attempt to reconstruct a damaged filesystem that has unreadable blocks, you want to perform that work on the original drive because GDB needs to know what blocks are unreadable. It will also attempt multiple re-reads. If you work from a clone, then the cloning process, by definition, will replace unreadable blocks with zeros. This creates additional problems because rewriting data with zeros destroys more data. Better to reconstruct and have known bad blocks, so the reconstructor can choose the right logic path.
Best practices is to work with a copy, but only if you have software that lets you manually submit a list of blocks with ECC errors, and unreadable errors. GDB is not quite as intelligent as that. You need more sophisticated software that people in the 'biz typically develop in-house.
But if "your life" is on this disk as you state, then pay the $500+, get a free quote from the major recovery companies, and don't attempt to run GDB or any consumer product. Take it to a professional. This is no substitute for a lab full of trained technicians in bunny suits.
1. The disk has gone through a great deal since the initial problems. You are past the point where you have to worry about a head crash or something unexpected to happen. This disk has survived the critical time between initial problem and inevitable catastrophic failure. So no need to perform another backup.
2. You will use this scratch drive as a target device for GDB to save the new filesystem (or what it can recover to).
3. Most critical ... when you attempt to reconstruct a damaged filesystem that has unreadable blocks, you want to perform that work on the original drive because GDB needs to know what blocks are unreadable. It will also attempt multiple re-reads. If you work from a clone, then the cloning process, by definition, will replace unreadable blocks with zeros. This creates additional problems because rewriting data with zeros destroys more data. Better to reconstruct and have known bad blocks, so the reconstructor can choose the right logic path.
Best practices is to work with a copy, but only if you have software that lets you manually submit a list of blocks with ECC errors, and unreadable errors. GDB is not quite as intelligent as that. You need more sophisticated software that people in the 'biz typically develop in-house.
But if "your life" is on this disk as you state, then pay the $500+, get a free quote from the major recovery companies, and don't attempt to run GDB or any consumer product. Take it to a professional. This is no substitute for a lab full of trained technicians in bunny suits.
dlethe, my suggestion refers to software level problem and from the description the HDD physically is good.
As GDB is recommended I would suggest trying recovery tools on copy but not the original drive. This is to bring the drive as is to clean lab if recovery service is used finally.
Once he takes sector level image of entire HDD to another HDD (lets say exact clone) he could play on it with recovery tool before considering $500-1000 from his pocket.
And sector level cloning/imaging does not write anything to source drive.
As GDB is recommended I would suggest trying recovery tools on copy but not the original drive. This is to bring the drive as is to clean lab if recovery service is used finally.
Once he takes sector level image of entire HDD to another HDD (lets say exact clone) he could play on it with recovery tool before considering $500-1000 from his pocket.
And sector level cloning/imaging does not write anything to source drive.
ASKER
Thanks for all the assistance, I've decided to opt for GDB, using the NTFS version it was able to read the drive as NTFS, and already appears to have found over 1000 files just minutes into the scan. I'll let it run overnight and report back my findings.
Well hopefully your recovery won't be limited to a bunch of browser cookies and tmp files. It is easy to get those files because they don't span more than 4K. Getting back pictures, music, games, etc is quite different. Crossing fingers for you. Also TEST any large file you get to make sure it is correct. This is most easy with pictures
ASKER
Quite impressed, still in the process of recovering but so far every major document, my resume, pictures of family and pets past, all look good. By the looks of things, the majority of it is going to be recoverable.
I'll update everyone once it's all finished. I believe it was Systematic Damage (the first option after "I don't know") that's worked for me.
I'll update everyone once it's all finished. I believe it was Systematic Damage (the first option after "I don't know") that's worked for me.
Then it's probably what I suspected - chkdsk failed to notice the MFT (or misinterpreted it as a FAT), and instead wrote a "repaired" FAT to the disk. Now hopefully chkdsk haven't overwritten any file data with the fake FAT.
You should probably report your findings on the Microsoft forums to help MS debug the issue once you get your data back.
You should probably report your findings on the Microsoft forums to help MS debug the issue once you get your data back.
ASKER
GetDataBack restored 99% of my data, and the items it could not recover are replaceable. Very happy with this software and I will continue to use and support it.
ASKER
Could you suggest a forum heading I could place it under? I asked this same basic question, and also tried to report it as a bug, but got pretty much nowhere on the MS TechNet Forums.
The main problem of yours is that that you let chkdsk run on this drive. It did corrupt the data with its stupid check and fix.
Now a question, do you have another HDD of 1TB to which you could take sector per sector copy of your HDD? We need to clone the drive before we start any attempt of recovery. Your ideas of converting the FAT32 to NTFS are also really bad. Stop these plays with the drive.