选 aes-256-cbc 更稳妥。它兼容性好，自 OpenSSL 0.9.8 起稳定支持；需显式指定 -md sha256、-pbkdf2 -iter 100000、-salt，并交互输入密码或用权限为 600 的密钥文件，避免明文传参和落盘明文；解密失败多因参数不一致，须严格匹配加密选项；验证需解密后检查头部及实际还原测试。
MySQL备份后用OpenSSL加密，选aes-256-cbc还是aes-256-gcm
选 aes-256-cbc 更稳妥。虽然 aes-256-gcm 支持认证加密（防篡改），但 MySQL 备份文件通常不涉及实时校验需求，且 gcm 模式在旧版 OpenSSL（如 1.0.2）中不支持，容易在生产环境触发 unsupported cipher 错误。
实操建议：
-
aes-256-cbc兼容性好，从 OpenSSL 0.9.8 起就稳定支持 - 必须显式指定
-md sha256（默认是 md5，已被认为不够安全） - 务必加
-pbkdf2 -iter 100000提升密钥派生强度，避免暴力破解 - 别依赖
-pass pass:xxx明文传参——会被ps或 shell history 泄露
mysqldump + OpenSSL 一行命令加密备份的正确写法
直接管道传递，避免落盘明文。错误做法是先 mysqldump > backup.sql 再加密，中间文件可能被未授权读取。
正确命令示例：
mysqldump -u root -p'secret' --all-databases | openssl enc -aes-256-cbc -pbkdf2 -iter 100000 -md sha256 -salt -out backup.sql.enc
注意点：
-
-salt必须加，否则相同密码每次生成相同密钥，失去随机性 - 密码由 OpenSSL 交互式提示输入（
enter aes-256-cbc encryption password），不暴露在命令行里 - 如果要用脚本自动化，改用
-pass file:/path/to/keyfile，且确保keyfile权限为600 - 别省略
-out，否则加密结果会输出到终端，可能被截断或乱码
解密时提示 bad decrypt 或 key derivation failed 怎么办
90% 是加密和解密参数不一致。OpenSSL 不报具体哪项错，只笼统提示失败。
高频原因：
- 加密用了
-pbkdf2，解密时漏了——必须两边都带 - 加密指定了
-iter 100000，解密没指定或数值不同 - 加密用了
-md sha256，解密时没写或写成-md sha1 - 备份文件被意外截断（比如磁盘满、管道中断），
openssl enc -d会直接报bad decrypt，而非文件损坏提示
验证是否完整：用 openssl enc -d -aes-256-cbc -pbkdf2 -iter 100000 -md sha256 -in backup.sql.enc -p | head -n 5，能打印出 key=... 和前几行解密内容才算通路跑通。
备份加密后如何验证可恢复性
加密不是目的，能还原才是关键。很多人加密完就归档，等真要恢复时才发现密钥记错、参数对不上、或压缩层嵌套出问题。
最小闭环验证步骤：
- 用
openssl enc -d解密到临时文件，检查head -n 1是否为-- MySQL dump开头 - 挑一个非核心库做快速还原：
mysql -u root -e "CREATE DATABASE test_restore;"，再mysql -u root test_restore - 别跳过
mysqlcheck -u root --all-databases --check，有些加密/解密过程会悄悄损坏 UTF-8 多字节字符（尤其含 emoji 或中文注释时） - 如果备份用了
--compress或额外 gzip，必须先解压再解密，顺序反了会一直报错
真正麻烦的是密钥管理——加密本身简单，但把密码存在哪、谁有权看、轮换时怎么通知所有运维，这些环节比 OpenSSL 命令难得多。
