用管道加密避免明文落地，这是生产环境的底线
直接
mysqldump -u root -p mydb > backup.sql生成明文 SQL 文件，在生产环境等于把敏感字段（如
user.email、
payment.card_number）裸奔发到磁盘上。哪怕立刻加密码，中间那几秒的
backup.sql仍可能被进程列表、审计日志或临时文件扫描捕获。 必须用管道：导出、压缩、加密三步串流完成，不落地明文 推荐组合：
mysqldump --single-transaction mydb | gzip | openssl enc -aes-256-cbc -pbkdf2 -iter 1000000 -salt -out mydb.sql.gz.enc
--single-transaction对 InnoDB 表保证一致性；MyISAM 必须换
--lock-all-tables，否则备份可能错乱 别省
-salt和
-pbkdf2 -iter 1000000—— 老版本 OpenSSL 默认用 MD5+弱迭代，新旧环境解密会失败
gpg 公钥加密更适合多机协作，但私钥管理是关键
如果你有固定备份服务器和多个数据库节点，gpg 比 openssl 更适合分发与权限控制：公钥可公开分发，私钥只存于恢复端。但一旦私钥丢失或密码遗忘，备份即永久不可用。
导出公钥：gpg --export -a 'backup@team.com' > public.key，分发给所有 DB 服务器 备份命令：
mysqldump mydb | gpg --encrypt --recipient 'backup@team.com' --cipher-algo AES256 --compress-level 9 > mydb.gpg恢复时若提示输入私钥密码，说明私钥已导入但受 passphrase 保护；不要用
gpg-agent --max-cache-ttl 0永久缓存——生产环境必须每次确认 注意：
--cipher-algo AES256必须显式指定，新版 GnuPG 不再 fallback 到强算法
解密恢复不能写临时文件，否则引入竞态和残留风险
看到
gpg -d backup.sql.gpg > tmp.sql && mysql -u root -p mydb 这类操作要立刻停手。临时文件不仅可能被未授权用户读取，还存在「刚写完还没执行就崩溃」导致数据不一致，或 <code>rm命令失败后明文长期滞留磁盘。 正确做法永远走流式：
gpg --decrypt mydb.gpg | mysql -u root -p mydbopenssl 同理：
openssl enc -d -aes-256-cbc -pbkdf2 -iter 1000000 -in mydb.sql.gz.enc | gunzip | mysql -u root -p mydb禁用
$(cat ...)或
eval执行解密结果——SQL 注入和 shell 注入入口就在这儿 如果遇到
ERROR 1044 (42000)，不是加密问题，大概率是 MySQL 客户端版本（如 5.7）和服务端（如 8.0）协议不匹配，统一升级客户端即可
云数据库别自己折腾，优先启用平台级 TDE 加密
阿里云 RDS、腾讯云 CDB、AWS RDS 等主流云服务都支持备份自动加密（TDE + KMS），开启后所有新增物理/逻辑备份默认加密，密钥由云平台托管，合规性与运维成本远优于自建脚本。
控制台路径一般为：实例管理 → 备份恢复 → 备份加密 → 开启 注意：开启后新备份才加密，历史备份不会补救；关闭后新备份不再加密，旧备份仍保持加密状态 物理备份时间预期延长 20%，日志备份延长 30%——这是加密计算开销的真实代价，压测时需纳入考量 本地自建环境没条件上 KMS？那就守住两条线：密码绝不出现命令行（用~/.my.cnf配置并
chmod 600），备份文件权限设为
600且不放 Web 目录
最常被忽略的其实是密钥生命周期管理：加密用的密码或私钥，比备份文件本身更需要定期轮换、离线存档、权限隔离。一次误删、一次弱口令、一次忘记
-salt参数，都可能让整套备份体系在真正需要时彻底失效。
