我正在将数据从一台服务器归档到另一台服务器。最初我开始了rsync一份工作。仅仅为 5 TB 的数据构建文件列表需要 2 周时间，而传输 1 TB 数据需要一周时间。
然后我不得不终止这项工作，因为我们需要在新服务器上休息一段时间。
已经同意我们会将其 tar，因为我们可能不需要再次访问它。我正在考虑将它分成 500 GB 的块。在我完成之后tar，我将通过ssh. 我正在使用tar，pigz但它仍然太慢。
有更好的方法吗？我认为两台服务器都在 Redhat 上。旧服务器是 Ext4，新服务器是 XFS。
文件大小从几 kb 到几 mb 不等，5TB 中有 2400 万个 jpeg。所以我猜 15TB 大约需要 60-80 百万。
编辑：在玩了几天 rsync、nc、tar、mbuffer 和 pigz 之后。瓶颈将是磁盘 IO。由于数据跨 500 个 SAS 磁盘和大约 2.5 亿个 jpeg 条带化。但是，现在我了解了所有这些我将来可以使用的好工具。
使用
tar,pigz(parallel gzip) 和nc.源机：
目标机器：
提取：
要保留存档：
如果您想查看传输率，请在
pv之后通过管道pigz -d！我会坚持使用 rsync 解决方案。现代 (3.0.0+) rsync 使用增量文件列表，因此在传输之前不必构建完整列表。因此，重新启动它不会要求您在出现问题时再次进行整个传输。拆分每个顶级或二级目录的传输将进一步优化这一点。（如果您的网络比您的驱动器慢，我会使用
rsync -a -P并添加。）--compress设置一个 VPN（如果它的互联网），在远程服务器上创建某种格式的虚拟驱动器（使其成为 ext4），将其安装在远程服务器上，然后将其安装在本地服务器上（使用块级协议，如 iSCSI )，并使用 dd 或其他块级工具进行传输。然后，您可以根据自己的方便将文件从虚拟驱动器复制到真实 (XFS) 驱动器。
两个原因：
如果旧服务器正在退役并且文件可能会脱机几分钟，那么将驱动器从旧盒子中拉出并将它们连接到新服务器，安装它们（现在重新联机）并复制文件通常是最快的到新服务器的本机磁盘。
使用 mbuffer，如果它在安全网络上，您可以避免加密步骤。
（许多不同的答案都可以工作。这是另一个。）
生成文件列表
find -type f（这应该在几个小时内完成），将其拆分为小块，然后使用rsync --files-from=....你考虑过运动鞋网吗？有了这个，我的意思是把所有东西都转移到同一个驱动器上，然后物理地移动那个驱动器。
大约一个月前，三星推出了 16 TB 驱动器（技术上是 15.36 TB），它也是一个 SSD：http ://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -驱动器-16tb
我认为这个驱动器几乎可以做到这一点。您仍然需要复制所有文件，但由于您没有网络延迟并且可能可以使用 SATA 或类似的快速技术，它应该会快很多。
如果在重复数据删除时有任何机会获得高成功率，我会使用像borgbackup或 Attic 这样的东西。
如果没有，请检查 netcat+tar+ pbzip2解决方案，根据您的硬件调整压缩选项 - 检查瓶颈是什么（CPU？网络？IO？）。pbzip2 可以很好地跨越所有 CPU，从而提供更好的性能。
您使用的是 RedHat Linux，所以这不适用，但作为另一种选择：
我在使用 ZFS 保存数百万个文件方面取得了巨大成功，因为 inode 不是问题。
如果这对您来说是一个选项，那么您可以拍摄快照并使用 zfs 发送增量更新。我在使用这种方法传输和存档数据方面取得了很大的成功。
ZFS 主要是一个 Solaris 文件系统，但可以在 illumos（Sun 的 OpenSolaris 的开源分支）中找到。我知道在 BSD 和 Linux 下使用 ZFS 也有一些运气（使用 FUSE？）——但我没有尝试过的经验。
在目标机器上启动一个
rsync守护进程。这将大大加快传输过程。