rpo和rto是业务约束条件而非配置项，必须基于业务容忍度设定并经实测验证：rpo取决于可接受的数据丢失时长（如订单系统≤5分钟），rto需通过完整恢复流程测试得出（含传输、解压、校验、binlog应用等），未验证的备份策略形同虚设。
RPO 和 RTO 不是配置项，而是业务约束条件；你填的数字必须能被验证，否则备份策略就是纸面摆设。
怎么定 RPO：看业务能丢多少数据，不是看技术能不能做
RPO 本质是业务对“数据新鲜度”的容忍底线。比如订单系统若要求“不能丢下单后 5 分钟内的支付记录”，那 RPO 就必须 ≤ 5 分钟——这意味着 binlog 必须启用，且至少每 5 分钟做一次增量快照或日志轮转归档。
- 金融/支付类系统：RPO 常压到
0或1分钟，需部署主从 + 半同步复制 + 实时 binlog 备份 - 内部 CMS 或报表库：RPO 设为
24小时也合理，每日全量 + 压缩归档即可 - 切忌把 RPO 定成
0却不开启binlog，或开了binlog却没保留足够天数——expire_logs_days默认是0（永不过期），但磁盘爆满会导致 MySQL 拒写日志，反而中断备份链
怎么定 RTO：测出来，不是估出来
RTO 是从故障发生到数据库可读写的时间上限。它取决于恢复动作的实际耗时，包括传输、解压、导入、校验、应用 binlog 等所有环节。很多团队把 RTO 定成 30 分钟，结果一次恢复花了 2 小时，问题出在没实测。
- 物理备份（如
xtrabackup）恢复快，但要求同版本、同页大小、同 innodb_file_per_table 设置，跨环境容易失败 - 逻辑备份（
mysqldump）恢复慢，尤其带--routines和--triggers时，大库可能卡在单线程导入阶段 - 真实 RTO 测试必须包含：从备份存储拉取文件 → 解密（如有）→ 校验 md5/sha256 → 启动空实例 → 导入 → 应用 binlog 到指定时间点 → 连接应用并执行简单 SELECT 验证
备份组合怎么配：全量 + 增量 + binlog 缺一不可
只做全量 = RPO 等于全备间隔；只做 binlog = 一旦全备损坏就彻底无法恢复。生产必须三层叠加。
- 全量：每周一次
xtrabackup --backup（InnoDB 热备），命名含日期与 checksum，存至异地对象存储 - 增量：每天基于上次全量做
xtrabackup --incremental-basedir，或用mysqlbinlog --read-from-remote-server拉取当日 binlog 并压缩归档 - binlog：必须开启
log-bin+server-id，设置expire_logs_days = 7（对应 RPO ≤ 7 天），且定期用mysqlbinlog --base64-output=DECODE-ROWS -v抽样检查内容可读性 - 注意：
mysqldump的--single-transaction对 MyISAM 表无效，混合引擎库慎用；而xtrabackup不支持 MyISAM 热备，需加--lock-ddl或停写
最容易被忽略的致命点：备份≠可用，没验证=没备份
线上见过太多“备份脚本 cron 每天跑成功”，结果某次磁盘损坏后发现最近 3 周的 .xbstream 文件全是空的，因为备份路径权限被误改，xtrabackup 静默失败。
- 每次备份后必须运行校验命令，例如：
xtrabackup --check-privileges --backup --target-dir=/tmp/test-verify - 每月至少一次完整 PITR（Point-in-Time Recovery）演练：选一个非高峰时段，用全量 + binlog 恢复到 5 分钟前，再比对关键表行数和最新时间戳
- 备份文件权限要严格限制：
chown backup:backup /backup/*+chmod 600，避免敏感 SQL 泄露
