最稳妥的备份加密方式是 mysqldump 与 openssl 或 7z 通过管道实时加密，避免明文落地；须禁用密码硬编码、启用密钥管理与定期解密验证。
用 mysqldump + openssl 管道加密，不落地明文
导出即加密是最稳妥的做法——文件从没以明文形式存在磁盘上，自然规避了临时文件被窃取或误删的风险。
常见错误现象：mysqldump -u root -p mydb > backup.sql && openssl enc -aes-256-cbc -in backup.sql -out backup.sql.enc 这种两步写法，会在中间生成未加密的 backup.sql，只要有人能访问备份目录，就可能拿到它。
- 正确做法是走管道：
mysqldump -u root -p'yourpass' mydb | openssl enc -aes-256-cbc -out backup_$(date +%F).sql.enc - 密码由
openssl交互式提示输入，不会出现在命令行历史里（避免ps aux或 shell history 泄露） - 解密时必须用相同算法和密码：
openssl enc -d -aes-256-cbc -in backup_2026-03-16.sql.enc | mysql -u root -p newdb - 注意：MySQL 8.0+ 默认禁用
local_infile，若后续要用LOAD DATA INFILE恢复，得在连接时加--local-infile=1并确认服务端已启用
压缩包加密码：用 7z 而不是 zip，防文件名泄露
zip 的传统加密只加密文件内容，不加密文件名和目录结构——攻击者即使没密码，也能看到压缩包里有哪些文件、路径多深、甚至猜出数据库名或时间戳。
而 7z（7-Zip）默认用 AES-256 加密整个归档，包括文件名和元数据，更可靠。
- 加密打包命令：
mysqldump -u root -p'pass' mydb | 7z a -p -mem=AES256 -si backup_$(date +%F).7z -
-p表示启用密码（交互式输入），-mem=AES256强制使用强加密模式（zip默认是弱的 ZipCrypto） -
-si表示从 stdin 读取数据，避免生成中间 SQL 文件 - 解压时需完整输入密码，且不支持“仅查看文件列表”——这是安全代价，也是验证点
Shell 脚本自动备份加密：别让密码硬编码进脚本
自动化是刚需，但把数据库密码或加密口令写死在脚本里，等于把钥匙贴在锁头上。
典型错误：mysqldump -u root -p'mypass' db | openssl ... ——该命令会留在 ps 输出和 bash history 中；脚本本身也可能被误传到 Git 或共享目录。
- 数据库密码应通过
~/.my.cnf配置文件管理，并设权限chmod 600 ~/.my.cnf - 加密密码建议用环境变量传入：
echo "$ENCRYPT_PASS" | openssl enc -aes-256-cbc -pbkdf2 -salt -in /dev/stdin -out backup.enc - 或者改用
gpg+ 公钥加密：mysqldump db | gpg --encrypt --recipient 'backup@company.com' > backup.gpg，私钥离线保管，无需每次输密码 - 脚本末尾务必加
rm -f /tmp/backup.*类清理逻辑——哪怕用了管道，某些异常中断仍可能残留临时文件
云环境或长期归档：别只靠压缩密码，要分层控制
一个带密码的 .7z 文件发给同事，他解压后得到明文 SQL，再转发、上传网盘、存桌面……密码保护就彻底失效了。
真正需要的是「加密 + 权限 + 生命周期」组合：比如云对象存储（如 AWS S3、阿里云 OSS）开启服务端加密（SSE-KMS），再配合 IAM 策略限制谁能在什么时间下载；本地归档则用 gpg 加密后，把公钥分发给可信接收方，私钥绝不离开安全设备。
- 单纯依赖压缩包密码，本质是“防盗门装在纸糊墙上”——它防不了内部人员、也防不了后续流转
- 如果备份要保留 3 年以上，优先选
gpg（OpenPGP 标准）而非openssl enc，前者有密钥吊销、子密钥轮换等机制，后者纯靠密码，丢了就永远没了 - 所有加密操作完成后，务必手动测试一次解密还原流程——很多团队备份多年从没验证过，直到真要恢复才发现密码记错或算法不兼容
