我需要将大约1TB的较小文件（大部分小于100KB）的数据迁移到另一台服务器上。 我甚至没有完全列举这些文件，但估计是在1-2百万之间。
使用SCP的最初的副本花了一个星期。 现在我们必须同步更改。 每天都会添加数百到数千个文件。
我已经尝试使用rsync（v3），但它耗时太长。 当它结束的时候，我们会回到数据不同步的地步。
我在这里看到了类似的问题，但他们有点老，想知道是否有新的工具来帮助这个过程。
由于共享iSCSI系统上的源数据读取性能差，问题更加复杂。
最新的策略可能是重新进行数据迁移，让开发人员编写一个工具来logging在迁移过程中添加的所有新文件。 目录结构键的唯一标识符是非常宽泛和深刻的，所以新的文件分散在这个结构中，重写应用程序把新文件放到特定的目录下是行不通的。
任何策略的赞赏。
操作系统是RHEL 5转到RHEL 6。
我会试图回答“停止滥用文件系统，把它当作数据库来对待”，但我相信这对你没有多大帮助;）
首先，您需要了解，如果您的限制是在读取的可用带宽内，则无法通过简单的同步命令来提高性能。 在这种情况下，您必须通过更改创build文件的方式（也就是说，正确地猜测，请开发人员更改源程序）来写入数据，或者通过使用产品做地理镜像（例如， 双重做 ：检查，因为我相信你会find替代品，这只是一个例子）。
在类似的情况下，问题的主要原因通常不是文件数据，而是元数据访问。 因此，您的第一个策略是将负载分成多个进程，这些进程充当（完全）不同的目录：这应该有助于文件系统跟上你所需要的元数据。
另一个策略是使用您的备份系统：在目标上重放上一次增量备份以保持数据库同步。
最后，在特定情况下可以应用更多的外来策略。 例如，我通过编写一个程序，每隔几分钟将文件加载到文件系统中，解决了Windows网站上类似的问题，从而保持了FS的清洁。
我不认为有任何改变。 如果你可以在源系统上静止数据，我认为一些tar的变种将是最快的。 如果没有，rsync仍然是下一个最好的方法，确保使用全文件开关和CPU密集度较低的压缩algorithm（如arcfour）。 你有没有select执行块级副本？ 你提到iSCSI存储。 新系统是否也具有iSCSI连接存储？
这是分阶段进行的：
1）使用scp的初始传输器2）使用rsync刷新的一些数据3）devs正在编写一个脚本，以便将从步骤1以来添加的文件添加到系统中4）在dns更改期间将数据从原始服务器代理到新服务器5）更改dns并获取摆脱了共享iSCSI服务的共享。