--- title: "Introduction to Fortanix DSM Backup and Restore" slug: "introduction-to-fortanix-dsm-backup-and-restore" updated: 2026-06-02T13:46:37Z published: 2026-06-02T13:46:37Z canonical: "support.fortanix.com/introduction-to-fortanix-dsm-backup-and-restore" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.fortanix.com/llms.txt > Use this file to discover all available pages before exploring further. # Introduction to Fortanix DSM Backup and Restore ## 1.0 Introduction This article describes the Fortanix-Data-Security-Manager (DSM) backup and restore procedures such as: - High Availability - Disaster Recovery Plan - Configuring Backup - Data Recovery ## 2.0 High Availability Fortanix DSM provides a highly available service if the majority of nodes in a cluster are active. An ideal multi-site deployment of Fortanix DSM would cover at least 3 data centres (Availability Zones). KMS cluster, so the service remains available. See the following picture for a proposed architecture. ![Typical_fortanix_DSM_Deployment.png](https://cdn.us.document360.io/c3bd85d2-4ad8-4d85-9f60-f1c168a3aad9/Images/Documentation/11619502225428.png) **Figure 1: A typical Fortanix DSM deployment** ## 3.0 Disaster Recovery Plan (Fortanix DSM Version 3.15 onwards) Disaster may be defined as a situation where the entire production Fortanix DSM cluster goes down. Due to the built-in HA capabilities of Fortanix DSM, this is an extremely unlikely event. Some extreme scenarios which may lead to a disaster include a region-wide weather event, a complete network failure or DDOS attack, or a software bug that leads to unrecoverable data corruption. Fortanix provides a DR plan to recover from some scenarios as explained below. These steps can be practiced periodically to test DR readiness. 1. Designate one Fortanix DSM node in the Out-of-region (OOR) data centre for DR. You can call this node “DR node”. 2. Make the DR node join the production cluster. During this process, the DR node obtains attestation, gets a copy of the cluster master key (CMK), and then encrypts the CMK with its sealing key (derived specifically to that node and a version of the Fortanix DSM software), and stores it in the database. 1. Obtain the join token by running the following commands on an existing node of the cluster. The token for the new node to join the cluster is generated at the time of cluster creation. This token is valid for 24 hours. If you do not see any valid token from the output of “`kubeadm` token list”, then run the following command to generate a new token: ```bash sudo KUBECONFIG=/etc/kubernetes/admin.conf kubeadm token list // Optional, required only when the token has expired in case of adding a DR node after the cluster was created. sudo KUBECONFIG=/etc/kubernetes/admin.conf kubeadm token create ``` 2. Run the following command on the DR node to join the cluster: ```bash RECONFIGURE sudo sdkms-cluster join --peer=10.0.1.4/24 --token=fc853c.6fd193ba34870ddfGO ``` 3. Configure backup in Fortanix DSM to take periodic backups of the Cassandra database of the production cluster. *For more information on how to configure the backups, refer to*[*Section 5.0: References*](/v1/docs/introduction-to-fortanix-dsm-backup-and-restore#50-references)*.* 4. Store the backups of Cassandra database in OOR data centre. 5. Set aside the DR nodes so that if the production cluster goes down in the future, you can restore the cluster from the backup. Run the following command from any node in the cluster to remove the DR node from the cluster: ```bash sudo sdkms-cluster remove --node ``` 6. After the DR node is successfully removed from the cluster, log in to the DR node and run the following command to clean up data on this DR node: ```bash sudo sdkms-cluster reset –-delete-data ``` > [!NOTE] > NOTE > > This command must be run on the removed DR node after the node has been removed successfully. You must not run this command on any existing node of the cluster or on the DR node if it is still part of the cluster. 7. You must bootstrap the Fortanix DSM cluster on this DR node prior to restoring the data. Run the following command to create a cluster: ```bash sudo sdkms-cluster create --self= --config ./config.yaml ``` 8. Perform the steps to restore the backups.*For more information on how to restore the backups, refer to the*[*Section 5.0: Reference*](/v1/docs/introduction-to-fortanix-dsm-backup-and-restore#50-references)*.* 9. The DR node should now have the production data. Add 2 or more Fortanix DSM nodes to the DR node to create a fault tolerant Fortanix DSM cluster. ![Disaster_Recovery.png](https://cdn.us.document360.io/c3bd85d2-4ad8-4d85-9f60-f1c168a3aad9/Images/Documentation/11619504480148.png) **Figure 2: Disaster Recovery using a node in out-of-region data center** ## 4.0 Backup Sizing The backups that are configured are full backups, and each time a backup is performed it will consume space based on the total size of objects. For estimation, use the following guideline: - The size of a database backup for a cluster is 800MB with the following objects: - 100, 000 security objects - 10,000 groups - 2000 apps - 1000 accounts ## 5.0 Configuring Backup This section describes the steps to configure backups before or after creating a Fortanix Data Security Manager cluster. The following example demonstrates how to configure password-based backups using SCP (Secure Copy Protocol). *For other backup methods, refer to*[*Fortanix DSM Backup and Restore – Manual*](/v1/docs/backup-and-restore-manual). 1. Edit the `config.yaml` file to add the following properties to enable backups using SCP.*For more information on the*`config.yaml`*file, refer to Section 4.3 of the*[*Fortanix Data Security Manager Installation Guide - On-Prem*](/v1/docs/fortanix-data-security-manager-installation-guide-on-prem#43-begin-fortanix-dsm-configuration). > [!NOTE] > NOTE > > By default, all the CRON jobs schedules are in the UTC time zone. - For Fortanix DSM version 4.6 and above, use the `authmode` parameter with the value `password` or `privatekey`: ```bash backup:   cron_schedule: "1 1 * * *"   backup_mode: "snapshot"   exclude_auditlog: true   scp:     server_ip: "ip_address"     authmode: "password"     username: "administrator"     password: "********"     path: "/home/administrator/backup" ``` Where, *For more information, refer to*[*Fortanix DSM Password-Based Backup and Restore Using SCP - SGX*](/v1/docs/fortanix-dsm-password-based-backup-and-restore-using-scp-sgx). - `authmode` can be set to either `password` or `privatekey`. - `backup_mode` can be set to snapshot. - `exclude_autditlog` can be set to either `true` or `false`. It is recommended that the value be set to `true`. > [!NOTE] > NOTE > > Since Cassandra data is encrypted with the CMK, separate encryption of backup files is not required. Backups are transferred and stored in their already-encrypted form and remain cryptographically bound to the cluster infrastructure. Backups can be restored only on nodes that have previously joined the production cluster and inherited the CMK, making them secure against external decryption even if intercepted. ## 6.0 Disable Backup Configuration Perform the following steps to disable backups: 1. Edit the `config.yaml` file and remove the `backup` section. ```bash backup:   cron_schedule: "1 1 * * *"   backup_mode: "snapshot"   exclude_auditlog: true   scp:     server_ip: "ip_address"     authmode: “password”     username: "administrator"     password: "********"     path: "/home/administrator/backup" ``` 2. Run the following command to redeploy the cluster to apply changes to the `config.yaml` file: ```bash sdkms-cluster deploy --config config.yaml --stage DEPLOY ``` 3. If the backup cron job still exists, run the following command to delete it manually: ```bash kubectl delete cronjob sdkms-backup ``` > [!NOTE] > NOTE > > - This procedure disables future backups and removes the backup configuration from the cluster but does not delete existing backup files stored on the server. > - Existing backups must be manually removed from the backup destination, if required. ## 7.0 References For the step-by-step backup and restore procedures on SGX and non-SGX machines, refer to the following articles: - [Fortanix DSM Password-Based Backup and Restore Using SCP -SGX](/v1/docs/fortanix-dsm-password-based-backup-and-restore-using-scp-sgx) - [Fortanix DSM Passwordless SSH Key-Based Backup and Restore Using SCP - SGX](/v1/docs/fortanix-dsm-passwordless-based-backup-and-restore-using-scp-sgx) - [Fortanix DSM Backup and Restore for AWS S3 Bucket- SGX](/v1/docs/fortanix-dsm-backup-and-restore-for-aws-s3-bucket-sgx) - [Fortanix DSM Backup and Restore for Azure Blob Storage- SGX](/v1/docs/fortanix-dsm-backup-and-restore-for-azure-blob-storage-sgx) - [Fortanix DSM Backup and Restore - Non-SGX](/v1/docs/fortanix-dsm-backup-and-restore-non-sgx) - [Fortanix DSM Backup and Restore for CDK - Non-SGX](/v1/docs/fortanix-dsm-backup-and-restore-for-cdk-non-sgx) - [Fortanix DSM Backup for Audit Log](/v1/docs/fortanix-dsm-backup-for-audit-log) Fortanix Data Security Manager (DSM) is the world’s first cloud service secured with Intel® SGX. With Fortanix DSM, you can securely generate, store, and use cryptographic keys and certificates, as well as other secrets such as passwords, API keys, tokens, or any blob of data. Your business-critical applications and containers can integrate with Fortanix DSM using legacy cryptographic interfaces (PKCS#11, CNG, and JCE) or using the native Fortanix DSM RESTful interface. Fortanix Data Security Manager (DSM) is the world’s first cloud service secured with Intel® SGX. With Fortanix DSM, you can securely generate, store, and use cryptographic keys and certificates, as well as other secrets such as passwords, API keys, tokens, or any blob of data. Your business-critical applications and containers can integrate with Fortanix DSM using legacy cryptographic interfaces (PKCS#11, CNG, and JCE) or using the native Fortanix DSM RESTful interface. ## Related - [Passwordless-Based Backup and Restore Using SCP - SGX](/fortanix-dsm-passwordless-based-backup-and-restore-using-scp-sgx.md) - [Password-Based Backup and Restore Using SCP - SGX](/fortanix-dsm-password-based-backup-and-restore-using-scp-sgx.md) - [Backup and Restore for AWS S3 Bucket - SGX](/fortanix-dsm-backup-and-restore-for-aws-s3-bucket-sgx.md) - [Data Center Labeling](/fortanix-data-security-manager-data-center-labeling.md) - [Fortanix Support Sign Up Process](/fortanix-support-sign-up-process.md)