log-backup: reduced RPO to 5 mins (pingcap#12160)

br/backup-and-restore-overview.md

@@ -10,7 +10,7 @@ aliases: ['/docs-cn/dev/br/backup-and-restore-tool/','/docs-cn/dev/reference/too
 
 TiDB 备份恢复功能可以用于满足以下业务的需求：
 
-- 备份集群数据到灾备系统，并保证 RPO 低至 10 分钟，减少灾难场景下数据的丢失。
+- 备份集群数据到灾备系统，并保证 Recovery Point Objective (RPO) 低至 5 分钟，减少灾难场景下数据的丢失。
 - 处理业务数据写错的案例，提供业务操作的“复原”能力。
 - 审计业务的历史数据，满足司法审查的需求。
 - 复制 (Clone) 生产环境，方便问题诊断、性能调优验证、仿真测试等。
@@ -49,7 +49,7 @@ TiDB 备份恢复功能可以用于满足以下业务的需求：
 #### 备份的性能，以及对集群的影响
 
 - 集群快照数据备份，对 TiDB 集群的影响可以保持在 20% 以下；通过合理的配置 TiDB 集群用于备份资源，影响可以降低到 10% 及更低；单 TiKV 存储节点的备份速度可以达到 50 MB/s ～ 100 MB/s，备份速度具有可扩展性；更详细说明请参考[备份性能和影响](/br/br-snapshot-guide.md#快照备份的性能与影响)。
-- 单独运行日志备份时影响约在 5%。日志备份每隔 5～10 分钟将上次刷新后产生的变更数据记录刷新到备份存储中，可以**实现低至十分钟 RPO 的集群容灾目标**。
+- 单独运行日志备份时影响约在 5%。日志备份每隔 3～5 分钟将上次刷新后产生的变更数据记录刷新到备份存储中，可以**实现低至五分钟 RPO 的集群容灾目标**。
 
 ### 恢复备份数据
 

faq/backup-and-restore-faq.md

@@ -29,17 +29,6 @@ TiKV 支持[动态配置](/tikv-control.md#动态修改-tikv-的配置)自动调
 
 ## PITR 问题
 
-### `br` 进程在执行 `br log truncate` 命令时为什么会出现 OOM 问题？
-
-Issue 链接：[#36648](https://github.com/pingcap/tidb/issues/36648)
-
-执行 `br log truncate` 时遇到 br OOM 问题，从以下几点考虑：
-
-- 由于删除的日志区间过大。
-    - 遇到此问题，解决方法是先减小删除的日志区间，可通过多次删除小区间日志来替代掉需要删除的大区间日志。
-- br 进程所在的节点内存配置过低。
-    - 建议升级节点内存配置到至少 16 GB，确保 PITR 恢复有足够的内存资源。
-
 ### 上游数据库使用 TiDB Lightning Physical 方式导入数据时，为什么无法使用日志备份功能？
 
 目前日志备份功能还没有完全适配 TiDB Lightning，导致 TiDB Lightning Physical 方式导入的数据无法备份到日志中。