mysql备份用openssl二次加密须管道流式执行、禁用明文密码、强制-salt/-pbkdf2/-iter 1000000，避免中间文件落地；解密必须直连mysql stdin，防止shell注入或编码损坏。
直接用 openssl enc 对 MySQL 备份文件做二次加密，核心是避免明文落地、防止密码泄露、确保解密可还原。不推荐先生成 backup.sql 再加密——中间文件可能被日志、进程列表或临时扫描捕获。
为什么不用 gpg 而选 openssl？
gpg 更适合公钥分发和多角色权限控制，但 openssl 在轻量环境（如 Alpine 容器、最小化 CentOS 镜像）里预装率更高；且当备份流程已集成 OpenSSL 工具链（如已有 TLS 证书管理），复用同一套密钥策略更一致。
- 常见错误现象：
openssl enc -aes-256-cbc -in backup.sql -out backup.sql.enc执行后，ps aux可能暴露命令行里的-k参数（如果用了明文密钥） - 别用
-k或-K直接传密钥字符串——必须交互输入或从安全文件读取 - 若脚本中硬编码
-pass pass:xxx，等同于把密码写进历史记录和审计日志 - openssl 1.1.1+ 默认启用
-pbkdf2，但旧版本（如 RHEL7 自带的 1.0.2k）需显式加，否则用的是弱 MD5 密钥派生，跨环境解密会失败
正确加密命令要带哪些参数？
必须包含 -salt、-pbkdf2、-iter 1000000，三者缺一不可。不加 salt 会导致相同密码生成相同密钥；不加 pbkdf2 会退化为单次哈希；迭代次数过低（默认 1 万）易被暴力破解。
- 安全写法（管道流式，无明文落地）：
mysqldump -u root --login-path=prod_db myapp | openssl enc -aes-256-cbc -pbkdf2 -salt -iter 1000000 -out backup_$(date +%F).sql.enc - 若必须处理已有明文文件，用二进制模式读取：
openssl enc -aes-256-cbc -pbkdf2 -salt -iter 1000000 -in backup.sql -out backup.sql.enc - 加
-z可在加密前自动 gzip 压缩（但注意：MySQL dump 含大量重复 SQL 关键字，压缩率高；加密后再压缩无效，所以必须放enc前）
解密还原时最容易出错的三个点
解密不是为了“看内容”，而是为了喂给 mysql 客户端执行。任何中间落盘、shell 注入、字符编码转换都会破坏 SQL 流完整性。
- 禁止：
openssl enc -d -in backup.sql.enc > tmp.sql && mysql -u root -p myapp —— <code>tmp.sql可能残留磁盘、权限失控、或未清理就崩溃 - 禁止：
eval "$(openssl enc -d -in backup.sql.enc)"—— 万一 SQL 里有`date`或$(rm -rf)，直接执行 shell 命令 - 正确做法永远走 stdin：
openssl enc -d -aes-256-cbc -pbkdf2 -iter 1000000 -in backup.sql.enc | mysql -u root --login-path=prod_db myapp - 若遇到
ERROR 1064 (42000)，先验证是否因 BOM 或 UTF-8 签名损坏：head -c 3 backup.sql.enc | hexdump -C看是否含ef bb bf—— openssl 不处理编码，但编辑器误保存可能引入
最常被忽略的是密钥生命周期：openssl 没有密钥管理概念，密码即密钥。一旦遗忘，备份即报废；定期轮换意味着你要同步更新所有备份脚本里的密码提示逻辑，而不是指望“下次再改”。
