我需要将约 1TB 的数据（由较小的文件组成，大多数小于 100KB）迁移到另一台服务器。我甚至没有完全列举这些文件，但估计有 100-200 万个。
使用 SCP 的初始复制耗时超过一周。现在我们必须同步更改。每天都会添加数百到数千个文件。
我尝试使用 rsync (v3)，但它耗时太长。等它完成时，我们又会回到数据不同步的状态。
我在这里看到过类似的问题，但它们有点老了，想知道是否有任何新工具可以帮助这个过程。
由于源数据位于读取性能较差的共享 iSCSI 系统上，问题变得更加复杂。
最新的策略可能是重新进行数据迁移，并让开发人员编写一个工具来记录迁移过程中添加的所有新文件。目录结构由唯一标识符组成，非常广泛和深入，因此新文件分散在此结构中，重写应用程序以将新文件放入特定目录中是行不通的。
任何策略都值得赞赏。
操作系统是 RHEL 5，将升级至 RHEL 6。
答案1
我很想回答“不要把文件系统当成数据库来滥用它”，但我确信这对你没有太大帮助；)
首先，您需要了解，如果您的限制在于读取时可用的带宽，则无法使用简单的同步命令来提高性能。在这种情况下，您必须在写入数据时拆分数据，方法是更改文件创建方式（这意味着，正如您猜对的那样，要求开发人员更改源程序）或使用支持地理镜像的产品（例如恍然大悟：请四处查看，我相信您会找到其他选择，这只是一个例子）。
在类似情况下，问题的主要原因通常不是文件数据，而是元数据访问。因此，您的第一个策略是将负载划分为多个作用于（完全）不同目录的进程：这应该有助于文件系统跟上为您提供所需的元数据。
另一个策略是使用您的备份系统：在目标上重播最后的增量备份以保持数据库同步。
最后，还有一些奇特的策略可以应用于特定情况。例如，我通过编写一个程序解决了 Windows 网站上的类似问题，该程序每隔几分钟将文件加载到文件系统中，从而保持 FS 清洁。
答案2
我认为没有什么变化。如果你可以在源系统上静默数据，我认为一些tar 的变体将是最快的。如果不是，rsync 仍然是次优方法，确保使用全文件切换和 CPU 密集程度较低的压缩算法（例如 arcfour）。您是否有任何选项可以执行块级复制？您提到了 iSCSI 存储。新系统是否也会有 iSCSI 连接存储？
答案3
这项工作分阶段进行：
1) 使用 scp 进行初始传输 2) 使用 rsync 刷新一些数据 3) 开发人员正在编写脚本以将自步骤 1 以来添加的文件拉到系统中 4) 在 dns 更改期间将数据从原始服务器代理到新服务器 5) 更改 dns 并摆脱性能不佳的共享 iSCSI 服务。