我有一组文件，目前存放在我们 LAN 上的 NAS 中，大约有 110 万个文件，总大小为 2TB。我们需要将其复制到 AWS 才能开始处理。但是，在云端进行更改时，也需要将其同步回我们的 LAN。
到目前为止，我们能够实现的最低同步延迟约为一两个小时。在我们的 EC2 实例上安装本地 NAS 并简单地枚举所有文件find [path] &> /dev/null需要一个多小时。
但是，这些文件是按照订单号排列的目录结构，一旦订单完成，它们就很少被修改。同样，目录包含订单号，因此可能有助于查找最新的订单号。我觉得这个事实可以为我们带来好处，但我不确定如何利用。
带宽不是问题（双向大约 100 MBPS），从办公室到我们选择的 AWS 区域的延迟大约为 35 毫秒。
有没有更好的方法来处理这个问题？如果需要，我们可以在局域网上本地运行虚拟机。
答案1
WAN 链路间的同步可能会受到延迟的严重影响，尤其是涉及远程目录遍历时。对于大量文件，在本地卷还是在网络共享上进行枚举已经会产生巨大差异。
双向的最佳选择是在本地运行双方的客户端 - 服务器方法，例如 rsync 就可以。
如果您能够将某些文件夹的同步减少为单向并且仅进行复制，那么您将拥有更多选项，例如根据存档标志进行复制（Windows）或通过远程管道使用 tar（Linux）。
无论如何，您也可以通过本地时间戳（“自上次同步以来有什么新内容？”）。
答案2
也许可以对卷进行快照并复制整个块设备。不是增量的，但 2 TB 的顺序复制应该比迭代一百万个文件更快。
或者使用内置发送和接收快照的文件系统，如 btrfs 或 zfs。