Jaap Haagmans The all-round IT guy

11Sep/145

Replacing a Bitlocker encrypted disk (with an SSD)

Our laptops use Dell docking stations, which leads to most of them being used in a (slightly) tilted stance. Of course, laptops are also carried around frequently, but this tilted stance seems to have a big impact on our disk performance and durability. We've had harddisks breaking down after just under 1 year and few have survived the 2-year mark. Of course, Dell replaces these harddisks, but the disk performance has become so low that we've decided to replace them all with SSDs.

So, we bought a stack of 128GB SSD drives, which led to problem 1: the source disk (320GB) is larger than the target disk. Windows ordinarily won't let you resize a 320GB disk below the 160GB mark and generic solutions to this problem (like using Perfectdisk to optimize a drive for shrinking) didn't work. So I thought I'd use GParted to resize the partition, but there was problem 2: the drives are encrypted with Bitlocker. GParted doesn't support the resizing of Bitlocker encrypted partitions.

After giving it much thought, I decided to decrypt the drive, something I was unwilling to do at first, but I unfortunately had to. It took just over 4 hours to finish (during which it rattled loudly. After that, I used GParted to resize the drive to 75 GB (to make the copy process faster), booted back into Windows and encrypted the drive. "Why?", you might ask. Well, I wasn't sure whether Dell would void the warranty when the laptop would have a non-Dell drive and my contact couldn't tell for sure either, so I wanted to keep hold of the old drives until our warranty period has passed. An important thing to note is that I don't recommend to store the new encryption key on the drive. I hope I don't have to explain why. If you're worried about USB safety (and you should), print out the key, put it in a sealed envelope and store it wherever your company stores important (confidential) documents.

N.B. If you are copying to a disk that is at least larger than half the size of your current disk and you can free up more than 50% of the space on your current disk, you can skip decrypting the drive. You will most likely be able to use the Windows partition manager to shrink the drive enough to be able to copy the partition to the new drive.

Copy the MBR

I use a desktop PC running Linux for development and it had 2 unused SATA3 slots. If you don't have one available, you can also buy an external SATA3 adapter and do all this from a Linux Live CD (like Ubuntu). So from here I put both the old disk and the SSD into the Linux machine. Because the drives had been re-encrypted with Bitlocker enabled, I had to ensure the entire MBR would remain the same. The MBR is located in the first 512 bytes of a drive and consists of the boot code, the partition table and a signature. I wanted to copy them all, so I issued the following dd command:

dd if=/dev/sdc of=/dev/sdd bs=512 count=1

Mind that I already have 2 disks in the desktop PC I'm using to clone these drives, so the drives are located at /dev/sdc and /dev/sdd. If the new drive is as big as or bigger than the old drive, you can easily copy the entire drive this way (just choose a bigger block size and omit the count), but for me this wasn't the case.

Clone the partitions

You'll now see in /proc/partitions that the drive /dev/sdd is partitioned the exact same way as /dev/sdc. From here on, you can copy all partitions (one by one) from /dev/sdc to /dev/sdd. I had two partitions, the first one was exactly 100 MB and the second just over 58 GB. Choosing a bigger block size (of at most the size of your drives' cache) will make the copying faster, but if your partition doesn't consist of a round number of these blocks, it will run out of space on the partition, so this will need some calculation. For me, /dev/sda1 was easy, because it was exactly 102400 KB in size (as seen in /proc/partitions), so I chose a block size of 10485760 (10 MB), meaning 10 equal blocks were to be copied. My second partition was a little more difficult and the biggest round divider I could find that was under 32 MB was 1 MB, which is what I chose. It took just under an hour to make the copy. These are the commands I used:

dd if=/dev/sdc1 of=/dev/sdd1 bs=10485760 conv=notrunc,noerror,sync
dd if=/dev/sdc2 of=/dev/sdd2 bs=1048576 conv=notrunc,noerror,sync

Important: Make sure you get the "if" and "of" bits right, please double check! If after copying, you discover your old disk is at /dev/sdd and your new one is at /dev/sdc, you've just erased your old disk!

Resize the disk

After this, I placed the new drive into the laptop and it immediatly worked, but I had to enlarge the partition. This can be easily done in Windows' own partition manager, but be sure to temporarily disable Bitlocker and restart once before re-enabling Bitlocker, because otherwise you will have to dig up the Bitlocker key you just hid somewhere sneaky. Changes to the partition table will trigger Bitlocker to lock your computer and ask for the key. Disabling Bitlocker for the next restart prevents this from happening.

Comments (5) Trackbacks (0)
  1. Hey Jaap, thanks for your post. It is very easy to follow!

    Does this also take care of proper block alignment for the SSD?

    • Hi Christian! Because you also copy the MBR, you will not have any alignment issues in your partition table if you didn’t have them before. The optimal block size for the copy is probably the buffer size of the old disk, but make sure it can be divided by the block size of the old disk and that the total disk size can be divided by your chosen block size. Simple example: if your block size is 512 bytes and the total size of the disk is 102400 bytes and the buffer is 1024 bytes, the optimal block size for the dd command would be 1024 bytes. In real world scenarios, you’re probably best off choosing 1 MB when unsure.

      • Thanks for the immediate reply! You are right the alignment stays the same. I checked the alignment and I was lucky, it matched the 4k block of my SSD. I also heard there are tools that can correct the partition alignment, in that case, that can be done after cloning is complete.

        The whole process worked like a charm using the Ubuntu Live CD and a cheap external USB SATA case. I found a nice trick to get feedback on the progress. It works by sending a -USR1 signal to the dd process. This then prints the current progress and speed, which is very handy when copying such large data. The whole thing is described here: http://www.development-cycle.com/2012/06/watching-the-progress-of-a-dd-action/

        Thanks for putting this out here!

      • Another handy tool in the process is to use gparted. There you can clearly identify which device is which and check the whole progress.

        • Hi Christian! Yeah, I mentioned GParted because the Windows partitioning tool didn’t work too well for me, unfortunately. Cheers!


Leave a comment

No trackbacks yet.