我有一个文件的集合，目前在我们局域网的NAS上，大约有110万个文件，总大小为2TB。 我们需要将其复制到AWS以开始处理它。 但是，在云侧进行更改也需要同步回到我们的LAN。
到目前为止，我们能够获得的最低同步延迟大约是一两个小时。 在我们的EC2实例上安装本地NAS，只需枚举所有文件， find [path] &> /dev/null需要花费一个多小时。
但是，这些文件按照订单编号处于目录结构中，一旦订单完成，它们很less（如果修改过）。 同样，这些目录包含订单号码，所以可以用来查找最近的订单号码。 我觉得这个事实可以用来对我们有利，但我不知道如何。
带宽不是一个问题（两种方法大约100 MBPS），从办公室到我们select的AWS区域的延迟大约是35毫秒。
有没有更好的方法来处理这个问题？ 如果需要的话，我们有能力在本地运行虚拟机。
跨越广域网链路的同步会受到延迟的严重影响，特别是涉及远程目录走动时。 有了大量文件，无论您是在本地卷上还是在networking共享上枚举，它都会产生巨大的影响。
你最好的双向select是一个客户端 – 服务器端的方式，在双方本地，如rsync可以。
如果你能够减less同步到某些文件夹的单向，只是复制，你有更多的select，如复制取决于存档标志（Windows）或通过远程pipe道（Linux）使用焦油。
无论如何，你也可以通过本地时间戳（“自从上次同步以来有什么新东西？”）。
也许快照卷和复制整个块设备英寸不是增量，但2 TB顺序复制应该比迭代一百万个文件更快。
或者使用内置发送和接收快照的文件系统，如btrfs或zfs。