Trying TrueCrypt full-disk encryption

I've been looking for a way to secure the data and IP on my laptop without a significant sacrifice of performance, reliability, or convenience. I looked into a few different directions:

BitLocker - This actually became an option once I upgraded from Vista Business to Ultimate (had to rebuild my dev laptop after an unfortunate Windows Update problem that MS couldn't solve). However, my laptop doesn't have a TPM, so I'd have to use an external USB key to boot. External key = high on the security scale, low on convenience. Next!

Windows EFS - Convenient, and allows the flexibility to encrypt at the folder level, but is difficult for multi-user access (something I do more of than I'd like). There's also a major performance hit for SQL Server operations. FAIL.

SQL 2008 Transparent Data Encryption - This one was intriguing, but it ultimately sounds like it wouldn't work well for my needs. I'd have to have the same keys used to create the backups, or encrypt AFTER restore of an unencrypted backup. Also, obviously limited to SQL Server, which doesn't cover everything I need. Either way, not going to fly.

TrueCrypt - Free, supports both file-based volume encryption, as well as bare-metal volume encryption. I'd used TrueCrypt before for the former, as well as for non-performance-sensitive stuff where we needed to move large volumes of sensitive data around on removable drives. I couldn't find anyone talking about the real-world performance hit, though. Windows boot volume encryption support is also fairly recent, so that made me a little nervous.

A few weeks ago, I decided to try the TrueCrypt route. To start, I created a file-based volume and did some testing in there. My benchmark was far from scientific, but I tested with things I do every day. I did a full SVN checkout of a code branch, opened and built it in Visual Studio, restored a SQL Server DB there, etc. Performance wasn't horrid, but it wasn't anywhere close to my bare-metal performance either- especially the SQL Server DB restore (took about 5x as long as on bare-metal). Most of the other operations I timed took anywhere from 1.5x-2x as long. There also doesn't appear to be a way to auto-mount file-based volumes, which means on every boot, I have to manually mount the volume (by entering the password), then restart the SQL Server. Gets old fast.

A file-based volume just wasn't going to cut it. Two weeks ago, I finally bit the bullet and decided to try hitting "Encrypt System Partition/Drive" (AFTER a full backup, thankyouverymuch). Making the leap easier to take was the fact that the process claims to be fully reversible. The experience was quite good- after choosing a password and generating keys, I burned a recovery CD (I'm glad the UI makes such an issue of this!). After the CD had burned and verified, it proceeded to background-encrypt the disk. I could theoretically use the system during this time, but decided not to try- just left it to crank overnight. When I came back the next morning, all was well. I rebooted and held my breath. I was presented with the TrueCrypt password prompt, followed by the normal Vista bootup process. Cool!

I went and retried my real world benchmarks, and much to my surprise, most of them were indistinguishable from their non-encrypted counterparts! The only one that was notably slower was a SQL DB restore- and that was only when the backup had a large log file. In case you didn't know: SQL Server won't allow you to resize the logfile on restore, so it allocates and zeroes an "empty" logfile matching whatever the server's logfile size was. We pre-allocate production server logfiles fairly large so they don't have to autogrow during large transactions. The side-effect is that restores to a clean DB are painfully slow. If I re-created the backup after truncating down to a reasonably-sized logfile, the restore performance was almost exactly the same as on a bare-metal, unencrypted drive.

Two weeks in, I'm really impressed with what the folks at TrueCrypt have done. 6.0a is as-advertised, and the performance hit is pretty minimal for just about everything I've tried. Looks like this problem is solved!