Backups

Backups are generated on the appliance and are stored there until deleted. They can be downloaded from the appliance and uploaded back to the same or to another appliance. When a backup is created, it is always encrypted with a backup key. If a backup key is not specified, the default backup key is used to encrypt the backup. This backup key is required to restore the backup file.

Backups and backup keys are not automatically copied to other nodes in a cluster. They only exist on a node where they are created or copied to. Backups are treated as resources and are controlled through the API, ksctl, and GUI.

CipherTrust Manager supports system backups and domain scoped backups.

Release compatibility

This compatibility applies to both system and domain backups.

By default, the CipherTrust Manager backups can be restored on the next three minor versions. For example, a backup of release 2.11 can be restored to 2.12, 2.13, and 2.14 instances. A --force option can override this restriction, allowing for restore of backups taken from three or more earlier minor versions.

For LTS versions, a backup from an LTS release can be restored on the next three minor versions, as stated above, and the next two LTS releases. For example, let's assume there are four LTS releases 2.11, 2.17, 2.20, and 2.25. Then, a backup from 2.11 (LTS release) can be restored on 2.12, 2.13, and 2.14 (the next three minor versions). In addition, a backup from 2.11 can be restored on 2.17 and 2.20 (the next two LTS releases).

Backward compatibility is not supported. For example, a backup of release 2.10 cannot be restored to a 2.9 instance.

HSM-anchored domain resources

Resources from every domain are included in a system backup, and domain-scoped backup is available for HSM-anchored domains. The contents of an HSM-anchored domain are always encrypted by an HSM partition. This means that you can only restore to a domain or appliance with a connection to the same HSM partition.

System backups

System backups are a snapshot of the database in an appliance at a point in time. They are created on the appliance, and after creation, they can be used to:

• Restore the appliance to a previous state

• Transfer the backup to another appliance to restore on that appliance

• Create a new appliance with the backup

CipherTrust Manager users (such as Application Administrators), who are authorized to perform backup, can perform system backups and restores. Domain administrators are not authorized to perform system backups.

Tying the system backup to an HSM

A system backup can optionally be tied to an HSM for increased protection of the data. This means that the backup can only be restored to an appliance that has the same active HSM Root of Trust (RoT) key as was used when the backup was taken. This feature improves the protection of backup files, but requires careful management of the HSM RoT key used for the backup. Otherwise, data loss is possible.

Unless the appliances share the same HSM partition and the same active HSM RoT key, a backup tied to the HSM cannot be restored to any other appliance. Also, if you manually delete the RoT key, or the HSM is tampered and the RoT key is deleted, a backup tied to that HSM can never be restored.

Rotating the HSM RoT key prevents the appliance from restoring the backup file. You can regain the ability to restore the backup by rotating the original RoT key back to an active state.

Backup Contents

A system backup includes the following:

• All domain resources

• Keys, key attributes, and key links

• Users, groups, and their relationships

• Local Certificate Authorities (CAs)

• External Certificate Authorities (CAs)

• Certificates issued by Local CAs, excluding certificates configured for the CipherTrust Manager interfaces

• Interface configuration, aside from the certificate

• Policies

• CSM customer fragments

• Audit records

• Schedules

• Legacy syslog connections and connection manager connections

• LDAP connections

• OIDC connections for managing CipherTrust Manager users.

• Resources of all supported applications: Keys, Access Management, Admin Settings, Data Discovery, ProtectDB, ProtectFile, ProtectApp, and KMIP

The following objects are excluded from the backup:

• Backup keys

• Cluster configuration

• DNS hosts

• NTP configuration

• HSM configuration

• Instance name

• Virtual CipherTrust Manager license

• Interface certificates

• Debug, KMIP Activity, and NAE Crypto Activity Logs

• Proxy configuration

Domain scoped backups

Domain scoped backup and restore is the ability to back up user-specified resources partially and incrementally from a domain. Domain scoped backups are created on the appliance, and after creation, can be used to:

• Restore the resources on the same domain to its previous state

• Restore on a different domain in the same appliance

• Transfer to another appliance to restore on a different domain

In all cases, a destination domain must exist for the backup to be restored to. For a backup taken from an HSM-anchored domain, the destination domain must have a connection to the same HSM partition as was configured for the backed up domain. You can only add an HSM connection to a domain during creation.

CipherTrust Manager users (such as Domain Administrators), who are authorized to perform backup, can perform domain scoped backup and restore. Application Administrators can perform backup and restore operations of domain scoped backup of root domain only, not other sub-domains.

Backup contents

Domain scoped backups include the following:

• Keys, key attributes, key links

• CTE policies

• Users and Groups

• Customer fragments

• CCKM resources: Projects, Google EKM Endpoints and Cryptospaces

  Note

  • The CipherTrust Manager allows you to take backup of the individual keys.

  • Trusted Partner Cloud Cryptospace type is not included in the domain backup.

Typical backup and restore operations

The following are typical backup operations using the ksctl. If you are using the API, refer to the API playground for details.

1. Create the backup key

2. Create the backup

3. Check the backup status

4. Download the backup key

5. Download the backup

6. Transfer the Backup using Secure Copy Protocol

7. Inspect the backup key file

8. Upload the backup key

9. Inspect the backup file

10. Upload the backup

11. Restore the backup

12. Check the restore status

Create the backup key

Backups are automatically encrypted by a backup key at the time of their creation. If no key is specified, the default backup key is used. If needed, a new backup key can be created and optionally set as the default backup key.

Backup keys can be of two types:

• System scoped keys to encrypt only system backups

• Domain scoped keys to encrypt only domain scoped backups

To create a system backup key

To create a system backup key, run ksctl backupkeys create. If not specified, the default scope is system.

Example:

ksctl backupkeys create
{
  "scope": "system",
  "account": "kylo:kylo:admin:accounts:kylo",
  "version": "2",
  "id": "5dac1d33-9c2d-4fc1-9793-961052d73a29",
  "createdAt": "2020-04-07T08:17:54.600032599Z",
  "isDefault": false
}

To create a system backup key and set it as the default key, run ksctl backupkeys create --scope system --default.

Example:

ksctl backupkeys create --scope system --default
{
  "scope": "system",
  "account": "kylo:kylo:admin:accounts:kylo",
  "version": "2",
  "id": "c05b638d-2eea-4651-9937-7bee49a95f6b",
  "createdAt": "2020-04-07T08:21:59.139786694Z",
  "isDefault": true
}

To create a domain scoped backup key

To create a domain scoped backup key, run ksctl backupkeys create --scope domain. Here, --scope domain specifies that the key is domain scoped. The scope flag must be used for creating domain scoped backup keys.

Example:

ksctl backupkeys create --scope domain
{
  "scope": "domain",
  "account": "kylo:kylo:admin:accounts:kylo",
  "domainID": "00000000-0000-0000-0000-000000000000",
  "version": "2",
  "id": "88f47a71-a1d7-41ae-af49-736862f4f625",
  "createdAt": "2020-04-07T08:31:29.314569058Z",
  "isDefault": false
}

To create a domain scoped backup key and set it as the default key, run ksctl backupkeys create --scope domain --default.

Example:

ksctl backupkeys create --scope domain --default
{
  "scope": "domain",
  "account": "kylo:kylo:admin:accounts:kylo",
  "domainID": "00000000-0000-0000-0000-000000000000",
  "version": "2",
  "id": "2f91020c-5fb7-4709-aca4-f4ce1ba9a54a",
  "createdAt": "2020-04-07T08:24:13.648719582Z",
  "isDefault": true
}

To view the list of available backup keys

Run the command ksctl backupkeys list.

Example:

ksctl backupkeys list

{
  "skip": 0,
  "limit": 10,
  "total": 2,
  "resources": [
    {
      "scope": "system",
      "account": "kylo:kylo:admin:accounts:kylo",
      "version": "2",
      "id": "c05b638d-2eea-4651-9937-7bee49a95f6b",
      "createdAt": "2020-04-07T08:21:59.139786694Z",
      "isDefault": true
      },
      {
        "scope": "domain",
        "account": "kylo:kylo:admin:accounts:kylo",
        "domainID": "00000000-0000-0000-0000-000000000000",
        "version": "2",
        "id": "2f91020c-5fb7-4709-aca4-f4ce1ba9a54a",
        "createdAt": "2020-04-07T08:24:13.648719582Z",
        "isDefault": true
      }
      ]
}

Create a backup

It allows you to create system and domain scoped backup using ksctl.

To create a system backup

To create a system backup, run ksctl backup create. If an encryption key is not specified when creating a backup, the backup is encrypted by the default backup key. You can check the status of the backup by running the ksctl backup status command. Refer to Check the backup status for details.

Example:

ksctl backup create
{
  "scope": "system",
  "account": "kylo:kylo:admin:accounts:kylo",
  "version": "v1.1.4",
  "id": "245d3336-21fa-4a34-9498-c0b64fa4d322",
  "createdAt": "2020-04-07T08:33:44.687970269Z",
  "status": "In Progress",
  "tiedToHSM": false,
  "backupKey": "c05b638d-2eea-4651-9937-7bee49a95f6b",
  "productVersion": "v1.10.0-beta4.4388"
}

When a backup is initiated, it status becomes "In Progress". It may take a while until the status becomes "Completed". When a backup operation is "In Progress", another backup or restore operation cannot be initiated.

To create a system backup by specifying the scope as system, run ksctl backup create --scope system.

Example:

ksctl backup create --scope system
{
  "scope": "system",
  "account": "kylo:kylo:admin:accounts:kylo",
  "version": "v1.1.4",
  "id": "06c7d57d-2749-4285-8c60-c2778c911cd2",
  "createdAt": "2020-04-07T08:34:49.914616905Z",
  "status": "In Progress",
  "tiedToHSM": false,
  "backupKey": "c05b638d-2eea-4651-9937-7bee49a95f6b",
  "productVersion": "v1.10.0-beta4.4388"
}

To create a domain scoped backup

When creating a domain scoped backup, specify the scope as domain. To create a domain scoped backup, run ksctl backup create --scope domain. You can check the status of the backup by running the ksctl backup status command. Refer to check the backup status for details.

Here, --scope domain specifies that the backup is domain scoped. The scope flag must be used for creating domain scoped backups.

Example:

ksctl backup create --scope domain
{
  "scope": "domain",
  "account": "kylo:kylo:admin:accounts:kylo",
  "domainID": "00000000-0000-0000-0000-000000000000",
  "version": "v1.1.4",
  "id": "762d15f3-4eba-4cd7-960c-c50a84a52b48",
  "createdAt": "2020-04-07T08:36:34.667280981Z",
  "status": "In Progress",
  "tiedToHSM": false,
  "backupKey": "2f91020c-5fb7-4709-aca4-f4ce1ba9a54a",
  "productVersion": "v1.10.0-beta4.4388"
}

Filters apply to domain scoped backups only.

To use filters, run either of the following commands:

• ksctl backup create --scope domain --filters <filters-json>

• ksctl backup create --scope domain --filters-jsonfile <file-name-containing-filters-json>

Examples:

• Example 1:

  To create a domain scoped backup of all CTE keys and CTE policies, run the following command:

  ksctl backup create --scope domain --filters '[{"resourceType": "Keys"},{"resourceType": "cte_policies"}]'
  

• Example 2:

  To create a domain scoped backup for all CTE policies (without keys), run the following command:

  ksctl backup create --scope domain --filters '[{"resourceType": "cte_policies"}]'
  

• Example 3:

  To create a domain scoped backup for only STANDARD CTE policies (without keys), run the following command:

  ksctl backup create --scope domain --filters '[{"resourceType": "cte_policies", "resourceQuery":{"policy_type":"STANDARD"}}]'
  

• Example 4:

  To create a domain scoped backup for all users and groups, run the following command:

  ksctl backup create --scope domain --filters '[{"resourceType": "users_groups"}]'
  

  For users, the valid resourceQuery parameter values are the same as query parameters of the list '/v1/usermgmt/users' endpoint. For example, to back up all users with name "frank" and email id "frank@local", use:

  ksctl backup create --scope domain --filters '[{"resourceType": "users", "resourceQuery":{{"name":"frank","email": "frank@local"}}]'
  

• Example 5:

  To create a domain scoped backup for individual keys using key names, run the following command:

  ksctl backup create --scope domain -k f52e26f8-ba8e-4f30-878d-ce88a118091f --filters '[{"resourceType":"Keys", "resourceQuery": { "names":["key1", "key2"]}}]'
  

  Note

  The backup and restore of users, groups, and CCKM resources (Projects, Google EKM Endpoints and Cryptospaces) in a domain only works among the domains of different CipherTrust Managers. This feature does not support backup and restore among different domains of the same CipherTrust Manager.

  Note

  • The assigned users from the root domain cannot be backed up.

  • If the same user exists in the source domain (backup file) and the target domain, the user from the source domain is ignored. However, the corresponding groups of that user are restored. The same user of the target domain will not be part of any restored groups; but, can be added manually, if required.

  • If the same group exists in the source domain (backup file) and the target domain, the group from the source domain is not restored. However, the corresponding users of that group are restored. The restored users will not be part of the same group; but can be added manually, if required.

Refer to the API playground for details on filters.

To view the list of available backups

To view the list of available backups, run ksctl backup list.

Example:

ksctl backup list
{
  "skip": 0,
  "limit": 10,
  "total": 2,
  "resources": [
    {
      "scope": "system",
      "account": "kylo:kylo:admin:accounts:kylo",
      "version": "v1.1.4",
      "id": "06c7d57d-2749-4285-8c60-c2778c911cd2",
      "createdAt": "2020-04-07T08:34:49.914616905Z",
      "status": "Completed",
      "tiedToHSM": false,
      "backupKey": "c05b638d-2eea-4651-9937-7bee49a95f6b",
      "productVersion": "v1.10.0-beta4.4388"
    },
    {
      "scope": "domain",
      "account": "kylo:kylo:admin:accounts:kylo",
      "domainID": "00000000-0000-0000-0000-000000000000",
      "version": "v1.1.4",
      "id": "762d15f3-4eba-4cd7-960c-c50a84a52b48",
      "createdAt": "2020-04-07T08:36:34.667280981Z",
      "status": "Completed",
      "tiedToHSM": false,
      "backupKey": "2f91020c-5fb7-4709-aca4-f4ce1ba9a54a",
      "productVersion": "v1.10.0-beta4.4388"
    }
  ]
}

To view the details of a backup

To view the details of a backup, run ksctl backup get --id "backupID". The status of the backup is given in the response. A status of "Completed" indicates that the backup is successful.

Example:

ksctl backup get --id "762d15f3-4eba-4cd7-960c-c50a84a52b48"
{
  "scope": "domain",
  "account": "kylo:kylo:admin:accounts:kylo",
  "domainID": "00000000-0000-0000-0000-000000000000",
  "version": "v1.1.4",
  "id": "762d15f3-4eba-4cd7-960c-c50a84a52b48",
  "createdAt": "2020-04-07T08:36:34.667280981Z",
  "status": "Completed",
  "tiedToHSM": false,
  "backupKey": "2f91020c-5fb7-4709-aca4-f4ce1ba9a54a",
  "productVersion": "v1.10.0-beta4.4388"
}

Check the backup status

Initiating a backup begins an asynchronous operation on the appliance. Only one backup or restore operation can be performed at a time. If you try to perform another operation until the previous is complete, the operation will fail.

To view the status of the last backup, run the command ksctl backup status. The status of the backup is given in the response.

Example:

ksctl backup status
{
  "scope": "system",
  "account": "kylo:kylo:admin:accounts:kylo",
  "operation": "Backup create",
  "id": "f6b55640-ddec-49d0-893b-4f33f0809bf0",
  "started": "2020-04-10T00:27:01.078766633Z",
  "status": "In Progress"
}

In the output above, the status of the backup is In Progress.

Download the backup key

The key with which the backup is encrypted must be transferred to the appliance where the backup will be restored. The backup key is required for the restore. To transfer a backup key, it must be downloaded using the command ksctl backupkeys download. After the key is downloaded, it can be uploaded to the appliance to restore the backup.

To download the backup key

Run the command ksctl backupkeys download --id "<backupkeyID>" --file "<file-to-store-key>". The same command is used to the download system scoped and domain scoped backup keys.

Here:

• "<backupkeyID>": ID of the backup key to download.

• "<file-to-store-key>": Name of the file to store the backup key.

Specify a password for the backup key when prompted.

Example - download system backup key:

ksctl backupkeys download --id "c05b638d-2eea-4651-9937-7bee49a95f6b" --file "sysbkkey.txt" Password is required for backupkey. Please provide the backupkey password:

Download the backup

The backup must be transferred to the appliance where it will be restored. To transfer a backup, it must be downloaded by using the command ksctl backup download. After the backup is downloaded, it can be uploaded to the appliance for restore.

To download the backup

To download a backup, run the command ksctl backup download --id "<backupID>" --file "<backup-file>".

Here,

• "<backupID>": ID of the backup to download.

• "<backup-file>": Name of the file to store the backup.

Example - download system backup:

ksctl backup download --id "245d3336-21fa-4a34-9498-c0b64fa4d322" --file "backup-file.txt"

Transfer the backup using Secure Copy Protocols (SCP/SFTP)

SCP/SFTP allows you to securely transfer only the system backups from the CipherTrust Manager to the external servers.

The following operations can be performed:

• Transfer backup to the destination host machine

• Get backup transfer status

To transfer the backup to the destination host machine

To transfer the backup to the destination host machine, first, you need to retrieve and then rotate the public key of the CipherTrust Manager.

Retrieve the public key

Syntax

ksctl scp public-key get

Example

ksctl scp public-key get
{
"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDHMDnKwJUTBwZsdrF11hni2aCnPob78Wwq3ix8WYI4TwAP6DWi0zy2aDlEry62DIVGOMJ1z4hdugfgTfzY45IVf/vGOlMsK+eOtvGErA6A6dCwXvxhX068MNytZHqt2tR6KV8smHMWec62hAubtQs1wZSAz80JvWDMOSKs3OtTRILLtgyaO7n1omAHZLxc6XZ70e2b0sAB03oV9PCzI2QJb/KBEdpcA1IEB0Ts4QrXlp3rEzCSYfAU2SW5pIrisSLKyBdu5MQ7esvf2SDcrCL3O2t0FXv8A/r0k63tmQNFRfLHOEQ1BjWF/jHNtZ4T7Wf5pH0JspSPARVAKLQTp9vTGM0bR28/oisWqC9Dbky5Ks5TfCfQKZBQ57mN3b4Z4aU1mb6TQqTCSps8INq9Bk7wzPXBa3mPDpdBmIrsofiDuMBem+PRtuW5RwU28dvt7D5HqjD2V8pW8YMKugl0MZwCe6pcPiiH8vaKe0EI/HAKRPooKBYmLHO6RzVtMUhxe0jUsD1zOZNviiB/S4j3JxE190FJCHEb4Ann3Tc1QFCMUMKnmGRfO4WNrgIWrULxFJSsyZVPk+E1g4RDFORwPbIwkEY0jhZaO/sW8ptriKNGVZgxU2G7RJOo0s4RTCUeA7wvcxHZFiYAu0jUGWhgN/YEYyztOXiWde/EFxd6o7WbaQ=="
}

Rotate the public key

It rotates the key used in the key-based authentication for securely copying the backups. The key rotation breaks the backup transfer operation in the existing backup scheduler, if any. After rotating the key, add the new CipherTrust Manager public key to ~/.ssh/authorized_keys file at the destination host machine.

Syntax

ksctl scp public-key rotate

Example

ksctl scp public-key rotate
{
    "success": true
}

To transfer the backup to the destination host machine, run:

Syntax

ksctl backup scp --id <backup-id> --host <hostname> port <port> --username <scp-connection-username> --auth-method <key or password> --protocol <scp-or-sftp> --password <scp-connection-password> --public-key <key> --path-to <destination-machine-path>

Example

ksctl backup scp --id fe70d13e-9598-48b8-8b49-d37d2591d7b4 --host 1.2.3.4 port 22 --username ksadmin --auth-method key --protocol sftp --public-key "ssh-rsa AAAAB3NzaCgQD1+kVUr4xNVA9Yhk=" --path-to /home/ksadmin 
{
    "id": "5d14bd52-a8fd-4410-bd31-850bfd7a67c0",
    "host": "1.2.3.4",
    "connection_status": "in_progress",
    "createdAt": "2024-07-02T11:19:10.283401126Z",
    "updatedAt": "2024-07-02T11:19:10.283401182Z"
}

To get the secure copy backup transfer status

To get the status of the backup transferred through SCP/SFTP, run:

Syntax

ksctl backup scp status --id <backup-id> --scpid <scp-id> 

Example

ksctl backup scp status --id 7589f772-2e7c-40e3-bc2e-83047de4a93a --scpid 403b4cb1-dbe4-4f17-84e8-4bb81e349707
{
    "id": "403b4cb1-dbe4-4f17-84e8-4bb81e349707",
    "host": "hostname",
    "connection_status": "completed",
    "createdAt": "2021-06-07T06:36:33.139235834Z",
    "updatedAt": "2021-06-07T06:36:43.811369505Z"
}

To get the status of all secure copy backup requests

To get the status of all SCP/SFTP requests for a given backup, run:

Syntax

ksctl backup scp status --id <backup-id>

Example

ksctl backup scp status --id 7589f772-2e7c-40e3-bc2e-83047de4a93a
[
    {
            "id": "403b4cb1-dbe4-4f17-84e8-4bb81e349707",
            "host": "hostname",
            "connection_status": "completed",
            "createdAt": "2021-06-07T06:36:33.139235834Z",
            "updatedAt": "2021-06-07T06:36:43.811369505Z"
    },
    {
            "id": "e16d23e8-c34c-4ed3-b704-61227a1c359d",
            "host": "hostname",
            "connection_status": "completed",
            "createdAt": "2021-06-07T06:39:16.983115218Z",
            "updatedAt": "2021-06-07T06:39:16.98311528Z"
    }
]

Inspect the backup key file

Before uploading the backup key file, inspect it by reviewing its metadata. To inspect the backup key file, run the command ksctl backupkeys inspect --file "<backup-key-file>".

Example - system backup key file:

ksctl backupkeys inspect --file "sysbkkey.txt"
{
  "version": 2,
  "keyid": "c05b638d-2eea-4651-9937-7bee49a95f6b",
  "createdAt": "2020-04-07T08:21:59.139786694Z"
}

Example - domain scoped backup key file:

ksctl backupkeys inspect --file "domainbkkey.txt"
{
  "version": 2,
  "keyid": "2f91020c-5fb7-4709-aca4-f4ce1ba9a54a",
  "createdAt": "2020-04-07T08:24:13.648719582Z"
}

Upload the backup key

Upload the backup key to the appliance where the backup will be restored.

To upload the system backup key

Run the command ksctl backupkeys upload --file "<backup-key-file>". Here, <backup-key-file> represents the name of the system backup key file.

Specify the password of the backup key when prompted.

Example:

ksctl backupkeys upload --file "sysbkkey.txt"
Please provide the backupkey password:
{
  "scope": "system",
  "account": "kylo:kylo:admin:accounts:kylo",
  "version": "2",
  "id": "c05b638d-2eea-4651-9937-7bee49a95f6b",
  "createdAt": "2020-04-07T08:21:59.139786694Z",
  "isDefault": false
}

To upload the domain scoped backup key

Run the command ksctl backupkeys upload --scope domain --file "<backup-key-file>".

Here,

• --scope domain: Scope of the backup key is domain. The scope flag must be used for uploading domain scoped backup keys.

• <backup-key-file>: Name of the domain scoped backup key file.

Specify the password of the domain scoped backup key when prompted.

Example:

ksctl backupkeys upload --scope domain --file "domainbkkey.txt"
Please provide the backupkey password:
{
  "scope": "domain",
  "account": "kylo:kylo:admin:accounts:kylo",
  "domainID": "00000000-0000-0000-0000-000000000000",
  "version": "2",
  "id": "2f91020c-5fb7-4709-aca4-f4ce1ba9a54a",
  "createdAt": "2020-04-07T08:24:13.648719582Z",
  "isDefault": false
}

Inspect the backup file

Before uploading the backup file, inspect the file by reviewing its metadata. To inspect the backup file, run the command ksctl backup inspect --file "<backup-file>".

Example - system backup file:

ksctl backup inspect --file "backup-file.txt"
{
  "version": "v1.1.4",
  "createdAt": "2020-04-07T08:33:44.687970269Z",
  "scope": "system",
  "domainID": "",
  "backupKeyId": "c05b638d-2eea-4651-9937-7bee49a95f6b",
  "isEncrypted": true,
  "creatorAccount": "kylo:kylo:admin:accounts:kylo",
  "isHSMBacked": false,
  "description": "",
  "checksum": "9f19ab202f860cfa5de7fcbe70872a0aea1ee91af9092c80cb89939c35aea994",
  "mkekChecksum": "d1fe06afe54bfe5f242323b42c640b218a76fae91e7bb0baf10720b47a39be20",
  "productVersion": "v1.10.0-beta4.4388",
  "id": "245d3336-21fa-4a34-9498-c0b64fa4d322"
}

Example - domain scoped backup file:

ksctl backup inspect --file "domain-backup-file.txt"
{
  "version": "v1.1.4",
  "createdAt": "2020-04-07T08:36:34.667280981Z",
  "scope": "domain",
  "domainID": "00000000-0000-0000-0000-000000000000",
  "backupKeyId": "2f91020c-5fb7-4709-aca4-f4ce1ba9a54a",
  "isEncrypted": true,
  "creatorAccount": "kylo:kylo:admin:accounts:kylo",
  "isHSMBacked": false,
  "description": "",
  "checksum": "1c1a58b2ead4f09fceb67297603dbf01e40a8bec6d812e78a64287afa9619f8f",
  "mkekChecksum": "12f700ed4f872bd93864cfd7f9d162574025d3ee30ec2c08ccf13362c899a837",
  "productVersion": "v1.10.0-beta4.4388",
  "id": "762d15f3-4eba-4cd7-960c-c50a84a52b48"
}

Upload the backup

Upload the backup to the appliance where it will be restored.

To upload the system backup

Run the command ksctl backup upload --file "<backup-file>". Here, <backup-file> represents the name of the system backup file.

Example:

ksctl backup upload --file "backup-file.txt"
{
  "scope": "system",
  "account": "kylo:kylo:admin:accounts:kylo",
  "version": "v1.1.4",
  "id": "245d3336-21fa-4a34-9498-c0b64fa4d322",
  "createdAt": "2020-04-07T08:33:44.687970269Z",
  "status": "Completed",
  "tiedToHSM": false,
  "backupKey": "c05b638d-2eea-4651-9937-7bee49a95f6b",
  "productVersion": "v1.10.0-beta4.4388
}

To upload the domain scoped backup

Run the command ksctl backup upload --scope domain --file "<domain-backup-file>".

Here,

• --scope domain: Scope of the backup is domain. The scope flag must be used for uploading domain scoped backups.

• <domain-backup-file>: Name of the domain scoped backup file.

Example:

ksctl backup upload --scope domain --file "domain-backup-file.txt"
{
  "scope": "domain",
  "account": "kylo:kylo:admin:accounts:kylo",
  "domainID": "00000000-0000-0000-0000-000000000000",
  "version": "2",
  "id": "2f91020c-5fb7-4709-aca4-f4ce1ba9a54a",
  "createdAt": "2020-04-07T08:24:13.648719582Z",
  "isDefault": false
}

Restore the backup

After the backup and the backup key are uploaded to the appliance, you can restore the backup on the appliance. Check the restore status by running the ksctl backup status command. Refer to check the restore status.

To restore the backup

Run the command ksctl backup restore --id "<backupID>". Here, <backupID> specifies the ID of the backup to restore.

System services will restart after the system backup is restored. Restore of the domain scoped backup does not restart the system services.

For domain-scoped backups, login to the desired destination domain where the backup objects will be restored.

Example:

ksctl backup restore --id "245d3336-21fa-4a34-9498-c0b64fa4d322"
{
  "version": "v1.1.4",
  "id": "245d3336-21fa-4a34-9498-c0b64fa4d322",
  "createdAt": "2020-04-07T08:33:44.687970269Z",
  "status": "Completed",
  "tiedToHSM": false
}

Strategies for restoring domain backup

If there are conflicting resources in the backup and restore domains, the following strategies are used by the CipherTrust Manager during backup restore:

Check the restore status

After performing the backup restore, you can check the status of the operation. To view the status of the restore, run the command ksctl backup status. The status of the restore is given in the response.

Example:

ksctl backup status
{
  "account": "kylo:kylo:admin:accounts:kylo",
  "id": "f6b55640-ddec-49d0-893b-4f33f0809bf0",
  "createdAt": "0001-01-01T00:00:00Z",,
  "status": "In Progress",
  "tiedToHSM": false
}

In the output above, the status of the restore is In Progress.

Backup/restore of customer fragments

Prerequisites

• CipherTrust Manager is up and running. Refer to CipherTrust Manager Deployment for details.

• Make sure to enable the secrets-manager service (Admin Settings > Services) before backup and restore operations. Otherwise, domain backup/partial domain backup will not include customer fragments into it.

Important notes

For the root-domain users

• Backup and restore of customer fragments can only be performed in the root domain. Let's understand different scenarios when the user is in the root domain and the secrets-manager service is enabled.

For the non-root domain users

• CipherTrust Manager doesn't support customer fragments backup and restore in the non-root domain. Let's understand different scenarios if backup or restore occurs in non-root domain.

Creating backup

ksctl backup create --scope domain

ksctl backup create --scope domain --filters <filters-json>

or

ksctl backup create --scope domain --filters-jsonfile <file-name-containing-filters-json>

ksctl backup create --scope domain --filters '[{"resourceType": "customer_fragments", "resourceQuery":{"ids":["47f03ddd-c92b-4834-a4d3-dfe60b5fcf6a","fd9cf9b5-179a-4eba-a58b-dd321484e474"]}}]'

ksctl backup create --scope domain --filters '[{"resourceType": "customer_fragments", "resourceQuery":{"names":["CipherTrust Manager's default customer fragment","CF 1"]}}]'

ksctl backup create --scope domain --filters-jsonfile test.json

[{"resourceType": "customer_fragments", "resourceQuery":{"names":["CipherTrust Manager's default customer fragment","CF 1"]}}]

Restoring backup

ksctl backup restore --id <backupID>