Register Login

SAP HANA Backup Encryption Interview Question and Answer

Updated May 18, 2018

SAP HANA Backup Encryption FAQ

What does SAP HANA backup encryption refer to?

Backup encryption denotes that authorized parties can access the backups which have been stored outside a secure area.

How does backup encryption work?

SAP HANA backups are all encrypted by a symmetrical encryption algorithm (AES-256) with the backup encryption root keys (BEK) (key length = 256 bit). These backup encryption root keys have been kept in the instance Secure Store located in the File System (instance SSFS).

Note: You should never store the backup of the instance SSFS in the same location as the SAP HANA backup.

SAP HANA utilizes the instance SSFS for protecting several types of encryption root key (for instance LOG, DATA and BACKUP).

Which version of SAP HANA version can be used for creating encrypted backups?

The Native backup encryption to the file system or the third-party backup tools (Backint) is braced from SAP HANA 2.0 SPS 01.

Do all tenant databases in the same system have similar backup encryption root key?

No, an exclusive backup encryption root key is produced for the system database and for each tenant database.

Would I require additional privileges for creating encrypted backups?

The following privileges would be required for both the system database and the tenant databases, for backup and recovery with or without encryption:

BACKUP ADMIN
BACKUP OPERATOR
DATABASE ADMIN (system database only)

Are DATA and LOG backups tacitly encrypted once the data volume or log volume encryption is enabled?

No, for creating encrypted DATA and LOG backups, backup encryption should be clearly enabled.

How can I disable or enable backup encryption?

For enabling backup encryption, you require the system privilege ENCRYPTION KEY ADMIN.

To enable backup encryption, use the SQL statement:

ALTER SYSTEM BACKUP ENCRYPTION ON

To disable backup encryption, use the SQL statement:

ALTER SYSTEM BACKUP ENCRYPTION OFF

Post the enablement of the backup encryption, various types of SAP HANA backups of the same tenant database or system database are encrypted with the same backup encryption root key.

Note: This statement does not hold good, when using external Snapshots.

Note: this statement is only partially valid, upon using SAP HANA Dynamic Tiering (DT).

Note: Only for an individual backup, it is impossible to enable encryption.

Am I required to enable the backup encryption for a tenant database explicitly once the backup encryption has already been enabled for the system database?

This would entirely depend on when the tenant database was initially created:

Incase, when the backup encryption was enabled, the tenant database already existed, then the backup encryption needs to be enabled explicitly for every tenant database

If a new tenant has been created, post the enablement of the backup encryption, then the newly created tenant database inherits the status of the system database. Obliquely, the backup encryption is previously enabled.

Every tenant database along with the system database are assigned their own encryption key, regardless of whether backup encryption has been enabled implicitly or explicitly

If a particular tenant database does not need to be encrypted, the tenant database administrator can disable encryption for that tenant database.

Which backup types can be possibly encrypted with backup encryption?

The backup types which can be encrypted are listed below:

Full Data Backups (complete data backups, no storage snapshots)
Delta Data Backups
Log backups

Does backup encryption impact the performance of backup/recovery or on other resource usage?

Backup encryption effects the runtime of backups as well as recovery.

In case, the backup encryption has been enabled, then the backup runtime increases by the time required for encrypting the backup.

The size of an encrypted backup does not vary from the size of an unencrypted backup.

Note: it is not possible to encrypt the backups as compressed with operating system tools.

What all information is required to know more about backup encryption and SAP HANA Dynamic Tiering (DT)?

SAP HANA Dynamic Tiering (DT) is primarily an add-on option meant for SAP HANA for enhanced data management.

Note:

- Complete Data Backups in DT cannot be encrypted.
- Delta and log backups can only be encrypted once the volume encryption is enabled (utilizing the volume encryption key).

How to verify if backup encryption is enabled?

System view M_ENCRYPTION_OVERVIEW, column IS_ENCRYPTION_ACTIVE, shows whether backup encryption has been enabled.

The following SQL statement have to be executed for the system database and for every tenant database.

SELECT IS_ENCRYPTION_ACTIVE FROM M_ENCRYPTION_OVERVIEW WHERE SCOPE = 'BACKUP'

The backup catalog creates a record whether a backup has been encrypted. This information is available in the system table M_BACKUP_CATALOG. Column ENCRYPTION_KEY_HASH displays the hash which refers to the backup encryption root key. If the column ENCRYPTION_KEY_HASH has not been assigned a value, then backup is not encrypted.

When a third-party backup tool is used, can backups be encrypted?

Yes, Once SAP HANA backup encryption is enabled, then all types of backups (full, delta, log) for third-party backup tools are encrypted.

Can SAP HANA encrypt storage snapshots ?

Storage snapshots have the ability to store an image of the data area. The storage snapshot encompasses the encrypted data, once the data area is encrypted by data volume encryption.

Important:

The SQL statement ALTER SYSTEM BACKUP ENCRYPTION ON does not have any influence on storage snapshots apart from the additional meta-data file, which is a part of the snapshot procedure.

The data volume encryption root key has been preserved in this meta-data file.
Even if data volume encryption has been enabled, the data volume encryption root key is still not encrypted.
The user is suggested for security reasons to utilize backup encryption along with the data volume encryption for storage snapshots.
The encryption root key should must be available for a SAP HANA recovery, If the meta-data file is encrypted.

Are backups of the backup catalog also encrypted?

No, the backups of the backup catalog are not encrypted.

Note: The backups of backup catalog comprise of the references to the backup encryption root keys which were utilized for encrypting the backups. SAP HANA tools use this information for determining all backup encryption root keys which are required for recovering and are available in the instance SSFS.

Is the instance SSFS a portion of an encrypted SAP HANA data backup?

No, the instance SSFS (which includes all encryption root keys) is not a part of the SAP HANA data backup.

A database administrator has to clearly ensure that the backup encryption root keys are backed up regularly, in case the backup encryption is enabled.

The user is suggested to save (export the instance SSFS) backup encryption root keys each time there are modified.

Note:

A backup of the backup encryption root keys should be available for using the encrypted data and log backups for recovering.

An encrypted backup cannot be utilized, without the SSFS backup, as result the data can be lost!

What is the dbid and how can I find out the dbid of a system/tenant database?

<dbid> is the internal identifier (ID) of a system database or a tenant database. The user has to specify to export or import the instance SSFS of a system or tenant database in a multitenant database container.

The <dbid> is stored in the topology, which is located in the system database only.

The system database has always the <dbid> = 1.

To find out the <dbid> of the tenant databases, the system database must be online.

Connect to the system database with a user with system privilege DATABASE ADMIN.

Execute the following SQL statement:

SELECT DATABASE_NAME,
CASE WHEN (DBID = '' AND DATABASE_NAME = 'SYSTEMDB')
THEN 1
WHEN (DBID = '' AND DATABASE_NAME <> 'SYSTEMDB')
THEN 3
ELSE TO_INT(DBID)
END DATABASE_ID
FROM (SELECT DISTINCT DATABASE_NAME, SUBSTR_AFTER (SUBPATH,'.') AS DBID FROM SYS_DATABASES.M_VOLUMES)

The database name and the database identifier (column: Database_ID), are visible in the results.

How can I find whether the instance SSFS has the root keys which were used for encrypting backups?

To find out if the current instance SSFS or the backup of the instance SSFS contains the backup encryption root key of a particular encrypted backup, you first have to find out which key hashes were used for the backup.

Using these key hashes and information from the backup catalog or system tables, use hdbnsutil as follows:

hdbnsutil -printHashedRootKeys --dbid=<dbid> [--verbose]

Note:

hdbnsutil only lists the current hashed keys if the option --verbose is missing

e.g. hdbnsutil -printHashedRootKeys --dbid=<dbid> --verbose

Example output:

Printing all Key(s) for DBID: 3

| Key Purpose | Key Version | Key State | Key Hash
| BACKUP | 0 | Active | b8aab5171c81cb2c499b5b303a18fbff3250
6c26d5e5dc4010116bd4f4fab5b8 |
| BACKUP | 1 | Preactive | 90eb11313912215c12d04a74b5e3b2e33539
10bd4acb42f1b5204955ea3979b8 |

Key Purpose 'Backup' specifies the backup encryption keys. The value Active lists the actual used key hash, the value Deactive specifies the history of enryption root keys. If a root key has the value Preactive a new root key has already been created but is not activated so far.

example output (without option --verbose):

PERSISTENCE Root Key: cb25c64651a50735ef77665033c44aef7a69a0d4c000524b7851e15e0
LOG Root Key: 0b1579f5c665f09e0cc7d18ade610872923d503a804bc5efae3238a392a3857e
BACKUP Root Key: 7ad2f60c69d7027c5f739c5b3d244da02972d6a3f350c4ef2e464b2cdd77845

Backup Root Key specifies the hash key used to encrypt the database. The hash key is in the instance SSFS. If storage snapshots are used only, the metadata file is encrypted with this hash key.

Where is the instance SSFS positioned?

Note:This information is not necessary to create or recover encrypted backups.

The default path to the key file (SSFS_<SID>.DAT) of the instance SSFS is:

$DIR_GLOBAL/hdb/security/ssfs.

Note:

Never manually change any of the files related to the instance SSFS!
For all administrative tasks related to instance SSFS, use the SAP HANA tool hdbnsutil.

With hdbnsutil, you can:

Create a backup (export) of the instance SSFS
Export or import the instance SSFS

What are the steps required to back up (export) encryption root keys from the instance SSFS?

A single passphrase, secures the encryption root key backup and that has to be set before a SSFS backup (export) is created. The passphrase is stored very securely and all subsequent backup encryption root key backups are protected by this same passphrase. For setting the passphrase, the user requires the system privilege ENCRYPTION ROOT KEY ADMIN.

For setting the encryption root key backup passphrase, the following SQL statement can be used

ALTER SYSTEM SET ENCRYPTION ROOT KEYS BACKUP PASSWORD "<passphrase>"

For creating a back-up the instance SSFS, this passphrase should be set for the system database. For each tenant database, the dbid used to export or import instance the SSFS.

A backup of encryption root keys should be saved in a root key backup file at an external location which is accessible to an SAP HANA administrator. The file can be named anything and located anywhere. The extension of the root key backup file should must always be .rkb. It is suggested that the file name has the name or ID of the tenant database.

Note:

Before beginning the SAP HANA database recovery, the present instance SSFS, encompasses the valid backup encryption root keys should be always available in the file system. The instance SSFS is required to be backed up (exported) for the system database and for each tenant database.

The export root key functionality should be used for creating a back-up the backup encryption root keys.

Import root key functionality, should be used for restoring backup encryption keys.

How to import or export the instance SSFS with backup encryption root keys?

To export and import the backup encryption root keys, use the tool hdbnsutil as the OS user <sid>adm.

Note:

You have to back up (export) the backup encryption root keys of the system database and of each tenant database.

The specified backup file cannot be overwritten if it already exists.

Location of hdbnsutil: /usr/sap/<SID>/<HDBinstance_no>/exe

Export: ./hdbnsutil -backupRootKeys <filename>.rkb --dbid=<dbid> --type='ALL'

<filename>: You can use any name and location for this encryption root key backup file.
<type>: possible values are ALL,PERSISTENCE,LOG,APPLICATION,BACKUP

ALL is mandatory for a point in time and disaster recovery.

Important:

You have to back up (export) the instance SSFS of the system database and of each tenant database.
SSFS backup files cannot be overwritten with a new export; You have to use a different file name

A backup encryption root key passphrase has to be set before you execute the option -backupRootKeys the first time.
The export command to backup encryption root keys can then be executed without passphrase specification..

Example:

System database: ./hdbnsutil -backupRootKeys system_CH1_01052017ssfs.rkb --dbid=1 --type='ALL'
one tenant database: ./hdbnsutil -backupRootKeys T1_CH1_29042017.rkb --dbid=3 --type='ALL'

Import:

First validate the password for the root key backup file ( *.rkb):

./hdbnsutil -validateRootKeysBackup <filename>

To import the instance SSFS, the database must be offline.

If the nameserver is running, you get error messages.

Import the backup encryption root keys:

./hdbnsutil -recoverRootKeys <filename>.rkb --dbid=<dbid> --type=<type>

Example: ./hdbnsutil -recoverRootKeys Tenant_ssfs.rkb --dbid=3 --type='BACKUP'

To access the file during import, the passphrase is required.

Note:

If your backup encryption root keys are stored in different files, you have to run the command separately for each file.
You have to import the root keys for the system database and separately for each tenant database.

Caution: The imported backup encryption root keys, initializes the instance SSFS. The root keys of the same type as well as the hash already in the SSFS are overwritten.

In case, since the last SSFS backup (export), the backup encryption root keys were modified and/or activated, then the user is suggested to export the current instance SSFS BEFORE you import an older instance SSFS backup.

Post successfully importing the instance SSFS you can begin the recovery of the SAP HANA database.

How can I ensure that a backup is encrypted?

The backup catalog comprises of the information about whether a backup has been encrypted.

For checking the content of the backup catalog, user can utilize the system table M_BACKUP_CATALOG. Incase a backup (column BACKUP_ID) has been encrypted, column ENCRYPTION_ROOT_KEY_HASH comprises of the backup encryption key.

Execute:

SELECT BACKUP_ID,ENCRYPTION_ROOT_KEY_HASH from M_BACKUP_CATALOG

WHERE BACKUP_ID = <backup_id>

If the database is offline, you can find out whether its backups are encrypted by executing hdbbackupdiag -v .The backup encryption key hash of each backup is listed.

Note:

You must execute hdbbackupdiag -v in that directory which contains the backup catalog.

Example for a tenant database:

cd /usr/sap/<SID>/HDB<instanceno>/backup/log/<tenant>
/usr/sap/<SID>/HDB<instance no>/exe/hdbbackupdiag -v

How can I alter the backup encryption root key?

The backup encryption key will be modified following the steps listed below:

Generate new root keys

For generating a new backup encryption root key for data and log backups, the following command can be used:

ALTER SYSTEM BACKUP ENCRYPTION CREATE NEW ROOT KEY WITHOUT ACTIVATE

Note:

Once a new root key has been already created however not activated, then a preactive root key pre-exists. A new root key cannot be created if the his pre-active root key is deactivated.

Back up instance SSFS

Post generating the new backup encryption root keys, user should export the backup encryption root keys (instance SSFS)

Activate the new root keys

Post creation of the the backup of the instance SSFS, activate the new backup encryption root keys.

The following command can be used:

ALTER SYSTEM BACKUP ENCRYPTION ACTIVATE NEW ROOT KEY

All subsequent backups are created utilizing the new backup encryption root key, once the new backup encryption root keys have been positively activated.

How can the encrypted backup for inconsistencies be checked?

You can utilize the hdbbackup check tool for checking the integrity of encrypted data backups and log backups. The block-level-integrity of encrypted backups can also be verified without accessing the backup encryption root keys.

Is a backup decrypted during a consistency check?

No. The backup encryption root key is not required for a block-level integrity check (structure consistency check). For running the structure check, there is no need to decrypt the backups. By using a checksum on the encrypted data, the check can be performed.

For recovery, can we use a mix of encrypted and unencrypted backups?

Yes, you can use a mix of encrypted and unencrypted data, delta and log backups for recovering a database.

If the data and / or log volume encryption has been disabled, is backup encryption possible?

Yes, you can decide whether to:

Enable volume (data and / or log) encryption only
Enable backup encryption only
Enable both volume (data and / or log) encryption and backup encryption

What should you keep in mind when using an encrypted backup for recovery?

For executing successful recovery with an encrypted backup, the instance SSFS which contains the BEK of the encrypted backup should be available/accessible for the system and the tenant databases.

What should you consider while utilizing an encrypted backup for a database copy?

Firstly, you need to consider the import the backup of the backup encryption root keys.

If the backup encompasses all encryption root keys, then make sure that you only import the types Application and Backup, else the data volume and log volume encryption key of the target system will be overwritten with those of the source system.

Utilize the appropriate backups for recovering the target system.


×