备份频率取决于数据变更速度和恢复点目标（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 路径。
