xtrabackup加密必须在备份时显式启用，漏配--encrypt或密钥则无法事后补救；它边读边加密边写入，不落地明文，且密钥须独立安全保管。
XtraBackup 加密必须在备份命令中显式启用，漏掉 --encrypt 或密钥参数，备份集就永远无法解密——没有“事后补救”这回事。
加密必须和备份同时发生，不能事后加
很多人试过先跑 xtrabackup --backup，再用 xbcrypt 手动加密文件，结果发现：还原时 xtrabackup --decrypt 报错或静默失败。这是因为 xtrabackup 的加密流程不是简单套壳，它在拷贝 .ibd 页时边读、边加密、边写入，整个过程不落地明文数据。一旦跳过 --encrypt，备份目录里全是未加密的原始页，xbcrypt 处理的是文件层，而 xtrabackup 后续的 --prepare 和 --copy-back 流程默认只认它自己加密/解密过的格式。
- 逻辑备份（如
mysqldump | openssl enc）可以事后流式加密，但物理备份不行 -
--encrypt参数必须和--backup出现在同一条命令里，拆成两步就失效 - 加密后的备份目录里，
.xbcrypt文件是元信息，.qp（ZSTD压缩后）或原.ibd文件才是加密主体，别误删
密钥管理是最大风险点，不是算法
你选 AES256 没问题，但若密钥丢了、放错了位置、或权限太松，整个备份等于白做。xtrabackup 不验证密钥是否可用，也不检查 keyring 插件状态——它只管把字节流加密写进去，报错一定发生在还原启动 mysqld 阶段。
- 绝对不要用
--encrypt-key="mysecret123"直接写在命令行里，ps 能看见，bash history 会留存 - 必须用
--encrypt-key-file=/etc/mysql/backup.key，且该文件权限设为600，属主为运行 xtrabackup 的用户（通常是mysql） - 密钥文件内容必须是纯二进制或 32 字节 base64 文本（对应 AES256），不能带换行、BOM、注释
- 密钥和还原目标实例无关——它只用于解密备份文件本身；MySQL 服务端的
keyring_file是另一套体系，仅影响加密表空间的运行时解密
加密+压缩组合命令容易踩的坑
压缩和加密虽然都支持多线程，但它们用的是独立线程池，参数不互通。常见错误是只设了 --compress-threads=4，却忘了配 --encrypt-threads，导致加密成为瓶颈，整体速度反而比单线程还慢。
- 必须显式指定两者：
--compress-threads=2 --encrypt-threads=2（建议不超过 CPU 核数一半，留资源给 IO） - 压缩算法优先用
--compress=zstd（xtrabackup 8.0 默认），别用gzip——它不支持多线程，且压缩率不如 ZSTD -
--defaults-file=/etc/my.cnf必须放在命令最前面，否则 xtrabackup 可能读不到datadir或 socket 路径，导致连接失败或备份错目录 - 加密备份后不能直接
--prepare，必须先--decrypt（或加--decompress，如果用了压缩）
还原时真正卡住的地方不是解密命令
执行 xtrabackup --decrypt --encrypt-key-file=... --target-dir=... 成功，不代表就能恢复。接下来 --prepare 会校验页校验和，而加密页的校验和跟明文不同；如果跳过 --decrypt 就直接 --prepare，会报 page checksum mismatch 并中断。
- 标准流程是：
--decrypt→--decompress（如有）→--prepare→--copy-back -
--decrypt和--decompress可以合并执行：xtrabackup --decrypt=AES256 --decompress --encrypt-key-file=... --target-dir=... - 还原到新实例前，确保目标 MySQL 已加载
keyring_file插件（如果原库用了加密表空间），否则即使备份文件解密成功，mysqld 启动时仍会因无法解密.ibd报Cannot decrypt tablespace
最常被忽略的一点：加密密钥文件的生命周期必须独立于备份文件。备份可存 OSS、NFS、磁带，但密钥必须存在 Vault、KMS 或至少另一块物理隔离的磁盘上——同盘备份+密钥，等于没加密。
