diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md
index f4c4f7bbc807a..e0d050feed3b2 100644
--- a/migrate-from-tidb-to-tidb.md
+++ b/migrate-from-tidb-to-tidb.md
@@ -103,9 +103,9 @@ After setting up the environment, you can use the backup and restore functions o
 
 > **Note:**
 >
-> In production clusters, performing a backup with GC disabled might affect cluster performance. It is recommended that you back up data in off-peak hours, and set `RATE_LIMIT` to a proper value to avoid performance degradation.
->
-> If the versions of the upstream and downstream clusters are different, you should check [BR compatibility](/br/backup-and-restore-overview.md#before-you-use). In this document, we assume that the upstream and downstream clusters are the same version.
+> - `BACKUP` and `RESTORE` SQL statements are experimental. It is not recommended that you use them in the production environment. They might be changed or removed without prior notice. If you find a bug, you can report an [issue](https://github.com/pingcap/tidb/issues) on GitHub.
+> - In production clusters, performing a backup with GC disabled might affect cluster performance. It is recommended that you back up data in off-peak hours, and set `RATE_LIMIT` to a proper value to avoid performance degradation.
+> - If the versions of the upstream and downstream clusters are different, you should check [BR compatibility](/br/backup-and-restore-overview.md#before-you-use). In this document, we assume that the upstream and downstream clusters are the same version.
 
 1. Disable GC.
 
diff --git a/replicate-between-primary-and-secondary-clusters.md b/replicate-between-primary-and-secondary-clusters.md
index 575fc9a2e7559..9b50a80bb688b 100644
--- a/replicate-between-primary-and-secondary-clusters.md
+++ b/replicate-between-primary-and-secondary-clusters.md
@@ -102,8 +102,8 @@ After setting up the environment, you can use the backup and restore functions o
 
 > **Note:**
 >
+> - `BACKUP` and `RESTORE` SQL statements are experimental. It is not recommended that you use them in the production environment. They might be changed or removed without prior notice. If you find a bug, you can report an [issue](https://github.com/pingcap/tidb/issues) on GitHub.
 > - In production clusters, performing a backup with GC disabled might affect cluster performance. It is recommended that you back up data in off-peak hours, and set RATE_LIMIT to a proper value to avoid performance degradation.
->
 > - If the versions of the upstream and downstream clusters are different, you should check [BR compatibility](/br/backup-and-restore-overview.md#some-tips). In this document, we assume that the upstream and downstream clusters are the same version.
 
 1. Disable GC.
diff --git a/sql-statements/sql-statement-backup.md b/sql-statements/sql-statement-backup.md
index 7a86bf8c34d05..11604511c9c4e 100644
--- a/sql-statements/sql-statement-backup.md
+++ b/sql-statements/sql-statement-backup.md
@@ -7,9 +7,10 @@ summary: An overview of the usage of BACKUP for the TiDB database.
 
 This statement is used to perform a distributed backup of the TiDB cluster.
 
-> **Note:**
+> **Warning:**
 >
-> This feature is not available on [TiDB Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-serverless) clusters.
+> - This feature is experimental. It is not recommended that you use it in the production environment. This feature might be changed or removed without prior notice. If you find a bug, you can report an [issue](https://github.com/pingcap/tidb/issues) on GitHub.
+> - This feature is not available on [TiDB Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-serverless) clusters.
 
 The `BACKUP` statement uses the same engine as the [BR tool](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview) does, except that the backup process is driven by TiDB itself rather than a separate BR tool. All benefits and warnings of BR also apply to this statement.
 
diff --git a/sql-statements/sql-statement-restore.md b/sql-statements/sql-statement-restore.md
index 6cea3d1fade7a..25c2a496b5dc3 100644
--- a/sql-statements/sql-statement-restore.md
+++ b/sql-statements/sql-statement-restore.md
@@ -7,9 +7,10 @@ summary: An overview of the usage of RESTORE for the TiDB database.
 
 This statement performs a distributed restore from a backup archive previously produced by a [`BACKUP` statement](/sql-statements/sql-statement-backup.md).
 
-> **Note:**
+> **Warning:**
 >
-> This feature is not available on [TiDB Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-serverless) clusters.
+> - This feature is experimental. It is not recommended that you use it in the production environment. This feature might be changed or removed without prior notice. If you find a bug, you can report an [issue](https://github.com/pingcap/tidb/issues) on GitHub.
+> - This feature is not available on [TiDB Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-serverless) clusters.
 
 The `RESTORE` statement uses the same engine as the [BR tool](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview), except that the restore process is driven by TiDB itself rather than a separate BR tool. All benefits and caveats of BR also apply here. In particular, **`RESTORE` is currently not ACID-compliant**. Before running `RESTORE`, ensure that the following requirements are met: