rsync工作。它花了2个星期的时间来构建仅用于5 TB数据的文件列表，又花了一周的时间来传输1 TB数据。然后我不得不终止工作，因为我们需要一些停机时间。新服务器。
由于我们可能不需要再次访问它，因此我们同意将其压缩。我当时正在考虑将其分成500 GB的块。在我
tar之后，我将通过ssh将其复制。我使用的是tar和pigz，但速度仍然太慢。还有更好的方法吗？我认为两个服务器都在Redhat上。旧服务器是Ext4，新服务器是XFS。
文件大小从几kb到几mb不等，而5TB中有2400万个jpeg。因此，我估计15TB大约需要60-80,000,000。
编辑：在与rsync，nc，tar，mbuffer和pigz玩了几天之后。瓶颈将是磁盘IO。由于数据跨500个SAS磁盘和约2.5亿jpeg进行条带化。但是，现在我了解了以后可以使用的所有这些好工具。
#1 楼
使用tar，pigz（并行gzip）和nc取得了很好的效果。源计算机：
tar -cf - -C /path/of/small/files . | pigz | nc -l 9876
目标计算机：
要提取：
nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here
要存档：
nc source_machine_ip 9876 > smallstuff.tar.gz
如果需要要查看传输速率，只需在
pv之后通过pigz -d传输管道即可！评论
仅供参考，您可以使用gzip替换Pigz或将其完全删除，但是速度会大大降低。
–h0tw1r3
2015年9月9日17:25
如果OP已经尝试过tar和pigz，如何接受呢？我不明白
–托马斯·韦勒（Thomas Weller）
2015年9月9日在22:26
@ThomasWeller你从哪儿得到他尝试过的？从这个问题来看，到目前为止，他似乎只尝试了rsync，并且正在考虑使用tar拆分和捆绑数据。尤其是如果他没有在rsync上使用-z /-compress选项，那么理论上来说Pigg可以提供很大帮助。
– Doktor J
2015年9月9日在22:38
@ThomasWeller是的，的确，我已经尝试过tar和Pigz，但没有尝试过nc。我使用的是ssh，因此增加了很多开销。
–lbanz
2015年9月10日在8:45
@lbanz只是意味着tar生成数据的速度不足以使Pigz使用大量CPU进行压缩。与读取相同数量的较大文件相比，读取许多小文件涉及更多的系统调用，更多的磁盘搜寻和更多的内核开销，并且看起来您只是在根本上遇到瓶颈。
–霍布斯
2015年9月11日，下午3:54
#2 楼
我会坚持使用rsync解决方案。现代（3.0.0+）rsync使用增量文件列表，因此在传输之前不必构建完整列表。因此，重新启动它并不需要您在遇到麻烦时再次进行整个传输。按顶级或二级目录划分传输将进一步优化此效果。 （如果您的网络比驱动器慢，我会使用rsync -a -P并添加--compress。）评论
我在旧服务器上使用rsync 2.6.8。因为它是其中一个不允许我们安装/更新供应商规定的任何物品的盒子之一，否则会使保修无效。我可能会更新它，看看是否更快。
–lbanz
2015年9月10日在8:43
查找（或构建）静态链接的rsync二进制文件，然后从家中运行它。希望这不会破坏任何保修。
–狐狸
2015年9月10日在9:09
一致如何？它与rsync相比如何？
– Gwyneth Llewelyn
18/12/9在18:28
#3 楼
设置VPN（如果有Internet），在远程服务器上创建某种格式的虚拟驱动器（使其成为ext4），将其安装在远程服务器上，然后将其安装在本地服务器上（使用像iSCSI这样的块级协议） ），然后使用dd或其他块级工具进行传输。然后，您可以方便地将文件从虚拟驱动器复制到实际（XFS）驱动器。两个原因：
没有文件系统开销，这是主要的性能元凶
没有寻找，您正在寻找双方的顺序读/写
评论
绕过文件系统是好的。复制读写安装的文件系统的块级是一个非常糟糕的主意。首先卸载或装载只读。
– JB。和莫妮卡
2015年9月10日12:38在
拥有15TB副本也很糟糕。这意味着新服务器至少需要30个。
– Arthur Kay
2015年9月10日于12:41
如果服务器使用的是LVM，则可以对文件系统进行只读快照并复制它。仅用于读取快照时发生的文件系统更改的空间开销。
– liori
2015年9月10日于17:51
#4 楼
如果旧服务器正在停用，并且文件可以脱机几分钟，则通常最快的方法是将驱动器从旧盒中拉出并用电缆将其连接到新服务器中，然后将它们装入（现在恢复在线）并复制文件到新服务器的本机磁盘。评论
大约1TB的2TB驱动器太多了。
–lbanz
2015年9月10日在8:40
#5 楼
使用mbuffer，如果它在安全的网络上，则可以避免加密步骤。#6 楼
（许多不同的答案都可以使用。这是另一个答案。）使用
find -type f生成文件列表（应该在几个小时内完成），将其拆分为小块，然后使用rsync --files-from=...传输每个块。#7 楼
你考虑过sneakernet吗？这样，我的意思是将所有内容转移到同一驱动器上，然后物理地移动该驱动器。大约一个月前，三星推出了16 TB驱动器（技术上为15.36 TB），这也是一个固态硬盘：http：//www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard-drive-16tb
我认为该驱动器正好可以做到这一点。您仍然必须复制所有文件，但是由于您没有网络延迟并且可能可以使用SATA或类似的快速技术，因此它应该快很多。
#8 楼
如果在重复数据删除时有机会获得很高的成功率，那么我会使用borgbackup或Attic之类的方法。如果没有，请检查netcat + tar + pbzip2解决方案，根据您的硬件调整压缩选项-检查什么瓶颈（CPU？网络？IO？）。 pbzip2可以很好地跨越所有CPU，从而提供更好的性能。
评论
lzma（xz）的解压缩速度比bzip2快，并且在大多数输入上效果都很好。不幸的是，xz的多线程选项尚未实现。
– Peter Cordes
2015年9月10日，下午3:40
通常，压缩阶段比解压缩需要更多的功率，因此，如果CPU是限制因素，则pbzip2将导致更好的整体性能。如果两台机器都相似，则减压不会影响该过程。
–中微子
2015年9月10日于7:45
是的，我的意思是没有一个单流多线程lzma令人遗憾。尽管对于此用例，要传输整个数据文件系统，pigz还是有可能的。成为您要使用的最慢的压缩机。甚至lz4。 （有一个lz4mt单线程多线程可用。它的线程效率不是很高（非常频繁地产生新线程），但确实可以提速）
– Peter Cordes
2015年9月10日9:14
#9 楼
您正在使用RedHat Linux，因此这将不适用，但是作为另一个选择：我已经非常成功地使用ZFS来保存数百万个文件，因为inode并不是问题。
如果这是您的选择，则可以制作快照并使用zfs发送增量更新。使用这种方法传输和归档数据已经取得了很多成功。
ZFS主要是Solaris文件系统，但是可以在illumos（Sun的OpenSolaris的开源分支）中找到。我知道在BSD和Linux（使用FUSE？）下使用ZFS也很幸运-但我没有尝试过的经验。
评论
ZFS的非FUSE本机Linux端口已有相当一段时间了：zfsonlinux.org
–EEAA
2015年9月10日在18:52
#10 楼
在目标计算机上启动rsync守护程序。 这将大大加快转移过程。
#11 楼
您可以仅使用tar和ssh来执行此操作，例如：tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz" 或者，如果要保留单个文件：
tar zcf - <your files> | ssh <destination host> "tar zxf -" 评论
仅使用一个CPU不会进行重复数据删除，也无法恢复。
–中微子
2015年9月11日19:53
评论
linux到linux的可能重复副本，传输10TB？一种选择是在外部驱动器上创建压缩的tar文件，然后将其移动到新系统。多余的磁盘将加快创建tar文件的速度（不会试图写入系统中的现有磁盘，可能会尝试从中读取15TB），并且不会占用新服务器的空间。
有更好的方法吗？ -是的，Windows Server 2012 R2 DFS复制将在大约10个小时内完成准备。它会同步更改，并在重新启动后从中断处恢复。
@TessellatingHeckler：所以您建议在归档之前将OP从Redhat迁移到Windows？
@ThomasWeller他们问“有没有更好的方法？”，确实有。我不建议他们使用更好的方法。他们可以在管道中自由使用命令，这些命令无法从中断中恢复，不会验证文件内容，无法报告副本状态，不能使用先前复制的块来避免复制文件的一部分，没有隐式支持低优先级复制，不能暂停，没有提及复制ACL，并且需要有人保持登录状态才能运行它。但是，接下来的其他人可能会感兴趣-或提示您说“ x在Linux上做到了”。