文件总数相同，不代表文件内容、数据库记录和业务状态都一致。计算主机租期届满前的业务迁出与数据一致性校验，应先界定需要迁移的数据范围，再逐层验证内容和业务结果。否则，目录结构看似完整，仍可能遗漏正在写入的文件、权限信息或数据库中的新记录。
先确认“什么算迁完”
迁移前列出数据源、目标位置、负责人和校验标准。除了文件，还要检查数据库、配置文件、定时任务、上传目录及依赖的证书或密钥；敏感资料应按既有安全要求处理。明确哪些数据只读、哪些持续变化，也要记录文件系统、数据库版本和运行环境差异。
文件数量只能发现明显缺项，无法证明字节内容相同。文件大小相同也不够：内容可能不同，但长度一致。可使用校验和比较内容，并根据业务需要核对权限、属主、时间戳、符号链接等元数据。时间戳可能受时区、复制方式或文件系统精度影响，不宜单独作为一致性证据。
按数据类型选择校验方法
文件与目录
先做全量复制，再进行增量同步，把首轮复制后发生变化的内容补齐。Linux 环境中可用 rsync 传输并核对文件；对重要文件，可在源端和目标端分别计算 SHA-256 校验和，再比较结果。大目录可按子目录或清单分批核验，保存执行时间、范围和异常记录，避免只留下“已完成”的口头结论。
若数据量较大，逐个读取并计算校验和会增加磁盘读负载和耗时。可先对关键目录全量核验，其余目录按风险分层；但抽样只能用于发现问题，不能证明未抽查部分完全一致。若文件仍在变化，应先安排最终同步窗口，避免校验期间源端继续写入造成结果过时。
数据库与业务状态
数据库迁移不能只比较导出文件大小或表的数量。以 PostgreSQL、MySQL 等常见数据库为例，可结合数据库自身的备份恢复检查、表级记录数、关键业务查询结果及必要的校验和比对。记录数相同不代表每一行内容相同；应挑选主键范围、更新时间或业务关键字段进行更深入核对。具体方法须符合数据库版本和迁移方式，避免在生产环境运行高负载校验。
按顺序完成迁移与复核
- 盘点并留基线：记录源主机目录、数据量、数据库对象、配置和当前业务状态，确认目标机容量与访问权限。
- 执行首轮迁移：复制静态文件并导入数据库；记录命令、时间和失败项，不要把跳过错误当作成功。
- 补齐变化数据：切换前安排只读切换或暂停写入；若不能停写，采用可靠的增量复制机制，并确认复制延迟已收敛。
- 逐项核验：比较文件校验和、关键元数据、数据库对象及业务查询结果；对不一致项查明原因后重传或修复，再重新验证。
- 小范围试运行：在目标机检查登录、读写、后台任务和外部依赖，确认业务负责人认可结果后再切换入口。
切换后保留回退依据
切换不等于立即销毁旧环境。预先约定观察期和回滚条件，例如关键数据写入异常、任务未执行或用户无法完成核心操作。切换后持续查看应用日志、数据库复制状态和业务结果；如果新旧主机都接受写入，回退前必须处理两端数据分叉，不能简单把旧机重新开放，否则可能覆盖新数据。
计算主机租期届满前的业务迁出与数据一致性校验，最终应留下可复查的证据：迁移范围、校验结果、异常处理、切换确认和回滚安排。文件数量可以作为清点指标，却不能代替内容比对与业务验证。
常见问题
文件数量相同，是否可以判定迁移成功？
不可以。还需核对内容校验和、必要元数据，以及数据库和业务功能。
所有文件都必须计算 SHA-256 吗？
不一定。关键数据适合全量核验；数据规模很大时可分级安排，但抽样不能证明未检查部分一致。
迁移时业务不能停写怎么办？
可先全量复制，再使用支持持续增量同步的方案；切换前仍需确认变更已追平，并评估并发写入和回退风险。
旧主机何时可以释放？
应在目标机通过业务验收、观察期结束且回退方案不再依赖旧数据后，再按数据保留和安全要求处理旧环境。
