log backup: reduce RPO to < 5m (#11502)

br/backup-and-restore-overview.md

@@ -10,7 +10,7 @@ Based on the Raft protocol and a reasonable deployment topology, TiDB realizes h
 
 BR satisfies the following requirements:
 
-- Back up cluster data to a disaster recovery (DR) system with an RPO of no more than 10 minutes, reducing data loss in disaster scenarios.
+- Back up cluster data to a disaster recovery (DR) system with an RPO as short as 5 minutes, reducing data loss in disaster scenarios.
 - Handle the cases of misoperations from applications by rolling back data to a time point before the error event.
 - Perform history data auditing to meet the requirements of judicial supervision.
 - Clone the production environment, which is convenient for troubleshooting, performance tuning, and simulation testing.
@@ -49,7 +49,7 @@ Full backup occupies much storage space and contains only cluster data at a spec
 #### Backup performance and impact on TiDB clusters
 
 - The impact of backup on a TiDB cluster is kept below 20%, and this value can be reduced to 10% or less with the proper configuration of the TiDB cluster. The backup speed of a TiKV node is scalable and ranges from 50 MB/s to 100 MB/s. For more information, see [Backup performance and impact](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-backup).
-- When there are only log backup tasks, the impact on the cluster is about 5%. Log backup flushes all the changes generated after the last refresh every 5-10 minutes to the backup storage, which can **achieve a Recovery Point Objective (RPO) of no more than ten minutes**.
+- When there are only log backup tasks, the impact on the cluster is about 5%. Log backup flushes all the changes generated after the last refresh every 3-5 minutes to the backup storage, which can **achieve a Recovery Point Objective (RPO) as short as five minutes**.
 
 ### Restore backup data
 

faq/backup-and-restore-faq.md

@@ -27,20 +27,6 @@ When you perform backup tasks on an offline cluster, to speed up the backup, you
 
 ## PITR issues
 
-### Why `br` encounters the OOM problem after I run the `br log truncate` command?
-
-Issue: [#36648](https://github.com/pingcap/tidb/issues/36648)
-
-Consider the following possible causes:
-
-- The range of logs to be deleted is too large.
-
-    To resolve this issue, reduce the range of logs to be deleted first and delete the target logs in several batches instead of deleting them once.
-
-- The memory allocation of the node where the `br` process is located is too low.
-
-    It is recommended to scale up the node memory configuration to at least 16 GB to ensure that PITR has sufficient memory for recovery.
-
 ### When the upstream database imports data using TiDB Lightning in the physical import mode, the log backup feature becomes unavailable. Why?
 
 Currently, the log backup feature is not fully adapted to TiDB Lightning. Therefore, data imported in the physical mode of TiDB Lightning cannot be backed up into log data