I used Recuva to recover moved files off a drive. The drive hadn't been used since the files were moved. After a Deep Scan, all files were reported 100% recoverable. I stopped the recover though because I didn't choose to Restore Directory Structure. I did that and began it again, but Windows at some point forced shut down because of a critical update. Now, when I try to recover these files, almost half of them (about 4,000 out of 8,000 files) are reported unrecoverable because of being crosslinked with other files.

I recovered some files reported unrecoverable anyway, and I compared them to some I had recovered on my first attempt, and many of them are indeed now damaged. All the ones I started recovering before though are 100% healthy.

What happened? Can I get out of this? It's hard to believe I was so close and a forced shut down destroyed my chances.

One of the main rules data in planning file extraction is to disable the automatic setting for Windows update.

As far as what happened in your case, ouch, nobody can answer with certainty. There is no telling what Windows may have done, or maybe the drive has additional issues.

Once the update installed, upon restarting the machine, did you have the source drive, from which you wanted to extract data from, connected to the machine? If yes, did you notice the checkdisk function kicking in?

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

I foolishly failed to report in my post that the drive has pending and uncorrectable sectors. This is why the files were moved from the drive in the first place months ago. Since then, the new drive I moved the files to is now failing. Pretty bad luck. I don't know though how from one scan and reboot, a failing drive can go from recovering 8,000 files perfectly to recovering only half of them correctly due to crosslinked files. Should I chkdsk /v /x /r on the drive, move the crosslinked files, then delete them to try to repair the file allocation table? I'm afraid that may make things worse, but I don't know.

Speedfan Report:

BLOCKING ISSUE : your hard disk has 313 pending sectors (this value is very large and your hard disk should be replaced). Those are sectors that couldn't be properly read and that the hard disk logic is waiting for a write operation to try to remap to a spare sector (if available). According to the Reallocated Sector Count attribute, your hard disk seems to have available spare sectors. A simple disk surface scan won't be enough to force the remap operation. You need a read/write surface scan to remap the sector. The best option should be a tool that knows about what should be read from that sector so that it has some option to apply the best fix to the missing data.

BLOCKING ISSUE : your hard disk has 276 offline uncorrectable sectors (this value is very large and your hard disk should be replaced). Those are sectors that an offline scanning found as unreadable. Offline scanning is a process that can be automatically started by the hard disk logic when a long enough idle period is detected or that can be forced by some tool. Those unreadable sectors are identified and the hard disk logic is waiting for a write command that will overwrite them to try to remap them to spare sectors (if available). According to the Reallocated Sector Count attribute, your hard disk seems to have available spare sectors. A simple disk surface scan won't be enough to force the remap operation. You need a read/write surface scan to remap the sector. The best option should be a tool that knows about what should be read from that sector so that it has some option to apply the best fix to the missing data.

For data recovery purposes, running chkdsk is not recommended. Hence, I asked if noticed it kicking in when restarted the drive.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

And it is a FAT file system?! Ouch.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

It's actually NTFS. I'm thinking now what happened was when Windows rebooted, it chkdsk'd that attached drive. I bet you anything that's what happened. Can I confirm that in a log file? If that's what happened, do you think I'm screwed now?

Sorry, I thought you said "file allocation table". FAT file systems use those.

As far as checkdisk, mhhh, it is possible that it initiated upon restart.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

@flashofthedark,

Due to some missing info, I can't understand enough of the detail of exactly what you did, and the original situation. I also wonder how much this relates to your previous thread:

wd20ears-help-t23060-20.html#p157223

However regarding the question of chkdsk - it may have run on boot (if the filesystem "dirty flag" was set) in which case it's strictly "autochk" and not "chkdsk" (you'd need to ask in a Windows-related forum about whether there's a log file for you to check, as you hoped), and then aborted part way through due to I/O errors. As always, chkdsk/autochk should not be run on a failing drive, as labtech also said. However, normally chkdsk/autochk would not leave any cross-linked files...

Another possibility is that your drive-waiting-for-recovery was used by Windows for storing the temporary Windows Update files which are downloaded, and again, that process may have been interrupted due to I/O errors which you say that drive was reporting, leading to filesystem corruption. Utimately, I'm not sure you'll find out exactly what happened and even if you did, I doubt it would help with the recovery.

IMHO all I can suggest now is what you should have done in the first place, if you're accepting the (many!) risks of DIY: Perform a raw clone of the drive which you want to recover from, onto a blank drive (or equivalent empty filesystem space) the same size as the original drive, using as many retries and other techniques as needed to get the most complete clone that you can. Personally, I use ddrescue under Linux/Unix for this (since my job is not DR, so I don't have a hardware imager as used by many DR pros) which has the added advantages of no automatic chkdsk/autochk and no Windows Update. (In some cases, I've even cloned the clone, to have a backup of that to revert back to, if any future step modifies the clone in a way that I don't like). Then use your chosen software to recover files from the clone onto yet another empty drive (or equivalent filesystem space).

If you're not confident that you can avoid future mistakes, or if the files are valuable, then perhaps you should allow an experienced DR company to see the drive, as there is always a limit to even educated guessing about diagnosis via web forums. Good luck whatever you decide.