How to Backup Up KMS files

[liuyang]

Hi, our customer's appliance is NBU5230 appliance (2.6.0.3), which is the only NBU server in their environment. Recently they plan to implement KMS in the appliance. I did some checking and found for normal master server, we can back up the KMS files (KMS_DATA.dat, KMS_HMKF.dat and KMS_KPKF.dat) for DR purpose. 

My question is:

For the appliance, how to back up these files? Thanks in advance. 

[sdo]

Well - I don't think that one would just back them up.  Really you should quiesce the KMS database and then copy the files somewhere, and then backup the copied files.

I would have thought our only option is to schedule a cron job to quiesce, copy, and maybe fire a short backup policy/job.

The problem then is what to do with the copy?  How to transport it?  Where to place it physically?

Ideally you want the keys off-site... but is your NetBackup AIR replication encrypted?  If you copy the keys to tape, then surely they need to be copied to a non-encrypted tape - and this tape needs to not be stored with the encrypted media?

[liuyang]

Yes, that is what I would like to know. We may be able to cron a job to quiesce and then make a copy of these files. But after that how to export these files outside the NetBackup appliance? The appliance is the only NBU server in this environments so there is no AIR replication. 

I am thinking that we need to periodically back up these files and export the backup copies to some folder in the file server in this encironment. So how to do it? Thanks.

[sdo]

Why not use the same mechanism that you use to get your Catalog Backup DR file off-host?

Do you email the DR file?  Or, point the catalog backup DR file save location to a mounted NFS export?

.

It's fairly straightforward to have an appliance save DR files to an appliance side NFS client mount of an NFS export from a Windows server.

You could then have your KMS quiesce/copy/unquiesce cron job save a copy of the KMS files to this mounted NFS export.

Want some tips on setting up the NFS side of things this from Windows and on the Appliance?

[liuyang]

Thanks a lot for the replies.

Is it possible to create a policy in NBU to back up these files in the appliance to a non encrypted volume pool?

[sdo · Accepted solution]

Yes, that should be workable.

The next thing to consider is perhaps... Do you want the keys to be stored with the encrypted media?  Maybe you might want to keep the media with the keys in a separate location, or at least in a separate box.  Some off-site media storage facilities will allow you to create restricted off-site boxes/locations, so that only 'managers' have access (i.e. only managers can recall 'restricted media'), and so normal backup/operator admins cannot recall the restricted media.

[sdo · Accepted solution]

IMO, I would backup the copied (post quiesce) files - and not backup the original unquiesced source files.

There is a reason for the quiesce feature, although I do not know what this reason is... we need to consider that the feature to quiesce a KMS database exists - AND - that it is a requirement to do this before copying the KMS files.  So, if you don't quiesce, then what might happen?  The answer is irrelevant... as any prior copy without having quiesced is unsupported.

So, quiesce before taking a copy - or - quiesce before taking a backup.

[Marianne]

Similar discussion in NBU forum: https://www-secure.symantec.com/connect/forums/key-management-database

[Mouse · Accepted solution]

When I raised this question with a respected NBU architecht within Veritas recently, the advise was to make a record of the passphrase (-es) on physical medium with several copies, basically print them out on paper and store in a few fire proof places. 

The hassle of backing up those databases might not be worth it given you won't get a proper shell on the recent appliances to make the pre-backup and post-backup wrappers to quiesce the KMS database. It would be easier to resolve if KMS was hosted elsewhere but not on the Appliance.

However, this is excellent idea and I published it, please vote for it to make life easier for all of us! https://www-secure.symantec.com/connect/ideas/create-standard-automated-backup-flow-nbu-kms-database...

[sdo · Accepted solution]

A short Windows VBScript to generate a pass phrase:

Option Explicit
Const cs_bs = "\"

Dim lo_fso, ls_script_spec, ls_script_path, ls_script_name, ls_out_spec, lo_out_chan, ll_err

Set lo_fso = CreateObject( "Scripting.FileSystemObject" )

ls_script_spec = WScript.ScriptFullName
ls_script_path = lo_fso.GetParentFolderName( ls_script_spec )
ls_script_name = lo_fso.GetBaseName( ls_script_spec )
ls_out_spec = ls_script_path & cs_bs & ls_script_name & ".out"

On Error Resume Next
Set lo_out_chan = lo_fso.OpenTextFile( ls_out_spec, 2, True )
ll_err = Err.Number
Select Case ll_err
Case 0
Case Else
  WScript.Echo "failed to open output file: " & ls_out_spec
  WScript.Quit( ll_err )
End Select
On Error Goto 0

Randomize

Dim ls_pool, ll_pool, ls_out, ll_len, ll_i

' no eye's or lowercase ell, and no 'oh's, no capital 'ess'...
' ...but does have zero and upercase ell, and a five...
ls_pool = "0123456789ABCDEFGHJKLMNPQRTUVWXYZabcdefghjkmnpqrstuvwxyz"

ll_pool = Len( ls_pool )

WScript.Echo ""
WScript.Echo "pool has " & ll_pool & " characters..."

ls_out = ""
ll_len = 32

For ll_i = 1 To ll_len
  ls_out = ls_out & Mid( ls_pool, Int( Rnd * ll_pool ) + 1, 1 )
Next

WScript.Echo ""
WScript.Echo "phrase length: " & Len( ls_out )
WScript.Echo ""
WScript.Echo ls_out

lo_out_chan.WriteLine ls_out
lo_out_chan.Close

WScript.Quit(0) 

.

Change the line:

ll_len = 32

...if you want a longer, or shorter, pass-phrase.

.

But choosing a much longer pass-phrase may just make things harder to check or harder to record, or harder to re-enter.

Remember, a pass-phrase of 32 characters in length, from a pool of 56 characters will yield a complexity of 56^32 combinations - which is a pretty big number.  So maybe a pass-phrase length of 16, i.e. 56^16 is sufficient for your site.

[sdo · Accepted solution]

Good points there.  If you use a pass-phrase to generate your key - i.e. and only have one key, or only have a few pass phrases and so only a few keys - then you may not need to backup the KMS files and so you would only need to record the pass-phrase used to generate the key - or the 'n' number of pass-phrases used to generate 'n' number of keys.

However, if you use KMS own random key generation method, you really must backup the KMS database files.

Here are some tips for pass phrases:

1) Do not print on laser printer paper - as the carbon will slide off after only a few years.

2) Do not use pencil or felt-tip or biro - as these also slide off, or bleed away or fade after a few years.

3) However, do use high quality ink and high quality paper, e.g. like a registrar or solicitor would use - as you may need to keep a record for many many years (e.g. like the ink used on birth certificates, etc.)

4) Some sites stamp the pass-phrases on to metal - like military dog tags; this way they survive the smoke point of paper, which can happen if a firesafe is surrounded by fire.

5) Check, double check (second person), triple check (third person) that the pass-phrase(s) have been recorded correctly.

6) Do not use punctuation characters in your random pass-phrase.

7) Do not use visually similar characters in your pass-phrase - e.g. do not use 'O' (oh) and '0' (zero) - use one of them - but not both.  Also, do not use 'i' '1' and 'l' (little ell) together, again use one of them but not all three.  Same maybe for '5' and 'S' (capital 'ess'), use one of them, but not both.

8) Do not use spaces or tabs in your pass phrase.

9) Use a sufficiently long random pass-phrase - but don't make it so long that it becomes unmanageable.

I'll post a short Windows VBScript which can be used generate a random pass-phrase for you.

[sdo · Accepted solution]

I forgot to say that one would run this script by:

1) Saving it as:    D:\NBU-SCRIPTS\gen-pass-phrase\gen-pass-phrase.vbs

2) cd /d D:\NBU-SCRIPTS\gen-pass-phrase

3) cscript gen-pass-phrase.vbs

...and when you are happy that you have recorded the pass-phrase (using real long-life ink on good paper), double checked it, and triple checked it, and got it saved physical off-site somewhere - all BEFORE actually using the encryption key that was created using the pass-phrase, and then...

4) del gen-pass-phrase.txt

HTH.