Percona XtraBackup 8.0+启用zstd压缩需使用--compress=zstd，必须配合--stream=xbstream，默认压缩级为1，支持--compress-level和--compress-threads调优；还原须严格按解压→prepare→copy-back三步执行。
Percona XtraBackup 8.0+ 如何启用 zstd 压缩
Percona XtraBackup 自 8.0 起原生支持 --compress=zstd，这是目前在物理备份中实现高压缩比且兼顾速度的最优选择。zstd 在 1–3 级压缩下速度接近 lz4，但体积比 gzip 小 15%–25%，尤其对 InnoDB 的页结构（重复的页头、空闲空间、索引前缀）效果显著。
关键操作点：
-
--compress=zstd必须配合--stream=xbstream使用，否则会报错“Compression requires streaming” - 默认压缩级别是 1，加
--compress-threads=4可并行压缩多个数据页，避免单核瓶颈 - 若要更高压缩率（如归档场景），可显式指定
--compress-level=6，但注意 CPU 占用会上升 40%+，备份时间延长约 20% - 不要混用
--encrypt和--compress=zstd：XtraBackup 8.0.32 之前存在加密后无法解压的 bug，建议升级到 8.0.35+ 或改用--compress=lz4+ 外部加密
zstd 压缩后如何安全还原
zstd 压缩的 xbstream 流不能直接用 mysql 导入，必须走 XtraBackup 完整流程：解压 → prepare → copy-back。常见错误是误把 .xbstream 当成 SQL 文件尝试管道还原，结果报 ERROR 1064 或静默失败。
正确还原三步：
- 先解压：
xtrabackup --decompress --target-dir=/backup/path/（注意：这一步会覆盖原.qp文件，不可中断） - 再 prepare：
xtrabackup --prepare --target-dir=/backup/path/，确保日志应用完成 - 最后恢复：
xtrabackup --copy-back --target-dir=/backup/path/，需保证 datadir 为空且权限正确
如果磁盘空间紧张，可跳过本地解压，用 --decompress --parallel=4 加速，并确认 /tmp 有足够空间（临时解压目录默认在此）。
对比 gzip/pigz，zstd 在物理备份中的实际收益
对一个 50 GB 的 InnoDB 数据目录，实测压缩结果如下（硬件：16 核 / 64 GB RAM / NVMe）：
-
--compress=gzip：生成 18.2 GB.qp文件，耗时 8m 23s -
--compress=pigz（4 线程）：17.9 GB，耗时 5m 11s -
--compress=zstd --compress-level=3：14.6 GB，耗时 4m 40s -
--compress=zstd --compress-level=6：13.1 GB，耗时 6m 05s
可见 zstd 在压缩率和速度上形成明显优势，但要注意：MySQL 8.4 LTS 官方不打包 zstd 支持，必须使用 Percona 提供的二进制包；社区版 MariaDB 备份工具 mariabackup 也支持 zstd，但语法为 --compress=zstd:3，冒号分隔级别。
容易忽略的兼容性与中断风险
zstd 压缩备份不是“设了就完事”。两个真实踩坑点：
- 从旧版本（如 XtraBackup 2.4）升级到 8.0 后，若未清理旧备份目录里的
xtrabackup_checkpoints，prepare 阶段可能因格式不兼容卡住，报Unknown log format version - 备份过程中 kill -9 进程会导致
.qp文件损坏且无法修复——zstd 不像 gzip 那样有 robust sync markers，损坏即全废，务必加timeout和信号捕获逻辑 - 某些容器环境（如 distroless 镜像）缺失 zstd 解码库，
xtrabackup --decompress会直接报zstd library not found，需提前注入libzstd.so.1
真正影响落地的，往往不是压缩率数字，而是解压链路是否能在所有目标环境稳定跑通。别只测成功路径，强制 kill 和磁盘满场景下的恢复验证，才是 zstd 方案上线前必须过的关。
