Problem Swapping Out an HDD with an SSD

I'm replacing my HDDs with SSDs. On the first drive I tried to swap out, I tried using Macrium Reflect to clone the 2TB HDD (WD Black) to a Samsung 850 EVO SSD and found out (the hard way) that cloning an MBR drive to a GPT drive will convert the GPT to MBR, which meant half of my new SSD was inaccessible. After converting the SSD back to GPT and reformatting it (quick format), I used FreeFileSync to copy my data on the 2TB HDD to the SSD. However, when I removed the HDD and replaced it with the SSD, then changed the drive letter on the SSD back to the drive letter of the original HDD, after a few minutes, the drive would disappear from Computer and Management. When I rebooted, chkdsk would run, supposedly fixing any problems, then after Win 7 had been running for a few minutes, either the drive would disappear again or Windows Explorer would stop running and the computer would freeze up. This happened several times until I got ticked off enough to swap the original HDD back into the computer. After booting up again and changing the now changed drive letter on the HDD back to original drive letter, everything seems to be working just fine.

What the big fat hairy heck went wrong? Is the problem related to the switch from MBR to GPT? Was a folder/file syncing (FreeFileSync) the wrong program to use? Did I mess up the SDD beyond repair? I've got a small fortune invested in this change-out and I can't get past the first drive.

I already converted it back to GPT using the second option in this tutorial (the first option didn't work because the convert to GPT never showed up in the right click menu). I had messed around with it trying to fix it with Mini Partition Wizard before it dawned on me that it had been changed to MBR (serious brain fart) after which I changed it back to GPT. I'm not awake enough right now to go into more detail but you can get more details with what has been going on with this fiasco in this post on another forum.

When you clone a disk, it will be the same type of the original one (Legacy - MBR or UEFI - GPT).

If it's a data disk, without any OS files, you can copy all folders from a Legacy - MBR to a UEFI - GPT.
Select all folders but (don't select) System Volume Information and $RECYCLE.BIN. Then Ctrl+c and then Ctrl+v

To clone the OS disk from Legacy - MBR to a UEFI - GPT it's a little more complicated as the boot loader isn't on C: and MBR, but on the UEFI partition.
Try this:
-Remove all drives but the one you want to install.
-Boot from the Win 7 installation disk on UEFI mode. Go to install, delete all partitions and create new. Windows will 3 partitions - UEFI-100M Fat32; MSR - 120M RAW; a large NTFS. ABORT. Don't proceed.
-Boot your Win 7 installation and clone the C: partition to the large partition NTFS on the new GPT disk.
-Remove all other disks but the GPT and do a startup repair.

DavidE said:

I thought you were converting an OS partition and Data partition(s) to the GPT SSD.
I see in your other thread this will only be a Data drive.

The chkdsk had index and MFT errors, i would turn off indexing on the GPT drive before copying data to it.
Your chkdsk snip shows you had 5 .PNG files that caused errors.
You might want to exclude those files, maybe they are corrupt causing the problem.
Maybe FreeFileSync isn't the right program to use for this.

When i copy (robocopy) an entire partition i exclude the $RECYCLE.BIN and System Volume Information folders, trying to copy those causes errors.
Maybe FreeFileSync is copying those.

Have you run a chkdsk to scan for errors on the source MBR drive to make sure there are no errors before copying ?

Macrium Reflect V6 paid has a File and Folder Backup option, that might be better to try.
MR V6 free does not have this option.
Here is a snip from the MR V6 User Guide about this.

FreeFileSync excludes $RECYCLE.BIN and System Volume are automatically excluded from a copy since the destination drive already has those.

I started chkdsk an hour ago and, with both options checked, it is apparent that it will take hours so I'm going to wait until I hit the hay tonight since I want to be able to access that drive during the day. I did update one of my backup HDDs using FreeFileSync and it backed up just fine so I suspect the problem is more likely with the SSD, not the source drive.

I think I may have finally found the problem. My E: HDD is a 2TB drive. The SSD is 4TB. The HDD was connected to one of the Marvel ports on my MOBO (when I built the machine, I used one of the Marvel ports for my main data drive in case I wanted to cache the drive with an SSD in the other Marvel port but the HDD was plenty fast for me so I never did cache it). Well, after repeated failures trying to get my data onto the 4TB SSD without errors, then having the SSD drop out when I swapped it out with the HDD, I disconnected the E: drive, put one of its backup drives in the 3.5" hot swap bay and the SSD in the 2.5" hot swap bay and used FreeFileSync to copy over the data. I also had formatted the SSD as E: since I had problems changing the drive letter before. The transfer took several hours but, once finished, I pulled the HDD out of the hot swap bay, rebooted with the SSD still in its hot swap bay and everything seemed to work just fine, so I relocated the SSD to the E: drive's slot. Again, everything seemed fine when I booted up.

I started to do a restore to the previous image since the profile for my keyboard was gone and I probably had other problems after several cold reboots when my computer or a window would freeze up, but I decided to be cautious and verify the image to make sure it didn't get damaged from all the problems I had been having. At 2% verification, the E: drive went AWOL. The same thing happened again after another reboot.

At that point, since the SSD seemed to work just fine in the hot swap bay, I pulled it from the E: slot and put it in another slot that is running off my HBA card (I already have a 4TB HDD running off the HBA card without any problems), the rebooted again. Everything seemed to be working just fine so I tried verifying the image again and, this time, the image verified. I still need to restore to that image but I'm going to wait a day or so first to make sure the SSD doesn't misbehave.

Apparently, the problem was with the not so marvelous Marvel port or its cable. Since I have an extended ATX MOBO crammed into a small ATX case, the cabling is rather crowded so I'm not going to worry about trying to see if the cable was at fault. Frankly, I don't care since this entire machine will be getting replaced once I finish building a scratch built case I've been working on.

I would have just copied and pasted and verified, in small chunks. Regardless of the amount of data to be transferred. Both MBR and GPT can be NTFS so that is not a problem.

I don`t trust copy programs.

AddRAM said:

I would have just copied and pasted and verified, in small chunks. Regardless of the amount of data to be transferred. Both MBR and GPT can be NTFS so that is not a problem.

I don`t trust copy programs.

FreeFileSync wasn't the problem (in fact, I've never had a problem with it). The problem was the Marvel port the E: drive had been plugged into and the problems went away once stopped using that misbegotten port. Marvel chips don't have the best reputation in the world and, apparently, they don't like drives over 2TB.