Server Backup and BitLocker

A lot of attention has been given to encrypting laptops because they are often stolen and their drives may contain sensitive company information.

Another popular topic is the need to store backup data off site so you can recover in case of disaster. In the small business arena, this is often accomplished by saving the data to external hard drives that are rotated off site.

But how secure are those backup drives once they leave your office? While a laptop may contain excerpts of data, that server backup drive contains all of your proprietary data, and likely private information about your clients as well. What happens if that drive is lost or stolen, either while en route or while stored off site?

BitLocker and External Drives

Windows Server 2008 introduced BitLocker as a built-in full-disk encryption (FDE) engine. Unfortunately, BitLocker makes it difficult to work with external drives in a server environment. Why? Because if you connect a BitLocker-encrypted USB drive to a computer, even if you have set it up to auto-unlock, it will not unlock until a user logs on. Apparently the unlock keys for removable drives are stored with the user profile, not the computer profile. Obviously in a server environment, this is unacceptable:  the server must have access to attached storage even if no one is logged on to the server console.

eSATA to the Rescue

Fortunately, there is a workaround:  use eSATA to connect external drives. Windows sees eSATA drives as internal drives, not removable drives, and you can enable Bitlocker with auto-unlock just as if they were internal data drives. In this example, the S: and T: drives are external eSATA drives, while the R: drive is an external USB drive which is only available in user-specific “Bitlocker To Go” mode:

eSATA and BitLocker 1

When you turn on BitLocker, choose “Automatically unlock” so the drive’s key will be stored on the system volume:

eSATA and BitLocker 2

Be sure to save the recovery key to a file and/or print it out. Keep it in a safe place so you can decrypt the volume elsewhere in a disaster recovery scenario. Test this by attaching the drive to another machine and making sure you can unlock it with the BitLocker recovery key.

Note that the system volume must be encrypted first, which means you must provide a Bitlocker “master” key to boot the server. See this post for a tip on how to use Bitlocker in a server environment when you need to be able to boot remotely.

If you are using the Enterprise or Datacenter editions of Windows Server 2008 R2, you may find that eSATA drives are offline by default. The simple fix is described here.

Safely Remove eSATA Drives

The next challenge is, how do we safely remove an eSATA drive so we can take it off site? Because Windows thinks eSATA drives are internal, not removable, they are not listed when you choose Safely Remove Hardware. Only the external USB drive is listed:

eSATA and BitLocker 3

Here a small, free program called HotSwap! has proved invaluable. Just copy the 64-bit version of this program to a folder under C:\Program Files, run HotSwap!.exe, and a small icon with a red arrow will appear in your system tray. Right-click on the icon to see program options, or just left-click to remove a drive:

eSATA and BitLocker 4

and within a few seconds the drive is ready for removal:

eSATA and BitLocker 5

My understanding is that HotSwap! works by uninstalling the drive. You could do the same thing from Device Manager.


Not Perfect

HotSwap!, and probably the underlying device uninstallation approach, are not perfect. If you have an open file on the drive, for example a VHD attached to a running virtual machine, you may see this dialog:

eSATA and BitLocker 6 

If you close the file and try again, you may get the dreaded “system restart requested” dialog:

eSATA and BitLocker 7


Once that happens, I’ve found that the only way to remove the drive safely is to restart the server.

Backup Staging

In general, my approach is to “stage” backups on the S: drive, which remains permanently attached to the server, then use a daily robocopy job to copy the S: drive to the T: drive, which rotates off site with another T: drive. This means that the S: drive is always available and always has the same shared folders. The T: drive is only accessed during the daily copy, so I shouldn’t run into the “system restart requested” issue when removing the T: drive. The one thing I still need to test is whether I can host a backup VHD on the S: drive and reliably copy it to the T: drive while the VHD is attached to the VM.

4 thoughts on “Server Backup and BitLocker

  1. Mark Berry Post author

    Interesting. I wonder why they make a distinction between SATA and eSATA. The OS seems to see them pretty much the same.

  2. Steven

    The OS will still show an eSATA as a removable drive for hotswapping, but will see it as a fixed drive for Bitlocker and O/S booting (the only removable connection type to appear so without resorting to boot “magic tricks”). Here’s one issue where this is important:

  3. Mark Berry Post author

    In my experience, the OS does not show eSATA drives as removable for hotswapping. See the section “Safely Remove eSATA Drives” in the post above.

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.

This site uses Akismet to reduce spam. Learn how your comment data is processed.