Chkdsk problem-dying hard drive

[Thump553]

Windows 10 (64) system, no RAID, SSD as boot drive (C SATA hard drive as data (E. Hard drive giving me some problems recently (had to press F1 on boot up). Got a replacement hard drive (G used WD version of Acronis to try to clone E: Failed half way through, sectors unreadable.

Ran chkdsk E: / f/ r/ x which caught quite a few bad sectors but eventually ended saying no more room on hard drive to move.

Rebooted (and emptied recycle bin). Now can't see drive E in either bios or under Windows File Explorer. Windows disk management shows the hard drive but says it is uninitialized, when I try to initialize it (MBR) I get an error message "Incorrect function."

Chkdsk cannot see this drive now either.

Any ideas what to do at this stage? I have some of the data backed up elsewhere but would really like to recover as much as I can if possible.

 

[VirtualLarry]

I hate to say this, but CHKDSK DOES NOT "fix" physically-failing HDDs. Really, it only makes things worse, and mostly, unrecoverable. (It only works to ensure that the filesystem is internally consistent, and if you give it the "/F" (fix) flag, it will TRASH user data on the drive, to do so. It is NOT a valid HDD recovery tool, most of the time.)

You should have bought two new HDD of the same size, and used DD_RESCUE under Linux, to clone the failing drive's sectors, as much as was physically possible given the state of the drive, and then made a copy of THAT cloned drive, as a "work drive", and then run CHKDSK on that "work drive", to fix up whatever filesystem errors that might have been present. Alternatively, you could have used yet another drive, and perform file-recovery on the "work drive", to the "file save drive", and dump the files onto that drive.

I hate to say this, but you're now in a really tough spot, to recover anything off of that drive.

May I suggest, in the future, a nice 2-bay or 4-bay NAS, running RAID 1 (mirroring), or RAID 5 (parity striping), respectively, in the future, for storing data. (Although, RAID is IS NOT backup, so you should actually have TWO NAS units, possibly in different locations, replicating, OR use a cloud backup provider to backup your NAS unit. Or manually back up to an external HDD every month or two weeks or whatever.)

As an aside, they really need to teach data-storage and RAID and backup basics, in Jr. High or High School. So many people, for so many years, simply DON'T KNOW. The info is out there, they just don't know, so they don't even look it up. The creation of "World Backup Day", is starting to change that, though, and foster some education in this area.

 

[Shmee]

Try booting into a linux or recovery environment (parted magic) to get the rest of the data. If that does not work, send the drive off to recovery service.

 

[mikeymikec]

I basically agree with VL (with the exception of "it will trash the drive" - disagreeing purely with the absolutism) - in future, if you suspect that a drive is failing, then think of it as something extremely frail and on death's door, so no unnecessary powering on of the drive, no unnecessary stress, etc. It's best to act like you've got one shot at data retrieval and that's it, and anything more that you get from it is a blessing. In such a situation I tend to switch off anti-virus, have a command prompt ready (no opening explorer on the drive as it loading thumbnails etc is unnecessary stress on the drive) ideally with a command ready to hit return on to go straight to the folder you need to get data from first, once you've got the most essential bit then go after less necessary stuff (because there would be nothing quite as frustrating as it managing to transfer a load of stuff that you could have easily lived without only to fail before it gets to transfer the essential data). Especially make sure you don't have any idiotic programs running like Dropbox ready to pounce on a removable drive the moment you connect it.

chkdsk is unnecessary stress on a drive known to be faulty, and could cause more problems. By all means if you have some suspicion that the drive could be at fault, use chkdsk to help diagnose it, but in such a situation I would normally have done a backup first.

If a drive is faulty in some way, the absolute best that chkdsk can do for you is a) give output consistent with that reality such as "read failure", "bad sectors/clusters"), and b) do the job the drive was supposed to do itself of flagging bad sectors so they don't get re-used, which can help in working around a problem temporarily.

As for your current situation, "GetDataBack for NTFS" is my friend in such situations (runtime.org), but there are limits to what software-based data recovery can do. Data recovery software is basically extremely tolerant of a drive that Windows's fault tolerance is not, so it can ignore say the million-and-one errors the drive is reporting and steadily transfer data even if it's at serial port speeds

 

[Thump553]

Sadly SMART posted the drive as green all the way along (even after failure) and Windows File Explorer's tools (scan / scan and repair) didn't find any errors either. It was sudden slowness and disappearing files that led me to suspect the drive. Fortunately I was able to back up 95% of what I NEED before it crashed but it's a same and PIA to lose everything.

 

[mikeymikec]

Sadly SMART posted the drive as green all the way along (even after failure) and Windows File Explorer's tools (scan / scan and repair) didn't find any errors either. It was sudden slowness and disappearing files that led me to suspect the drive. Fortunately I was able to back up 95% of what I NEED before it crashed but it's a same and PIA to lose everything.

I wouldn't rely on any single reporting system to diagnose a faulty hard drive. Sometimes its SMART data will deliver the goods, sometimes the BIOS will say "SMART Status: BAD" (I once had a customer who ignored this for months), sometimes the event log will show tonnes of disk/storage driver/ntfs errors/warnings, sometimes chkdsk will give obvious feedback, sometimes a mix of all three, but I certainly wouldn't look for all three: Your 'sudden slowness' plus one of the above symptoms I mentioned would be enough to convince me. If I felt the need to be extra-thorough I'd disconnect the drive and plug it in via USB to see whether it still acted squirrely (I've heard people cite SATA cables for example, I personally have never experienced that as a cause for such symptoms).

I've got a customer's laptop in that is basically unusable - Windows boots to the login screen quickly, then after login can take ten minutes to get to the desktop and then no apps will start, SMART says one recovered sector was found IIRC, but the event log has tonnes of warnings/errors that point to the disk. I didn't bother doing a chkdsk.