rpo需根据写入节奏和业务容忍度确定：先用show global status查com_insert/update峰值，结合业务日志识别关键事务窗口，高频表单独做5–15分钟增量快照；rto依赖本地ssd存储、版本匹配的xtrabackup及每次备份后预验证恢复。
怎么定RPO：先看写入节奏，再卡备份间隔
RPO不是拍脑袋定的数字，它直接对应“最多能丢多少秒数据”。比如订单库每秒插入200条，RPO设成5分钟，意味着一次故障最多丢6万条记录——业务能不能兜住，得看下游系统有没有补偿机制。
实操建议：
- 用 SHOW GLOBAL STATUS LIKE 'Com_insert' 和 SHOW GLOBAL STATUS LIKE 'Com_update' 查过去24小时峰值写入量
- 结合业务日志确认关键事务窗口（比如每天早10点批量扣款、晚8点促销下单）
- 高频表（如 user_balance、stock_snapshot）单独做增量快照，间隔控制在5–15分钟，用 mysqldump --single-transaction --tables
- 别把所有表塞进一个全备脚本里——锁表时间随表数量线性增长，失败后重跑成本高，且无法按表恢复
怎么压RTO：备份放哪、恢复链验没验、工具版本对不对
RTO卡在分钟级，靠的不是“恢复快”，而是“不卡壳”。常见卡点：备份存在NFS上挂载超时、压缩包没解压就直接 xtrabackup --prepare、恢复机器缺 qpress 解压工具、甚至用XtraBackup 8.0.30去恢复8.0.33的备份——报错 Unsupported redo log format 直接中断。
实操建议：
- 备份目标必须是本地SSD或低延迟SAN，禁用跨机房NAS；用 df -h 和 iostat -x 1 确认I/O吞吐达标
- 每次新备份生成后，立刻执行轻量验证：xtrabackup --copy-back --target-dir=/backup/2026-08-10 --datadir=/tmp/mysql-test，然后连上去查 SELECT COUNT(*) FROM test_table
- xtrabackup 版本必须和MySQL主版本严格一致（如MySQL 8.0.33 → XtraBackup 8.0.33），否则prepare阶段失败
- binlog保留时长至少为最长全备周期×2+1天，且必须和数据文件分盘存储——同一块盘故障会导致全链失效
全量+增量+binlog三层链怎么不断
全备是基线，增量是差量，binlog是缝合线。三者断一环，PITR（时间点恢复）就失效。最容易被忽略的是增量备份的依赖关系：每个增量都基于前一个全备或增量，删旧备份时若只看mtime，可能误删某个增量链的父节点。
实操建议：
- 全量每周一次，存放在独立目录（如 /backup/full/2026-08-07）
- 增量每6小时一次，明确标记base-lsn和to-lsn，目录结构带父备份ID（如 /backup/inc/2026-08-07_0600_to_2026-08-07_1200）
- 删除旧备份前，用 xtrabackup --incremental-history 查当前有效链，而不是简单 find /backup -mtime +7 -delete
- binlog按天滚动，文件名带server-id和序列号（如 mysql-bin.000123），启用 expire_logs_days=7 仅作兜底，主策略靠外部清理脚本校验LSN连续性
mysqldump和xtrabackup到底选哪个
小库（mysqldump --single-transaction --quick --skip-lock-tables 足够；一旦库变大或写入密集，mysqldump 的锁等待、导出慢、恢复更慢的问题就会暴露——尤其遇到FLUSH TABLES WITH READ LOCK失败时，备份进程会卡死并阻塞线上DML。
实操建议：
- 生产环境50GB以上数据库，直接上 xtrabackup；它不锁表、支持流式压缩、可并发备份多个实例
- 用 xtrabackup --backup --compress --stream=xbstream 时，恢复端必须提前装好 xbstream 和对应解压工具（如 qpress）
- mysqldump 适合跨版本迁移或部分表导出，但别指望它撑起核心库的RTO/RPO指标
- 所有备份脚本里必须包含 --rsync 或 --parallel 参数开关，避免单线程拖慢整体节奏
真正卡住RPO/RTO的，往往不是工具本身，而是备份链的拓扑设计是否经得起删、验、切、换。比如一个没验证过的增量备份目录，看着存在，其实prepare失败；又比如binlog和全备不在同一存储域，恢复时网络延迟让整个流程多耗20分钟——这些细节不提前踩一遍，指标就是纸面数字。
