mysql备份生命周期管理需靠外部脚本+定时任务实现，推荐用find清理过期文件、对齐binlog保留周期、冷热分层时附带manifest元数据、并强制自动化恢复验证。
mysqldump 和 xtrabackup 本身不提供生命周期管理能力，必须靠外部脚本+定时任务+存储策略协同实现。硬编码保留天数或手动删备份，迟早会撑爆磁盘或丢失关键恢复点。
用 find + cron 清理过期备份文件最直接可靠
MySQL不管理备份文件的存活时间，所有“保留7天”“只留3份”都得自己落地。依赖备份工具内置清理（如某些xtrabackup封装脚本）容易失效或版本不兼容。
推荐在备份脚本末尾追加清理逻辑，或单独用 find 定时执行：
-
find /backup/mysql/ -name "*.sql.gz" -mtime +7 -delete：删除7天前的压缩备份 -
find /backup/mysql/ -name "full_backup_*" -type f | sort -r | tail -n +4 | xargs rm -f：只保留最近3个全备（按文件名时间戳排序） - 务必先用
-print替代-delete测试匹配是否准确，误删不可逆
binlog 保留周期必须和备份策略对齐
只保留3天 binlog 却存着14天前的全量备份，等于那14天备份根本无法恢复到任意时间点——中间的事务日志早就被 expire_logs_days 清掉了。
检查并设置：
- 确认
my.cnf中expire_logs_days = 7（至少覆盖最长备份间隔） - 若用
xtrabackup --incremental，增量备份依赖的 base backup 必须在 binlog 有效期内能完整回放 - 运行
SHOW BINARY LOGS;和SHOW MASTER STATUS;核对当前日志边界
冷热分层存储不能只靠“移动文件”，得带元数据标记
把3个月前的备份 mv 到 NAS 或 S3，不代表它就自动变成“可删冷备”。没记录原始备份类型、对应 binlog 范围、校验码，后期恢复时根本不敢用。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
每次归档动作必须附带一个描述文件：
backup_orderdb_20260501_030000.sql.gz backup_orderdb_20260501_030000.manifest.json
manifest.json 至少含：backup_type（full/incremental）、binlog_start、binlog_end、checksum（如 sha256sum 值）。否则所谓“分层”只是把问题从磁盘转移到了对象存储里。
验证失败的备份比不备份更危险
一个没通过恢复测试的 full_backup_20260601.sql.gz，可能因字符集错误、GTID 不一致、或 mysqldump 参数漏写 --set-gtid-purged=OFF 而静默损坏。它占着空间，还给你虚假安全感。
自动化验证不是可选项：
- 每周抽1个全备 + 对应 binlog 段，在临时实例上跑完整恢复流程
- 验证项必须包括：
SELECT COUNT(*)对比原库、关键表MIN(id)/MAX(id)区间、以及SELECT @@gtid_executed是否连续 - 验证脚本失败时，不仅发告警，还要自动给该备份打上
.broken后缀，防止被清理脚本误删——它得被人工介入定性
