From 9838e39e28b81e3b251e040cc1391771e4d4f6e2 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Mon, 23 Mar 2026 18:24:57 +0800 Subject: [PATCH 1/9] cloud-premium: add manual backup support for premium instances - Add manual backup feature with key characteristics and creation steps - Update PITR window to 7 days for premium instances - Fix Premium naming consistency using {{{ .premium }}} variable - Remove manual backup limitation note since it's now supported Co-Authored-By: Claude Opus 4.6 --- .../premium/backup-and-restore-premium.md | 34 +++++++++++++++---- 1 file changed, 27 insertions(+), 7 deletions(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 392acfacbd4c0..a5438c3eadd07 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -6,12 +6,12 @@ aliases: ['/tidbcloud/restore-deleted-tidb-cluster'] # Back Up and Restore {{{ .premium }}} Data -This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports automatic backup and lets you restore backup data to a new instance as needed. +This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports both automatic backups and manual backups, and lets you restore backup data to a new instance as needed Backup files can originate from the following sources: - Active {{{ .premium }}} instances -- The Recycle Bin for backups from deleted Premium instances +- The Recycle Bin for backups from deleted {{{ .premium }}} instances > **Tip:** > @@ -67,6 +67,29 @@ To delete an existing backup file for your {{{ .premium }}} instance, perform th 2. Locate the corresponding backup file you want to delete, and click **...** > **Delete** in the **Action** column. +## Manual backups +In addition to automatic backups, {{{ .premium }}} supports manual backups. Manual backups provide a user-controlled, guaranteed restore point, which is highly recommended before performing high-risk actions such as system upgrades, critical data deletion, or irreversible schema/configuration changes. + +### Key characteristics of manual backups: + +- **Retention and Deletion**: Unlike automatic backups, manual backups are not automatically deleted based on retention rules. They are retained indefinitely until you explicitly delete them. If the instance is deleted, its manual backups are moved to the Recycle Bin and will remain there permanently until manual deletion. + +- **Storage Location**: Manual backups are stored in TiDB Managed Cloud Storage. + +- **Cost**: Due to their long-term retention, manual backups are subject to additional charges. + +- **Limitations**: Manual backups do not support Point-in-Time Recovery (PITR) or partial backups (e.g., table-level or database-level). Restoring a manual backup into an existing or running cluster is not supported; each restore requires a new cluster. + +- **Permissions**: Both Organization owners and Instance managers can perform manual backups. However, only Organization owners can perform restore actions for system-managed manual backups. + +### Create a manual backup + +1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. + +2. In the upper-right corner, click **...**, and then click **Manual Backup**. + +3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the Backup List. It can be restored directly through the UI without requiring external storage credentials. + ## Restore TiDB Cloud provides restore functionality to help recover data in case of accidental loss or corruption. You can restore from backups of active instances or from deleted instances in the Recycle Bin. @@ -75,11 +98,11 @@ TiDB Cloud provides restore functionality to help recover data in case of accide TiDB Cloud supports snapshot restore and point-in-time restore for your instance. -- **Snapshot Restore**: restores your instance from a specific backup snapshot. +- **Snapshot Restore**: restores your instance from a specific backup snapshot. Both automatic and manual backups can be restored this way. Manual backups are displayed in the Backup List with a "Manual" backup type and a "Permanent" expiration status. - **Point-in-Time Restore**: restores your instance to a specific point in time. - - Premium instances: can be restored to any time within the last 33 days, but not earlier than the instance creation time or later than one minute before the current time. + - Premium instances: can be restored to any time within the last 7 days, but not earlier than the instance creation time or later than one minute before the current time. (Note: PITR is not supported for manual backups) ### Restore destination @@ -194,9 +217,6 @@ To restore backups from cloud storage, do the following: 5. Click **Restore** to restore the backup. -## Limitations - -Currently, manual backups are not supported for {{{ .premium }}} instances. ## References From fdd5c155814233c3311fa63cf2e811ccde1ef2ef Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Tue, 24 Mar 2026 09:41:35 +0800 Subject: [PATCH 2/9] Apply suggestions from code review Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/backup-and-restore-premium.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index a5438c3eadd07..e5dd94bfc4476 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -6,7 +6,7 @@ aliases: ['/tidbcloud/restore-deleted-tidb-cluster'] # Back Up and Restore {{{ .premium }}} Data -This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports both automatic backups and manual backups, and lets you restore backup data to a new instance as needed +This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports both automatic backups and manual backups, and lets you restore backup data to a new instance as needed. Backup files can originate from the following sources: @@ -88,7 +88,7 @@ In addition to automatic backups, {{{ .premium }}} supports manual backups. Manu 2. In the upper-right corner, click **...**, and then click **Manual Backup**. -3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the Backup List. It can be restored directly through the UI without requiring external storage credentials. +3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. You can restore it directly through the UI without requiring external storage credentials. ## Restore @@ -102,7 +102,7 @@ TiDB Cloud supports snapshot restore and point-in-time restore for your instance - **Point-in-Time Restore**: restores your instance to a specific point in time. - - Premium instances: can be restored to any time within the last 7 days, but not earlier than the instance creation time or later than one minute before the current time. (Note: PITR is not supported for manual backups) + - Premium instances: can be restored to any time within the last 7 days, but not earlier than the instance creation time or later than one minute before the current time. Note that PITR is not supported for manual backups. ### Restore destination From df26b429fb9240483642a5a8b9b4780c769d3d62 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Tue, 24 Mar 2026 10:21:19 +0800 Subject: [PATCH 3/9] Apply suggestions from code review --- tidb-cloud/premium/backup-and-restore-premium.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index e5dd94bfc4476..1af3438f10859 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -68,19 +68,20 @@ To delete an existing backup file for your {{{ .premium }}} instance, perform th 2. Locate the corresponding backup file you want to delete, and click **...** > **Delete** in the **Action** column. ## Manual backups -In addition to automatic backups, {{{ .premium }}} supports manual backups. Manual backups provide a user-controlled, guaranteed restore point, which is highly recommended before performing high-risk actions such as system upgrades, critical data deletion, or irreversible schema/configuration changes. + +In addition to automatic backups, {{{ .premium }}} supports manual backups. Manual backups provide a user-controlled, guaranteed restore point, which is highly recommended before performing high-risk actions such as system upgrades, critical data deletion, and irreversible schema or configuration changes. ### Key characteristics of manual backups: -- **Retention and Deletion**: Unlike automatic backups, manual backups are not automatically deleted based on retention rules. They are retained indefinitely until you explicitly delete them. If the instance is deleted, its manual backups are moved to the Recycle Bin and will remain there permanently until manual deletion. +- **Retention and deletion**: unlike automatic backups, manual backups are not automatically deleted based on retention rules. They are retained indefinitely until you explicitly delete them. If the instance is deleted, its manual backups are moved to the Recycle Bin and will remain there permanently until manual deletion. -- **Storage Location**: Manual backups are stored in TiDB Managed Cloud Storage. +- **Storage location**: manual backups are stored in cloud storage managed by TiDB. -- **Cost**: Due to their long-term retention, manual backups are subject to additional charges. +- **Cost**: due to their long-term retention, manual backups are subject to additional charges. -- **Limitations**: Manual backups do not support Point-in-Time Recovery (PITR) or partial backups (e.g., table-level or database-level). Restoring a manual backup into an existing or running cluster is not supported; each restore requires a new cluster. +- **Limitations**: manual backups do not support Point-in-Time Recovery (PITR) or partial backups (for example, table-level or database-level). Restoring a manual backup into an existing or running instance is not supported. Each restore requires a new instance. -- **Permissions**: Both Organization owners and Instance managers can perform manual backups. However, only Organization owners can perform restore actions for system-managed manual backups. +- **Permissions**: both **Organization owners** and **Instance managers** can perform manual backups. However, only **Organization owners** can perform restore actions for system-managed manual backups. ### Create a manual backup @@ -98,7 +99,7 @@ TiDB Cloud provides restore functionality to help recover data in case of accide TiDB Cloud supports snapshot restore and point-in-time restore for your instance. -- **Snapshot Restore**: restores your instance from a specific backup snapshot. Both automatic and manual backups can be restored this way. Manual backups are displayed in the Backup List with a "Manual" backup type and a "Permanent" expiration status. +- **Snapshot Restore**: restores your instance from a specific backup snapshot. Both automatic and manual backups can be restored this way. Manual backups are displayed in the **Backup List** with a **Manual** backup type and a **Permanent** expiration status. - **Point-in-Time Restore**: restores your instance to a specific point in time. @@ -217,7 +218,6 @@ To restore backups from cloud storage, do the following: 5. Click **Restore** to restore the backup. - ## References This section describes how to configure access for Amazon S3 and Alibaba Cloud OSS. From 03a47b961f39224eeb94fc9677f30b7a9a1a3e6f Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Tue, 24 Mar 2026 11:23:43 +0800 Subject: [PATCH 4/9] Update tidb-cloud/premium/backup-and-restore-premium.md --- tidb-cloud/premium/backup-and-restore-premium.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 1af3438f10859..e102dfba7c42e 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -89,7 +89,9 @@ In addition to automatic backups, {{{ .premium }}} supports manual backups. Manu 2. In the upper-right corner, click **...**, and then click **Manual Backup**. -3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. You can restore it directly through the UI without requiring external storage credentials. +3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. + +You can restore the manual backup directly through the UI without requiring external storage credentials. ## Restore From f070954ad8d0ece2475b01899e2e67f078fb8597 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Tue, 24 Mar 2026 12:56:16 +0800 Subject: [PATCH 5/9] Apply suggestions from code review Co-authored-by: Aolin --- tidb-cloud/premium/backup-and-restore-premium.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index e102dfba7c42e..5276ff6672f16 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -69,19 +69,19 @@ To delete an existing backup file for your {{{ .premium }}} instance, perform th ## Manual backups -In addition to automatic backups, {{{ .premium }}} supports manual backups. Manual backups provide a user-controlled, guaranteed restore point, which is highly recommended before performing high-risk actions such as system upgrades, critical data deletion, and irreversible schema or configuration changes. +In addition to automatic backups, {{{ .premium }}} supports manual backups. A manual backup provides a controlled, guaranteed restore point. It is highly recommended that you create a manual backup before you perform high-risk operations such as system upgrades, critical data deletion, or irreversible schema or configuration changes. -### Key characteristics of manual backups: +### Key characteristics -- **Retention and deletion**: unlike automatic backups, manual backups are not automatically deleted based on retention rules. They are retained indefinitely until you explicitly delete them. If the instance is deleted, its manual backups are moved to the Recycle Bin and will remain there permanently until manual deletion. +- **Retention and deletion**: unlike automatic backups, manual backups are not automatically deleted based on retention policies. They are retained until you explicitly delete them. If you delete the instance, its manual backups move to the recycle bin and remain there until you manually delete them. - **Storage location**: manual backups are stored in cloud storage managed by TiDB. -- **Cost**: due to their long-term retention, manual backups are subject to additional charges. +- **Cost**: because manual backups are retained long term and incur additional charges. -- **Limitations**: manual backups do not support Point-in-Time Recovery (PITR) or partial backups (for example, table-level or database-level). Restoring a manual backup into an existing or running instance is not supported. Each restore requires a new instance. +- **Limitations**: manual backups do not support point-in-time recovery (PITR) or partial backups (for example, table-level or database-level backups). You cannot restore a manual backup to an existing instance. Each restore operation creates a new instance. -- **Permissions**: both **Organization owners** and **Instance managers** can perform manual backups. However, only **Organization owners** can perform restore actions for system-managed manual backups. +- **Permissions**: both `Organization Owner` and `Instance Manager` can create manual backups. Only `Organization Owner` can restore system-managed manual backups. ### Create a manual backup @@ -91,7 +91,7 @@ In addition to automatic backups, {{{ .premium }}} supports manual backups. Manu 3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. -You can restore the manual backup directly through the UI without requiring external storage credentials. +You can restore a manual backup directly in the TiDB Cloud console without providing external storage credentials. ## Restore @@ -101,7 +101,7 @@ TiDB Cloud provides restore functionality to help recover data in case of accide TiDB Cloud supports snapshot restore and point-in-time restore for your instance. -- **Snapshot Restore**: restores your instance from a specific backup snapshot. Both automatic and manual backups can be restored this way. Manual backups are displayed in the **Backup List** with a **Manual** backup type and a **Permanent** expiration status. +- **Snapshot Restore**: restores your instance from a specific backup snapshot. You can use this method to restore both automatic and manual backups. In the **Backup List**, manual backups are labeled with the **Manual** type and a **Permanent** expiration status. - **Point-in-Time Restore**: restores your instance to a specific point in time. From d07be4747486729beb458be69710eb442d1be582 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 28 Apr 2026 12:21:37 +0800 Subject: [PATCH 6/9] cloud/premium: add Dual-layer Data Encryption documentation Add documentation for CMEK (Customer-Managed Encryption Key) and Service-Managed Encryption Key features on TiDB Cloud Premium. Co-Authored-By: Claude Opus 4.7 --- .../tidb-cloud-encrypt-cmek-aws-premium.md | 146 ++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md new file mode 100644 index 0000000000000..fed076456e2d0 --- /dev/null +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -0,0 +1,146 @@ +--- +title: Dual-layer Data Encryption +summary: Learn how to enable Dual-layer Data Encryption on {{{ .premium }}} TiDB. +aliases: ['/tidbcloud/premium/tidb-cloud-encrypt-cmek'] +--- + +# Dual-layer Data Encryption + +## Overview +{{{ .premium }}} enables data encryption at rest by default on TiDB service instance storage and snapshot volumes. This provides basic encryption capabilities to enhance data security. Building on this, {{{ .premium }}} allows you to combine TiDB service's storage engine encryption with your cloud provider's KMS, adding another layer of data encryption (Dual-layer Data Encryption). + +### Encryption mechanism + +To provide the highest level of data security, {{{ .premium }}} TiDB adopts a two-tier architecture for data-at-rest encryption. Your data is safeguarded by both Storage-layer and Database-layer protections. + +- Storage-layer Data Encryption + - This is the underlying data encryption directly implemented by cloud service providers on their storage infrastructure. For example, on AWS, this includes EBS volume encryption and S3 bucket encryption. + - This layer of encryption is enabled by default for all {{{ .premium }}} instances and cannot be disabled. It serves as the foundational security baseline for your data. + +- Database-layer Encryption + - Building on top of the storage-layer encryption, TiDB Cloud allows you to add an extra layer of data encryption at the database level (labeled as **Dual-layer Data Encryption** in the console). Once enabled, static data encryption specifically covers TiKV's stored data and BR's backup data. + - The TiDB database system ensures that data remains encrypted at rest within the system, thereby effectively reducing the risk of data leakage during subsequent data transfers. + - Unlike default storage encryption, this feature can be managed by users, allowing you to choose either a Customer-Managed Encryption Key (CMEK) or a Service-Managed Encryption Key based on your security compliance and operational requirements. + + +#### Backup & Restore Description +When Dual-layer Data Encryption is enabled, the backup data for your {{{ .premium }}} TiDB instance is also encrypted. Any new instance restored from this backup will natively inherit the encryption attributes and KMS master key of the original instance. + +Since accessing the backup data relies on the originally configured KMS master key, please ensure the following: + +- **Maintain key availability**: Even if you delete the original Premium TiDB instance, the associated KMS master key must remain active to successfully recover the backup data. +- **Ensure correct authorization**: During a restore operation, you must configure the exact same KMS master key associated with the backup and ensure it has the proper permissions for data access. + +### Key Management Mechanism + +Premium's Dual-layer Data Encryption uses AWS KMS to manage master keys for data-at-rest encryption. Depending on your compliance and maintenance requirements, you can choose between two key management options： + +1. **Customer-Managed Encryption Key (CMEK)**: You provide and manage your own AWS KMS master key. This option offers maximum control over your encryption, making it ideal for organizations prioritizing strict security. +- **Important:** You are fully responsible for maintaining the key's security and availability. If the configured CMEK is deleted, your Premium TiDB instance will malfunction, and the encrypted data will become permanently unrecoverable. + +2. **Service-Managed Encryption Key**：TiDB Cloud Premium automatically provisions and maintains the KMS master key for you, offering a balance of security and convenience with zero maintenance overhead. +- Key Characteristics: + - It is a symmetric encryption key. + - It is automatically generated when you create your first encrypted Premium TiDB instance in a specific region. + - TiDB Cloud creates one key per organization per region, which is shared across all your Premium instances within that region. + - The key is automatically removed only after all data encrypted by it within your organization has been completely deleted + +## Limitations + +- Currently, this feature only supports AWS KMS. Support for Alibaba Cloud KMS and Azure Key Vault will be available soon. +- Data encryption applies to TiKV, CDC, and BR components. Support for TiFlash data encryption is coming soon. +- Once Dual-layer Data Encryption is enabled, the encryption properties of the {{{ .premium }}} instance cannot be modified. +- Custom encryption algorithms are not supported. Additionally, you can only rotate the KMS master key; rotation of other keys is not supported. +- Your AWS KMS key must reside in the same region as your TiDB instance. Consequently, cross-region restore operations are not supported for CMEK-encrypted backups. + +## Enable and Manage Encryption + +### Enable encryption during instance creation + +You can enable Dual-layer Data Encryption when creating a new {{{ .premium }}} instance. Depending on your security compliance and maintenance requirements, you can choose between two key management options: **Customer-Managed Encryption Key (CMEK)** or **Service-Managed Encryption Key**. + +#### Option 1: Customer-Managed Encryption Key (CMEK) + +To use your own encryption key, follow these steps: + +- **Step 1. Create a symmetric encryption key in your AWS KMS (Preparation)** + +Before proceeding, you must create a symmetric encryption key in AWS KMS. Ensure the key resides in the **same region** as your planned TiDB service. For detailed instructions, see [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html). + +- **Step 2. Configure CMEK in TiDB Cloud** + +1. On the **My TiDB** page, click **Create Resource**. +2. Select the {{{ .premium }}} plan and complete the basic instance configuration. +3. In **Dual-Layer Data Encryption** section, click **Enable**. +4. Select **Customer-Managed Encryption Key (CMEK)** and click **Add KMS Key ARN**. +5. Copy the displayed JSON policy and save it as ROLE-TRUST-POLICY.JSON. This file describes the required trust relationship. +6. In your AWS KMS Console, add this trust relationship to the your key. For more information, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). +7. Return to the TiDB Cloud console, scroll to the bottom of the key creation page, and enter the **KMS Key ARN** obtained from AWS KMS. +8. Click **Test and Add KMS Key ARN** to verigy the key trust relationship. +9. Once the verification passes, Click **Create** to finish creating your {{{ .premium }}} instance. + +#### Option 2: Service-Managed Encryption Key + +To let TiDB Cloud automatically manage the encryption key for you, follow these steps: + +1. On the **My TiDB** page, click **Create Resource**. +2. Select the {{{ .premium }}} plan and complete the basic instance configuration. +3. In **Dual-Layer Data Encryption** section, click **Enable**. +4. Select **Service-Managed Encryption Key**. +5. Click **Create** to finish creating your {{{ .premium }}} instance. + +### Enable Encryption for an existing instance + +If you did not enable encryption during cluster creation, you can still enable it later. Depending on your requirements, you can choose between a Customer-Managed Encryption Key (CMEK) or a Service-Managed Encryption Key. + +> **Note:** +> +> Enable Encryption on an existing instance requires some time to complete the activation process. + +#### Option 1: Customer-Managed Encryption Key (CMEK) + +Before proceeding, ensure you have created a symmetric encryption key in your AWS KMS. Then, follow these steps: + +1. On the **Security** page of your {{{ .premium }}} instance, click **Enable** for in the Dual-layer Data Encryption section. +2. Select **Customer-Managed Encryption Key (CMEK)** and click **Add KMS Key ARN**. +3. Copy the displayed JSON policy and save it as ROLE-TRUST-POLICY.JSON. This file describes the required trust relationship. +4. In your AWS KMS console, add this trust policy to your key. For more information, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). +5. Return to the TiDB Cloud console, scroll to the bottom of the page, and enter the **KMS Key ARN** obtained from AWS KMS. +6. Click **Test and Add KMS Key ARN** to check the key trust relationship. +7. Click **Enable** to enable the Dual-layer Data Encryption feature. + +#### Option 2: Service-Managed Encryption Key + +To let TiDB Cloud automatically manage the encryption key for you, follow these steps: +1. On the Security page of your {{{ .premium }}} instance , click **Enable** in the Dual-layer Data Encryption section. +2. Select **Service-Managed Encryption Key**. +3. Click **Enable**. + +### View encryption status + +Once encryption is enabled, you can verify its status and configuration details in the following two places: +- Check the **Encryption** property on the **Overview** page of the instance to see the active key management method (either **Enabled with Customer-Managed Encryption Key (CMEK)** or **Enabled with Service-Managed Encryption Key**). +- Navigate to the Security page to view the detailed configuration properties of your Dual-layer Data Encryption. + +### Restore from an encrypted backup + +Backups generated from an encrypted {{{ .premium }}} instance are also encrypted. When restoring such a backup to a new instance, the restored instance must maintain consistent encryption properties. + +#### Customer-Managed Encryption Key (CMEK) + +If the backup is encrypted using a CMEK, you must verify that the new instance can correctly access the KMS master key during the restore process: + +1. The key ARN will remain unchanged. Click **Check** to proceed with the trust policy verification. +2. The system will check if the authorized TiDB Cloud account in the key policy matches the one associated with the original backup. +3. If the TiDB Cloud account in the key policy is the same as the TiDB Cloud account associated with the original backup TiDB instance, no further authorization is required +4. If the TiDB Cloud account in the key policy is different from the TiDB Cloud account associated with the original backup TiDB instance, you must copy the provided key policy and update it in your AWS KMS. This re-authorizes the key and ensures the new instance can access it. + +#### Service-Managed Encryption Key + +If the backup is encrypted using a Service-Managed Encryption Key, the restored instance will automatically inherit the same key type. During the restore process, you will see that encryption is enabled by default and the key type is set to **Service-Managed Encryption Key**. + + +### Rotate Customer-Managed Encryption Key (CMEK) + +You can configure [automatic CMEK rotation](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) in AWS KMS. No configuration updates are required in TiDB Cloud. + From 8cfd75d9eb2d4292b2541fc0823ee20f8070c245 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 26 May 2026 18:43:36 +0800 Subject: [PATCH 7/9] doc: add alibaba cloud support for cmek --- ....md => tidb-cloud-encrypt-cmek-premium.md} | 53 +++++++++++-------- 1 file changed, 30 insertions(+), 23 deletions(-) rename tidb-cloud/premium/{tidb-cloud-encrypt-cmek-aws-premium.md => tidb-cloud-encrypt-cmek-premium.md} (71%) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md similarity index 71% rename from tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md rename to tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md index fed076456e2d0..f56e91c9d1879 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md @@ -7,7 +7,7 @@ aliases: ['/tidbcloud/premium/tidb-cloud-encrypt-cmek'] # Dual-layer Data Encryption ## Overview -{{{ .premium }}} enables data encryption at rest by default on TiDB service instance storage and snapshot volumes. This provides basic encryption capabilities to enhance data security. Building on this, {{{ .premium }}} allows you to combine TiDB service's storage engine encryption with your cloud provider's KMS, adding another layer of data encryption (Dual-layer Data Encryption). +{{{ .premium }}} enables data encryption at rest by default on TiDB service instance storage and snapshot volumes. This provides basic encryption capabilities to enhance data security. Building on this, {{{ .premium }}} allows you to combine TiDB service's storage engine encryption with your cloud provider KMS, adding another layer of data encryption (Dual-layer Data Encryption). ### Encryption mechanism @@ -33,9 +33,9 @@ Since accessing the backup data relies on the originally configured KMS master k ### Key Management Mechanism -Premium's Dual-layer Data Encryption uses AWS KMS to manage master keys for data-at-rest encryption. Depending on your compliance and maintenance requirements, you can choose between two key management options： +Premium's Dual-layer Data Encryption uses your cloud provider KMS to manage master keys for data-at-rest encryption. Depending on your compliance and maintenance requirements, you can choose between two key management options： -1. **Customer-Managed Encryption Key (CMEK)**: You provide and manage your own AWS KMS master key. This option offers maximum control over your encryption, making it ideal for organizations prioritizing strict security. +1. **Customer-Managed Encryption Key (CMEK)**: You provide and manage your own cloud provider KMS master key. This option offers maximum control over your encryption, making it ideal for organizations prioritizing strict security. - **Important:** You are fully responsible for maintaining the key's security and availability. If the configured CMEK is deleted, your Premium TiDB instance will malfunction, and the encrypted data will become permanently unrecoverable. 2. **Service-Managed Encryption Key**：TiDB Cloud Premium automatically provisions and maintains the KMS master key for you, offering a balance of security and convenience with zero maintenance overhead. @@ -47,11 +47,11 @@ Premium's Dual-layer Data Encryption uses AWS KMS to manage master keys for data ## Limitations -- Currently, this feature only supports AWS KMS. Support for Alibaba Cloud KMS and Azure Key Vault will be available soon. +- Currently, this feature only supports AWS KMS and Alibaba Cloud KMS. Support for Azure Key Vault will be available soon. - Data encryption applies to TiKV, CDC, and BR components. Support for TiFlash data encryption is coming soon. - Once Dual-layer Data Encryption is enabled, the encryption properties of the {{{ .premium }}} instance cannot be modified. - Custom encryption algorithms are not supported. Additionally, you can only rotate the KMS master key; rotation of other keys is not supported. -- Your AWS KMS key must reside in the same region as your TiDB instance. Consequently, cross-region restore operations are not supported for CMEK-encrypted backups. +- Your cloud provider KMS key must reside in the same region as your TiDB instance. Consequently, cross-region restore operations are not supported for CMEK-encrypted backups. ## Enable and Manage Encryption @@ -63,9 +63,11 @@ You can enable Dual-layer Data Encryption when creating a new {{{ .premium }}} i To use your own encryption key, follow these steps: -- **Step 1. Create a symmetric encryption key in your AWS KMS (Preparation)** +- **Step 1. Create a symmetric encryption key in your Cloud Provider KMS (Preparation)** -Before proceeding, you must create a symmetric encryption key in AWS KMS. Ensure the key resides in the **same region** as your planned TiDB service. For detailed instructions, see [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html). +Before proceeding, you must create a symmetric encryption key in your cloud provider KMS. Ensure the key resides in the **same region** as your planned TiDB service. + - For AWS, see [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html). + - For Alibaba Cloud, see [Understanding KMS keys](https://www.alibabacloud.com/help/en/kms/key-management-service/user-guide/overview-of-key-management). - **Step 2. Configure CMEK in TiDB Cloud** @@ -73,11 +75,13 @@ Before proceeding, you must create a symmetric encryption key in AWS KMS. Ensure 2. Select the {{{ .premium }}} plan and complete the basic instance configuration. 3. In **Dual-Layer Data Encryption** section, click **Enable**. 4. Select **Customer-Managed Encryption Key (CMEK)** and click **Add KMS Key ARN**. -5. Copy the displayed JSON policy and save it as ROLE-TRUST-POLICY.JSON. This file describes the required trust relationship. -6. In your AWS KMS Console, add this trust relationship to the your key. For more information, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). -7. Return to the TiDB Cloud console, scroll to the bottom of the key creation page, and enter the **KMS Key ARN** obtained from AWS KMS. -8. Click **Test and Add KMS Key ARN** to verigy the key trust relationship. -9. Once the verification passes, Click **Create** to finish creating your {{{ .premium }}} instance. +5. Copy the displayed JSON policy statement. This policy statement defines the required key access permissions for TiDB Cloud. +6. In your cloud provider KMS Console, append this policy statement to your key policy. + - For AWS, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). + - For Alibaba Cloud, refer to [Manage Keys](https://www.alibabacloud.com/help/en/kms/key-management-service/user-guide/manage-keys-2). +7. Return to the TiDB Cloud console, scroll to the bottom of the key creation page, and enter the **KMS Key ARN** obtained from your cloud provider KMS. +8. Click **Test and Add KMS Key ARN** to verify the key access configuration. +9. Once the verification passes, click **Create** to finish creating your {{{ .premium }}} instance. #### Option 2: Service-Managed Encryption Key @@ -99,20 +103,22 @@ If you did not enable encryption during cluster creation, you can still enable i #### Option 1: Customer-Managed Encryption Key (CMEK) -Before proceeding, ensure you have created a symmetric encryption key in your AWS KMS. Then, follow these steps: +Before proceeding, ensure you have created a symmetric encryption key in your cloud provider KMS. Then, follow these steps: -1. On the **Security** page of your {{{ .premium }}} instance, click **Enable** for in the Dual-layer Data Encryption section. +1. On the **Security** page of your {{{ .premium }}} instance, click **Enable** in the Dual-layer Data Encryption section. 2. Select **Customer-Managed Encryption Key (CMEK)** and click **Add KMS Key ARN**. -3. Copy the displayed JSON policy and save it as ROLE-TRUST-POLICY.JSON. This file describes the required trust relationship. -4. In your AWS KMS console, add this trust policy to your key. For more information, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). -5. Return to the TiDB Cloud console, scroll to the bottom of the page, and enter the **KMS Key ARN** obtained from AWS KMS. -6. Click **Test and Add KMS Key ARN** to check the key trust relationship. +3. Copy the displayed JSON policy statement. This policy statement defines the required key access permissions for TiDB Cloud. +4. In your cloud provider KMS console, append this policy statement to your key policy.. + - For AWS, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). + - For Alibaba Cloud, refer to [Manage Keys](https://www.alibabacloud.com/help/en/kms/key-management-service/user-guide/manage-keys-2). +5. Return to the TiDB Cloud console, scroll to the bottom of the page, and enter the **KMS Key ARN** obtained from your cloud provider KMS. +6. Click **Test and Add KMS Key ARN** to verify the key access configuration. 7. Click **Enable** to enable the Dual-layer Data Encryption feature. #### Option 2: Service-Managed Encryption Key To let TiDB Cloud automatically manage the encryption key for you, follow these steps: -1. On the Security page of your {{{ .premium }}} instance , click **Enable** in the Dual-layer Data Encryption section. +1. On the Security page of your {{{ .premium }}} instance, click **Enable** in the Dual-layer Data Encryption section. 2. Select **Service-Managed Encryption Key**. 3. Click **Enable**. @@ -130,10 +136,10 @@ Backups generated from an encrypted {{{ .premium }}} instance are also encrypted If the backup is encrypted using a CMEK, you must verify that the new instance can correctly access the KMS master key during the restore process: -1. The key ARN will remain unchanged. Click **Check** to proceed with the trust policy verification. +1. The key ARN will remain unchanged. Click **Check** to proceed with the key access verification. 2. The system will check if the authorized TiDB Cloud account in the key policy matches the one associated with the original backup. 3. If the TiDB Cloud account in the key policy is the same as the TiDB Cloud account associated with the original backup TiDB instance, no further authorization is required -4. If the TiDB Cloud account in the key policy is different from the TiDB Cloud account associated with the original backup TiDB instance, you must copy the provided key policy and update it in your AWS KMS. This re-authorizes the key and ensures the new instance can access it. +4. If the TiDB Cloud account in the key policy is different from the TiDB Cloud account associated with the original backup TiDB instance, you must copy the provided key policy and update it in your cloud provider KMS. This re-authorizes the key and ensures the new instance can access it. #### Service-Managed Encryption Key @@ -142,5 +148,6 @@ If the backup is encrypted using a Service-Managed Encryption Key, the restored ### Rotate Customer-Managed Encryption Key (CMEK) -You can configure [automatic CMEK rotation](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) in AWS KMS. No configuration updates are required in TiDB Cloud. - +You can configure automatic CMEK rotation in your cloud provider KMS. No configuration updates are required in TiDB Cloud. +- For AWS, see [automatic CMEK rotation](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). +- For Alibaba Cloud, see [Key rotation](https://www.alibabacloud.com/help/en/kms/key-management-service/user-guide/configure-key-rotation). From 72c7f8e9645d3b9fcb9e81c7ca7af81055ca12b5 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Wed, 27 May 2026 10:10:38 +0800 Subject: [PATCH 8/9] Apply suggestion from @gemini-code-assist[bot] Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md index f56e91c9d1879..b65f496654e4a 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md @@ -4,7 +4,7 @@ summary: Learn how to enable Dual-layer Data Encryption on {{{ .premium }}} TiDB aliases: ['/tidbcloud/premium/tidb-cloud-encrypt-cmek'] --- -# Dual-layer Data Encryption +# Dual-layer data encryption ## Overview {{{ .premium }}} enables data encryption at rest by default on TiDB service instance storage and snapshot volumes. This provides basic encryption capabilities to enhance data security. Building on this, {{{ .premium }}} allows you to combine TiDB service's storage engine encryption with your cloud provider KMS, adding another layer of data encryption (Dual-layer Data Encryption). From e34be36d1127124db21111397f72d54d0b0f6d62 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Wed, 27 May 2026 10:10:48 +0800 Subject: [PATCH 9/9] Apply suggestion from @gemini-code-assist[bot] Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md index b65f496654e4a..d9d2a658d4924 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-premium.md @@ -23,7 +23,7 @@ To provide the highest level of data security, {{{ .premium }}} TiDB adopts a tw - Unlike default storage encryption, this feature can be managed by users, allowing you to choose either a Customer-Managed Encryption Key (CMEK) or a Service-Managed Encryption Key based on your security compliance and operational requirements. -#### Backup & Restore Description +#### Backup and restore description When Dual-layer Data Encryption is enabled, the backup data for your {{{ .premium }}} TiDB instance is also encrypted. Any new instance restored from this backup will natively inherit the encryption attributes and KMS master key of the original instance. Since accessing the backup data relies on the originally configured KMS master key, please ensure the following: