1. 备份策略设计

为了平衡备份速度和恢复时间（RTO/RPO），通常采用 “周全量 + 日/时增量 + 实时 binlog” 的组合方案。
- 每周一次全量备份，提供完整的数据基准，简化恢复流程，使用工具XtraBackup
- 每日一次增量备份，使用工具XtraBackup
- 实时日志，记录所有写操作，用于“任意时间点”恢复 (PITR)，使用Binlog
工具选择
- 大型生产环境首选物理备份，因为恢复速度（RTO）极快。
- 首选开源工具Percona XtraBackup，支持加密与压缩

2. 异地与冷热备份结合方案

冷热结合
- 热数据 (Hot)：最近 7 天的备份保存在本地 SSD 磁盘或万兆内网的 NAS/NFS 上。优点是恢复极快。
- 冷数据 (Cold)：超过 7 天的备份进行压缩并打标签，上传至云存储（如阿里云 OSS/AWS S3） 的低频/归档存储中，保留 30-90 天，满足审计和极端灾难恢复需求。
异地备份
- 传输方式：利用 rsync 或云厂商的跨地域复制功能，在全量备份完成后，自动将加密后的备份包同步至异地数据中心。
- 架构补充：除了备份文件异地化，建议配置跨城从库（Slave），通过 MySQL 半同步复制（Semi-sync）实现秒级的实时数据异地冗余。

安全性保障
- 加密存储：备份文件必须开启 AES 加密（XtraBackup 自带加密参数），防止备份包泄露导致脱库。
- 权限最小化：备份专用账号仅授予 RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT 等最小权限。
- 防篡改：开启 OSS 的 WORM（只读不可删）策略，防止勒索软件攻击。
可恢复性验证
- 定期演练：每周自动随机抽取一个备份包，在隔离的临时服务器上执行 prepare 和 restore 挂载测试。
- 监控告警：监控备份脚本的返回状态码、备份文件的大小波动（防止空备份）、备份完成耗时。

监控指标
- 执行状态 (Exit Code)：脚本退出码是否为 0。
- 备份耗时 (Duration)：如果平时 1 小时下完，今天跑了 3 小时，可能存在锁表或 I/O 异常。
- 文件大小 (File Size)：如果备份文件大小突然下降（例如从 100G 变成 1M），通常意味着备份了空表或发生了静默失败。
- Binlog 连续性：监控 mysql-bin 日志是否有断档，确保增量恢复链路完整。
- 存储容量 (Storage)：监控备份挂载盘或云存储（OSS/S3）的剩余空间，防止因空间不足导致备份截断。
Prometheus 生态
- 脚本上报：在备份脚本（如 xtrabackup.sh）末尾增加 curl 操作，将执行状态和文件大小推送到 Prometheus Pushgateway。
- 指标定义：定义指标如 mysql_backup_last_success_timestamp 和 mysql_backup_size_bytes。
- 超时告警：time() - mysql_backup_last_success_timestamp > 86400（超过 24 小时未成功则告警）。
- 容量异常：监控备份文件大小的环比变化率。
自动化恢复演练告警
- 每天自动启动一个临时的 Docker 容器（MySQL 实例）。
- 下载当天的备份包并执行 prepare 和 restore。
- 尝试登录并随机查询几条关键数据。
- 如果上述还原流程中任何一步失败，发出最高等级告警（这意味着现有的备份方案全部失效）。