优先选percona xtrabackup：mysql单库超50gb后，mysqldump因单线程、锁表、恢复慢等缺陷不应再作主力；xtrabackup支持物理热备、增量、zstd压缩，是tb级生产环境事实标准。
优先选 Percona XtraBackup，不是“可选”，是生产级刚需
MySQL 单库超 50GB 后，mysqldump 就不该再作为主力备份工具——它本质是 SQL 导出，单线程、内存吃紧、锁风险高、恢复慢。而 Percona XtraBackup 是专为 InnoDB 设计的物理热备工具，不锁表、支持增量、能流式压缩传输，TB 级环境的事实标准。
- 全量备份必须加
--compress=zstd（不是 gzip）：Zstandard 压缩率接近 gzip，但解压速度快 3–5 倍，直接影响恢复时间 - 增量备份前务必确认
--incremental-basedir指向的是已成功--prepare过的全量目录，否则合并失败且无明确报错 - 别跳过
--apply-log-only：合并多个增量时漏掉这个参数，会导致事务状态混乱，恢复后数据不一致 - 恢复前必须停 MySQL、清空
datadir、用--copy-back而非直接 mv：权限和文件属主错位是恢复后无法启动的最常见原因
用 mysqldump？那就必须分表 + 并行 + 流式压缩
不是不能用 mysqldump，而是不能“裸用”。它只适合百 GB 级以下、需跨版本迁移、或仅导出部分表的场景。关键在控制粒度和资源消耗。
- 禁用
--extended-insert（即加--skip-extended-insert）：避免单行 INSERT 包含上万值，导入时内存溢出或超时 - 按表并行导出：用 shell 脚本遍历
SHOW tableS结果，每 2–4 张表起一个mysqldump进程，避免单点卡死 - 强制流式压缩：
mysqldump ... | pigz -p 4 > db1_$(date +%F).sql.gz，pigz利用多核，比gzip快 2–3 倍 - 跳过日志类表：
--ignore-table=db1.audit_log --ignore-table=db1.tmp_stats，这类表通常不参与恢复，却占体积和时间
备份策略不校验 = 没备份
大库备份耗时长、环节多，一次 prepare 失败、一个压缩损坏、一个 binlog 位点偏移，都会让备份变“废片”。自动化校验不是锦上添花，是底线。
- 物理备份后立即跑：
xtrabackup --prepare --target-dir=/backup/full_2026-01-28 --dry-run，验证回滚/前滚逻辑是否通 - 逻辑备份抽样导入：从
.sql.gz随机解压一张中等大小的表（如gzip -cd backup.sql.gz | sed -n '/^CREATE TABLE `orders`/,/^CREATE TABLE `/p' | mysql -D test），查count(*)和CHECKSUM TABLE对比源库 - 所有备份必须带时间戳+校验和：
sha256sum backup_full_2026-01-28.xbstream > backup_full_2026-01-28.sha256，上传前本地验证，异地存储后再次验证
压缩算法和存储路径选错，等于白备份
备份体积动辄上百 GB，压缩效率和存储介质直接决定 RTO（恢复时间目标）。别让硬盘 IO 或网络带宽成为瓶颈。
-
--compress=zstd比--compress=zlib节省约 15% 空间，且解压快 2.7 倍；--compress=lz4更快但压缩率低，适合 SSD 本地备份 - 备份目标路径别放在系统盘或 MySQL 数据盘同磁盘：IO 争抢会导致备份期间 QPS 下跌甚至超时
- 异地存储必须走对象存储（如 OSS/S3）而非 rsync 到另一台 ECS：前者支持断点续传、服务端加密、生命周期自动清理；后者网络中断就全功尽弃
- 保留策略要刚性落地：例如“最近 7 天全量 + 每日 1 个增量”，用脚本自动
find /backup -name "inc_*" -mtime +7 -delete，别靠人工删
备份最大的坑不在命令写错，而在“以为自己备份成功了”。物理备份没 --prepare，逻辑备份没抽样验证，压缩包没校验和，异地没真正上传完成——这些都不会报错，但故障时全部失效。