MySQL 8.0+ 原生命令 mysqldump 和 mysqlpump 不支持备份文件加密，必须通过管道结合 openssl enc（启用 -pbkdf2、-iter、-salt）流式加密，或使用企业版 MySQL Enterprise Backup；明文落盘、硬编码密码、参数不匹配是常见风险点。
MySQL 8.0+ 备份加密必须用 mysqlpump 或 mysqldump 加密插件？错，原生命令不支持
mysql 原生的 mysqldump 和 mysqlpump 都不支持备份文件加密输出——它们生成的 sql 文件是明文，哪怕加了 --ssl-mode=required，也只是加密客户端连接，和备份文件本身无关。
真正能落地的加密路径只有两条：
-
mysqldump+ 系统级加密命令（如gpg、openssl），最常用、兼容性最好 - 启用 MySQL 企业版的
keyring_encryption插件 +BACKUP DATABASE（仅限 MySQL Enterprise Backup），但该功能不适用于社区版
别被文档里“encryption”字眼误导：keyring_file 或 keyring_encrypted_file 是管表空间加密（ENCRYPTION='Y'）的，跟 mysqldump 输出文件毫无关系。
用 openssl 流式加密备份文件，避免中间落盘明文
常见错误是先 mysqldump > backup.sql，再 openssl enc -aes-256-cbc -in backup.sql -out backup.sql.enc——这会在磁盘上短暂留下未加密的 backup.sql，勒索软件完全可能趁机扫描并加密它。
正确做法是管道直传，全程不写明文到磁盘：
mysqldump --single-transaction --routines --triggers mydb | \ openssl enc -aes-256-cbc -pbkdf2 -iter 1000000 -salt -out backup.sql.enc
关键参数说明：
-
-pbkdf2：必须启用，否则默认用过时的evp密钥派生，安全性弱 -
-iter 1000000：迭代次数越高越抗暴力破解，MySQL 官方建议 ≥100000；低于 10000 就形同虚设 -
-salt：必须加，防止彩虹表攻击；漏掉它，相同密码每次生成的密文都一样 - 密码不要存脚本里，用
openssl交互式输入，或通过read -s+ 环境变量间接传入
恢复时解密失败报 bad decrypt？大概率是密码或参数不匹配
这个错误不是加密坏了，而是解密端用的参数和加密时对不上。最常踩的坑有三个：
- 加密用了
-pbkdf2，恢复时却漏写，直接用openssl enc -d -aes-256-cbc -in backup.sql.enc→ 必报错 - 加密指定了
-iter，恢复时没指定，或数值不同 → 解密出乱码，mysql导入时报语法错误，而非明确提示 - 备份文件被意外截断（比如磁盘满、管道中断），
openssl仍会输出部分解密内容，但后续 SQL 执行必然失败
验证是否完整可用，恢复前先试解密头几行：
openssl enc -d -aes-256-cbc -pbkdf2 -iter 1000000 -in backup.sql.enc 2>/dev/null | head -20
能看到正常的 CREATE TABLE 和 INSERT 就基本没问题。
自动备份脚本里硬编码密码？别碰，用 openssl 的 -pass env:VAR 更安全
把密码写进 crontab 或 shell 脚本，等于把钥匙贴在保险柜上。进程列表里 ps aux 一眼就能看到完整命令行，包括密码参数。
安全做法是用环境变量传参，并限制变量作用域：
- 备份前执行
export BACKUP_PASS="your-strong-passphrase" - 加密命令改用
openssl enc ... -pass env:BACKUP_PASS - 脚本末尾加
unset BACKUP_PASS，避免泄露给子进程 - 确保脚本权限为
600，且不记录到 bash history（开头加空格，或设HISTCONTROL=ignorespace）
更进一步：密码存在 systemd 的 EnvironmentFile 或 HashiCorp Vault，但对中小团队来说，环境变量已够用——关键是别图省事写死。
加密不是一劳永逸的事。密钥管理、迭代参数、管道安全、权限控制，每一步松动都可能让整条链失效。尤其注意 openssl 版本差异：1.1.1 和 3.0 对 -pbkdf2 默认哈希算法处理不同，跨机器恢复前务必验证兼容性。
