How I switched to an SSD with free software and no CD-ROM drive

A lot of great tools exist to help clone drives. Acronis, Ghost, and many other examples are available for the user to do an easy and clean copy of their system from one drive to another. But when I got my first-gen Intel X25-M SSD, I had two real problems: A) I didn’t want to spend any additional money, and B) I wanted to overprovision my SSD since it didn’t support TRIM. So, hooking both drives up to my system, I turned to the internet for a lot of instruction (and frustration), and tools in order to accomplish these two goals.

dd – A Linux cloning tool
“dd” isn’t a cloning tool like the ones I mentioned before, there’s no pretty interface, and it’s possible to mess up and erase your entire drive. Part of what you’re paying for with the other solutions are ease-of-use and peace-of-mind, but with my entire hard drive already backed up on my NAS, I forwent those options in favor of free.

First was a choice of Linux distributions to use. Ease of making it install on a USB and be bootable, and inclusion of the tools that I needed, were the two things I looked for in this step. “dd” comes with nearly every distribution, so I focused on a tool that could help me with the over-provisioning, as well. GParted is a GNOME-based partition tool, which has its own distribution housed on sourceforge.net. Following GParted’s instructions on making a bootable USB key, and with the tool UNetbootin, I had a system that I could now perform my cloning in. The short version of the instructions is this: download the GParted ISO and UNetbootin. Run UNetbootin, choosing your downloaded ISO as the distribution, and let it do its magic.

Preparing for cloning
The SSD I was moving to and the hard disk I already had were both 160GB. Normally for cloning, this is the perfect scenario: no changes are needed to move the data. However, as I said before, I wanted to overprovision my SSD (giving it extra never-used space to serve as a swap area, keeping performance of non-TRIM drives at their peak). Since I was doing that, I made sure I had less than 140GB on my disk drive to leave me enough room for over-provisioning.

Although GParted is able to move data around when it resizes partitions, it’s recommended to choose the safer option and defragment your drive first, lessening the risk of any data issues. Using Windows Disk Defragmenter, I made sure all or most of the data was in the first 140GB of the drive.

The next step I did was to resize the partition on the hard disk to 140GB. This was the first opportunity to use the Linux environment, and the tools I had set up earlier. Launching the GParted live USB, and choosing the default options (yes, I want to use English, yes, please boot me right into GParted), I was presented with little rectangles representing my two drives. At this point, it’s good to note which is which. Using the “Label” of my drive, I could easily verify in the software that my hard drive was listed under /dev/sda1, and my SSD under /dev/sda2. Now, to drag the slider until the partition was just under 140,000,000 bytes and apply the new partition size. No hitches, no problems, everything went great.

The cloning
This is the easiest part, but the one where one small mistake can wipe out your entire drive. So fair warning, make sure what you’re doing is right, don’t just trust me, read the help, and good luck!

Rookie mistake 1: cloning the whole drive. I told you I was over-provisioning the SSD, which means leaving a portion empty. When I first copied my drives over with dd, I just simply copied one whole drive over onto the other, after all, I had already shrunk the hard disk to 140GB, right? After it was done, being a NAND technology guy, I realized I had made a huge mistake. An empty bit on a hard drive has zeroes. An empty bit on an SSD has ones. Since I had copied the empty section on the end of my drive over to the SSD, I had programmed zeroes across the end of the drive. Instead of leaving it empty, I filled it entirely.  Oops! To fix that, I had to go through and secure-erase the entire drive with a different tool, one I won’t cover here since you hopefully won’t be making the same mistake.

So now for the correct version of what I should have done, copying one drive over to the other. During partitioning, I had already confirmed which drive was which, so now it was just validating my command. For dd, “if” is the input file, my hard drive, which I already confirmed was /dev/sda1. “of” is output file, the SSD, /dev/sda2. Not to repeat mistakes, I set options for only 140GB of data transfer, meaning I had to use some simple arithmetic. 140,000,000 bytes (how much of the SSD I want to fill), divided by 4096 (the byte size I chose in the dd command “bs”). That means I want to write 4k bytes 34,180 times. My final command was this:

    dd if=/dev/sda1 bs=4096 count=34180 of=/dev/sda2

Now the moment of truth: running the command, letting it finish, swapping the drives, and rebooting. After all of this was done, I swapped the drives, and success! A successfully cloned, over-provisioned, brand new SSD in my system.

A lot of great tools exist to help clone drives. Acronis, Ghost, and many other examples exist for the user to do an easy and clean copy of their system from one drive to another. But when I got my first X25-M drive, I had two real problems: A) I didn’t want to spend any money, and B) I wanted to overprovision my drive since it didn’t support TRIM. So hooking up both drives to my system, to the internet I turned for a lot of instruction and tools in order to accomplish these two goals.

dd – A Linux cloning tool

“dd” isn’t a cloning tool like the ones I mentioned before, there’s no pretty interface, and it’s possible to mess up and erase your entire drive. Part of what you’re paying for with the other solutions is ease-of-use and peace-of-mind, but with my entire drive already backed up on my NAS, I forwent those options in favor of free.

First was a choice of Linux distributions to use. Ease of making it install on a USB and be bootable, and inclusion of the tools that I needed, were the two things I looked for in this step. “dd” comes with nearly every distribution, so I focused on a tool that could help me with the over-provisioning, as well. GParted is a GNOME-based partition tool , which has its own distribution housed on the popular sourceforge.net. Following their instructions on making a bootable USB key, and the tool Unetbootin, I had a system that I could now perform my cloning in. The short version of the instructions is this: download the GParted ISO and Unetbootin. Run unetbootin, choosing your downloaded ISO as the distribution, let it do its magic.

Preparing for cloning

The drive I was moving to was 160GB, and the drive I had was also 160GB. For a normal cloning, this is the perfect scenario, no changes are really needed to move the data. However, as I said before, I wanted to overprovision my drive (giving it a little more never-used space to serve as a swap area, keeping performance of non-TRIM drives at their peak). Since I was doing that, I made sure I had enough free space on the drive to shrink down to less than 140GB of space on the new drive.

Although GParted is able to move data around when it resizes partitions, it’s recommended to choose the safer option and defragment your drive first, lessening the risk of any data issues. Using Windows defragmentation tool, I made sure all or most of the data was in the first 140GB of the drive. The next step I did was to resize the drive of the original partition to 140GB. This was the first opportunity to use the Linux environment, and the tools I set up earlier. Launching the GParted live USB, and choosing the default options (yes, I want to use English, yes, please boot me right into GParted), I was presented with little rectangles representing my two drives. At this point, it’s good to note which is which. Using the “Label” of my drive, I could easily verify in the software that my hard drive was listed under /dev/sda1, and my SSD under /dev/sda2. Now, to drag the slider until the partition was just under 140,000,000 bytes, and apply the new partition size. No hitches, no problems, everything went great. The cloning This is the easiest part, but the one where one small mistake can wipe out your entire drive. So fair warning, make sure what you’re doing is right, don’t just trust me, read the help, and good luck!
Rookie mistake 1: cloning the whole drive. I told you I was over-provisioning the drive, which means leaving a portion empty. When I first copied my drive with dd, I just simply copied one whole drive over onto the other. After it was done, being a NAND technology guy, I realized I had made a huge mistake. An empty bit on a hard drive has zeroes. An empty bit on a flash drive has ones. Since I had copied the empty section on the end of my drive over to the SDD, I had programmed zeroes across the end of the drive. Instead of leaving it empty, I filled it entirely. To fix that, I had to go through and secure-erase the entire drive with a different tool, one I won’t cover here since you hopefully won’t be making the same mistake. So now for the correct version of what I should have done, copying one drive over to the other. During partitioning, I had already confirmed which drive was which, so now it was just validating my command. For dd, “if” is the input file, my original drive, which I already confirmed was /dev/sda1. “of” is output file, the new drive, /dev/sda2. Not to repeat mistakes, I set options for only 140GB of data transfer, meaning I had to use some simple arithmatic. 140,000,000 bytes (how much of the drive I want to fill) divided by 4096 (the byte size I chose in the dd command “bs”). That means I want to write 4k bytes 34,180 times. My final command was this:
dd if=/dev/sda1 bs=4096 count=34180 of=/dev/sda2 Now the moment of truth: running the command, letting it finish, swapping the drives, and rebooting. After all of this was done, I swapped the drives, and success! A successfully cloned, over-provisioned, brand new SSD in my system.

Comments are closed.