一、先把要搬的东西列全

多数搬迁事故的起因是清单不全，不是传输失败。要搬的至少六类。第一类是原始数据，训练语料、标注结果、预训练权重，体量偏大，常被当成全部要搬的东西。第二类是运行环境，包括框架版本、驱动程序、依赖库与系统层面的配置，不是拷一个目录就能带走。第三类是代码与配置，训练脚本、启动参数、模型结构定义，以及写在配置里却没进版本管理的路径与环境变量。第四类是中间产物，检查点、日志、特征缓存，不搬这些等于下次只能从头跑。第五类是对外依赖，数据来源的访问凭据、外部服务的接入信息、以及许可凭据。第六类是账号与权限关系，哪些人能读哪个目录、哪些任务用哪个身份提交。六类里前两类容易估错工作量，后四类容易漏。列清单时按用途分而不按目录分：一个目录里常混着代码、配置与少量样本，按目录搬既容易带上不该带的，也容易漏在某条子路径里。列完再筛一遍，凡属“还能再生成”的可跳过，其余都按不可再生处理。

二、环境要打包成可重建的形态

环境搬迁的目标不是把文件拷过去，而是让新环境能重现旧环境的行为。做到这一步有几种做法，本质上都是把“装了什么”变成一份可读、可复现的记录。第一种是整机镜像：把系统盘做成镜像，在新环境以同一镜像启动，一致性稳，代价是体量大、通用性差，换到不同规格的机器上可能出现驱动不匹配。第二种是容器镜像：把系统之上的一层连同依赖一起打包，启动快、可复用，是新旧架构不同时的常用手段；要注意基础镜像与加速卡驱动的对应关系，镜像里带了与宿主不一致的驱动，往往表现为设备识别不到。第三种是依赖清单锁定：只记录精确版本号，在新环境里按清单重建，体量小、灵活，代价是对源的可达性有要求、重建耗时长。三种做法可以叠加使用，常见组合是容器镜像打底、依赖清单兜底。无论走哪一种，都要顺手记下三样东西：版本号、安装来源、以及当年为了跑通做过的临时改动。第三样容易被忽略，却恰恰是排查“新环境行为不同”的关键线索——绕过环境检查、打过本地补丁、设过特殊变量这类临时动作，没有记录就只能靠比对现象去猜。

三、数据按体量分档搬

传输方式与体量直接相关，用错档位会白耗时间。几十 GB 以内走常规在线传输即可，传完做一次抽样读取，确认能打开、能解析。几百 GB 到几 TB，就该用支持断点续传与分片并行的批量工具，重点两件事：一是并发数与单连接带宽的取舍，并发过高时单条链路反而变慢，甚至触发对端连接数限制；二是续传粒度，粒度过粗时一次中断要重传一整块。体量再往上，如几十 TB 或文件数千万计，还要多考虑两件事：文件数量本身即瓶颈，小文件多到一定程度，光目录遍历与元数据操作就能耗掉大半时间，可行的办法是先合并成大文件或打包归档再传，到对端展开；以及是否干脆走线下，把数据装进可移动介质寄送，落地后再做完整校验。大文件与小文件处理逻辑不同，按文件数量与总量两个维度分一下，能提前判断用哪种方式。

四、传完的校验比传输本身更重要

搬迁里常被省掉的环节就是校验，而它恰恰是能证明“搬对了”的动作。校验分四层，从粗到细。第一层是数量与体积：文件总数、目录总数、总字节数，两端对一遍，这一层能抓出大面积的漏传与截断。第二层是逐文件摘要：对每个文件算一次摘要值，两端比对；文件数量极多时可按目录生成汇总摘要，逐级向上比对，定位到具体子目录即可，不必全量重算。第三层是内容可用性抽样：随机抽若干个文件，实际读一遍、解析一遍，确认不是空文件、不是被截断的半个文件、编码没有变。第四层是权限与属主：目录的可读可写关系是否与原来一致，这一层不做，后面往往表现为“任务能启动、读不到数据”或“能读不能写”。四层里前两层能自动化、可全量，后两层必须抽样人工确认。校验记录要留档，写清时间、方法、结果与执行人；日后出现数据不一致的争议，这份记录就是主要凭据。还有一条常被跳过：传输日志不要删，里面有失败重试、跳过文件、大小写冲突这类信息，出问题时比重跑一遍校验更快定位。

五、窗口怎么定：全量、增量与静默期

搬迁不能只做一次全量传输。数据在搬的过程中还在产生，全量传完到切换之间新增的部分必须补上，否则会丢一段。常规做法是三步：先做一次全量，把绝大部分数据搬过去；再做增量同步，只搬新增与变更的部分；末了在切换前留一个静默窗口，暂停写入、做末次增量、确认两端一致后立即切换。静默窗口的长度是关键决策：窗口太短，末次增量做不完；窗口太长，业务停得久。压缩窗口的办法有两个，一是把增量做得足够频繁，让末次的差异足够小；二是把只读部分（历史数据、权重文件）与写入部分分开处理，前者可提前很久搬完，后者才需在窗口内处理。判断增量是否追得上，看一个简单指标：每轮增量耗时是否在缩短。若基本不变，说明写入速度与传输速度接近，再往下也追不上，这时该考虑限流写入或延长窗口，而不是继续加并发。窗口期要提前通知相关方，写清停多久、哪些功能不可用、恢复后如何核对。

六、切换、双跑与回退

切换动作要设计成可回退的。常见失误是切换与清理同时做：一边把访问指向新环境，一边删掉旧环境数据，结果新环境某环节不对，想退回已无退路。稳妥次序是三步。第一步，先让新环境以只读方式接入，用真实请求验证读路径是否正常，这一阶段旧环境继续对外服务。第二步，把新环境接上少量写请求，同时保留旧环境的写入，做一段双跑；双跑期间按业务主键对账，比对两边结果是否一致，差异逐条查清，而不是笼统看总量。第三步，确认无误后把写入正式切过去，旧环境转入只读并保留一段时间，保留期至少覆盖一个完整业务周期。回退方案要写清触发条件、操作步骤与谁有权决定，而不是等出问题再讨论。还有一处细节要提前安排：新旧环境的标识要能区分，日志、监控、账单里若同名，双跑期间分不清数据来自哪一边，对账会很被动。切换完成后先别宣布结束，留一天观察错误率与耗时曲线，很多问题要过一个业务高峰才暴露。

七、搬迁后的清尾与复盘

收尾阶段有三件实事。第一件是旧环境的下线与计费停止：确认数据已完整落地、旧资源可以释放，再按流程关停；这一步怕两件事：没确认就关会丢数据，忘了关会持续支出。关停前把末轮校验结果与保留期到期时间记下来。第二件是凭据轮换：搬迁过程里凭据常被多人使用、写进临时脚本、贴进沟通窗口，搬完后统一换一遍更省心；不再需要的临时账号与访问路径一并收回。第三件是文档更新：新环境的接入方式、数据位置、环境版本、常用操作入口写进文档，旧文档标注失效，防止后来的人照着旧说明操作。复盘不必写成长篇报告，回答四个问题就够：哪类东西差点漏掉、实际耗时与估算差多少、校验抓出了什么、切换时哪一环压力大。答案直接决定下一次同类动作能省多少时间。搬迁做过一次之后，沉淀下来的不是工具用法，而是那份清单与那套校验动作；留住它们，第二次只需改几个参数。

结语

搬迁的实质是四件事：清单列全、环境可重建、数据按体量分档传、传完逐项校验。清单要按用途分而非按目录分，环境要把版本与临时改动一起记下来，传输方式随体量换档，校验做到数量、摘要、可用性、权限四层。切换按只读验证、双跑对账、正式切换、旧环境保留的次序走，别把切换与清理同时做；收尾时确认数据落地再停旧资源、统一轮换凭据、更新文档。把清单与校验动作留成模板，这类搬迁就从一次冒险变成一道例行工序。