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 Partition SMK
>Restoring a Cluster from Backup
NOTE Thales recommends Luna Network HSM Appliance Software 7.8.3 with cluster package 1.0.3, Luna HSM Firmware 7.8.2, and Luna HSM Client 10.6.0 to use clusters.
Backing Up/Restoring the Partition 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.
Prerequisites
>The Luna Backup HSM must be connected to a USB port on the Luna Network HSM appliance, and connected to power if necessary.
>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.
To restore the cluster SMK from backup
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.
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 Partition 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
curl -X PUT "https://1.2.3.4:50070/api/clusters/2afac9b6-f74c-4888-a059-da015240cd1b/backup" --data '{"action": "run", "password": "backuppassword", "filename": "myBackup", "UUID":"2afac9b6-f74c-4888-a059-da015240cd1b"}' -H "Content-Type: application/json" -H "Authorization: Basic dXNlcjpwYXNzd29yZA==" --insecure
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
curl -X PUT "https://1.2.3.4:50070/api/clusters/2afac9b6-f74c-4888-a059-da015240cd1b/backup" --data '{"action": "disable"}' -H "Content-Type: application/json" -H "Authorization: Basic dXNlcjpwYXNzd29yZA==" --insecure
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
curl -X PUT "https://1.2.3.4:50070/api/clusters/2afac9b6-f74c-4888-a059-da015240cd1b/backup" --data '{"action": "config", "total":"5", "time":"3:14:14", "filename": "myBackup"}' -H "Content-Type: application/json" -H "Authorization: Basic dXNlcjpwYXNzd29yZA==" --insecure
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
curl -X PUT "https://1.2.3.4:50070/api/clusters/2afac9b6-f74c-4888-a059-da015240cd1b/backup" --data '{"action": "enable", "password": "backuppassword"}' -H "Content-Type: application/json" -H "Authorization: Basic dXNlcjpwYXNzd29yZA==" --insecure
4.[Optional] Display the scheduled backup configuration.
PUT /api/clusters/{clusterid}/backup
curl -X PUT "https://1.2.3.4:50070/api/clusters/2afac9b6-f74c-4888-a059-da015240cd1b/backup" --data '{"action": "show"} -H "Content-Type: application/json" -H "Authorization: Basic dXNlcjpwYXNzd29yZA==" --insecure
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.
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 (see known issue LUNA-25157).
Restoring a Cluster from Backup
Use this procedure to restore the primary cluster member from backup using REST API or LunaSH.
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.
curl -X PUT "https://1.2.3.4:50070/api/cluster/restore" --data '{"myBackupPassword": "iamtheCO", "filename": "myBackup.tar.gz", "type": "keyring"}' -H "Content-Type: application/json" -H "Authorization: Basic dXNlcjpwYXNzd29yZA==" --insecure
NOTE During the restore operation, objects with the same UUID will be skipped.
This operation takes longer for larger clusters.
2.[Optional] Check the status of the restore operation.
curl "https://1.2.3.4:50070/api/cluster/restore" -H "Content-Type: application/json" -H "Authorization: Basic dXNlcjpwYXNzd29yZA==" --insecure
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
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 During the restore operation, objects with the same UUID will be skipped.
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
