Cluster Backup and Restore
These procedures allow you to back up the contents of a cluster to an encrypted file on the appliance, using REST API or LunaSH:
>Backing Up/Restoring the Cluster SMK
>Restoring a Cluster from Backup
NOTE Thales requires minimum Luna Appliance Software 7.8.5 with the lnh_cluster-1.0.4 package, Luna HSM Firmware 7.8.4, and Luna HSM Client 10.7.2 to use clusters in production environments.
Backing Up/Restoring the Cluster SMK
All keyrings on the cluster are encrypted with a SKS Master Key (SMK), which is stored on the V1 partition that created the cluster and cloned to the V1 partition on each joining cluster member. In the highly unlikely event that the SMK is lost from all members, the entire cluster is unrecoverable. Therefore, Thales recommends backing up the SMK to a Luna Backup HSM as part of your general recovery plan. This procedure requires an initialized Luna Backup HSM connected to the appliance. You must use LunaSH to back up or restore the cluster SMK.
Backing Up the Cluster SMK
Use the following procedure to back up the Cluster SMK to a Luna Backup HSM.
Prerequisites
>The Luna Backup HSM must be connected to a USB port on the Luna Network HSM 7 appliance.
>If you are backing up the SMK on a multifactor quorum-authenticated HSM, you require a local or remote Luna PED. Refer to Multifactor Quorum Authentication for setup procedures.
To back up the cluster SMK
1.Log in to LunaSH as admin, or a custom user with admin privileges.
2.[Optional] View the Luna Backup HSMs currently connected to the appliance and find the correct serial number.
lunash:> token backup list
3.If you have not already done so, initialize the backup HSM, specifying its serial number and a label.
lunash:> token backup init -label <backup_hsm_label> -serial <backup_hsm_SN>
You are prompted to set the backup HSM SO password and a cloning domain string.
4.Initiate the backup operation, specifying the cluster partition label, a label for the backup (either a new label or the label, or an existing backup you wish to overwrite), and the Backup HSM serial number.
If you omit the -tokenpar option when creating a new backup, the backup is assigned a default name (<source_partition_name>_<YYYYMMDD>).
lunash:> partition backup -partition <cluster_partition_label> -serial <Backup_HSM_SN> [-tokenpar <target_label>]
You are prompted for the following credentials:
a.Crypto Officer password/PED key for the cluster partition
b.HSM SO password/PED key for the backup HSM (Luna Backup HSM 7 only)
c.New password/PED key for the backup partition
d.Domain string or PED key for the backup partition (must match the cluster partition domain)
The backup operation begins once you have completed the authentication process.
Restoring the Cluster SMK
Use the following procedure to restore the cluster SMK from a Luna Backup HSM.
Prerequisites
>Do not restore the SMK to a partition that is already encrypting a cluster on the Luna Network HSM 7. You must restore the SMK before creating a new cluster. It is not necessary to restore the SMK on each member of a cluster; the SMK is replicated to each new member when it joins the cluster on the primary member.
To restore the cluster SMK from backup
Do not restore the cluster SMK to a Luna Network HSM 7 that has an existing cluster
1.Log in to LunaSH as admin, or a custom user with admin privileges.
2.[Optional] View the Luna Backup HSMs currently connected to the appliance and find the correct serial number.
lunash:> token backup list
3.[Optional] View the backups currently available on the Backup HSM.
lunash:> token backup partition list -serial <Backup_HSM_serialnum>
4.Initiate the restore operation, specifying the cluster partition label, the backup label, the Backup HSM serial number, and the -add option.
lunash:> partition restore -partition <target_label> -tokenpar <backup_label> -serial <Backup_HSM_SN> -add
You are prompted for the following credentials:
a.Crypto Officer password/PED key for the backup
b.Crypto Officer password/PED key for the cluster partition
The restore operation begins once you have completed the authentication process. When it is complete, you can create a new cluster on the appliance (see Creating a Cluster).
Backing Up a Cluster
Use this procedure to back up the contents of a cluster to an encrypted file on the appliance using REST API or LunaSH. You can perform backups on demand or schedule periodic backups. This procedure does not restore the SMK used to encrypt the contents of the cluster. Refer to Backing Up/Restoring the Cluster SMK.
NOTE Ensure that the member you are using to back up the cluster is authorized at the time of backup; otherwise the backup will fail.
REST API
Prerequisites
>Backup and restore operations can only be done on the primary member of the cluster.
>The cluster service must be running on the appliance and the member must be authorized.
To back up a cluster manually
Back up the cluster by specifying its UUID, a filename for the backup file, and a password that will be required to restore from this backup.
NOTE Using the same filename as an existing backup will overwrite the existing file.
PUT /api/clusters/{clusterID}/backup
{
"action": "run",
"password": "backuppassword",
"filename": "myClusterBackup"
}
To schedule periodic backups
1.If you already have backups scheduled, and you wish to make changes, first disable the backup service.
PUT /api/clusters/{clusterID}/backup
{
"action": "disable"
}
2.Set the backup schedule by specifying a filename prefix that will be used to name all backup files ("filename"), the number of backups you would like to store before old backups are deleted ("total", valid range 1-15), and the time you want backup to occur ("time") in the format d:hh:mm (where d is a number representing the day of the week as follows: 0 == Sunday, 1 == Monday, 2 == Tuesday, etc).
The filename you specify may have a maximum length of 64 characters. The following characters are allowed:-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz
PUT /api/clusters/{clusterID}/backup
{
"action": "config",
"total": 5,
"time": "7:09:30",
"filename": "myClusterBackup"
}
3.Enable the backup service, specifying a password that will be required to restore from any of the scheduled backups.
PUT /api/clusters/{clusterID}/backup
{
"action": "enable",
"password": "backuppassword"
}
4.[Optional] Display the scheduled backup configuration.
PUT /api/clusters/{clusterID}/backup
{
"action": "show"
}
All backups are available on the appliance in the admin user's files. The scheduled backup configuration is not affected by rebooting the appliance or restarting the cluster service. However, you must restart the cluster service after changing the appliance time zone or after a daylight savings time change, or the new time will not be reflected in the backup schedule.
NOTE If you promote a new cluster member to primary, you must disable and re-enable scheduled backups. You do not need to re-configure the schedule.
LunaSH
Prerequisites
>Backup and restore operations can only be done on the primary member of the cluster.
>The cluster service must be running on the appliance and the member must be authorized.
>You must be logged in to LunaSH as admin to do backup/restore operations.
To back up a cluster manually
Back up the cluster by specifying its UUID, a filename for the backup file, and a password that will be required to restore from this backup.
NOTE Using the same filename as an existing backup will overwrite the existing file.
The filename you specify may have a maximum length of 64 characters. The following characters are allowed:
-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz
lunash:> cluster backup run -clusterid <string> -filename <filename> -backuppassword <password>
To schedule periodic backups
1.If you already have backups scheduled, and you wish to make changes, first disable the backup service.
lunash:> cluster backup disable
2.Set the backup schedule by specifying the cluster UUID (-clusterid), a filename prefix that will be used to name all backup files (-filename), the number of backups you would like to store before old backups are deleted (-number <1-15>), and the time you want backup to occur (-time) in the format d:hh:mm (where d is a number representing the day of the week as follows: 0 == Sunday, 1 == Monday, 2 == Tuesday, etc).
The filename you specify may have a maximum length of 64 characters. The following characters are allowed:-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz
lunash:> cluster backup config -clusterid <string> -filename <filename> -number <number> -time <string>
3.Enable the backup service, specifying a password that will be required to restore from any of the scheduled backups.
lunash:> cluster backup enable -backuppassword <password>
4.[Optional] Display the scheduled backup configuration.
lunash:> cluster backup show
All backups are available on the appliance in the admin user's files. To view them, use lunash:> my file list. The scheduled backup configuration is not affected by rebooting the appliance or restarting the cluster service. However, you must restart the cluster service after changing the appliance time zone or after a daylight savings time change, or the new time will not be reflected in the backup schedule.
NOTE If you promote a new cluster member to primary, you must disable and re-enable scheduled backups. You do not need to re-configure the schedule.
lunash:> cluster backup disable
lunash:> cluster backup enable -backuppassword <password>
Restoring a Cluster from Backup
Use this procedure to restore the primary cluster member from backup using REST API or LunaSH.
CAUTION! Restoring the cluster from backup is a service-disrupting operation; do not perform client operations on the cluster until the restore process is complete.
NOTE
>Keyrings can be restored to a different cluster than the one where they were created, as long as the new cluster uses the same SKS Master Key (SMK). If the SMK is destroyed and cannot be restored from backup, keyrings are unrecoverable.
>
REST API
Prerequisites
>Backup and restore operations can only be done on the primary member of the cluster.
>The cluster service must be running on the appliance and the member must be authorized.
>Stop the cluster service on all non-primary members of the cluster before you begin the restore operation (serviceid: cluster, actionid: stop):
POST /api/lunasa/services/{serviceid}/actions/{actionid}
To restore a cluster from backup
1.Restore the cluster from backup by specifying the backup filename, the backup password, and the keyring type of restore operation.
{
"filename": "myBackupFile",
"password": "backuppassword",
"type": "keyring"
}
NOTE This operation takes longer for larger clusters.
2.[Optional] Check the status of the restore operation.
3.When the restore operation is complete, you may start the cluster service on each non-primary member, one at a time (serviceid: cluster, actionid: start). Wait until each member is authorized before starting the next member. The amount of time it takes for each member to be authorized may vary, depending on the size of the data restored.
POST /api/lunasa/services/{serviceid}/actions/{actionid}
Confirm that the member is authorized ("memberActive": true) before starting the next member:
GET /api/clusters/{clusterID}/members
4.Restart the cluster service on the primary member (serviceid: cluster, actionid: restart). This step is required in this release; refer to known issue LUNA-31648.
POST /api/lunasa/services/{serviceid}/actions/{actionid}
LunaSH
Prerequisites
>Backup and restore operations can only be done on the primary member of the cluster.
>The cluster service must be running on the appliance and the member must be authorized.
>You must be logged in to LunaSH as admin to do backup/restore operations.
>Stop the cluster service on all non-primary members of the cluster before you begin the restore operation:
lunash:> service stop cluster
To restore a cluster from backup
1.Restore the cluster from backup by specifying the backup filename, the backup password, and the keyring type of restore operation.
lunash:> cluster restore run -filename <filename> -type keyring -restorepassword <password>
NOTE This operation takes longer for larger clusters.
2.[Optional] Check the status of the restore operation.
lunash:> cluster restore show
3.When the restore operation is complete, you may start the cluster service on each non-primary member, one at a time. Wait until each member is authorized before starting the next member. The amount of time it takes for each member to be authorized may vary, depending on the size of the data restored.
lunash:> service start cluster
Confirm that the member is authorized (Authorized: True) before starting the next member:
lunash:> cluster member show
4.Restart the cluster service on the primary member. This step is required in this release; refer to known issue LUNA-31648.
lunash:> service restart cluster
