跨机房备份必须分离执行“生成→传输→验证”三阶段SHA256校验，且高安全场景需用GPG detached-signature防篡改；rsync --checksum不校验传输过程，无法发现网络抖动导致的静默损坏。
跨机房备份传输必须加校验，否则网络抖动导致的静默损坏无法被发现——SHA256是底线，GPG签名是生产级标配。
为什么rsync + --checksum 不足以应对跨机房抖动
rsync默认用文件大小和修改时间判断是否跳过同步，--checksum虽能逐块比对，但它只在校验本地源文件与远程目标文件的块哈希，不验证传输过程是否出错。当网络中间设备（如防火墙、负载均衡）发生字节篡改或截断时，rsync可能误判“已同步”，实际文件已损坏。
- 实测案例：某金融客户在跨省专线中遭遇TCP重传丢包，rsync声称同步完成，但
mysqldump恢复时报错ERROR 1034 (HY000): Index for table 'xxx' is corrupt - 根本原因：rsync未校验原始数据流完整性，仅依赖最终落地文件状态
- 正确做法：先生成校验值，再传输，最后独立验证——三步不可合并
备份文件传输后必须独立执行 SHA256 校验
校验不能嵌在传输命令里，必须分离为“生成→传输→验证”三阶段，且校验文件本身需单独传输或带签名。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 生成阶段（源机）：
sha256sum backup_20261105.sql > backup_20261105.sql.sha256 - 传输阶段（建议用
scp -o ConnectTimeout=10 -o ServerAliveInterval=30）：scp backup_20261105.sql backup_20261105.sql.sha256 user@dst:/backup/ - 验证阶段（目标机）：
sha256sum -c backup_20261105.sql.sha256，输出backup_20261105.sql: OK才算通过 - 关键细节：校验命令必须指定
.sha256文件路径，不能只写sha256sum backup_20261105.sql——后者是重新计算，失去比对意义
高安全场景下必须启用 GPG 签名防篡改
SHA256只能防意外损坏，无法防恶意篡改或中间人替换。跨机房备份若涉及第三方网络或托管环境，GPG签名是强制要求。
- 签名前先导入可信公钥：
gpg --import db-backup-signing-key.pub - 生成签名（源机）：
gpg --default-key "backup@company.com" --detach-sign backup_20261105.sql→ 输出backup_20261105.sql.sig - 验证签名（目标机）：
gpg --verify backup_20261105.sql.sig backup_20261105.sql，必须看到Good signature from "backup@company.com" - 注意：不要用
--clearsign，它会改变原文件内容；--detach-sign保持原文件纯净，仅多一个.sig文件
真正容易被忽略的是校验时机——很多脚本把sha256sum -c放在scp命令后面，却没处理scp因超时失败但返回0的情况。务必用set -e并显式检查scp退出码，否则校验永远跑不到。
