I want to enable encryption on all of my backup tapes. I more-or-less know how to do this technically, but the procedural and human elements of implementing this are tricky.

I use HP LTO4 drives with bacula, which doesn't have any key-management features. In fact, its support for hardware encryption is to call an external script which sets the key on the drive before reading and writing.

My questions:

  1. How should I keep track of which tapes have encryption? I already have a few hundred tapes without encryption. Even if I take the time to rewrite them all with encryption, there will be months of overlap where some have it and some don't. How will bacula know whether to set the key before reading a given tape? Is the drive smart enough to read unencrypted tapes even when a key is set?
  2. If the key is ever compromised, we'll have to change it and we'll have the same problem as #1.
  3. If the key is lost, we've effectively lost all of our backups. How can I mitigate this without increasing the risk that it is compromised?
  4. Should the key change regularly? Once per year? What is the best practice?
  5. How do the big ISV backup systems handle these issues?
  • These are excellent questions that I, too, would like to know the answer to. Sep 27, 2009 at 2:25
  • 2
    Come on, Serverfault regulars... There must be better answers out there? It's a good question...
    – user2874
    Oct 1, 2009 at 19:15

3 Answers 3


Very good questions. I too would like to see good answers from people who know more about this than I do. :-)

3 If the key is lost, we've effectively lost all of our backups

Precisely, which is why many or most people don't use encrypted backups.

One possible way to go is to build a couple of "lifeboats", i.e. packages with install media, usernames and passwords for essential systems like backups, Active Directory and others (i.e. the stuff you need to load a backup if the main site has been completely destroyed in a fire, but not the backup data itself). You should store these lifeboats securely off site, for example in a bank vault, or in a high-security safe in a remote office with an alarm system. And lastly document this, so that others can figure out how to use the lifeboats after you've left the company, if needed.

4 Should the key change regularly? Once per year? What is the best practice?

From a practical point of view, I would say to not change the keys, since it quickly becomes unmanageable if you do. If you're worried about backup security not being good enough, then beef up physical security around your tapes, by using a service such as Iron Mountain, or by building a storage system with good physical security yourself.

Lastly: I would prefer to have all encryption & backup handling in one system, so there is less risk of recovery not working. By this I mean to use the built-in encryption in software like Retrospect or Backup Exec, rather than drive-level encryption.


I use a dm-crypt FS, encrypting it with a long and strong passfrase.

In order to avoid losing passfrase I wrote it on a wax sealed letter, gave it to the company property and he stored it in a security strongbox.

Of course you can give it to a notary, or whatever you think.

I think a passfrase is better for this job, as it can be only in the mind of people authorized to know it, while a digital device can be lost, stolen and so on.

You can be tortured, of course :)

  • You could use Secret Sharing and split the key into multiple, individually useless, pieces distributed among equally (un)trustworthy guardians... Jan 15, 2013 at 14:48

I'm answering this, and I'm making it a community wiki, since I am copying and pasting from an existing document.

For the record, I use Amanda Enterprise as my backup solution, and I don't use the tape encryption that it provides, for the very reasons that you mention.

I was researching tape encryption, and I came across a great whitepaper from HP talking about LTO-4 encryption, and included are many possibilities for key management. Here's a basic rundown of the available options that are presented:

• Native mode encryption (sometimes referred to as set and forget). This method controls the LTO4 encryption from within the tape drive library. There is one key that is set by way of the library management interface (Web GUO or Operator Control Panel). This method encrypts all tapes with the same key, with the downside of negatively impacting the security level.

• Software-based encryption encrypts the data before it leaves the server and keys are stored in the internal database or catalog of the application. This method of encryption places a high load on the server as the software performs many mathematical operations using host processing power. Several applications including HP Open View Storage Data Protector 6.0 offer encryption as a feature. Although the security of date encrypted this way is very high (as the data is encrypted in transit), because encrypted data is highly random it then becomes impossible to achieve any data compression downstream in the tape drive and therefore storage is inefficient.

• Keys managed by the ISV application, also known as in-band key management. The ISV software supplies the keys and manages them, and the Ultrium LTO4 Tape Drive then performs the encryption. Keys would be referenced by the key-associated data and stored in the applications internal database. (Please refer to your individual ISV backup application vendor for support of this functionality).

• An in-band encryption appliance intercepts the Fibre Channel links and encrypts the data in-flight. These products are available from several vendors such as Neoscale and Decru. Key management is from a hardened key management appliance. This method is independent of ISV software and supports legacy tape drives and libraries. Data compression must be performed by these devices as compression within the tape drive is not possible after encryption.

• A SAN fabric switch with encryption capability is similar to the in-band appliance, but encryption hardware is embedded in the switch.

• A Key Management Appliance works with enterprise class libraries such as the HP StorageWorks EML and ESL E-series libraries. It is known as out-of-band key management, as the key is supplied to the tape drive by the key management appliance. Figure 8 shows the basic components of a key management appliance. The backup applications have no knowledge of the encryption capability of the tape drive. The keys are supplied to the tape library controller by way of a network connection using a Secure Sockets Layer (SSL), recently renamed Transport Layer Security (TLS). This is an encrypted connection necessary to protect the security of the keys in transit from the appliance. To set up the security, a digital certificate is installed into the library management hardware. This establishes the necessary secure connection. The setup of the SSL/TLS uses public key encryption, but then after the handshake is complete, a secret key passes to encrypt the link. When tapes are restored, the key associated data, (retrieved from the tape), is used to reference the request for the correct key to decrypt the tape independent of the backup application.

What we're really missing is, of course, what people in the real world are doing. Whitepapers are great, but that doesn't necessarily reflect on reality.

Also, I posted this question on my blog, so some answers or examples may show up there, too.

  • +1. From the whitepaper "Where drives have encryption enabled, interchange of encrypted data is .. possible .. regardless of manufacturer." So LTO4 encryption is an open standard, that's good. (The paper also says that not all LTO4 drives support encryption, and that encryption was not part of the LTO3 and earlier standards.)
    – user2874
    Oct 4, 2009 at 2:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .