<b>From OSSG</b>: Encryption is a tool that needs a very clear objective. You can put it on most any level of the backup flow, but each level has its own risk characteristics.
Most people simply want to avoid headlines like “company xyz lost a backup tape with 2.99E8 customer credit card numbers on it”. This can be done with tape encryption.
Tape encryption can be done several ways: on the host or on the tape device are the most common. Most current lines of tape drives have encryption built in. LTO4 , and IBM’s jaguar drives both do, but LTO3 and before do not. If your drives themselves will do the encryption, this usually allows you to continue using compression as they will compress the data and then encrypt it. Performing the encryption somewhere else, will add entropy to the data, rendering it uncompressable. Drive based encryption also prevents your backup host from having to do a fairly processor intensive encryption task on top of its usual workload.
Once you know how you will do your encryption, you need to start worrying about a key manager. If you have your host perform the backups, it will have to manage the keys. Your tape vendor should also be able to provide a key manager that can either work on its own, or interface with a host’s key manager. The goal is to have the private keys available in case of a restore, even if the site (or key management server) is compromised. The best way to do this is to have the key manager database replicated or copied off site in a secure manner.
<b>From Jervin</b>: SAN encryption is also available, on fibre channel and IP SANs, which would offer a different level of protection for data “inside the building.” Key management can be handled a the host level, or tied in with other security efforts. [In addition to tape,] you should also look like encrypting the disk drives of any system you have, especially if it is accessible via the outside, or leaves the building: laptops, webservers or mail servers that have access to sensitive data in the intranet, and so on.