备份频率需根据数据变更速度和rpo确定，全量+binlog增量是mysql常用方案，percona xtrabackup适合大库，备份后必须验证恢复能力。
备份频率取决于数据变更速度和恢复点目标（RPO）
不是“每天一次”就安全，也不是“每分钟一次”就合理。关键看业务能容忍丢失多少分钟的数据。比如电商订单库，若 RPO 是 5 分钟，就必须确保任意时刻最多只丢失 5 分钟的写入；而内部报表库可能允许小时级丢失，备份间隔拉长到 4–6 小时也无妨。
实际判断时，先查 SHOW MASTER STATUS 中的 File 和 Position，再结合 SHOW BINARY LOGS 看 binlog 增长速度——如果 10 分钟就生成一个 100MB 的 binlog 文件，说明写入密集，单纯靠全量备份风险极高。
全量备份 + binlog 增量是 MySQL 最常用且可控的组合
全量备份用 mysqldump 或 mysqlpump（推荐后者，支持并行和更细粒度过滤），但必须加 --single-transaction（InnoDB）或 --lock-all-tables（MyISAM），否则备份期间写入会导致不一致。
binlog 必须开启（log-bin=ON），且建议设置 expire_logs_days=7 或 binlog_expire_logs_seconds=604800，避免磁盘被撑爆。恢复时顺序是：最近一次全量备份 → 按 mysqlbinlog 解析出对应时间段的 binlog → 重放。
- 全量备份建议在低峰期执行，配合
--skip-lock-tables仅对非事务表生效，别误以为它能跳过所有锁 - 不要把
mysqldump输出直接 gzip 后扔到同一台机器，磁盘故障时备份和生产库一起丢 - 用
mysqlbinlog --base64-output=DECODE-ROWS -v查看某段 binlog 是否含 DML，避免误删或重复应用
Percona XtraBackup 适合大库，但配置稍复杂
当单库超 50GB 或备份窗口紧张时，xtrabackup 的热备能力就不可替代。它不锁表、支持流式压缩（--stream=xbstream）、可指定 --incremental-basedir 做增量备份。
但要注意：xtrabackup 版本必须与 MySQL 主版本严格匹配（如 MySQL 8.0.33 要用 xtrabackup 8.0.33），否则 apply-log 阶段会报 Unknown redo log format；另外，它默认不备份 binlog，需单独配置 rsync 或 mysqlbinlog --read-from-remote-server 拉取。
备份验证比备份本身更容易被忽略
90% 的备份失效发生在“以为能恢复”的错觉里。每周至少抽一份备份做最小化还原测试：解压/解包 → innobackupex --apply-log（或 xtrabackup --prepare）→ 启动临时实例 → 连上去 SELECT COUNT(*) 几张核心表。
不验证的后果不是“恢复慢”，而是“恢复失败后才发现备份文件损坏或权限不对”。尤其注意 SELinux 或 AppArmor 限制下，xtrabackup 可能无法读取 /var/lib/mysql 下某些 socket 或 tmpdir 路径。
