diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md
index 1cd655431e8b..7dd7a97887c3 100644
--- a/br/backup-and-restore-storages.md
+++ b/br/backup-and-restore-storages.md
@@ -108,7 +108,7 @@ tiup br restore db --db test -u "${PD_IP}:2379" \
 在备份之前，需要为 br 命令行工具访问 Amazon S3 中的备份目录设置相应的访问权限：
 
 - 备份时 TiKV 和 br 命令行工具需要的访问备份数据目录的最小权限：`s3:ListBucket`、`s3:GetObject`、`s3:DeleteObject`、`s3:PutObject` 和 `s3:AbortMultipartUpload`。
-- 恢复时 TiKV 和 br 命令行工具需要的访问备份数据目录的最小权限：`s3:ListBucket`、`s3:GetObject`、`s3:DeleteObject` 和 `s3:PutObject`。br 命令行工具会将断点信息写到备份数据目录下的 `./checkpoints` 子目录。在恢复日志备份数据时，br 命令行工具会将备份恢复集群的表 ID 映射关系写到备份数据目录下的 `./pitr_id_maps` 子目录。
+- 恢复时 TiKV 和 br 命令行工具需要的访问备份数据目录的最小权限：`s3:ListBucket` 和 `s3:GetObject`。
 
 如果你还没有创建备份数据保存目录，可以参考[创建存储桶](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-bucket.html)在指定的区域中创建一个 S3 存储桶。如果需要使用文件夹，可以参考[使用文件夹在 Amazon S3 控制台中组织对象](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-folder.html)在存储桶中创建一个文件夹。
 
diff --git a/br/backup-and-restore-use-cases.md b/br/backup-and-restore-use-cases.md
index 9f7a5b02e362..dbc82f529844 100644
--- a/br/backup-and-restore-use-cases.md
+++ b/br/backup-and-restore-use-cases.md
@@ -71,7 +71,7 @@ aliases: ['/docs-cn/dev/br/backup-and-restore-use-cases/','/docs-cn/dev/referenc
 2. 配置 br 命令行工具和 TiKV 访问 S3 中的备份目录的权限。本文推荐使用最安全的 IAM 访问方式，配置过程可以参考[控制存储桶访问](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/userguide/walkthrough1.html)。权限要求如下：
 
     - 备份集群的 TiKV 和 br 命令行工具需要的 `s3://tidb-pitr-bucket/backup-data` 权限：`s3:ListBucket`、`s3:GetObject`、`s3:DeleteObject`、`s3:PutObject` 和 `s3:AbortMultipartUpload`。
-    - 恢复集群的 TiKV 和 br 命令行工具需要 `s3://tidb-pitr-bucket/backup-data` 的最小权限：`s3:ListBucket`、`s3:GetObject`、`s3:DeleteObject` 和 `s3:PutObject`。
+    - 恢复集群的 TiKV 和 br 命令行工具需要 `s3://tidb-pitr-bucket/backup-data` 的最小权限：`s3:ListBucket` 和 `s3:GetObject`。
 
 3. 规划备份数据保存的目录结构，以及快照（全量）备份和日志备份的目录。
 
diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md
index 19f735553a70..d53fa8501239 100644
--- a/br/br-checkpoint-restore.md
+++ b/br/br-checkpoint-restore.md
@@ -60,3 +60,25 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold
 ### 不要在恢复期间修改集群数据
 
 在恢复失败后，请避免向集群写入或删除数据、删除或创建表。由于备份数据中可能包含重命名表的 DDL 操作，断点恢复无法确认被删除的表或已存在的表是否是外部操作引起的，这会影响下次重试恢复的准确性。
+
+## 具体操作细节
+
+断点恢复的具体操作细节分为快照恢复和 PITR 恢复两部分。
+
+### 快照恢复
+
+在第一次执行恢复时，br 工具会在恢复集群中创建名为 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint` 的库，用于存放断点数据。并且 br 工具还记录了这次恢复的上游集群的 ID 和备份的 BackupTS。
+
+当恢复执行失败后，你可以用相同的命令再次执行恢复，br 工具会从库 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint` 的断点信息自动继续上一次的恢复。
+
+当恢复执行失败后，如果你尝试使用其他备份数据恢复到同一集群，那么 br 工具会报告错误，提示这一次恢复指定的备份数据来源的上游集群的 ID 与断点中记录的不同，或者这一次恢复指定的备份数据的 BackupTS 与断点中记录的不同。如果你确认已经清理了集群，那么可以手动删除库 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`，然后重新尝试使用其他备份数据恢复到这个集群。
+
+### PITR 恢复
+
+PITR 恢复分为快照恢复和日志恢复两个阶段。
+
+在第一次执行恢复时，br 工具会首先进入快照恢复阶段，这与上述只进行快照恢复操作相同。当恢复进入到快照恢复阶段，备份数据的上游集群的 ID 和备份数据的 BackupTS （等于日志恢复的起始时间点 `start-ts`）已经被记录于断点中。这意味着当恢复在快照恢复阶段执行失败时，尝试断点恢复继续时只能调整日志恢复的恢复时间点 `restored-ts`.
+
+在第一次执行恢复并且 br 工具进入日志恢复阶段时，br 工具会在恢复集群中创建名为 `__TiDB_BR_Temporary_Log_Restore_Checkpoint` 的库，用于存放断点数据。并且 br 工具还记录了这次恢复的上游集群 ID 和恢复的时间范围 `start-ts` 与 `restored-ts`。这意味着当恢复在日志恢复阶段执行失败时，尝试断点恢复继续时需要指定与断点记录中相同的快照备份路径和参数 `restored-ts`。否则，br 工具会报告错误，提示这一次恢复指定的恢复时间范围与断点中记录的不同，或者这一次恢复指定的备份数据来源的上游集群的 ID 与断点记录的不同。如果你确认已经清理了集群，那么可以手动删除库 `__TiDB_BR_Temporary_Log_Restore_Checkpoint`，然后重新尝试其他备份数据恢复到这个集群。
+
+在第一次执行恢复并且 br 工具进入日志恢复阶段中的库表数据恢复前，会构造出在时间点 `restored-ts` 的上下游集群库表 ID 的映射，并持久记录在系统表 `mysql.tidb_pitr_id_map` 中，用于断点恢复重试时避免库表 ID 被错误分配。