合规备份必须支持5分钟粒度时间点恢复，需开启ROW格式binlog并归档完整，全量备份须带--master-data=2，清理binlog用PURGE命令而非expire_logs_days，mysqldump应避免--all-databases并按库拆分执行，备份文件须AES256加密且密钥隔离，元数据须写入backup_meta表实现可追溯清理。
备份保留策略必须绑定时间点恢复能力
只设“保留7天”没用，合规要求的是能还原到任意5分钟粒度的过去时间。这意味着二进制日志（binlog）必须开启、归档完整，且与全量备份时间对齐。
-
binlog格式必须为ROW，STATEMENT在部分函数或非确定性语句下无法精确回放 - 全量备份（如
mysqldump或mysqlpump）必须加--master-data=2，才能在备份文件里记录对应binlog位置 - 定期清理
binlog不能只靠expire_logs_days：它按文件创建时间删，而实际需要按最后写入时间删；建议用PURGE BINARY LOGS BEFORE '2024-06-01 00:00:00'手动控制
mysqldump 备份需绕过事务一致性陷阱
默认 mysqldump 加 --single-transaction 对 InnoDB 有效，但遇到 DDL 操作（如 ALTER TABLE）时会卡住或失败，导致备份中断或不一致。
- 生产环境必须加
--lock-tables=false，否则 MyISAM 表会被锁死，影响业务 - 若库中混有 MyISAM 表，必须改用
--lock-all-tables，但代价是全局只读窗口——得避开高峰时段执行 - 避免使用
--all-databases：一旦某个库权限不足或损坏，整个备份失败；应拆成单库循环调用mysqldump -B db_name
备份文件加密与权限隔离不可省略
合规检查常卡在“备份是否明文存储”和“谁可读取”。MySQL 自身不加密备份文件，必须由外部机制兜底。
- 用
gpg --symmetric --cipher-algo AES256加密后传输，密钥不得存于同台服务器；解密命令必须带--batch --passphrase-fd 0避免交互 - 备份目录属主必须是独立系统用户（如
backup），禁止mysql或root用户直接读写 - 云对象存储（如 S3）上传时启用服务端加密（
SSE-S3或SSE-KMS），但注意 KMS 密钥策略要显式允许备份脚本角色调用Decrypt
保留策略落地依赖元数据跟踪而非文件名
靠 ls -t | head -n7 删旧备份？文件名可能被篡改，时间戳可能不准，审计时直接被否。
- 每次备份成功后，必须写入一行到独立元数据表（如
backup_meta），字段含：backup_id、start_time、end_time、file_path、binlog_pos、checksum - 清理脚本必须查该表，按
end_time排序并保留最近 N 天+最近 M 次，再反向删除——避免因某次失败导致连续空档 - 所有备份操作需打日志到专用文件（如
/var/log/mysql/backup.log），每行带date +%s时间戳，便于与监控系统对齐
真正难的不是配参数，而是让每一次备份行为都可追溯、可验证、可对齐审计项。文件删了还能补，元数据断了就真说不清了。
