Netbackup 7.x "Client Encryption" and 32bit Linux/Unix clients running 6.5.x

[RLeon]

Hi all,

Environment:
We have a Win2003 32bit Netbackup 6.5.0 Master Server with a mix of 32bit and 64bit Linux/Unix clients.
All our *nix OS versions are supported by Netbackup according to the 6.x Compatibility List.
The environment will soon be upgraded to Netbackup 7.1.x (Don't want to do 7.5.x now).

We plan to upgrade the 64bit clients to Nbu 7.x,
but leave the 32bit clients running in Nbu 6.5.x., because Netbackup 7.x client software does not support 32bit *nix.
This should work for normal backup and restore operations because 7.x servers are backward compatible with 6.x clients.

About Client Encryption:
We have been using the Netbackup Client Encryption feature, where each client has its own encryption key by using the "bpkeyutil" command.
Backup and Restores of client encrypted data have been successful.
The encryption feature is verified to work by observing that if a different restore destination does not have the key, the restores would fail.

Query:
After the upgrade to Netbackup 7.x, some of our clients would still be running Netbackup Client version 6.5.x (because of 32bit *nix OS).
We have a few questions but couldn't find much in the guides:
 - Would Client Encryption work between a 7.x server and a 6.5.x client running 32bit *nix OS?
 - Would the same encryption keys still work, or do we have to generate new keys for the 7.x clients?
 - Same question as above, but for the 6.5.x clients?
 - If new keys are needed, how do we restore data backed up using old keys?

Thanks all,

RLeon
 

[CRZ]

The "old" keys should work fine after the upgrade.  I can't find anything that says otherwise.  I don't believe, as far as CEO, we made a whole lot of changes between the versions, other than automatically including the package in an installation instead of making it a separate add-on.  With CEO, the encryption takes place on the client, so when you're updating your master/media servers, it's not actually changing anything to do with the client-side encryption.  And obviously the keys stay on the client.

(DISCLAIMER: I've never actually TRIED this)

[Marianne]

Seems 6.5 encrypted backups can only be restored to 6.5 and 7.x to same version.

See this forum discussion: https://www-secure.symantec.com/connect/forums/how-encrypted-backup-can-restore

[CRZ]

Interesting stuff, Marianne...  I forgot about that thread.

I did some digging after checking that discussion and TechNote.  It appears that what's described in the TechNote is actually a defect in the bpkeyutil command (Etrack 2535074).  There is a workaround, which is to use a "previous" version of "bpkeyutil" (which can be accomplished by restoring to a client of the same version... but isn't exactly the same thing).  There is also a procedure to update keys if this defect is encountered, which I won't go into here.

But the definitive word is that ALL old encrypted backups are SUPPOSED to be able to be read, no matter what version you've upgraded the client to...which isn't even actually happening in RLeon's case, as his CLIENTS are remaining at 6.5, while the servers are getting upgraded to 7.x.

[RLeon]

Thank you both for the information.
I've read through the info from Marianne's link.
Please let me know if I've got everything correct:

1. Officially from Symantec, encrypted backups created by a 6.5.x client could be restored to 7.1.x clients if they use the same key/passphrase.

2. The above 7.1.x client could just be the same host with the Netbackup version upgraded from 6.5.x.
   2a. The same key file is used for both creating new encrypted backups,
   2b. and also for restoring the older encrypted backups created before the Netbackup client version upgrade.

3. However, there seems to be a defect, and both 1. and 2. are not actually possible. The 6.5.x encrypted backups will not restore to 7.1.x clients even with the same key/passphrase. (Same actual host or not.)

4. The current workaround is to only upgrade the clients to 7.0. (Do not use 7.0.1 or 7.1.x.) This way, 1. and 2. will be possible.

Thanks all,

RLeon

[CRZ]

1. I believe this to be correct.

2. I believe this to be correct.

3/4. I am not sure that it becomes "not possible" for ALL clients.  We've seen it reported on Windows clients for sure.  It appears the issue was introduced in 7.0.1, so 7.0 would be OK.

I would add that in the event that an updated-to-7.x client does NOT restore an encrypted backup from the previous version, there are workarounds to mitigate, but they do involve updating the key/passphrase.  It would probably require a call to support and an escalation, but it can be done.  You can't "lose" those encrypted backups should you need to restore them later.  (But it may be a but of a pain, especially if you have a lot of updated clients and a lot of old backups.)

Also, from the previously referenced TechNote, it appears that it's possible to upgrade to 7.0, update the key/passphrase WHILE you're at 7.0 using it's bpkeyutil, and then you WILL have a key that should be fine for any future backups, through any future upgrades to 7.1 or 7.5 or future 7.x.

Finally, I have to covery my butt and stress that any advice I offer here on Connect should not be taken as solid as actual advice given to you in the context of a support case.  If you have any questions or concerns at all, please open a new case, mention this thread and Etrack 2535074 and let them be known.  Ounce of prevention and all that.  :)

[RLeon]

Thanks for your input Chris.

I fully understand that your advice here does not represent that from a support case.

Since there seems to be potential problems if we upgrade 6.5.x clients directly to 7.1.x., should/could we plan the upgrade in stages as follows:

1. Upgrade the client from 6.5.x to 7.0.

2. Add a new passphrase to the keyfile using the 7.0 bpkeyutil. (add new, not edit existing). So the keyfile now has a passphrase from the 6.5.x bpkeyutil, and another passphrase added by the 7.0 bpkeyutil. It now has two passphrases.

3. Test that new backups could be encrypted, and old 6.5.x encrypted backups could be restored.

4. Upgrade the client from 7.0 to 7.1. (may also patch to 7.1.0.4 at this point).

    4a. (Optional?) Add a 3rd passphrase to the keyfile by using the 7.1.x bpkeyutil.

5. Test that new backups could be encrypted, and old 6.5.x encrypted backups could be restored.

Basically, by staging the upgrade through version 7.0, it is POSSIBLE that the "defect" could be bypassed altogether, right?

Thanks!

RLeon

[CRZ · Accepted solution]

I THINK that's right.

I would go so far as to say I don't even think you'd need to do step 4a (unless you really wanted to).

What'd I'd love to say is that a future NetBackup version will handle ALL of these keys just fine without you having to do anything, as that was always the intent of the feature.  Problem is, I'm not sure which future version that might be...if that means 7.5.0.3, 7.6, 8.0, or something even later than that.  What I CAN say is that this defect IS known and we certainly intend to address it (beyond this thread, even!).

Again, this might be something you'd want to bring up to your Sales Engineer, or Account Manager, or whatever you have, as well as with a support case, letting them know that that open Etrack 2535074 is one you feel you are directly affected by, have concerns about, and so forth - and make sure your voice is heard.

(And finally, if you DO follow your procedure above, please come back and let us know how it went!  I'm really curious how this turns out now and am wondering if there's a future TechNote in it.  :)  )

[RLeon]

Thanks for your suggestions Chris.

I now have a better understand of what's going on.

At least I don't have to do much with the 6.5.x clients. (The 7.1.x server should work fine with their keyfiles.)

The Etrack number could be handy, so thanks for that as well. But then, if you recall, you gave me an Etrack number for a different problem in an entirely different thread some time ago. I have to say, it wasn't very, erm... "stimulating" for the Sales Engineers and Account Managers that we have as contacts over here. Someone else from elsewhere might be able to make better use of Etrack numbers with their Symantec contacts, I hope.

Thanks,

RLeon