I have an LTO5 tape that has been backed up with hardware encryption. It has a variety of different types of backup sessions (flat files, MS SQL servers, MS Exchange) and I've been given the passphrase, so I've re-created the key and can pull off the flat files without any issue. The client has asked me to create an unencrypted version of the tape (they wish to use various 3rd party tools to extract the SQL and MS Exchange backups), and I've tried doing this with the duplication function, but I can't get it to work.
I have a second tape drive in which I've mounted a freshly erased and labelled LTO5. When I try duplicating the original sessions from the encrypted tape onto it, I'm given the option of types of encryption (I chose none) but BE is switching on hardware encryption on the target drive anyway. This is regardless of whether I use DirectCopy, or choose to actually have encryption (which then gives me the option of choosing which key to use).
Any ideas? Is there some option or other hidden deep in the bowels of BE that's telling it to encrypt everything it writes to tape by default?
You should be able to run a "duplicate job" for each backup set on the tape that you wish to replicate. There is not a "single button" solution, that I know of, to replicate a whole tape with a bunch of different backup sets on it. In the "Duplicate Job" options, you can specify what encryption you want, including "none".
Yes, there is a default option for "backup to tape" jobs, along with default options for all the other job types. But that just sets a default, not a rule, so when you create each new job you can override the default.
Is your source a physical LTO5 tape cartridge? If you don't have an appropriate VTL, then the "enable DirectCopy to tape" option has no effect and the job log should say "disabled".
Is your job log for the duplication job showing that encryption is happening? or how are you determining the destination tape is getting encrypted?
|Job Operation - Duplicate|
Thanks for the reply.
Yes, I'm copying from a physical LTO5, and writing out to a physical LTO5 drive/tape.
But the dialog box I get doesn't automatically disable the DirectCopy option. It allows me to tick it or not tick it:
BE does allow me to select multiple backup sets to duplicate to tape, but even when I try to do them one at a time it's still encrypting them. I know this because i) the output drive's blue "encryption" light comes on, and ii) because when I try to read the tape with other tools the drive returns an error as soon as it hits the first encrypted area (incidentally, if anyone knows a straightforward way to find the raw 32 byte (256-bit AES) encryption keys generated by BE from a passphrase, that would allow me to use other tools to duplicate the tape).
When I try to duplicate the sessions to disk file(s), and then look at the properties for those backup sessions, they're marked as "encrypted" too.
Oh! And before anyone suggests the "export database keys" function, that just exports the encryption keys used to encrypt the database, not the keys stored in the database used for backup/restore!
Well yes, that does seem to be the case.
But why? Seeing as that particular instance of BE has to have the right key and send it to the drive in order to pull off the decrypted data in the first place, there's clearly no security issue.
The fact it's not mentioned in the documentation, and the duplication window offers "no encryption" as an option (and then ignores it) suggests it's a bug.
No. It is not a bug. The "no encryption" option is for when you duplicate from disk to tape and you have already encrypted the disk backup set. Without specifying "no encryption", you would be doing a double encryption.
And you know this because... you're on the design/development team?
Think about it. The software "knows" you're duplicating from an encrypted tape. And, once you've selected a tape to output to, it knows you're writing to tape. If what you're saying is correct, why is it even giving the user the ability to select a particular encryption option on the output tape, if it's going to ignore the user's choice? Without even warning them?
If this is by design then it's poor design. And it's also placing pointless obstacles in the way of users trying to get something done (and no, before you say it's for security reasons, it categorically isn't; the user is unable to read data off an encrypted tape without having the right key to begin with). And if it's not by design... and is counterproductive... and isn't documented... then it's a bug.
I didn't say it did.
When you read from an encrypted tape, the drive decrypts the data before handing it over; i.e the data itself is no longer encrypted. Asking a program to then write that data to tape without encryption is not the same as asking it to decrypt the data; that's aready been done by the drive hardware.
Thanks for taking the time to pass on my problem to engineering.
The title and "problem" sections of the article are correct but it seems to me the "cause" doesn't quite get it right:
"A duplicate backup copies the data from source set as it is. The data is not decrypted even if the duplicate job is set to use no encryption"
When BE attempts to duplicate a backup set from a tape that was written using hardware encryption, the drive will refuse to read the data unless the correct key is given to it by BE, at which point the drive will decrypt the data before passing it to BE to be duplicated. If the wrong or no key is presented by BE, the drive will return an error and the job will fail. So I think the sentence should read something like:
"A duplicate backup is supposed to copy the data from source set as it is. However, the duplicated data is being re-encrypted even if the duplicate job is set to use no encryption".
In terms of solution, it seems to me as a user that the best way of dealing with the problem is to ensure that the user's instructions are followed with regards to whether the duplicate is encrypted, and - if so - how that encryption should be carried out: hardware/software, and with what key.
Thanks again, and please feel free to PM me if I can be of any service.