我有一个文件存储服务器，它使用文件的 sha256 哈希值作为文件名以及文件扩展名将文件存储在磁盘上，并存储在三级目录中，例如具有 sha256 哈希值的 PDF 文件AABB1F1C6FC86DB2DCA6FB0167DE8CF7288798271EA24B68D857CBC5CF8DC66A将存储在如下子目录中：
<root>/AA/BB/AABB1F1C6FC86DB2DCA6FB0167DE8CF7288798271EA24B68D857CBC5CF8DC66A.pdf
文件将被添加到目录结构中，但永远不会被删除或修改。
我使用每 10 分钟运行一次的 cron 任务来保存此文件结构的实时副本，该任务使用 rsync 将文件推送到远程服务器。由于文件一旦添加就永远不会被删除或更改，因此实际上它只会发送新文件。
我发现 rsync 仅用于比较两个目录（即没有更改）的带宽就约为 11 MB，并且随着文件总数的增加（目前为 148 207）而增加。这是有道理的 - rsync 实际上必须将所有文件名的列表发送到远程服务器，才能找出远程服务器上缺少哪些文件。
我的问题是：有没有办法减少使用的带宽？它不一定是基于 rsync 的解决方案，但它是更好的选择。我曾考虑将 rsync 查看的文件限制为最近修改的文件，即上次同步后修改的文件，但似乎不建议这样做：rsync 仅在某个日期和时间之后创建或修改的文件
还有其他建议吗？
答案1
大多数情况下不建议这样做，但考虑到您的目标是减少差异计算带宽，这样做是合适的。考虑以下脚本流程：
- 触摸一个文件作为您的“最高条”，这需要系统地命名，并且不会覆盖您最后的“最高条”，现在它是您的“最低条”。脚本将传输这两个文件日期之间带有 mtime 的任何内容。请注意，您不得重命名或以其他方式更改这些文件上的日期戳。
- 使用 find 来
-newer <lowbarfile> ! -newer <highbarfile>选择要传输的文件，像您的参考问题一样通过管道传输到 rsync。 - 每周（或每晚）重新 rsync 整个目录，以确保没有遗漏任何内容。获取以这种方式传输的文件的电子邮件日志，以便查看先前步骤是否出现问题。
这不像 inotifywatch 那样是一个出色的解决方案，但它在 8000 个目录之后也不会中断，并且您的层次结构似乎使用了最多 256+65536 个目录。
答案2
每次运行都rsync需要建立本地和远程目录结构的完整列表并计算差异，然后才能确定哪些文件是新创建的并发送这些新文件。这就是“昂贵”之处。
你还没有提到文件服务器的操作系统是什么，但在 Linux 上，你可以使用类似inotofywatch针对创建或修改文件的每个文件系统事件生成警报，并使用该事件作为输入来复制新文件。inotifywatch不过，您的分层目录结构会有些昂贵。
在 Windows 上你有分布式文件系统其功能大致与名称相同，它还插入文件系统层，并且更加智能，只复制文件的修改部分，而不是整个文件。
答案3
您可以使用 -e“ssh -C”运行 rsync，从而压缩 ssh 隧道，而不是像使用 -z 运行时那样只压缩数据。或者通过压缩流量的 vpn 进行连接（openvpn 可以做到这一点）。