必须用SSH加密通道+文件级加密双层防护，因scp/rsync仅加密传输过程，备份文件落地后以明文或仅压缩形式存在，易被入侵、挂载或权限误配导致数据泄露；gzip非加密，gpg或openssl加密才真正保护静态文件。
公网传输 MySQL 大体积备份压缩包，必须用 SSH 加密通道 + 文件级加密双层防护，单靠 scp 或 rsync 不够安全。
为什么不能只用 scp/rsync 传 .sql.gz？
scp 和 rsync -e ssh 确实加密了传输过程，但它们只保护「传输中」的数据。一旦文件落到目标服务器磁盘上，就以明文（或仅压缩）形式存在——如果服务器被入侵、磁盘被挂载、或备份目录权限配置错误，.sql.gz 里的表结构、字段名、甚至脱敏不彻底的业务数据（如手机号前缀、邮箱域名）都可能直接暴露。mysqldump 输出的 SQL 文件本质是纯文本，gzip 压缩不等于加密，gunzip 一下就能读。
必须加一层文件级加密：gpg 或 openssl
推荐优先用 gpg，尤其团队协作场景；若目标端无 GPG 环境，再选 openssl。关键不是“能不能解”，而是“谁有权限解”。
-
gpg --encrypt --recipient your-backup-key@company.com backup.sql.gz：用公钥加密，只有持有对应私钥的恢复机器能解；导出前确保已gpg --import public.key -
openssl enc -aes-256-cbc -pbkdf2 -iter 1000000 -salt -in backup.sql.gz -out backup.sql.gz.enc：密码加密，注意-pbkdf2 -iter 1000000必须显式指定，否则老版本默认弱哈希，新版本可能报错 - 别用
openssl -k "pass"这种明文密码写法，它会降级为 MD5+8字节 salt，暴力破解成本极低
传输时避免落盘，减少攻击面
大文件（>10GB）别先 gzip 再 scp，中间文件多一次磁盘写入，就多一次被窃取或篡改机会。直接管道流式处理：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
mysqldump -u root -p --single-transaction mydb | gzip | gpg --encrypt --recipient backup@prod.com | ssh user@remote-host "cat > /backup/mydb_$(date +%Y%m%d).sql.gz.gpg"
这行命令完成四件事：dump → 压缩 → GPG 加密 → 通过 SSH 流式写入远端，全程无本地临时文件。注意远端目录需提前创建且权限严格（chmod 700 /backup），user 不应是 root，而应是专用备份账号。
校验和权限比压缩率更重要
传输完成后，别只比对文件大小。必须做两件事：
- 在源端生成 SHA256 校验值：
sha256sum backup.sql.gz.gpg > backup.sql.gz.gpg.sha256，连同加密文件一起传过去 - 在目标端执行
sha256sum -c backup.sql.gz.gpg.sha256，确认传输未损坏 - 恢复前先测试解密通路：
gpg --decrypt backup.sql.gz.gpg | head -20，看是否输出合法 SQL 头（如-- MySQL dump），而不是乱码或gpg: decryption failed: No secret key
真正容易被忽略的是：GPG 私钥的存储方式、SSH 密钥的权限（chmod 600 ~/.ssh/id_rsa）、以及远端 /backup 目录是否被其他用户可读——这些细节不出问题时没人检查，一出就是数据泄露。
