I have two western digital Hdd, one is a 500gb and the other a 640gb.
I was in the process of moving everything from these drives to the home server I built.

Anyway, I had the 640 mounted as a 2nd drive and finished copying data to the server.
Then I had the erroneous thought that "these are sata drives and are hot swappable" WRONG!
So I unplugged the 640 and connected the 500gb and checked My computer for the new drive, but I didn't
see it. I thought that was weird and restarted the computer. When it restarted chkdsk launched and it began
" deleting index" (I think that was the message), now all of the data on the 500gb drive is gone except for a common
folder between the two drives called "upped to server"

Can someone tell me what happened? Its like it compared the master file table of the 640 to the 500 and deleted everything that didn't match.

Drive information:
WD500AAKS
WD Caviar SE16
Model: WD5000AAKS-OOYGAO

WD6400AACS
Model: WD6400AACS-00G8B1

What can you see on the HDD? No files at all?

_________________
http://www.pclab.com.pt facebook.com/PCLAB.A.T
ACELab partner

@WDIO,

Based on the level of detail available (which is enough to understand the overview, though not the fine details), then IMHO your thoughts are basically correct about what happened:


The devil is in the detail... At a hardware level, when connected to a hot-swap compatible controller (e.g. AHCI / RAID or equivalent, with an appropriate driver), then yes, SATA drives are hot-swappable. The mistake was omitting the OS considerations which are also necessary. In your case, there was still a mounted filesystem on the 640GB disk when you removed it, and there would have been metadata from the filesystem cached in RAM.


At some point after this, it is likely that cached filesystem metadata from the 640GB drive (held by Windows in RAM), was then de-staged onto the 500GB drive, probably when you shutdown & restarted Windows.


The original data on the 500GB disk actively erased, but chkdsk did exactly what it is designed to do, which is to fix a broken / inconsistent / corrupted filesystem to make it usable (i.e. internally consistent) - and if that means that some of the files become inaccessible, then that is just the price you have to pay, to have a filesystem which is usable..


See above for my guess, based on what you've described. There might be more clues if you paid for a forensic investigation of the filesystem, but I don't see that being a useful way to spend your money at this point.


You're not far from what I've described above - I believe you've ended up with part of the 640GB disk's MFT written to the 500GB disk, but without the matching files on the 500GB disk, of course. Then, because the filesystem wasn't left in a consistent state, chkdsk (actually autochk) ran during the Windows boot, to try to make the fileystem usable, but you've lost access to the files which were originally on the disk. The damage had already been done before chkdsk ran, by Windows overwriting filesystem information on the 500GB disk when it was swapped-in and then doing a shutdown, as Windows didn't know that the 640GB disk had been swapped-out.

On a Linux/Unix-based OS, normal sys admin procedures would be to unmount the filesystem(s) on the first disk, then swap the disks, then mount the new filesystem(s) on the second disk, which prevents this type of problem. Unfortunately Windows hides these details about what goes on under the covers with filesystems, so although I've seen at least one "unmount" utility written for Windows, typical users aren't warned that you'd need to use it, in your situation with a Windows "Local" disk (i.e. no Eject option in the explorer context menu).

Assuming you want to try to recover the original files fropm the 500GB disk, IMHO the short version is: Don't do anything to that 500GB disk and consider whether you want to use the services of a DR company, or want to try to perform a DIY recovery with its associated risks (for which you'll need to use a "raw" recovery approach, since the MFT is likely useless for finding any of the files which were originally on that disk).

Vulcan, Thanks for the excellent reply.

I was not aware that windows held that in ram. I thought it was read and written to as needed on the disc.

I realized the error in my ways as soon as the computer finished booting and my data was gone.
I heard the little voice say..." Hdd are ONLY hot swappable if the BIOS supports it"

Can you recommend software for this type of recovery? I've heard EaseUS was good.

In your case it's not the BIOS, but the OS (Windows) where the "surprise removal" caused a problem.


I work in a different part of the data storage industry, not DR, so I don't use such Windows software on a daily basis. However from my experience over the years, I have seen disks where recovery software program X recovered more than program Y, and another disk where the reverse was true, due to the different algorithms in each program, and the different filesystem state in each case. Therefore if you're going to do DIY (and accept that you might be unsuccessful or cause further issues, due to your human error, hardware failure, or just bad luck), then I would try a few different recovery programs - many offer trial versions - to get at least some idea of what each one might recover.

However, for a raw (i.e. file signature-based) recovery, your success rate will depend on how fragmented the files were on the disk, how well these files can be recognised by the software on the disk, whether any of MFT fragments contain useful pointers when you also try a filesystem-based recovery, etc. etc. A typical trial software limitation would be that they only recover small files until the software is bought. Unfortunately that means you won't know whether larger files (which are more likely to be incorrectly recovered than smaller files, due to fragmentation) can actually be successfully recovered or not, without buying the software.

If the "lost files" were photos, then some recovery software trials will create real thumbnails from the whole (large) photo file, so you can get a true representation of the whole photo (not just display the embedded thumbnails, which can be intact even when the large photo file is corrupted, due to it being fragmented on the disk and not fully recovered). That's just an example of how it can be difficult to judge the likely success of raw recoveries, when using trial recovery software versions, in my experience.

Two software packages which get mentioned here often are R-Studio and GetDataBack, but as I said, there are many others. You'll need to have empty disk space to hold all the files which are recovered by whatever software you choose. Also, personally, I'd make a full raw clone of the 500GB disk before you start (which needs more empty disk space, of course), just in case that original disk fails while you're trying to recover files from it, or you drop it, or you cause damage by ESD, or you mistakenly write to it (since you won't have a hardware write-blocker) etc. etc. At least one person here has said that such cloning "just in case" is unnecessary, where there is no hardware fault with the disk; others agree with my approach. Your disk, your choice

I hope that helps in your decision making, but since I don't know your skill level, experience, available equipment etc., it's impossible to know if I've given the right advice for you, which is why you have to decide what risks you want to take, with your data.