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:

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

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:

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:

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

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:

 

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

 

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.