NBU Encryption issues - Quantum and Symantec

I would agree with KMS...if the data coming out of the restore are unencrypted then the decryption is working, whats left is a performance issue.

But that doesnt explain your log snippet ...Encryption unavailable.

Do yourself a favour: on the target master only , find yourself a big fat file, a few Gb , (an iso supplied by Symantec say!), create a policy for it, write it out to tape, restore from tape to a different location and compare with original and observe.

Bugs and misconfigurations aside, this will be rapid both ways and will be encrypted to tape and decrypted on restore. You might want to check this ie report on the image/observe during both backup and restore that encr/decr is happening.

I would add to check the blocking factor on tape: this can slow things: but thats easily checked from the backup viewpoint: what speed backup do you get? ( Its a good idea to up the blocksize for performance to 256k or more - check for LTO5 what you can use). I dont think this is the issue, as you would have logged it as a backup issue not a restore issue. The blocking is (normally) handled automatically on restore since you cant do anything with it at that point. Tape drive issues notwithstanding.

How long have you been running with this setup?  Any other odd issues? I ask since if there are name resolution issue this can be very detrimental to netbackbackup generally.

This sounds like a fun interesting problem, my rates are very reasonable!

 

Jim

I would agree with KMS...if the data coming out of the restore are unencrypted then the decryption is working, whats left is a performance issue.

But the data coming out of the restore is encrpyted - at least KMS is set up, and it is using an ENCR_ pool.

 

Do yourself a favour: on the target master only , find yourself a big fat file, a few Gb , (an iso supplied by Symantec say!), create a policy for it, write it out to tape, restore from tape to a different location and compare with original and observe.

Interesting idea - assume you mean unencrpyted, correct?  Well, thats my only option since any attempt at a new encrpyted backup fails :)

 

 

How long have you been running with this setup? Any other odd issues? I ask since if there are name resolution issue this can be very detrimental to netbackbackup generally.

 

The DR site has been configured for about 1 1/2 months.  The prod site  pre-dates me, as far as I know since it is still running 7.0 it's been around since - 7.0 came out!  Before we started this project they were using the Spectra proprietary Encryption.

Wonder if we should have tried a backup out there after running a long erase on the media, just in case Spectra left anything wierd on the headers.

 

Of course that doesnt help with the current situation, but something else occurs to me:  If the tapes I am trying to use in this 7.0 environment were once upon a time used in a 7.5 Encrypted environment, might these be some of the symptoms? i.e. can't encrypt because its already encrypted via a method that 7.0 era KMS doesnt know about?

 

Interesting point re versions, that could have mileage - and indeed more work for you!

I am not familiar with the on-tape format: dd would be the tool here if you were unix, hopefully others might chip in with information on the subject under Win.

You say the data coming out of restore is encrypted. How do you know? To clarify my thought: determine its encrypted on write and decrypted on read: once its back on disk you wont be any the wiser.My drives tell me "encrypting" when I write, and of course the reverse on read.The catalog should also tell you. 

For whats its worth, I've done this kind of exercise as part of DR several times and it should work fine.

You are certain the two environments are the same versions/rev/patches?

Jim

It depends on the OS - solaris it is viewed in ulimit -a and can be set in /etc/system Could you confirm the OS involved

It depends on the OS - solaris it is viewed in ulimit -a and can be set in /etc/system
Could you confirm the OS involved

 

Oh that would help, wouldn't it! :)

 

All systems involved (Both masters and one media server) are Windows 2008 Server R2 Enterprise

OK, far as I know no concerns with this on windows, I think the max is around 16000 which is fine. This issue is more unix/ linux which has a low default that requires increasing to min of 8192

OK, far as I know no concerns with this on windows, I think the max is around 16000 which is fine. This issue is more unix/ linux which has a low default that requires increasing to min of 8192

You mentioned earlier, if KMS wasn't configured correctly it wouldn't work at all - I agree, all or nothing. I think it is also 'very unlikely' for the config to give intermittent results (that's my sensitive way of suggesting not a chance ... but with a 0.1% get out clause in case I'm wrong ... ;0) ) I am wondering if this is something to do with the data held on the internal chip in the cartridge - I don't know if this is used in KMS, but it does hold quite a lot of info about the tape, so there is a possibility it is. Can you advise of the tape brand ? This may be different from what is written on the tape (Eg. Oracle branded tapes are actually made by Imation (or at least they used to be)). If you look in the bptm log, you should see the manufacture listed - I guess searching for 'man' might narrow down the search. If they are fuji, we might be in luck as I know someone who works there who might be able to confirm a couple of things. Is there any current Symantec case number as a matter of interest ? Even if not, I can ping an email direct to to a few people to see if we can get some more ideas. To answer Jim's question on 'dd' for win. I think we're stuffed there, I am not aware of any 3rd party equivalent. There is a utility within NBU for windows, but I can't remember what it's called and I think it's only useful for positioning - I'll ask about.

>>since any attempt at a new encrpyted backup fails :)

 

Wait a sec...  Does this mean you can't write a new tape? 

WR is confused, me too! Its catching.

I think we all need a rundown of what does what where, followed by a stiff drink.

I had another idea: if the restore does work, is there a chance that you have a monumentally large MPX setting, combined with a huge number of small files? This scenario could slow thing down majorly but it would need to be mpx 100 and sub 1k files. Im guessing at the numbers but both slow things down so in combo you'd get the (un)desired effect.

Jumping ahead a bit tell us about the lifecycle of a single large file from backup through to restore, preferably carried out in isolation to everything else.

Jim