Video Screencast Help

Backup Exec 2012 encrypting tapes with Quantum's QEKM

Created: 13 Dec 2013 • Updated: 17 Dec 2013 | 13 comments
This issue has been solved. See solution.

I need to enable hardware encryption yet I don't want Backup Exec to manage any keys. Quantums has a QEKM, Quantum Encryption Key Manager Server, that handles all the key. I noticed that in the past on other backup software, that if the QEKM server is down the backup will not happen. With Backup Exec it appears it doesn't matter. How do I set Backup Exec to ignore the keys and still do hardware encryption?

I see under each drive in Backup Exec that it says under "Supports Hardware Encryption:" No

Which is incorrect because I own the license and the library says it is working just fine. Is this a drive issue with Backup Exec?

Operating Systems:

Comments 13 CommentsJump to latest comment

Larry Fine's picture

re: I see under each drive in Backup Exec that it says under "Supports Hardware Encryption:" No

That is correct.  When the library is configured for QEKM, the tape drives now tell BE that they don't support encyption by BE so that you don't accidently get double encryption.

If the QEKM key server is down, the tape drives should complain to BE and the backups will fail.

With BE managed encryption, you control which jobs get encrypted.  With QEKM, ALL jobs get encrypted.

If you find this is a solution for the thread, please mark it as such.

pkh's picture

If the QEKM key server is down, the tape drives should complain to BE and the backups will fail.

How do you know how would BE react in a situation like this?

 

Could it be that the QEKM is transparent to BE? That is, BE does not know or care about the existence of QEKM just like NBU.

http://www.symantec.com/docs/TECH148573

scoutt's picture

And that is what I would expect, but the jobs continue to run regardless if the server is down or not. Last nigth all jobs ran perfect, but the QEKM service was not started. Accidently forgot it had restarted. For QEKM you have to manually restart the service each time a reboot.

scoutt's picture

Been playing around with somethings and rechecking all settings, I now have it so the tape library alerts me about not being able to connect, yet the job continued on without failing

pkh's picture

BE is not designed to work with other software/hardware which turns on hardware encryption on the tape drive. You can use these but you must ensure that they are working if you want encryption. As you have experienced, BE will continue with the backup regardless of whether these are working or not. There was a previous discussion in which the user asked about a HP device which turns on hardware encryption on a HP library.  He was told not to use it, but use BE hardware encryption instead.

Why do you want to use QEKM to manage your encryption keys rather than BE?

When you use QEKM, rather than BE, to manage the encryption keys, what happens when you are at a DR site with nothing up?  You would not be able to use your encrypted tapes because the QEKM server has not been recovered and you need to read the QEKM-encrypted tapes to recover the QEKM server. Wouldn't you end up with a chicken and an egg situation?

Larry Fine's picture

re: BE is not designed to work with other software/hardware which turns on hardware encryption on the tape drive.

Umm, yes it is.

http://www.symantec.com/docs/TECH59814

Backup Exec for Windows 11d and Library Managed Encryption (LME) Technote/Whitepaper

An LME/QEKM environment IS transparent to BE, when LME is working correctly.  But when the tape drive cannot get a key from the key server and/or cannot encrpyt like it is told to, it is expected that the tape drive will report an error to BE.

If you find this is a solution for the thread, please mark it as such.

pkh's picture

Bad choice of words.  By "not designed to work with ...", what I meant is that BE does not care about the other hardware/software, so even if the tape library using QEKM throws an error that it cannot get the encryption key, BE will still carry on with the backup.

SOLUTION
scoutt's picture

I have been using QEKM way before I started running Backp Exec. That statement almost sounds proprietary in a way. Use ours or don't use anything else kind of mentality. The software I had before only did software encryption and most of those are network intensive, being soley encrypted from a hardware point of view takes all that out of the equation. Why not use the tools that are given to me?

Yes it is almost like a chicken and egg thing, but it takes less than 30sec to install and if I can use any running VM to make it work. Besides, the QEKM server is not backed up to tape for that very reason. I can either move the VM (which is already snapped to DR anyway) or create a new one. All keys are backed up to CD as well. Just import keys and way you go.

So it appears as long as the QEKM server is up it should be encrypting. One would test this by restoring from an encrypted tape, if QEKM server is down it should fail, correct? but will it fail the restore job?

pkh's picture

I guess it is about being self-contained.  In a DR situation where nothing is up, if you are using BE encryption, then all you need is the pass-phrase, to get your restores going, whereas using QEKM, you need to restore the QEKM server first, etc.

If the QEKM server is down, then the restore would probably fail because BE cannot read the tape.

You can use QEKM, but it is up to you to manage it.  I can understand why you use QEKM before, but why don't you make the switch now that you have BE.  To use hardware encryption with BE is easy, all you need is to create your encryption key, and enable your library and your job to use hardware encryption.

scoutt's picture

If the QEKM server is down, then the restore would probably fail because BE cannot read the tape.

and that's what I would expect.

There is no managing at all, it runs behind the scences. Same with the BE server, we just have to make sure it is up and running. I will have to think it over on whether to use BE or not. Now that it is running on QEKM it would mean for me to change 182 jobs to use BE's encryption. sounds eaiser to just keep using the way it is now.

 

hanks all for the insight.

pkh's picture

Does all the tapes created by the 182 jobs leave the premises?  For me, I do not encrypt tapes which do not leave the premises.  There is a performance penalty to be paid for encryption.  One of my jobs will run about 1 hour faster without encryption.  With QEKM, it is all or nothing.  You cannot selectively encrypt tapes.  With BE you can specify through the jobs which tapes to encrypt.  If you turn of QEKM, you might only have to enable encryption on some jobs and save yourself some time with the other jobs which do not need encryption.

scoutt's picture

Thats is why I like QEKM, there is very minimal performance hit.but yes, all our tapes leave the premises. and yes, I need every tape encrypted, no matter the job. When I accidently left QEKM turned off they didn't run any faster. The only hit you "might" see is when the tape is loading, not the duration of the job.

 

pkh's picture

Don't get the impression that using BE hardware encryption to supply the encryption key slows things down.  Regardless of whether you use QEKM or BE hardware encryption to supply the encryption key, the encryption process is the same, i.e. it is done by the tape drive hardware.  Here is a quote from page 3 of the Quantum white-paper on QEKM (attached)

There is no performance penalty for using out-of-band versus in-band encryption key management.
AttachmentSize
quantum key management white paper.pdf 1.72 MB