备份文件必须加密存储且传输，使用gpg或openssl加盐派生密钥，禁用弱密码和明文传输，定期验证解密并记录日志。
备份文件本身不加密，等于裸奔
数据库导出的 .sql 文件默认是明文——哪怕你用 mysqldump 加了 --single-transaction 或 --routines，内容照样可直接用文本编辑器打开。攻击者只要拿到备份文件，就等于拿到了全量数据。加密必须发生在写入磁盘前，不能靠“藏路径”或“改后缀”糊弄。
- 别依赖文件系统权限（
chmod 600）代替加密：权限失控、误拷贝、临时目录泄露都会让文件暴露 - 别用弱密码或硬编码密钥：比如
openssl enc -aes-256-cbc -pass pass:123456这种写法，密钥会留在 shell 历史和进程列表里 - 真正有效的加密必须带盐（salt）和密钥派生（如 PBKDF2），且密码/密钥不落地
用 openssl + gpg 分场景选对工具
openssl 和 gpg 都能加密，但适用场景不同。选错会导致解密失败、自动化脚本卡死，或者密钥管理混乱。
- 用
gpg --symmetric --cipher-algo AES256：适合人工参与少、需长期归档的备份。它默认加 salt，支持 passphrase 缓存（gpg-agent），且解密时能自动识别算法 - 用
openssl enc -aes-256-cbc -pbkdf2 -iter 100000：适合嵌入到 shell 脚本中自动执行，但必须显式指定-salt（否则默认不加），且-iter值太低（如默认 10000）易被暴力破解 - 避免混用：比如用
openssl加密的文件，别指望gpg -d能解；反之亦然
示例（安全的自动备份片段）：
mysqldump -u root -p$DB_PASS mydb | \ gpg --symmetric --cipher-algo AES256 --compress-algo 1 --armor -o backup_$(date +%F).sql.gpg
备份传输过程比存储更危险
很多团队只关注备份文件落盘加密，却在 scp/rsync 上传时用明文协议传 .sql.gpg。其实中间节点（跳板机、代理、NAS）可能缓存未加密副本，或被 MITM 截获正在传输的密文流（虽难解密，但会暴露备份频率、大小、时间等元信息）。
- 强制走
rsync -e "ssh -o StrictHostKeyChecking=yes"，禁用弱 SSH 协议（关闭 ssh-dss、rsa1） - 别把加密备份推到公共云盘或共享网盘：它们的客户端常驻内存，可能抓取解密后的临时文件
- 如果必须用对象存储（如 S3），启用服务端加密（
SSE-S3或SSE-KMS）只是基础，仍要确保上传前已用gpg或openssl做客户端加密——双重加密不是过度，是防止单点失效
解密流程必须可验证、不可绕过
最常被忽略的一点：没设计解密验证环节。备份加密了，但没人定期试还原，直到真出事才发现 gpg 版本升级后默认 cipher 变了，或 openssl 的 -pbkdf2 参数在旧系统不支持，导致备份变“数字废片”。
- 每周自动跑一次解密+校验：用
gpg --decrypt backup_*.sql.gpg | sha256sum对比原始 dump 的 hash（注意别把原始明文留太久） - 所有解密操作必须记录日志（含时间、用户、退出码），禁止用
gpg -d file.gpg > /dev/stdout这类无重定向的命令——输出若被截断或终端异常，根本不知道哪步失败 - 密钥或密码不能只存在一个人脑里：用
pass或age管理加密口令，而非共享文档或邮件
复杂点不在技术，而在每次备份后是否真有人看一眼解密日志里有没有 gpg: decryption failed: Bad session key 这类报错——它往往意味着密钥轮换没同步，或者某台机器的 gpg 配置被覆盖了。
