云迁移：文件传输策略指南
规划云迁移的文件传输策略。最大限度减少停机时间，确保数据完整性，优化带宽利用。
云迁移文件传输策略取决于三个决策：传输路径（公共互联网、专线还是物理设备），割接模式（一次性、分阶段还是并行运行），以及你信任的完整性校验方式。对于1Gbps链路上的50TB数据，以线速计算纯传输时间约需5天——压缩后更短，线路共享时更长。先规划顺序，再规划工具，并为重试和核对预留20%的余量。
接线前先清点数据集
在选择 AWS DataSync、Azure AzCopy 或 Google Storage Transfer Service 之前，先清点实际数据量。对文件共享运行 du -sh，查询数据库目录获取行数，导出对象存储清单。一个审计过的中型企业以为 NAS 上有8TB数据，把快照和隐藏的 ~$ Office 锁定文件算进去后，实际是34TB。
按三个维度对清单分类：大小、变更频率和合规权重。1MB以下的文件每字节移动速度慢，因为每个对象有固定开销——一个有2亿个小文件的存储桶可能比一个10TB视频文件的存储桶花费更长时间。把热数据（每天变化）与冷数据（PDF 归档、2017年的发票）分开排列。冷数据可提前数周传输；热数据需要"持续同步直到割接"的逻辑。
选择与时间表匹配的传输路径
10TB以下且有不错的光纤链路，TLS 1.3 在线传输通常最优。10-500TB之间，预留带宽或申请 AWS Direct Connect / Azure ExpressRoute，避免占满企业广域网。500TB以上，物理播种优于互联网传输：AWS Snowball Edge 承载80TB，Snowmobile 用集装箱运输PB级数据，Azure Data Box Heavy 存储1PB。
诚实做数学。在1Gbps（持续125MB/s，扣除开销后实际约80MB/s）下，100TB需要约14天不间断传输。如果运维窗口是48小时，链路根本不够——发磁盘。别忘了出口费：100TB数据从旧服务商出去，按每GB 0.09美元计算，仅带宽费约4.5万元人民币。
完整性：信任加校验
每次迁移都需要端对端完整性验证，仅靠传输层 TLS 不够。在源端生成 SHA-256 或 xxHash64 哈希，随数据一同传输，在目标端重新哈希比对。AWS DataSync 默认执行此操作；rsync 加 --checksum 强制执行；rclone 支持 --check-first 和 crypt 后端。
对于合规工作负载，在完整留存期内保留清单——包含路径、字节数和哈希的 CSV 文件。依据《数据安全法》（DSL）对重要数据的完整性要求，迁移过程中的哈希校验日志应作为合规证据留存。一个字节错位可能让医学影像查看器拒绝打开 DICOM 文件。
用增量同步最小化停机时间
一次性大规模割接是睡眠的敌人。提前数周做初始批量复制，然后每晚运行增量同步，直到割接窗口。Rclone（--update --use-server-modtime）、AzCopy（--overwrite=ifSourceNewer）和 Google 的 gsutil rsync -d 通过 mtime 或哈希检测变更文件，只移动差异部分。
数据库需要单独的计划。对于2TB的 PostgreSQL 实例，使用 pg_basebackup 加 WAL 传输；MySQL 则在目标端建立复制并在割接时提升为主库。通过 rsync 同步文件系统增量，可将最终同步时间从数小时缩短到分钟级，通常能装进周六夜间的维护窗口。
带宽整形与分时传输
迁移占满所有广域网带宽会带来糟糕结果——上班前工单就已堆满。积极限速。AzCopy 接受 --cap-mbps，rclone 支持 --bwlimit 50M:100M 区分白天/夜间速率，DataSync 按每小时带宽上限调度任务。合理策略：工作时间用链路的30%，夜间用90%，周末用100%。
在防火墙层也对流量分段。给迁移流量打 DSCP 标记，使 QoS 策略不会让视频会议卡顿。如果通过 MPLS 连接分支机构，考虑 SD-WAN 本地出口，让迁移流量直接出去，而不是绕回总部。
传输中的敏感数据处理
包含个人信息、受保护健康信息或持卡人数据的迁移，需要符合相关标准的加密。TLS 1.3 是基准；暂存时静态文件在上传前用 AES-256-GCM 包裹。依据 PIPL 第38条，将境内个人信息迁移至境外云服务时，须满足通过网信办（CAC）安全评估或订立标准合同之一；境内迁移无此限制但需确保接收方符合同等安全水平。
迁移过程中的临时文件一次性传输（比如顾问导出 Salesforce 表格或数据库管理员移动凭证库），端对端加密工具能将密钥隔离在传输服务商之外。HexaTransfer 适合迁移过程中一次性文件的处理——加密在浏览器端完成，数据不触碰服务器。
割接前演练割接
在子集上演练完整流程。选择一个部门——比如市场部300GB的共享盘——运行完整流程：源端清单、传输、哈希验证、权限映射和应用故障切换。计时每个步骤并记录哪里出了问题。
常见意外：NTFS ACL 无法干净映射到 S3 存储桶策略，rclone 将符号链接当作文件处理，应用配置中硬编码的 SMB 共享路径，以及 Windows 和 Linux 目标之间的大小写敏感差异。在演练阶段修复这些，不要留到凌晨两点的上线之夜。一周的演练，省去一个月的回滚。
割接后核对
只有完成核对后才宣布成功。比较源端和目标端的对象数量、总字节数以及随机1%的哈希抽样。查询应用指标——文档管理系统显示420万个文件，而目标端只有419万，在关闭源端之前找到那缺失的1万个。
割接后至少30天内将源端保持为只读状态。用户不可避免会提出他们需要某个没有迁移的文件，因为它在 ~/Desktop/old_stuff/ 里而不在被清点的共享目录中。为此预算，不要感到意外，并在需要之前写好回滚手册。
免费试用 hexatransfer.com——无需注册，单次最大10GB。