必须用管道流式加密，禁止生成明文临时文件；优先选 mysqldump | gpg --encrypt，次选用 openssl enc -aes-256-cbc -pbkdf2 -iter 1000000 -salt；密钥管理比加密本身更关键。
直接上结论：必须用管道流式加密，禁止生成明文临时文件；优先选 mysqldump | gpg --encrypt，次选用 mysqldump | openssl enc -aes-256-cbc -pbkdf2 -iter 1000000 -salt；密钥管理比加密本身更关键。
为什么不能先 dump 再加密？
常见错误是分两步：mysqldump -u root -p db > backup.sql，再 gpg -c backup.sql。中间的 backup.sql 会以明文形式落在磁盘上——哪怕只存在几秒，也可能被 ps、/proc/*/cmdline、审计日志或容器层快照捕获。在共享主机、K8s Pod 或 CI 环境中，这等于主动暴露敏感字段（如 user.phone、payment.token）。
gpg 加密备份怎么写才安全？
用非对称加密（公钥加密）比对称加密更可控，适合团队协作和自动化：
mysqldump --single-transaction mydb | gpg --encrypt --recipient 'backup@company.com' --cipher-algo AES256 --compress-level 9 > mydb_$(date +%F).sql.gpg- 必须提前导入收件人公钥：
gpg --import backup.pub.asc，且gpg --list-keys 'backup@company.com'要显示有效[SC]标识 - 在 cron 或 systemd 中运行时，加
--no-tty并设置GPG_TTY=$(tty)，否则卡住 - 别用
--symmetric+ 密码短语硬编码——密码泄露即全盘失守
openssl 加密要注意哪些兼容性坑？
OpenSSL 1.1.1+ 和 3.x 对参数容忍度不同，老版本默认用弱密钥派生，新旧环境解密失败很常见：
- 必须带
-pbkdf2 -iter 1000000 -salt，缺一不可；不加-salt会导致相同密码每次生成相同密文 - 禁用
-k或-pass pass:xxx：密码会进ps aux和 shell history - 验证解密是否成功，别直接 pipe 给
mysql：openssl enc -d -aes-256-cbc -pbkdf2 -iter 1000000 -in backup.sql.enc | head -n 3，看到-- MySQL dump才算对 - MySQL 8.0.27+ 可用
--dry-run预检：openssl enc -d ... | mysql --dry-run -u root -p mydb
密钥和凭据怎么管才不算裸奔？
加密本身容易，但密钥丢了备份就废，凭据泄露等于白加：
- MySQL 登录密码别写命令行，用
mysql_config_editor set --login-path=backup --user=backup_user --password，自动存到~/.mylogin.cnf（权限强制600） - GPG 私钥密码别设太短，也别用
gpg-agent --max-cache-ttl 0永久缓存——生产环境每次操作都该手动确认 - 备份文件别只放本地；上传 S3 时开服务端加密（SSE-S3），客户端密钥仍由你控制
- 定期实测还原：
gpg --decrypt backup.sql.gpg | mysql -u test -p test_db，不能只验文件是否存在
真正难的不是敲出那条命令，而是确保从 mysqldump 启动那一刻起，敏感数据就没在内存外落地过，且解密密钥永远不在同一台机器上长期驻留。
