因此从技术层面来说建议从一开始就使用带有全链路数据校验功能的服务，自建存储服务的全链路一致性也需要自行建设，否则在迁移后只能通过md5sum这类工具对全部数据进行校验，确保迁移前后数据没有差异，而不保证迁移后的文件依然是访客当初上传的文件。尽管需要做这样的妥协，海量小文件的迁移和校验依然会造成迁移工期的压力。

利用md5sum递归遍历整个目录，生成所有文件的md5结果，可以通过以下命令完成：

find ./ -type f -print0 | xargs -0 md5sum > ./my.md5

相应的，可以通过以下命令对迁移后的整个目录进行递归遍历校验。

md5sum -c my.md5

对象存储同步

数据同步

对象存储的数据同步和校验的复杂度介于数据库和文件存储之间，因为它基本上是基于HTTP协议的，镜像回源的功能就能派上用场了，即如果一个文件在我们平台上不存在，那对象存储会尝试到源站去获取并保存下来。而相对于InnoDB数据表这种结构化数据，对象存储的数据一致性保障还是相对较弱。

目前市面上各种平台的对象存储服务对S3协议都有较好支持，而通过US3SYNC工具就可以将其他支持S3协议的对象存储数据迁移到UCloud对象存储US3中。虽然US3也支持镜像回源，但是在数据同步的刚开始时，不建议将原平台bucket配置为回源目标之后就将US3作为服务入口来使用起来，因为这个时候US3 bucket中还没有数据，直接使用US3会造成大量镜像回源，一是从而导致整体访问延迟变大，其次也容易出现访问失败的情况。

US3SYNC工具与redis协同工作。在数据同步开始前，US3SYNC工具会通过S3协议的列表接口，将一定数量的源bucket对象key以及这些key的同步状态记录进redis中。每当一个文件完成从源bucket的下载、缓存和上传到US3后，导入工具就会在redis中将数据标记为已同步。这样在US3SYNC工具因为一些可能的原因，例如网络环境不好等问题故障挂起之后，只需要重启US3SYNC，它都可以从断点开始续传。

当完成一轮数据导入之后，就可以开始配置镜像回源配置了，这时候直接访问US3也能得到不错的命中率。当然也可以选择再运行一次US3SYNC工具，如果这样操作需要注意US3SYNC工具原本的功能是断点续传的，所以我们应该把redis的内容清除。

但是直接清理掉redis再重新跑，US3SYNC工具的行为是重新加载文件列表并且重新写入US3，这样会导致所有数据都要重新写一次，效率很低。在这个时候，我们可以配置US3SYNC工具为文件比对模式，在获取文件列表后将文件都通过HEAD获取文件大小，这时候只要将源bucket HEAD成功，但是US3为not found或者文件大小不同的数据同步到US3即可。在实际的数据迁移实践中，我们可以更加灵活的使用续传和比对模式来提高工作效率。

【案例】

以近期的xx公司迁移到UCloud为例，该公司的CDN和对象存储从友商迁移到UCloud的过程里面，有一个bucket中存在文件数量达到了12亿，将所有key存储到redis中并不合理，会导致redis数据膨胀，进而对迁移中转主机提出非常高的内存需求。这时候应该从一开始就配置US3SYNC工具为文件比对模式对数据进行迁移，进而避免不合理的redis内存使用。

数据校验

对象存储的数据校验方面，大多数对象存储都支持给文件提供ETag的Header，且ETag的生成都跟原始数据有一定关系，所以可以根据源平台的ETag计算方式，在下载到文件后对文件进行一次计算，看看ETag是否相符。而US3SYNC功能本身也会按照US3的ETag计算规则预先计算我们的ETag，在上传成功后对比US3返回的ETag和导入工具自行计算的值，来实现对数据的校验。