How to use the NetBackup Encryption Option - detailed demonstration of encrypted backups, restores, disaster recovery and troubleshooting

In NetBackup, the encryption software is automatically installed with the NetBackup UNIX and Windows server and client installations. A valid license key is required to enable functionality.

Encryption updates are included in applicable UNIX and Windows maintenance packs. Encryption will need to be enabled on the client through its Host Properties ( Host Properties > Clients > Encryption)

The NetBackup Encryption Option is located on the"UNIX Options" media (UNIX) and is automatically included in the NetBackup installation (Windows).  A valid license key is required to enable functionality.

Note: This article demonstrates "Standard" Encryption (5.1 and above) rather than "Legacy" Encryption (5.0).

To place the encryption agent on a client:
/ # bpinst-ENCRYPTION <client>

To confirm installation as well as version installed:
/ # cat/usr/openv/share/version_crypt
NetBackup-CRYPT-Solaris86.0MP5

In Windows, this file can be found at C:\ProgramFiles\VERITAS\NetBackup\share\version_crypt.

Encryption maintenance packs contain the string ENC.  It is recommended that Encryption be kept at the same maintenance pack level as the NetBackup software.

/ # grep ENC/usr/openv/pack/pack.summary
NB_ENC_60_5_M installed. *NB_CLT_60_5_M

On Windows systems, encryption updates are included in applicable Windows maintenance packs and not separate as they are in UNIX.

Encryption will need to be enabled on the client through its Host Properties ( Host Properties > Clients > Encryption)

 

Check the Enable Encryption checkbox to enable encryption.  A 128-bit or 256-bit key can be selected from the Client Cipher dropdown menu as well.

A key file will now need to be created on the client.  From the command line:

/# bpkeyutil -clients<client>
Enter new NetBackup pass phrase:********************
Re-enter new NetBackup pass phrase:********************

/ #ls -l/usr/openv/var/keyfile.dat
-rw-------  1 root     other        136 Jan 1408:41 /usr/openv/var/keyfile.dat

For this discussion, an encrypted policy will be created to back up a single file.  That file will be a simple text file.

/ # echo "Here is our testfile.  It is unencrypted text." >/tmp/testfile

/ # ls -l/tmp/testfile
-rw-r--r--   1root     other         48 Jan 14 08:36/tmp/testfile

/ # cat/tmp/testfile
Here is our test file.  It is unencrypted text.

To enable encryption in the policy, check the "Encryption" checkbox:

 

The backup selection list contains the path to the test file:

 

For this discussion, an additional policy will be created to back up the key file as well:

 

Note that this policy should NOT be encrypted.  If the key is lost, it would be impossible to restore if the restore first required a key - itself - before it could complete!

 

bppllist output provides a closer examination of these two policies as seen in the above figures.  Note the encryption setting in the policy listing as denoted by the Client Encrypt setting:

/ #bppllist ENC-U
------------------------------------------------------------

PolicyName:      ENC

 PolicyType:        Standard
 Active:              no
 Effectivedate:      01/09/200815:38:28
 ClientCompress:    no
 Follow NFS Mounts:  no
 Cross MountPoints:  no
 Collect TIRinfo:    no
 BlockIncremental:   no
 Mult.DataStreams:  no
 ClientEncrypt:      yes
 Checkpoint:          no
 PolicyPriority:     0
 MaxJobs/Policy:    Unlimited
 DisasterRecovery:   0
 Collect BMRinfo:    no
 Residence:          dsu_enc
 VolumePool:        NetBackup
 Keyword:            (nonespecified)

 HW/OS/Client:  Solaris      Solaris9      <client>

 Include:  /tmp/testfile

...

/# bppllist keyfile-U
------------------------------------------------------------

PolicyName:      keyfile

 PolicyType:        Standard
 Active:              no
 Effectivedate:      01/09/200815:40:31
 ClientCompress:    no
 Follow NFS Mounts:  no
 Cross MountPoints:  no
 Collect TIRinfo:    no
 BlockIncremental:   no
 Mult.DataStreams:  no
 ClientEncrypt:      no
 Checkpoint:          no
 PolicyPriority:     0
 MaxJobs/Policy:    Unlimited
 DisasterRecovery:   0
 Collect BMRinfo:    no
 Residence:          dsu_enc
 VolumePool:        NetBackup
 Keyword:            (nonespecified)

 HW/OS/Client:  Solaris      Solaris9      <client>
 
 Include:  /usr/openv/var/keyfile.dat

...

In this example, these two policies have been assigned a disk storage unit (DSU) with the path /opt/encrypted_backups ,which will make it easier to examine the backup images written by these policies.

A manual backup of the test file using the encrypted policy is performed:

 

A similar command line version would be:

/ #bpbackup -p <policy> -s <schedule> -i -S <master> -t<type>

The image has been written.  What is init?  First, change directory to the DSU:

/ # cd/opt/encrypted_backups

Find the files that make up the just-written image:

/opt/encrypted_backups #ls -l
total66898
...
-rw-------  1 root     root       32768 Jan 14 08:46<client>_1200321967_C1_F1.1200321967.img
-rw-------  1 root     root         896 Jan 14 08:46<client>_1200321967_C1_F1.1200321967.info
-rw-------  1 root     root        1024 Jan 14 08:46<client>_1200321967_C1_HDR.1200321967.img
-rw-------  1 root     root         898 Jan 14 08:46<client>_1200321967_C1_HDR.1200321967.info

tar can be used to examine the contents of the image:

/opt/encrypted_backups # tar -tf<client>_1200321967_C1_F1.1200321967.img
1074262335010741770322 //
1074267266210742672662 //tmp/
1074267266310742672663/.EnCrYpTiOn_CiPhEr.0
1074267162610742671610 //tmp/testfile

Note the presence of the cipher file.  One of the most frequently asked questions is "How can one tell whether a backup is encrypted or not?"  In an encrypted backup, every file will have a corresponding cipher.  Here is another example from an encrypted backup from a different policy:

/opt/encrypted_backups # tar-tf  <client>_1199915090_C1_F1.1199915090.img
10741237766 10726067164//
10741240125 10741240125//tmp/
10741240126 10741240126/.EnCrYpTiOn_CiPhEr.0
1074047247710740472477//tmp/.dcs.<client>:0.dcgtlock
1074124012610741240126/.EnCrYpTiOn_CiPhEr.1
1074047247710741237763//tmp/.dcs.<client>:0.37dd79
1074124012610741240126/.EnCrYpTiOn_CiPhEr.2
1074047247710740472477//tmp/.dcs.<client>:0.utillock
1074124012610741240126/.EnCrYpTiOn_CiPhEr.3

...

The file list continues on, alternating cipher files with actual files.

The ciphers are unreadable data - attempting to extract and cat them produces unreadable results:

/tmp # cat .EnCrYpTiOn_CiPhEr.0
°þ#Kä}Ð
     &Äh5ØQ"·xØy¯T3C3?©ø¹

1. To simulate a disaster recovery (DR) scenario, the test file is deleted:
     
/opt/encrypted_backups # rm/tmp/testfile
rm: remove/tmp/testfile (yes/no)?yes

/opt/encrypted_backups# cd /

First, a restore of the file is attempted without the use of the NetBackup framework (including the encryption agent).  A tar is performed on the backup image in an attempt to extract the test file:

/ # /usr/openv/netbackup/bin/tar-xvf/opt/encrypted_backups/<client>_1200321967_C1_F1.1200321967.img
Blocksize= 64records
/
Removing leading / from absolute path names in the archive.
/tmp/
/tmp/testfile

However, because the file was encrypted, it was restored as encrypted data.  It is unreadable:

/ # cd/tmp

/tmp # cattestfile
›`<?QŒÝîJªK
ì-Qp´ê a¢ÄéùJZi-•ã|$¯r«lP;DW

It is necessary to perform the restore from NetBackup, where the key file can be used to decrypt the file.

 

The restore succeeds, and now the file can be read:

/tmp # cattestfile
Here is our test file.  It is unencrypted text.

2. Another DR test - the key file is deleted along with the test file to simulate the loss of both files:

/tmp # rm/usr/openv/var/keyfile.dat
rm:remove /usr/openv/var/keyfile.dat (yes/no)?yes

/tmp # rmtestfile
rm: remove testfile(yes/no)? yes

If the attempt is made to restore the file, the restore will hang and ultimately fail, showing a job status of INCOMPLETE and status code 5 (the restore failed to recover the requested files) reported.

 

A closer examination of the detailed status for the job will also reveal an initial Status Code 49 (client did not start).  This error can also be seen as an"exit status 49" in bpbrm logs.

 

Performing a restore of the key file is necessary prior to restore of any encrypted file.

 

/tmp # ls -l/usr/openv/var/keyfile.dat
-rw-------  1 root     other        136 Jan 1408:41 /usr/openv/var/keyfile.dat

After the keyfile is restored, the encrypted test file may be restored:

/tmp # bprestore -p ENC/tmp/testfile

(Note that the above is the command line equivalent of the earlier restore using the GUI.)

/tmp # cattestfile
Here is our testfile.  It is unencrypted text.

3. Another DR scenario.  Suppose the key file and test file are both lost:

/tmp # rm/usr/openv/var/keyfile.dat
rm:remove /usr/openv/var/keyfile.dat (yes/no)?yes

/tmp # rmtestfile
rm: remove testfile(yes/no)? yes

Suppose the passphrase is known.  It can be used to manually regenerate the key file without performing a manual restore of the keyfile:

/tmp #bpkeyutil

Enter new NetBackup pass phrase:********************
Re-enter new NetBackup pass phrase: ********************

Note:because the command is being invoked on the client itself, the -clients <client> command line switch is optional in this case.

/tmp # ls-l/usr/openv/var/keyfile.dat
-rw-------  1 root     other        136 Jan 1409:26/usr/openv/var/keyfile.dat

/tmp #bprestore -p ENC/tmp/testfile

/tmp # cattestfile
Here is our testfile.  It is unencrypted text.

4.  If for some reason, the key file is incorrectly generated - for example, the incorrect passphrase is given - restores of encrypted files using the original key file will fail:

/tmp # rmtestfile
rm: remove testfile(yes/no)? yes

/tmp # rm/usr/openv/var/keyfile.dat
rm:remove /usr/openv/var/keyfile.dat (yes/no)?yes

/tmp #bpkeyutil
Enter new NetBackup pass phrase: *********************** (this is not the correct passphrase)
Re-enter new NetBackup pass phrase:***********************

/tmp# ls -l/usr/openv/var/keyfile.dat
-rw-------  1 root     other        136 Jan 1409:33/usr/openv/var/keyfile.dat

/tmp #bprestore -p ENC/tmp/testfile

/tmp # ls -l/tmp/testfile
/tmp/testfile: Nosuch file or directory

An examination of the Detailed Status for the restore job will reveal a status code 183 (tar received an invalid archive) prior to the Activity Monitor's INCOMPLETE status and exit status 5 reported.  

 

Again, this "exit status 183" could also be found in the bpbrm logs for the restore.


Summary:
The key file ( keyfile.dat) is the most important piece of the encryption process, as it generates all ciphers included in the encrypted backup.  Without the keyfile, any necessary decryption will not be possible.  Therefore, it is important that the key file always be recoverable.  The Encryption Guide lists two procedures:

1. All passphrases used to generate the key file are written down and placed in a secure location (for instance, a safe).  The key file can be regenerated using the passphrases if it is lost.

2. The key file can be regularly backed up as part of DR planning.  If the key is lost, it can be restored from backup.

If the key file is regularly backed up, the potential exists for that key to be restored to alternate systems and used to decrypt files onto those alternate systems.  For this reason, some administrators opt to exclude the key files from backup selections.  In those situations, it is imperative that the passphrases be kept in the event that the key file needs to be regenerated.

For more information about the NetBackup Encryption Option,please consult the Encryption Guides (linked below).

Many of the commands listed in this document are explained in greater detail in the Commands Guides.

 

Veritas NetBackup™ Security and Encryption Guide
https://www.veritas.com/content/support/en_US/doc/21733320-143639988-0/v127786724-143639988