Back in August I wrote that I had started my exodus from Truecrypt as the software is no longer supported by its authors. Over the months I've experimented a lot with dm-crypt on Linux to see if it is a workable alternative for me. As it turns out, dm-crypt works great and here's how my migration went. It's a bit of a long story but since I did a couple of other things along the way that are typical maintenance tasks that have to be done when running out of disk space, I thought it's perhaps a story worthwhile to be told to pass on the tips and tricks I picked up along the way from different sources.
Migrating My Backup Drives To DM-Crypt
At first I migrated my backup hard drives from Truecrypt to dm-crypt while I stayed with Truecrypt on my PC. Instead of using a dm-crypt container file I chose to create a dm-encrypted partition on my backup drives with Ubuntu's “Disk Utility”. Ubuntu automatically recognizes the dm-crypt partition when I connect the backup hard drives to the PC and asks for the password. Pretty much foolproof.
Running Out Of Disk Space Faster Than I Thought
The next step came when my 500 GB SSD drive was close to becoming full and I had to get a bigger SSD. Fortunately prices have come down quite a bit over the last year once again and a 1 TB Samsung 840 EVO was to be had for little over 300 euros. I had some time to experiment with different migration options as the 840 EVO had a firmware bug that decreased file read speeds over time so I chose to wait with my migration until Samsung had a fix.
DM-Crypt Partitions Can Be Mounted During the Boot Process
A major positive surprise during those trial runs was that even my somewhat older Ubuntu 12.04 LTS recognizes the dm-crypt partition during the boot process when configured in the “fstab” and “crypttab” configuration files and asks for the password during the boot process before the user login screen is shown. Perfect!
Here's how my “/etc/cryptab” entry looks like:
# create a /dev/mapper device for the encrypted drive
data /dev/sda3 none luks,discard
And here's how my “/etc/fstab” entry looks like:
# /media/data LUKS
/dev/mapper/data /media/data ext4 discard,rw 0 0
Sins Of The Past – Hard Disk Migration The Hard Way
When I initially upgraded my from a 350 GB hard drive to a 500 GB SSD I used Clonezilla to make a 1:1 copy of my hard drive to the SSD and used the extra space for a separate partition. After all, I couldn't imagine that I would run out of disk space on the initial 350 GB partition anytime soon. That was a bad mistake as it turned out pretty quickly, as the virtual machine images on that partition soon grew beyond 200 GB. As a consequence I moved my Truecrypt container file to the spare partition but that only delayed the inevitable for a couple of months. In the end I was stuck with about 50 GB left on the primary partition and 100 GB on the spare partition, with the virtual machine images threatening to eat up the remaining space in the next months.
As a consequence, I decided that once I moved to a 1 TB SSD, I would change my partitions and migrate to a classic separation of the OS in a small system partition and a large user data partition. I left the system partition unencrypted as the temp directory is in memory, the swap partition is a separately encrypted partition anyway and the default user directories are file system encrypted. In other words, I decided to only encrypt the second partition with dm-crypt in which I would store the bulk of my user data and to which I would link from my home directory.
Advantages of a Non-Encrypted System Partition
There are a couple of advantages of a non-encrypted system partition. The first one is that in case something goes wrong and the notebook refuses to boot, classic tools can be used to repair the installation. The second advantage is that Clonezilla can back up the system partition very quickly because it can see the file system and hence only needs to read and compress the sectors of the partition that are filled with data. In practice my system partition contains around 20 GB of data which Clonezilla can copy in a couple of minutes even on my relatively slow Intel i3 based notebook. If I used dm-crypt for the system partition, Clonezilla would have to back up each and every sector of the 120 GB partition.
Minimum Downtime Considerations
The next exodus challenge was how to migrate to the 1 TB SSD with minimum downtime. As this is quite a time intensive process during which I can't use the notebook I played with several options. The first one I tried was to use Clonezilla to only copy over the 350 GB primary partition to the new SSD and then shrink it down to around 120 GB. This works quite well but it requires shrinking the partition before recreating the swap partition and then manually reinstalling the boot sector. Reinstalling the boot sector is a bit tricky if done manually but the Boot-Repair-Disk project pretty much automates the process. The advantage of only copying one partition obviously is that it speeds things up quite a bit. In the end I chose another option when the time came and that was to use Clonezilla to make a 1:1 copy of my 500 GB SSD including all partitions to the 1 TB SSD. This saved me the hassle of recreating the boot sector and I had the time for it anyway as I ran the job over night.
Tweaking, Recreating and Encrypting Partitions On The New SSD
Once that was done I had a fully functional image on the 1 TB SSD with a working boot sector and to continue the work, I put it into another notebook. This way I could finish the migration while I was still being able to work on my main notebook. At this point, I deleted all data on my spare partition on the 1 TB SSD and also the virtual machine images on the primary partition. This left about 20 GB on the system partition. I then booted from a live Ubuntu system from a CD and used “gparted” to decrease the system partition from 350 GB down to 120 GB and to recreate a Linux swap partition right after the new and smaller system partition. Like the 1:1 Clonezilla copy process eariler, this takes quite a while. This is not a problem, however, as I could still work on the 'old' SSD and even change data there as migrating the data would only come later. Once the new drive was repartitioned I rebooted into the system on my spare notebook and used Ubuntu's “Disk Utility” to create the dm-crypt user partition in the 880 GB of remaining space on the SSD.
Auto-Mounting The Encrypted Partition and Filling It With Data
As described above it's possible to auto-mount the encrypted partition during the boot process so the partition is available before user login. As in my previous installation where I mapped the “Documents” folder and a couple of other directories to the Truecrypt volume, I removed the logical links for that and recreated new ones that pointed to empty directories on the new dm-crypt volume. And once that was done it was time to migrate all my data including the virtual machine images to the new SSD. I did this by backing up all my data to one of my cold-storage backup disks as usual and restoring it from there to the new SSD. The backup only takes a couple of minutes as LuckyBackup is pretty efficient by only coping new and altered files. To keep the downtime to a minimum I swapped the SSDs after I made the copy to the backup drives and started working with the 1 TB SSD in my production notebook. Obviously I restored the email directory and the most important virtual machine images first so I could continue working with those while the rest of the data was copied over in the background.
Thunderbird Is A Special Bird
In my Truecrypt installation I used a logical link for the mail directory so I could have it on the Truecrypt volume while the rest of the Thunderbird installation remained in the user directory. At first I thought it was only necessary to replace the local link to the mail folder but it turned out that Thunderbird also keeps the full path in its settings and doesn't care much about logical links. Fortunately the full paths can be changed in "Preferences – Mail Setup".
Summary
There we go, this is the story of my migration away from Truecrypt, upgrading to bigger SSD and cleaning up my installation at the same time. I'm glad I could try all things on a separate notebook first without Ubuntu complaining or making things difficult when it detected different hardware as other operating systems perhaps would have. Quite a number of steps ended up in trial and error sessions that would have resulted in a lot of stress if I hadn't known about them during the real migration. It's been a lot of work but it was worth it!