diff --git a/best-practices/readonly-nodes.md b/best-practices/readonly-nodes.md
index 9597e8ddbf6cf..80faadb4da59f 100644
--- a/best-practices/readonly-nodes.md
+++ b/best-practices/readonly-nodes.md
@@ -127,5 +127,5 @@ spark.tispark.replica_read learner
 To read data from read-only nodes when backing up cluster data, you can specify the `--replica-read-label` option in the br command line. Note that when running the following command in shell, you need to use single quotes to wrap the label to prevent `$` from being parsed.
 
 ```shell
-br backup full ... --replica-read-label '$mode:readonly'
+tiup br backup full ... --replica-read-label '$mode:readonly'
 ```
diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md
index ceaed93ddbd88..8f589075995ef 100644
--- a/br/backup-and-restore-storages.md
+++ b/br/backup-and-restore-storages.md
@@ -19,7 +19,7 @@ By default, BR sends a credential to each TiKV node when using Amazon S3, GCS, o
 Note that this operation is not applicable to cloud environments. If you use IAM Role authorization, each node has its own role and permissions. In this case, you need to configure `--send-credentials-to-tikv=false` (or `-c=0` in short) to disable sending credentials:
 
 ```bash
-./br backup full -c=0 -u pd-service:2379 --storage 's3://bucket-name/prefix'
+tiup br backup full -c=0 -u pd-service:2379 --storage 's3://bucket-name/prefix'
 ```
 
 If you back up or restore data using the [`BACKUP`](/sql-statements/sql-statement-backup.md) and [`RESTORE`](/sql-statements/sql-statement-restore.md) statements, you can add the `SEND_CREDENTIALS_TO_TIKV = FALSE` option:
@@ -50,14 +50,14 @@ This section provides some URI examples by using `external` as the `host` parame
 **Back up snapshot data to Amazon S3**
 
 ```shell
-./br backup full -u "${PD_IP}:2379" \
+tiup br backup full -u "${PD_IP}:2379" \
 --storage "s3://external/backup-20220915?access-key=${access-key}&secret-access-key=${secret-access-key}"
 ```
 
 **Restore snapshot data from Amazon S3**
 
 ```shell
-./br restore full -u "${PD_IP}:2379" \
+tiup br restore full -u "${PD_IP}:2379" \
 --storage "s3://external/backup-20220915?access-key=${access-key}&secret-access-key=${secret-access-key}"
 ```
 
@@ -67,14 +67,14 @@ This section provides some URI examples by using `external` as the `host` parame
 **Back up snapshot data to GCS**
 
 ```shell
-./br backup full --pd "${PD_IP}:2379" \
+tiup br backup full --pd "${PD_IP}:2379" \
 --storage "gcs://external/backup-20220915?credentials-file=${credentials-file-path}"
 ```
 
 **Restore snapshot data from GCS**
 
 ```shell
-./br restore full --pd "${PD_IP}:2379" \
+tiup br restore full --pd "${PD_IP}:2379" \
 --storage "gcs://external/backup-20220915?credentials-file=${credentials-file-path}"
 ```
 
@@ -84,14 +84,14 @@ This section provides some URI examples by using `external` as the `host` parame
 **Back up snapshot data to Azure Blob Storage**
 
 ```shell
-./br backup full -u "${PD_IP}:2379" \
+tiup br backup full -u "${PD_IP}:2379" \
 --storage "azure://external/backup-20220915?account-name=${account-name}&account-key=${account-key}"
 ```
 
 **Restore the `test` database from snapshot backup data in Azure Blob Storage**
 
 ```shell
-./br restore db --db test -u "${PD_IP}:2379" \
+tiup br restore db --db test -u "${PD_IP}:2379" \
 --storage "azure://external/backup-20220915account-name=${account-name}&account-key=${account-key}"
 ```
 
@@ -128,7 +128,7 @@ It is recommended that you configure access to S3 using either of the following
     Associate an IAM role that can access S3 with EC2 instances where the TiKV and BR nodes run. After the association, BR can directly access the backup directories in S3 without additional settings.
 
     ```shell
-    br backup full --pd "${PD_IP}:2379" \
+    tiup br backup full --pd "${PD_IP}:2379" \
     --storage "s3://${host}/${path}"
     ```
 
@@ -195,7 +195,7 @@ You can configure the account used to access GCS by specifying the access key. I
     - Use BR to back up data to Azure Blob Storage:
 
         ```shell
-        ./br backup full -u "${PD_IP}:2379" \
+        tiup br backup full -u "${PD_IP}:2379" \
         --storage "azure://external/backup-20220915?account-name=${account-name}"
         ```
 
diff --git a/br/br-batch-create-table.md b/br/br-batch-create-table.md
index 842bad3b156ad..9be3c57f838d5 100644
--- a/br/br-batch-create-table.md
+++ b/br/br-batch-create-table.md
@@ -27,7 +27,7 @@ BR enables the Batch Create Table feature by default, with the default configura
 To disable this feature, you can set `--ddl-batch-size` to `1`. See the following example command:
 
 ```shell
-br restore full \
+tiup br restore full \
 --storage local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log \
 --ddl-batch-size=1
 ```
diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md
index aaf9f7e836db6..286cbbbdd486b 100644
--- a/br/br-checkpoint-backup.md
+++ b/br/br-checkpoint-backup.md
@@ -35,7 +35,7 @@ To avoid this situation, `br` keeps the `gc-safepoint` for about one hour by def
 The following example sets `gcttl` to 15 hours (54000 seconds) to extend the retention period of `gc-safepoint`:
 
 ```shell
-br backup full \
+tiup br backup full \
 --storage local:///br_data/ --pd "${PD_IP}:2379" \
 --gcttl 54000
 ```
diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md
index 14469e18a08be..a0dac0d3e6d48 100644
--- a/br/br-incremental-guide.md
+++ b/br/br-incremental-guide.md
@@ -1,6 +1,6 @@
 ---
 title: TiDB Incremental Backup and Restore Guide
-summary: Incremental data is the differentiated data between starting and end snapshots, along with DDLs. It reduces backup volume and requires setting `tidb_gc_life_time` for incremental backup. Use `br backup` with `--lastbackupts` for incremental backup and ensure all previous data is restored before restoring incremental data.
+summary: Incremental data is the differentiated data between starting and end snapshots, along with DDLs. It reduces backup volume and requires setting `tidb_gc_life_time` for incremental backup. Use `tiup br backup` with `--lastbackupts` for incremental backup and ensure all previous data is restored before restoring incremental data.
 ---
 
 # TiDB Incremental Backup and Restore Guide
@@ -13,7 +13,7 @@ Incremental data of a TiDB cluster is differentiated data between the starting s
 
 ## Back up incremental data
 
-To back up incremental data, run the `br backup` command with **the last backup timestamp** `--lastbackupts` specified. In this way, br command-line tool automatically backs up incremental data generated between `lastbackupts` and the current time. To get `--lastbackupts`, run the `validate` command. The following is an example:
+To back up incremental data, run the `tiup br backup` command with **the last backup timestamp** `--lastbackupts` specified. In this way, br command-line tool automatically backs up incremental data generated between `lastbackupts` and the current time. To get `--lastbackupts`, run the `validate` command. The following is an example:
 
 ```shell
 LAST_BACKUP_TS=`tiup br validate decode --field="end-version" --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"| tail -n1`
diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md
index 68d3d9f94ccc9..64418cd1a7198 100644
--- a/br/br-pitr-guide.md
+++ b/br/br-pitr-guide.md
@@ -19,7 +19,7 @@ Before you back up or restore data using the br command-line tool (hereinafter r
 > - The following examples assume that Amazon S3 access keys and secret keys are used to authorize permissions. If IAM roles are used to authorize permissions, you need to set `--send-credentials-to-tikv` to `false`.
 > - If other storage systems or authorization methods are used to authorize permissions, adjust the parameter settings according to [Backup Storages](/br/backup-and-restore-storages.md).
 
-To start a log backup, run `br log start`. A cluster can only run one log backup task each time.
+To start a log backup, run `tiup br log start`. A cluster can only run one log backup task each time.
 
 ```shell
 tiup br log start --task-name=pitr --pd "${PD_IP}:2379" \
@@ -48,7 +48,7 @@ checkpoint[global]: 2022-05-13 11:31:47.2 +0800; gap=4m53s
 
 ### Run full backup regularly
 
-The snapshot backup can be used as a method of full backup. You can run `br backup full` to back up the cluster snapshot to the backup storage according to a fixed schedule (for example, every 2 days).
+The snapshot backup can be used as a method of full backup. You can run `tiup br backup full` to back up the cluster snapshot to the backup storage according to a fixed schedule (for example, every 2 days).
 
 ```shell
 tiup br backup full --pd "${PD_IP}:2379" \
@@ -57,10 +57,10 @@ tiup br backup full --pd "${PD_IP}:2379" \
 
 ## Run PITR
 
-To restore the cluster to any point in time within the backup retention period, you can use `br restore point`. When you run this command, you need to specify the **time point you want to restore**, **the latest snapshot backup data before the time point**, and the **log backup data**. BR will automatically determine and read data needed for the restore, and then restore these data to the specified cluster in order.
+To restore the cluster to any point in time within the backup retention period, you can use `tiup br restore point`. When you run this command, you need to specify the **time point you want to restore**, **the latest snapshot backup data before the time point**, and the **log backup data**. BR will automatically determine and read data needed for the restore, and then restore these data to the specified cluster in order.
 
 ```shell
-br restore point --pd "${PD_IP}:2379" \
+tiup br restore point --pd "${PD_IP}:2379" \
 --storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' \
 --full-backup-storage='s3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}' \
 --restored-ts '2022-05-15 18:00:00+0800'
@@ -80,7 +80,7 @@ Restore KV Files <--------------------------------------------------------------
 
 As described in the [Usage Overview of TiDB Backup and Restore](/br/br-use-overview.md):
 
-To perform PITR, you need to restore the full backup before the restore point, and the log backup between the full backup point and the restore point. Therefore, for log backups that exceed the backup retention period, you can use `br log truncate` to delete the backup before the specified time point. **It is recommended to only delete the log backup before the full snapshot**.
+To perform PITR, you need to restore the full backup before the restore point, and the log backup between the full backup point and the restore point. Therefore, for log backups that exceed the backup retention period, you can use `tiup br log truncate` to delete the backup before the specified time point. **It is recommended to only delete the log backup before the full snapshot**.
 
 The following steps describe how to clean up backup data that exceeds the backup retention period:
 
@@ -100,7 +100,7 @@ The following steps describe how to clean up backup data that exceeds the backup
 4. Delete snapshot data earlier than the snapshot backup `FULL_BACKUP_TS`:
 
     ```shell
-    rm -rf s3://backup-101/snapshot-${date}
+    aws s3 rm --recursive s3://backup-101/snapshot-${date}
     ```
 
 ## Performance capabilities of PITR
diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md
index b1cad71f51289..d4c9076ea1949 100644
--- a/br/br-pitr-manual.md
+++ b/br/br-pitr-manual.md
@@ -1,6 +1,6 @@
 ---
 title: TiDB Log Backup and PITR Command Manual
-summary: TiDB Log Backup and PITR Command Manual describes commands for log backup and point-in-time recovery. Use `br log` command to start, pause, resume, stop, truncate, and query log backup tasks. Specify parameters like `start-ts`, `task-name`, `--storage`, and `--pd` for log backup. Use `br log metadata` to view backup metadata and `br restore point` for PITR. Be cautious when pausing and resuming backup tasks.
+summary: Introduce the commands used in TiDB log backup and point-in-time recovery (PITR).
 aliases: ['/tidb/dev/br-log-command-line/']
 ---
 
@@ -15,10 +15,10 @@ For more information about log backup and PITR, refer to:
 
 ## Perform log backup
 
-You can start and manage log backup using the `br log` command.
+You can start and manage log backup using the `tiup br log` command.
 
 ```shell
-./br log --help
+tiup br log --help
 
 backup stream log from TiDB/TiKV cluster
 
@@ -37,22 +37,22 @@ Available Commands:
 
 Each subcommand is described as follows:
 
-- `br log start`: start a log backup task.
-- `br log status`: query the status of the log backup task.
-- `br log pause`: pause a log backup task.
-- `br log resume`: resume a paused log backup task.
-- `br log stop`: stop a log backup task and delete the task metadata.
-- `br log truncate`: clean up the log backup data from the backup storage.
-- `br log metadata`: query the metadata of the log backup data.
+- `tiup br log start`: start a log backup task.
+- `tiup br log status`: query the status of the log backup task.
+- `tiup br log pause`: pause a log backup task.
+- `tiup br log resume`: resume a paused log backup task.
+- `tiup br log stop`: stop a log backup task and delete the task metadata.
+- `tiup br log truncate`: clean up the log backup data from the backup storage.
+- `tiup br log metadata`: query the metadata of the log backup data.
 
 ### Start a backup task
 
-You can run the `br log start` command to start a log backup task. This task runs in the background of your TiDB cluster and automatically backs up the change log of KV storage to the backup storage.
+You can run the `tiup br log start` command to start a log backup task. This task runs in the background of your TiDB cluster and automatically backs up the change log of KV storage to the backup storage.
 
-Run `br log start --help` to see the help information:
+Run `tiup br log start --help` to see the help information:
 
 ```shell
-./br log start --help
+tiup br log start --help
 start a log backup task
 
 Usage:
@@ -83,18 +83,18 @@ The example output only shows the common parameters. These parameters are descri
 Usage example:
 
 ```shell
-./br log start --task-name=pitr --pd="${PD_IP}:2379" \
+tiup br log start --task-name=pitr --pd="${PD_IP}:2379" \
 --storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}"'
 ```
 
 ### Query the backup status
 
-You can run the `br log status` command to query the backup status.
+You can run the `tiup br log status` command to query the backup status.
 
-Run `br log status --help` to see the help information:
+Run `tiup br log status --help` to see the help information:
 
 ```shell
-./br log status --help
+tiup br log status --help
 get status for the log backup task
 
 Usage:
@@ -118,7 +118,7 @@ In the example output, `task-name` is used to specify the name of the backup tas
 Usage example:
 
 ```shell
-./br log status --task-name=pitr --pd="${PD_IP}:2379"
+tiup br log status --task-name=pitr --pd="${PD_IP}:2379"
 ```
 
 Expected output:
@@ -146,12 +146,12 @@ The output fields are described as follows:
 
 ### Pause and resume a backup task
 
-You can run the `br log pause` command to pause a running backup task.
+You can run the `tiup br log pause` command to pause a running backup task.
 
-Run `br log pause --help` to see the help information:
+Run `tiup br log pause --help` to see the help information:
 
 ```shell
-./br log pause --help
+tiup br log pause --help
 pause a log backup task
 
 Usage:
@@ -177,15 +177,15 @@ Global Flags:
 Usage example:
 
 ```shell
-./br log pause --task-name=pitr --pd="${PD_IP}:2379"
+tiup br log pause --task-name=pitr --pd="${PD_IP}:2379"
 ```
 
-You can run the `br log resume` command to resume a paused backup task.
+You can run the `tiup br log resume` command to resume a paused backup task.
 
-Run `br log resume --help` to see the help information:
+Run `tiup br log resume --help` to see the help information:
 
 ```shell
-./br log resume --help
+tiup br log resume --help
 resume a log backup task
 
 Usage:
@@ -202,26 +202,26 @@ Global Flags:
  -u, --pd strings             PD address (default [127.0.0.1:2379])
 ```
 
-After the backup task is paused for more than 24 hours, running `br log resume` reports an error, and BR prompts that backup data is lost. To handle this error, refer to [Backup & Restore FAQs](/faq/backup-and-restore-faq.md#what-should-i-do-if-the-error-message-errbackupgcsafepointexceeded-is-returned-when-using-the-br-log-resume-command-to-resume-a-suspended-task).
+After the backup task is paused for more than 24 hours, running `tiup br log resume` reports an error, and BR prompts that backup data is lost. To handle this error, refer to [Backup & Restore FAQs](/faq/backup-and-restore-faq.md#what-should-i-do-if-the-error-message-errbackupgcsafepointexceeded-is-returned-when-using-the-br-log-resume-command-to-resume-a-suspended-task).
 
 Usage example:
 
 ```shell
-./br log resume --task-name=pitr --pd="${PD_IP}:2379"
+tiup br log resume --task-name=pitr --pd="${PD_IP}:2379"
 ```
 
 ### Stop and restart a backup task
 
-You can stop a log backup task by running the `br log stop` command and restart a backup task that is stopped by using the original `--storage` directory.
+You can stop a log backup task by running the `tiup br log stop` command and restart a backup task that is stopped by using the original `--storage` directory.
 
 #### Stop a backup task
 
-You can run the `br log stop` command to stop a log backup task. This command cleans up the task metadata in the backup cluster.
+You can run the `tiup br log stop` command to stop a log backup task. This command cleans up the task metadata in the backup cluster.
 
-Run `br log stop --help` to see the help information:
+Run `tiup br log stop --help` to see the help information:
 
 ```shell
-./br log stop --help
+tiup br log stop --help
 stop a log backup task
 
 Usage:
@@ -240,17 +240,17 @@ Global Flags:
 
 > **Note:**
 >
-> Use this command with caution. If you need to pause a log backup task, use `br log pause` and `br log resume` instead.
+> Use this command with caution. If you need to pause a log backup task, use `tiup br log pause` and `tiup br log resume` instead.
 
 Usage example:
 
 ```shell
-./br log stop --task-name=pitr --pd="${PD_IP}:2379"
+tiup br log stop --task-name=pitr --pd="${PD_IP}:2379"
 ```
 
 #### Restart a backup task
 
-After running the `br log stop` command to stop a log backup task, you can create a new log backup task in another `--storage` directory or restart the log backup task in the original `--storage` directory by running the `br log start` command. If you restart the task in the original `--storage` directory, pay attention to the following points:
+After running the `tiup br log stop` command to stop a log backup task, you can create a new log backup task in another `--storage` directory or restart the log backup task in the original `--storage` directory by running the `tiup br log start` command. If you restart the task in the original `--storage` directory, pay attention to the following points:
 
 - Parameters of the `--storage` directory for restarting a task must be the same as the task that is stopped.
 - The `--start-ts` does not need to be specified. BR automatically starts the backup from the last backup checkpoint.
@@ -258,12 +258,12 @@ After running the `br log stop` command to stop a log backup task, you can creat
 
 ### Clean up backup data
 
-You can run the `br log truncate` command to clean up the outdated or no longer needed log backup data.
+You can run the `tiup br log truncate` command to clean up the outdated or no longer needed log backup data.
 
-Run `br log truncate --help` to see the help information:
+Run `tiup br log truncate --help` to see the help information:
 
 ```shell
-./br log truncate --help
+tiup br log truncate --help
 truncate the incremental log until sometime.
 
 Usage:
@@ -289,7 +289,7 @@ This command only accesses the backup storage and does not access the TiDB clust
 Usage example:
 
 ```shell
-./br log truncate --until='2022-07-26 21:20:00+0800' \
+tiup br log truncate --until='2022-07-26 21:20:00+0800' \
 –-storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}"'
 ```
 
@@ -305,12 +305,12 @@ Removing metadata... DONE; take = 24.038962ms
 
 ### View the backup metadata
 
-You can run the `br log metadata` command to view the backup metadata in the storage system, such as the earliest and latest timestamp that can be restored.
+You can run the `tiup br log metadata` command to view the backup metadata in the storage system, such as the earliest and latest timestamp that can be restored.
 
-Run `br log metadata --help` to see the help information:
+Run `tiup br log metadata --help` to see the help information:
 
 ```shell
-./br log metadata --help
+tiup br log metadata --help
 get the metadata of log backup storage
 
 Usage:
@@ -330,7 +330,7 @@ The `--storage` parameter is used to specify the backup storage address. Current
 Usage example:
 
 ```shell
-./br log metadata –-storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}"'
+tiup br log metadata –-storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}"'
 ```
 
 Expected output:
@@ -341,12 +341,12 @@ Expected output:
 
 ## Restore to a specified point in time (PITR)
 
-You can run the `br restore point` command to perform a PITR on a new cluster or just restore the log backup data.
+You can run the `tiup br restore point` command to perform a PITR on a new cluster or just restore the log backup data.
 
-Run `br restore point --help` to see the help information:
+Run `tiup br restore point --help` to see the help information:
 
 ```shell
-./br restore point --help
+tiup br restore point --help
 restore data from log until specify commit timestamp
 
 Usage:
@@ -379,7 +379,7 @@ The example output only shows the common parameters. These parameters are descri
 Usage example:
 
 ```shell
-./br restore point --pd="${PD_IP}:2379"
+tiup br restore point --pd="${PD_IP}:2379"
 --storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}"'
 --full-backup-storage='s3://backup-101/snapshot-202205120000?access-key=${access-key}&secret-access-key=${secret-access-key}"'
 
diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md
index 7d6b3ed6873f2..06f34a8287564 100644
--- a/br/br-snapshot-guide.md
+++ b/br/br-snapshot-guide.md
@@ -22,7 +22,7 @@ Besides basic backup and restore, snapshot backup and restore also provides the
 > - The following examples assume that Amazon S3 access keys and secret keys are used to authorize permissions. If IAM roles are used to authorize permissions, you need to set `--send-credentials-to-tikv` to `false`.
 > - If other storage systems or authorization methods are used to authorize permissions, adjust the parameter settings according to [Backup Storages](/br/backup-and-restore-storages.md).
 
-You can back up a TiDB cluster snapshot by running the `br backup full` command. Run `br backup full --help` to see the help information:
+You can back up a TiDB cluster snapshot by running the `tiup br backup full` command. Run `tiup br backup full --help` to see the help information:
 
 ```shell
 tiup br backup full --pd "${PD_IP}:2379" \
@@ -33,7 +33,7 @@ tiup br backup full --pd "${PD_IP}:2379" \
 
 In the preceding command:
 
-- `--backupts`: The time point of the snapshot. The format can be [TSO](/glossary.md#tso) or timestamp, such as `400036290571534337` or `2018-05-11 01:42:23`. If the data of this snapshot is garbage collected, the `br backup` command returns an error and `br` exits. If you leave this parameter unspecified, `br` picks the snapshot corresponding to the backup start time.
+- `--backupts`: The time point of the snapshot. The format can be [TSO](/glossary.md#tso) or timestamp, such as `400036290571534337` or `2018-05-11 01:42:23`. If the data of this snapshot is garbage collected, the `tiup br backup` command returns an error and `br` exits. If you leave this parameter unspecified, `br` picks the snapshot corresponding to the backup start time.
 - `--storage`: The storage address of the backup data. Snapshot backup supports Amazon S3, Google Cloud Storage, and Azure Blob Storage as backup storage. The preceding command uses Amazon S3 as an example. For more details, see [URI Formats of External Storage Services](/external-storage-uri.md).
 - `--ratelimit`: The maximum speed **per TiKV** performing backup tasks. The unit is in MiB/s.
 
@@ -68,7 +68,7 @@ The output is as follows, corresponding to the physical time `2022-09-08 13:30:0
 > - Starting from BR v7.6.0, to address potential restore bottlenecks in scenarios with large-scale Regions, BR supports accelerating restore through the coarse-grained Region scattering algorithm (experimental). You can enable this feature by specifying the command-line parameter `--granularity="coarse-grained"`.
 > - Starting from BR v8.0.0, the snapshot restore through the coarse-grained Region scattering algorithm is generally available (GA) and enabled by default. BR improves the snapshot restore speed significantly by implementing various optimizations such as adopting the coarse-grained Region scattering algorithm, creating databases and tables in batches, reducing the mutual impact between SST file downloads and ingest operations, and accelerating the restore of table statistics. According to test results from real-world cases, the SST file download speed for snapshot restore is improved by approximately up to 10 times, the data restore speed per TiKV node stabilizes at 1.2 GiB/s, the end-to-end restore speed is improved by approximately 1.5 to 3 times, and 100 TiB of data can be restored within one hour.
 
-You can restore a snapshot backup by running the `br restore full` command. Run `br restore full --help` to see the help information:
+You can restore a snapshot backup by running the `tiup br restore full` command. Run `tiup br restore full --help` to see the help information:
 
 The following example restores the [preceding backup snapshot](#back-up-cluster-snapshots) to a target cluster:
 
@@ -96,7 +96,7 @@ BR supports restoring partial data of a specified database or table from backup
 
 **Restore a database**
 
-To restore a database to a cluster, run the `br restore db` command. The following example restores the `test` database from the backup data to the target cluster:
+To restore a database to a cluster, run the `tiup br restore db` command. The following example restores the `test` database from the backup data to the target cluster:
 
 ```shell
 tiup br restore db \
@@ -109,7 +109,7 @@ In the preceding command, `--db` specifies the name of the database to be restor
 
 **Restore a table**
 
-To restore a single table to a cluster, run the `br restore table` command. The following example restores the `test.usertable` table from the backup data to the target cluster:
+To restore a single table to a cluster, run the `tiup br restore table` command. The following example restores the `test.usertable` table from the backup data to the target cluster:
 
 ```shell
 tiup br restore table --pd "${PD_IP}:2379" \
@@ -122,7 +122,7 @@ In the preceding command, `--db` specifies the name of the database to be restor
 
 **Restore multiple tables with table filter**
 
-To restore multiple tables with more complex filter rules, run the `br restore full` command and specify the [table filters](/table-filter.md) with `--filter` or `-f`. The following example restores tables that match the `db*.tbl*` filter rule from the backup data to the target cluster:
+To restore multiple tables with more complex filter rules, run the `tiup br restore full` command and specify the [table filters](/table-filter.md) with `--filter` or `-f`. The following example restores tables that match the `db*.tbl*` filter rule from the backup data to the target cluster:
 
 ```shell
 tiup br restore full \
@@ -217,7 +217,7 @@ The impact of backup on cluster performance can be reduced by limiting the backu
 - BR provides a coarse-grained Region scattering algorithm to accelerate Region restore in large-scale Region scenarios. The algorithm is controlled by the command-line parameter `--granularity="coarse-grained"` and is enabled by default. This algorithm ensures that each TiKV node receives stable and evenly distributed download tasks, thus fully utilizing the resources of each TiKV node and achieving a rapid parallel recovery. In several real-world cases, the snapshot restore speed of the cluster is improved by about 3 times in large-scale Region scenarios. The following is an example:
 
     ```bash
-    br restore full \
+    tiup br restore full \
     --pd "${PDIP}:2379" \
     --storage "s3://${Bucket}/${Folder}" \
     --s3.region "${region}" \
diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md
index 8631205949ace..2906e05298dd5 100644
--- a/br/br-snapshot-manual.md
+++ b/br/br-snapshot-manual.md
@@ -29,10 +29,10 @@ For more information about snapshot backup and restore, refer to:
 
 ## Back up cluster snapshots
 
-You can back up the latest or specified snapshot of the TiDB cluster using the `br backup full` command. For more information about the command, run the `br backup full --help` command.
+You can back up the latest or specified snapshot of the TiDB cluster using the `tiup br backup full` command. For more information about the command, run the `tiup br backup full --help` command.
 
 ```shell
-br backup full \
+tiup br backup full \
     --pd "${PD_IP}:2379" \
     --backupts '2022-09-08 13:30:00' \
     --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
@@ -42,7 +42,7 @@ br backup full \
 
 In the preceding command:
 
-- `--backupts`: The time point of the snapshot. The format can be [TSO](/glossary.md#tso) or timestamp, such as `400036290571534337` or `2018-05-11 01:42:23`. If the data of this snapshot is garbage collected, the `br backup` command returns an error and 'br' exits. If you leave this parameter unspecified, `br` picks the snapshot corresponding to the backup start time.
+- `--backupts`: The time point of the snapshot. The format can be [TSO](/glossary.md#tso) or timestamp, such as `400036290571534337` or `2018-05-11 01:42:23`. If the data of this snapshot is garbage collected, the `tiup br backup` command returns an error and 'br' exits. If you leave this parameter unspecified, `br` picks the snapshot corresponding to the backup start time.
 - `--ratelimit`: The maximum speed **per TiKV** performing backup tasks. The unit is in MiB/s.
 - `--log-file`: The target file where `br` log is written.
 
@@ -62,12 +62,12 @@ Backup & Restore (BR) supports backing up partial data of a specified database o
 
 ### Back up a database
 
-To back up a database in a cluster, run the `br backup db` command.
+To back up a database in a cluster, run the `tiup br backup db` command.
 
 The following example backs up the `test` database to Amazon S3:
 
 ```shell
-br backup db \
+tiup br backup db \
     --pd "${PD_IP}:2379" \
     --db test \
     --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
@@ -79,12 +79,12 @@ In the preceding command, `--db` specifies the database name, and other paramete
 
 ### Back up a table
 
-To back up a table in a cluster, run the `br backup table` command.
+To back up a table in a cluster, run the `tiup br backup table` command.
 
 The following example backs up the `test.usertable` table to Amazon S3:
 
 ```shell
-br backup table \
+tiup br backup table \
     --pd "${PD_IP}:2379" \
     --db test \
     --table usertable \
@@ -97,12 +97,12 @@ In the preceding command, `--db` and `--table` specify the database name and tab
 
 ### Back up multiple tables with table filter
 
-To back up multiple tables with more criteria, run the `br backup full` command and specify the [table filters](/table-filter.md) with `--filter` or `-f`.
+To back up multiple tables with more criteria, run the `tiup br backup full` command and specify the [table filters](/table-filter.md) with `--filter` or `-f`.
 
 The following example backs up tables that match the `db*.tbl*` filter rule to Amazon S3:
 
 ```shell
-br backup full \
+tiup br backup full \
     --pd "${PD_IP}:2379" \
     --filter 'db*.tbl*' \
     --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
@@ -119,7 +119,7 @@ If you do not set this parameter to `false`, the `br` command-line tool uses the
 The following is an example of backing up cluster snapshot data and backing up table statistics with `--ignore-stats=false`:
 
 ```shell
-br backup full \
+tiup br backup full \
 --storage local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log \
 --ignore-stats=false
 ```
@@ -127,7 +127,7 @@ br backup full \
 After backing up data with the preceding configuration, when you restore data, the `br` command-line tool automatically restores table statistics if table statistics are included in the backup (Starting from v8.0.0, the `br` command-line tool introduces the `--load-stats` parameter, which controls whether to restore backup statistics. The default behavior is to restore backup statistics. There is no need to set it to `false` in most cases):
 
 ```shell
-br restore full \
+tiup br restore full \
 --storage local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log
 ```
 
@@ -150,7 +150,7 @@ Since TiDB v5.3.0, you can encrypt backup data by configuring the following para
 The following is an example:
 
 ```shell
-br backup full\
+tiup br backup full\
     --pd ${PD_IP}:2379 \
     --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
     --crypter.method aes128-ctr \
@@ -164,10 +164,10 @@ br backup full\
 
 ## Restore cluster snapshots
 
-You can restore a TiDB cluster snapshot by running the `br restore full` command.
+You can restore a TiDB cluster snapshot by running the `tiup br restore full` command.
 
 ```shell
-br restore full \
+tiup br restore full \
     --pd "${PD_IP}:2379" \
     --with-sys-table \
     --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
@@ -193,12 +193,12 @@ You can use `br` to restore partial data of a specified database or table from b
 
 ### Restore a database
 
-To restore a database to a cluster, run the `br restore db` command.
+To restore a database to a cluster, run the `tiup br restore db` command.
 
 The following example restores the `test` database from the backup data to the target cluster:
 
 ```shell
-br restore db \
+tiup br restore db \
     --pd "${PD_IP}:2379" \
     --db "test" \
     --ratelimit 128 \
@@ -214,12 +214,12 @@ In the preceding command, `--db` specifies the name of the database to be restor
 
 ### Restore a table
 
-To restore a single table to a cluster, run the `br restore table` command.
+To restore a single table to a cluster, run the `tiup br restore table` command.
 
 The following example restores the `test.usertable` table from Amazon S3 to the target cluster:
 
 ```shell
-br restore table \
+tiup br restore table \
     --pd "${PD_IP}:2379" \
     --db "test" \
     --table "usertable" \
@@ -232,12 +232,12 @@ In the preceding command, `--table` specifies the name of the table to be restor
 
 ### Restore multiple tables with table filter
 
-To restore multiple tables with more complex filter rules, run the `br restore full` command and specify the [table filters](/table-filter.md) with `--filter` or `-f`.
+To restore multiple tables with more complex filter rules, run the `tiup br restore full` command and specify the [table filters](/table-filter.md) with `--filter` or `-f`.
 
 The following example restores tables that match the `db*.tbl*` filter rule from Amazon S3 to the target cluster:
 
 ```shell
-br restore full \
+tiup br restore full \
     --pd "${PD_IP}:2379" \
     --filter 'db*.tbl*' \
     --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
@@ -246,12 +246,12 @@ br restore full \
 
 ### Restore execution plan bindings from the `mysql` schema
 
-To restore execution plan bindings of a cluster, you can run the `br restore full` command, including the `--with-sys-table` option and also the `--filter` or `-f` option to specify the `mysql` schema to be restored.
+To restore execution plan bindings of a cluster, you can run the `tiup br restore full` command, including the `--with-sys-table` option and also the `--filter` or `-f` option to specify the `mysql` schema to be restored.
 
 The following is an example of restoring the `mysql.bind_info` table:
 
 ```shell
-br restore full \
+tiup br restore full \
     --pd "${PD_IP}:2379" \
     --filter 'mysql.bind_info' \
     --with-sys-table \
@@ -286,7 +286,7 @@ ADMIN RELOAD BINDINGS;
 After encrypting the backup data, you need to pass in the corresponding decryption parameters to restore the data. Ensure that the decryption algorithm and key are correct. If the decryption algorithm or key is incorrect, the data cannot be restored. The following is an example:
 
 ```shell
-br restore full\
+tiup br restore full\
     --pd "${PD_IP}:2379" \
     --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
     --crypter.method aes128-ctr \
diff --git a/br/br-use-overview.md b/br/br-use-overview.md
index 4bacceb740063..dd28eadd7b2d9 100644
--- a/br/br-use-overview.md
+++ b/br/br-use-overview.md
@@ -16,8 +16,8 @@ Before using TiDB backup and restore features, it is recommended that you unders
 
 **TiDB provides two types of backup. Which one should I use?** Full backup contains the full data of a cluster at a certain point in time. Log backup contains the data changes written to TiDB. It is recommended to use both types of backup at the same time:
 
-- **[Start log backup](/br/br-pitr-guide.md#start-log-backup)**: Run the `br log start` command to start the log backup task. After that, the task keeps running on all TiKV nodes and backs up TiDB data changes to the specified storage in small batches regularly.
-- **Perform [snapshot (full) backup](/br/br-snapshot-guide.md#back-up-cluster-snapshots) regularly**: Run the `br backup full` command to back up the snapshot of the cluster to the specified storage. For example, back up the cluster snapshot at 0:00 AM every day.
+- **[Start log backup](/br/br-pitr-guide.md#start-log-backup)**: Run the `tiup br log start` command to start the log backup task. After that, the task keeps running on all TiKV nodes and backs up TiDB data changes to the specified storage in small batches regularly.
+- **Perform [snapshot (full) backup](/br/br-snapshot-guide.md#back-up-cluster-snapshots) regularly**: Run the `tiup br backup full` command to back up the snapshot of the cluster to the specified storage. For example, back up the cluster snapshot at 0:00 AM every day.
 
 ### How to manage backup data?
 
@@ -53,13 +53,13 @@ If the TiDB cluster is deployed in a self-built data center, the following pract
 
 Assume that you need to set the life cycle for each backup data, for example, 7 days. Such a life cycle is called **backup retention period**, which will also be mentioned in backup tutorials.
 
-* To perform PITR, you need to restore the full backup before the restore point, and the log backup between the full backup and the restore point. Therefore, **It is recommended to only delete the log backup before the full snapshot**. For log backups that exceed the backup retention period, you can use `br log truncate` command to delete the backup before the specified time point.
+* To perform PITR, you need to restore the full backup before the restore point, and the log backup between the full backup and the restore point. Therefore, **It is recommended to only delete the log backup before the full snapshot**. For log backups that exceed the backup retention period, you can use `tiup br log truncate` command to delete the backup before the specified time point.
 * For backup data that exceeds the retention period, you can delete or archive the backup directory.
 
 ### How to restore data?
 
-- To restore only full backup data, you can use `br restore` to perform a full restore of the specified backup.
-- If you have started log backup and regularly performed a full backup, you can run the `br restore point` command to restore data to any time point within the backup retention period.
+- To restore only full backup data, you can use `tiup br restore` to perform a full restore of the specified backup.
+- If you have started log backup and regularly performed a full backup, you can run the `tiup br restore point` command to restore data to any time point within the backup retention period.
 
 ## Deploy and use BR
 
diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md
index 40ef11381c5b0..3cfcc43cde70b 100644
--- a/br/use-br-command-line-tool.md
+++ b/br/use-br-command-line-tool.md
@@ -1,6 +1,6 @@
 ---
 title: br Command-line Manual
-summary: The `br` command-line tool is used for snapshot backup, log backup, and point-in-time recovery (PITR) in TiDB clusters. It consists of sub-commands, options, and parameters, with common options like `--pd` for PD service address and `-s` for storage path. Sub-commands include `br backup`, `br log`, and `br restore`, each with specific functionalities. Backup commands include `full`, `db`, and `table` options, while log backup and restore commands have various tasks for managing backup operations.
+summary: The `br` command-line tool is used for snapshot backup, log backup, and point-in-time recovery (PITR) in TiDB clusters. It consists of sub-commands, options, and parameters, with common options like `--pd` for PD service address and `-s` for storage path. Sub-commands include `tiup br backup`, `tiup br log`, and `tiup br restore`, each with specific functionalities. Backup commands include `full`, `db`, and `table` options, while log backup and restore commands have various tasks for managing backup operations.
 ---
 
 # br Command-line Manual
@@ -14,26 +14,26 @@ A `br` command consists of sub-commands, options, and parameters. A sub-command
 The following is a complete `br` command:
 
 ```shell
-br backup full --pd "${PD_IP}:2379" \
+tiup br backup full --pd "${PD_IP}:2379" \
 --storage "s3://backup-data/snapshot-202209081330/"
 ```
 
 Explanations for the preceding command are as follows:
 
-* `backup`: the sub-command of `br`.
-* `full`: the sub-command of `br backup`.
+* `backup`: the sub-command of `tiup br`.
+* `full`: the sub-command of `tiup br backup`.
 * `-s` (or `--storage`): the option that specifies the path where the backup files are stored. `"s3://backup-data/snapshot-202209081330/"` is the parameter of `-s`.
 * `--pd`: the option that specifies the PD service address. `"${PD_IP}:2379"` is the parameter of `--pd`.
 
 ### Commands and sub-commands
 
-A `br` command consists of multiple layers of sub-commands. Currently, br command-line tool has the following sub-commands:
+A `tiup br` command consists of multiple layers of sub-commands. Currently, br command-line tool has the following sub-commands:
 
-* `br backup`: used to back up the data of the TiDB cluster.
-* `br log`: used to start and manage log backup tasks.
-* `br restore`: used to restore backup data of the TiDB cluster.
+* `tiup br backup`: used to back up the data of the TiDB cluster.
+* `tiup br log`: used to start and manage log backup tasks.
+* `tiup br restore`: used to restore backup data of the TiDB cluster.
 
-`br backup` and `br restore` include the following sub-commands:
+`tiup br backup` and `tiup br restore` include the following sub-commands:
 
 * `full`: used to back up or restore all the cluster data.
 * `db`: used to back up or restore a specified database of the cluster.
@@ -53,7 +53,7 @@ A `br` command consists of multiple layers of sub-commands. Currently, br comman
 
 ## Commands of full backup
 
-To back up cluster data, run the `br backup` command. You can add the `full` or `table` sub-command to specify the scope of your backup operation: the whole cluster (`full`) or a single table (`table`).
+To back up cluster data, run the `tiup br backup` command. You can add the `full` or `table` sub-command to specify the scope of your backup operation: the whole cluster (`full`) or a single table (`table`).
 
 - [Back up TiDB cluster snapshots](/br/br-snapshot-manual.md#back-up-cluster-snapshots)
 - [Back up a database](/br/br-snapshot-manual.md#back-up-a-database)
@@ -63,7 +63,7 @@ To back up cluster data, run the `br backup` command. You can add the `full` or
 
 ## Commands of log backup
 
-To start log backup and manage log backup tasks, run the `br log` command.
+To start log backup and manage log backup tasks, run the `tiup br log` command.
 
 - [Start a log backup task](/br/br-pitr-manual.md#start-a-backup-task)
 - [Query the backup status](/br/br-pitr-manual.md#query-the-backup-status)
@@ -74,7 +74,7 @@ To start log backup and manage log backup tasks, run the `br log` command.
 
 ## Commands of restoring backup data
 
-To restore cluster data, run the `br restore` command. You can add the `full`, `db`, or `table` sub-command to specify the scope of your restore: the whole cluster (`full`), a single database (`db`), or a single table (`table`).
+To restore cluster data, run the `tiup br restore` command. You can add the `full`, `db`, or `table` sub-command to specify the scope of your restore: the whole cluster (`full`), a single database (`db`), or a single table (`table`).
 
 - [Point-in-time recovery](/br/br-pitr-manual.md#restore-to-a-specified-point-in-time-pitr)
 - [Restore cluster snapshots](/br/br-snapshot-manual.md#restore-cluster-snapshots)
diff --git a/dumpling-overview.md b/dumpling-overview.md
index df2d02a47f7d8..d376f157f9276 100644
--- a/dumpling-overview.md
+++ b/dumpling-overview.md
@@ -87,7 +87,7 @@ Dumpling exports data to SQL files by default. You can also export data to SQL f
 {{< copyable "shell-regular" >}}
 
 ```shell
-dumpling -u root -P 4000 -h 127.0.0.1 --filetype sql -t 8 -o /tmp/test -r 200000 -F 256MiB
+tiup dumpling -u root -P 4000 -h 127.0.0.1 --filetype sql -t 8 -o /tmp/test -r 200000 -F 256MiB
 ```
 
 In the command above:
@@ -121,7 +121,7 @@ When you export data to CSV files, you can use `--sql <SQL>` to filter the recor
 {{< copyable "shell-regular" >}}
 
 ```shell
-./dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --filetype csv --sql 'select * from `test`.`sbtest1` where id < 100' -F 100MiB --output-filename-template 'test.sbtest1.{{.Index}}'
+tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --filetype csv --sql 'select * from `test`.`sbtest1` where id < 100' -F 100MiB --output-filename-template 'test.sbtest1.{{.Index}}'
 ```
 
 In the command above:
@@ -236,7 +236,7 @@ export AWS_SECRET_ACCESS_KEY=${SecretKey}
 Dumpling also supports reading credential files from `~/.aws/credentials`. For more information about URI parameter descriptions, see [URI Formats of External Storage Services](/external-storage-uri.md).
 
 ```shell
-./dumpling -u root -P 4000 -h 127.0.0.1 -r 200000 -o "s3://${Bucket}/${Folder}"
+tiup dumpling -u root -P 4000 -h 127.0.0.1 -r 200000 -o "s3://${Bucket}/${Folder}"
 ```
 
 ### Filter the exported data
@@ -246,7 +246,7 @@ Dumpling also supports reading credential files from `~/.aws/credentials`. For m
 By default, Dumpling exports all databases except system databases (including `mysql`, `sys`, `INFORMATION_SCHEMA`, `PERFORMANCE_SCHEMA`, `METRICS_SCHEMA`, and `INSPECTION_SCHEMA`). You can use `--where <SQL where expression>` to select the records to be exported.
 
 ```shell
-./dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --where "id < 100"
+tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --where "id < 100"
 ```
 
 The above command exports the data that matches `id < 100` from each table. Note that you cannot use the `--where` parameter together with `--sql`.
@@ -258,7 +258,7 @@ Dumpling can filter specific databases or tables by specifying the table filter
 {{< copyable "shell-regular" >}}
 
 ```shell
-./dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test -r 200000 --filter "employees.*" --filter "*.WorkOrder"
+tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test -r 200000 --filter "employees.*" --filter "*.WorkOrder"
 ```
 
 The above command exports all the tables in the `employees` database and the `WorkOrder` tables in all databases.
@@ -329,8 +329,8 @@ The `--snapshot` option can be set to a TSO (the `Position` field output by the
 {{< copyable "shell-regular" >}}
 
 ```shell
-./dumpling --snapshot 417773951312461825
-./dumpling --snapshot "2020-07-02 17:12:45"
+tiup dumpling --snapshot 417773951312461825
+tiup dumpling --snapshot "2020-07-02 17:12:45"
 ```
 
 The TiDB historical data snapshots when the TSO is `417773951312461825` and the time is `2020-07-02 17:12:45` are exported.
diff --git a/encryption-at-rest.md b/encryption-at-rest.md
index b36c4ced30b99..9653ba186c16d 100644
--- a/encryption-at-rest.md
+++ b/encryption-at-rest.md
@@ -402,19 +402,19 @@ TiFlash also optimizes encrypted metadata operations in v4.0.9, and its compatib
 To enable S3 server-side encryption when backup to S3 using BR, pass `--s3.sse` argument and set value to "aws:kms". S3 will use its own KMS key for encryption. Example:
 
 ```
-./br backup full --pd <pd-address> --storage "s3://<bucket>/<prefix>" --s3.sse aws:kms
+tiup br backup full --pd <pd-address> --storage "s3://<bucket>/<prefix>" --s3.sse aws:kms
 ```
 
 To use a custom AWS KMS CMK that you created and owned, pass `--s3.sse-kms-key-id` in addition. In this case, both the BR process and all the TiKV nodes in the cluster would need access to the KMS CMK (for example, via AWS IAM), and the KMS CMK needs to be in the same AWS region as the S3 bucket used to store the backup. It is advised to grant access to the KMS CMK to BR process and TiKV nodes via AWS IAM. Refer to AWS documentation for usage of [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html). For example:
 
 ```
-./br backup full --pd <pd-address> --storage "s3://<bucket>/<prefix>" --s3.sse aws:kms --s3.sse-kms-key-id 0987dcba-09fe-87dc-65ba-ab0987654321
+tiup br backup full --pd <pd-address> --storage "s3://<bucket>/<prefix>" --s3.sse aws:kms --s3.sse-kms-key-id 0987dcba-09fe-87dc-65ba-ab0987654321
 ```
 
 When restoring the backup, both `--s3.sse` and `--s3.sse-kms-key-id` should NOT be used. S3 will figure out encryption settings by itself. The BR process and TiKV nodes in the cluster to restore the backup to would also need access to the KMS CMK, or the restore will fail. Example:
 
 ```
-./br restore full --pd <pd-address> --storage "s3://<bucket>/<prefix>"
+tiup br restore full --pd <pd-address> --storage "s3://<bucket>/<prefix>"
 ```
 
 ## BR Azure Blob Storage server-side encryption
@@ -428,13 +428,13 @@ To specify an encryption scope for the backup data, you can use one of the follo
 - Include the `--azblob.encryption-scope` option in the `backup` command and set it to the scope name:
 
     ```shell
-    ./br backup full --pd <pd-address> --storage "azure://<bucket>/<prefix>" --azblob.encryption-scope scope1
+    tiup br backup full --pd <pd-address> --storage "azure://<bucket>/<prefix>" --azblob.encryption-scope scope1
     ```
 
 - Include `encryption-scope` in the URI and set it to the scope name:
 
     ```shell
-    ./br backup full --pd <pd-address> --storage "azure://<bucket>/<prefix>?encryption-scope=scope1"
+    tiup br backup full --pd <pd-address> --storage "azure://<bucket>/<prefix>?encryption-scope=scope1"
     ```
 
 For more information, see the Azure documentation: [Upload a blob with an encryption scope](https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-scope-manage?tabs=powershell#upload-a-blob-with-an-encryption-scope).
@@ -442,7 +442,7 @@ For more information, see the Azure documentation: [Upload a blob with an encryp
 When restoring the backup, you do not need to specify the encryption scope. Azure Blob Storage automatically decrypts the data. For example:
 
 ```shell
-./br restore full --pd <pd-address> --storage "azure://<bucket>/<prefix>"
+tiup br restore full --pd <pd-address> --storage "azure://<bucket>/<prefix>"
 ```
 
 ### Method 2: use an encryption key
@@ -452,20 +452,20 @@ To specify an encryption key for the backup data, you can use one of the followi
 - Include the `--azblob.encryption-key` option in the `backup` command and set it to an AES256 encryption key:
 
     ```shell
-    ./br backup full --pd <pd-address> --storage "azure://<bucket>/<prefix>" --azblob.encryption-key <aes256-key>
+    tiup br backup full --pd <pd-address> --storage "azure://<bucket>/<prefix>" --azblob.encryption-key <aes256-key>
     ```
 
 - Include `encryption-key` in the URI and set it to an AES256 encryption key. If the key contains URI reserved characters such as `&` and `%`, you need to percent-encode it first:
 
     ```shell
-    ./br backup full --pd <pd-address> --storage "azure://<bucket>/<prefix>?encryption-key=<aes256-key>"
+    tiup br backup full --pd <pd-address> --storage "azure://<bucket>/<prefix>?encryption-key=<aes256-key>"
     ```
 
 - Set the `AZURE_ENCRYPTION_KEY` environment variable to an AES256 encryption key. Before running, make sure that you remember the encryption key in the environment variable to avoid forgetting it.
 
     ```shell
     export AZURE_ENCRYPTION_KEY=<aes256-key>
-    ./br backup full --pd <pd-address> --storage "azure://<bucket>/<prefix>"
+    tiup br backup full --pd <pd-address> --storage "azure://<bucket>/<prefix>"
     ```
 
 For more information, see the Azure documentation: [Provide an encryption key on a request to Blob storage](https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-customer-provided-keys).
@@ -475,18 +475,18 @@ When restoring the backup, you need to specify the encryption key. For example:
 - Include the `--azblob.encryption-key` option in the `restore` command:
 
     ```shell
-    ./br restore full --pd <pd-address> --storage "azure://<bucket>/<prefix>" --azblob.encryption-key <aes256-key>
+    tiup br restore full --pd <pd-address> --storage "azure://<bucket>/<prefix>" --azblob.encryption-key <aes256-key>
     ```
 
 - Include `encryption-key` in the URI:
 
     ```shell
-    ./br restore full --pd <pd-address> --storage "azure://<bucket>/<prefix>?encryption-key=<aes256-key>"
+    tiup br restore full --pd <pd-address> --storage "azure://<bucket>/<prefix>?encryption-key=<aes256-key>"
     ```
 
 - Set the `AZURE_ENCRYPTION_KEY` environment variable:
 
     ```shell
     export AZURE_ENCRYPTION_KEY=<aes256-key>
-    ./br restore full --pd <pd-address> --storage "azure://<bucket>/<prefix>"
+    tiup br restore full --pd <pd-address> --storage "azure://<bucket>/<prefix>"
     ```
diff --git a/table-filter.md b/table-filter.md
index a6768fcd76a92..ec1a5cf97cab0 100644
--- a/table-filter.md
+++ b/table-filter.md
@@ -21,11 +21,11 @@ Table filters can be applied to the tools using multiple `-f` or `--filter` comm
 * [BR](/br/backup-and-restore-overview.md):
 
     ```shell
-    ./br backup full -f 'foo*.*' -f 'bar*.*' -s 'local:///tmp/backup'
+    tiup br backup full -f 'foo*.*' -f 'bar*.*' -s 'local:///tmp/backup'
     ```
 
     ```shell
-    ./br restore full -f 'foo*.*' -f 'bar*.*' -s 'local:///tmp/backup'
+    tiup br restore full -f 'foo*.*' -f 'bar*.*' -s 'local:///tmp/backup'
     ```
 
 </CustomContent>
@@ -33,7 +33,7 @@ Table filters can be applied to the tools using multiple `-f` or `--filter` comm
 * [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview):
 
     ```shell
-    ./dumpling -f 'foo*.*' -f 'bar*.*' -P 3306 -o /tmp/data/
+    tiup dumpling -f 'foo*.*' -f 'bar*.*' -P 3306 -o /tmp/data/
     ```
 
 <CustomContent platform="tidb">
@@ -41,7 +41,7 @@ Table filters can be applied to the tools using multiple `-f` or `--filter` comm
 * [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md):
 
     ```shell
-    ./tidb-lightning -f 'foo*.*' -f 'bar*.*' -d /tmp/data/ --backend tidb
+    tiup tidb-lightning -f 'foo*.*' -f 'bar*.*' -d /tmp/data/ --backend tidb
     ```
 
 </CustomContent>
@@ -51,7 +51,7 @@ Table filters can be applied to the tools using multiple `-f` or `--filter` comm
 * [TiDB Lightning](https://docs.pingcap.com/tidb/stable/tidb-lightning-overview):
 
     ```shell
-    ./tidb-lightning -f 'foo*.*' -f 'bar*.*' -d /tmp/data/ --backend tidb
+    tiup tidb-lightning -f 'foo*.*' -f 'bar*.*' -d /tmp/data/ --backend tidb
     ```
 
 </CustomContent>
@@ -139,8 +139,8 @@ employees.*
 the following two invocations are equivalent:
 
 ```bash
-./dumpling -f '@config/filter.txt'
-./dumpling -f 'employees.*' -f '*.WorkOrder'
+tiup dumpling -f '@config/filter.txt'
+tiup dumpling -f 'employees.*' -f '*.WorkOrder'
 ```
 
 A filter file cannot further import another file.
@@ -235,10 +235,10 @@ To build a block list, an explicit `*.*` must be used as the first rule, otherwi
 
 ```bash
 # every table will be filtered out
-./dumpling -f '!*.Password'
+tiup dumpling -f '!*.Password'
 
 # only the "Password" table is filtered out, the rest are included.
-./dumpling -f '*.*' -f '!*.Password'
+tiup dumpling -f '*.*' -f '!*.Password'
 ```
 
 In a filter list, if a table name matches multiple patterns, the last match decides the outcome. For instance:
diff --git a/tidb-lightning/tidb-lightning-command-line-full.md b/tidb-lightning/tidb-lightning-command-line-full.md
index 4f4b3778a4998..6af6b5016fc13 100644
--- a/tidb-lightning/tidb-lightning-command-line-full.md
+++ b/tidb-lightning/tidb-lightning-command-line-full.md
@@ -38,7 +38,7 @@ You can configure the following parameters using `tidb-lightning`:
 | `--key <file>` | Private key path for TLS connection | `security.key-path` |
 | `--server-mode` | Start TiDB Lightning in server mode | `lightning.server-mode` |
 
-If you specify both a command line parameter and the corresponding setting in the configuration file, the command line parameter takes precedence. For example, running `./tidb-lightning -L debug --config cfg.toml` would always set the log level to "debug" regardless of the content of `cfg.toml`.
+If you specify both a command line parameter and the corresponding setting in the configuration file, the command line parameter takes precedence. For example, running `tiup tidb-lightning -L debug --config cfg.toml` would always set the log level to "debug" regardless of the content of `cfg.toml`.
 
 ## `tidb-lightning-ctl`
 
diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md
index 59ec10b04bb95..9715d96ff5e85 100644
--- a/tidb-lightning/tidb-lightning-configuration.md
+++ b/tidb-lightning/tidb-lightning-configuration.md
@@ -489,7 +489,7 @@ log-progress = "5m"
 | --key *file* | Private key path for TLS connection | `security.key-path` |
 | --server-mode | Start TiDB Lightning in server mode | `lightning.server-mode` |
 
-If a command line parameter and the corresponding setting in the configuration file are both provided, the command line parameter will be used. For example, running `./tidb-lightning -L debug --config cfg.toml` would always set the log level to "debug" regardless of the content of `cfg.toml`.
+If a command line parameter and the corresponding setting in the configuration file are both provided, the command line parameter will be used. For example, running `tiup tidb-lightning -L debug --config cfg.toml` would always set the log level to "debug" regardless of the content of `cfg.toml`.
 
 ## Usage of `tidb-lightning-ctl`
 
diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md
index 1bede6ce99bc4..ff7722a070816 100644
--- a/tidb-lightning/tidb-lightning-data-source.md
+++ b/tidb-lightning/tidb-lightning-data-source.md
@@ -410,35 +410,35 @@ The following examples show how to import data from Amazon S3 using TiDB Lightni
 + Use the locally configured permissions to access S3 data:
 
     ```bash
-    ./tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
+    tiup tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
         -d 's3://my-bucket/sql-backup'
     ```
 
 + Use the path-style request to access S3 data:
 
     ```bash
-    ./tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
+    tiup tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
         -d 's3://my-bucket/sql-backup?force-path-style=true&endpoint=http://10.154.10.132:8088'
     ```
 
 + Use a specific AWS IAM role ARN to access S3 data:
 
     ```bash
-    ./tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
+    tiup tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
         -d 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role'
     ```
 
 * Use access keys of an AWS IAM user to access S3 data:
 
     ```bash
-    ./tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
+    tiup tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
         -d 's3://my-bucket/test-data?access_key={my_access_key}&secret_access_key={my_secret_access_key}'
     ```
 
 * Use the combination of AWS IAM role access keys and session tokens to access S3 data:
 
     ```bash
-    ./tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
+    tiup tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
         -d 's3://my-bucket/test-data?access_key={my_access_key}&secret_access_key={my_secret_access_key}&session-token={my_session_token}'
     ```
 
diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md
index 20d6219d0ea09..b80dbc82f3ccf 100644
--- a/tidb-lightning/tidb-lightning-distributed-import.md
+++ b/tidb-lightning/tidb-lightning-distributed-import.md
@@ -107,7 +107,7 @@ sorted-kv-dir = "/path/to/sorted-dir"
 If the data source is stored in external storage such as Amazon S3 or GCS, you need to configure additional parameters for connection. You can specify parameters for such configuration. For example, the following example assumes that data is stored in Amazon S3:
 
 ```
-./tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
+tiup tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \
     -d 's3://my-bucket/sql-backup'
 ```