传输15TB的小文件

79

我正在将数据从一台服务器归档到另一台服务器。最初我开始rsync工作。它只花了2周的时间就建立了仅用于5 TB数据的文件列表，又花了一周的时间来传输1 TB的数据。

然后我不得不取消工作，因为我们需要在新服务器上停机。

我们已经同意将其压缩，因为我们可能不需要再次访问它。我当时正在考虑将其分成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数据条带化。但是，现在我了解了以后可以使用的所有这些好工具。

— 班兹
source

1

可能的Linux

— D34DM347'9

2

一种选择是在外部驱动器上创建压缩的tar文件，然后将其移动到新系统。多余的磁盘将加快创建tar文件的速度（不会尝试写入系统中的现有磁盘，可能会尝试从中读取15TB），并且不会占用新服务器的空间。

— 布赖恩

4

有更好的方法吗？-是的，Windows Server 2012 R2 DFS复制将在大约10个小时内准备就绪。并且它将同步更改，并在重新启动后从中断处恢复。

— TessellatingHeckler，2015年

27

@TessellatingHeckler：所以您建议在归档之前将OP从Redhat迁移到Windows？

— Thomas Weller

12

@ThomasWeller他们问“有没有更好的方法？”，确实有。我不建议他们使用更好的方法。他们可以在管道中自由使用命令，这些命令无法从中断中恢复，不会验证文件内容，无法报告复制状态，不能使用先前复制的块来避免复制文件的一部分，没有隐式支持低优先级复制，不能暂停，没有提及复制ACL，并且需要有人保持登录状态才能运行它。但是，接下来的其他人可能会感兴趣-或提示说“ x在Linux上做到了”。

— TessellatingHeckler

64

我已经使用了非常好的效果了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！

— h0tw1r3
source

3

仅供参考，您可以替换pigz使用gzip或者完全删除，但速度会慢显著。

— h0tw1r3 2015年

10

如果OP已经尝试过tar，该如何接受pigz？我不明白...

— Thomas Weller

5

@ThomasWeller你从哪里得到了他的尝试pigz？从这个问题看来，他rsync到目前为止还只是尝试过，并且正在考虑使用tar拆分和捆绑数据的方法。特别是如果他没有在rsync上使用-z/ --compress选项，那么从pigz理论上讲可以有很大帮助。

— Doktor J

1

@ThomasWeller是的，确实我已经尝试过tar和pigz，但是还没有尝试过nc。我使用的是ssh，因此增加了很多开销。

— lbanz

2

@lbanz只是意味着tar生成数据的速度不够快，pigz无法使用大量CPU进行压缩。与读取相同数量的较大文件相比，读取大量小文件涉及更多的系统调用，更多的磁盘搜寻和更多的内核开销，并且看起来您只是在根本上遇到瓶颈。

— hobbs 2015年

21

我会坚持使用rsync解决方案。现代（3.0.0+）rsync使用增量文件列表，因此在传输之前不必构建完整列表。因此，重新启动它并不需要您在遇到麻烦时再次进行整个传输。按顶级或二级目录划分传输将进一步优化此功能。（如果您的网络慢于驱动器，我会使用rsync -a -P并添加--compress。）

— 狐狸
source

我在旧服务器上使用rsync 2.6.8。因为它是其中一个不允许我们安装/更新供应商规定的任何物品的盒子之一，否则它会使保修无效。我可能会更新它，看看是否更快。

— lbanz

18

查找（或构建）静态链接的rsync二进制文件，然后从家中运行它。希望这不会破坏任何保修。

— 福克斯

怎么unison样与之相比rsync呢？

— Gwyneth Llewelyn '18年

15

设置VPN（如果有Internet），在远程服务器上创建某种格式的虚拟驱动器（使其成为ext4），将其安装在远程服务器上，然后将其安装在本地服务器上（使用像iSCSI这样的块级协议）），然后使用dd或其他块级工具进行传输。然后，您可以方便地将文件从虚拟驱动器复制到真实（XFS）驱动器。

两个原因：

没有文件系统开销，这是主要的性能根源
不寻觅，您正在寻找双方的顺序读/写

— 亚瑟·凯
source

3

绕过文件系统是好的。复制读写安装的文件系统的块级是一个非常糟糕的主意。首先卸载或装载只读。

— JB。

拥有15TB副本也很糟糕。这意味着新的服务器需要的最小30

— 亚瑟·凯

3

如果服务器使用的是LVM，则可以对文件系统进行只读快照，然后将其复制。仅用于读取快照时发生的文件系统更改的空间开销。

— liori

9

如果旧服务器正在停用，并且文件可以脱机几分钟，那么通常最快的方法是将驱动器从旧盒中拉出并用电缆将其连接到新服务器上，将它们挂载（现在恢复在线）并复制文件到新服务器的本机磁盘。

— 罗宾·哈蒙德
source

2

大约1PB的2TB驱动器太多了。

— lbanz

3

使用mbuffer，如果它在安全的网络上，则可以避免加密步骤。

— 詹姆斯·瑞安
source

3

（可以使用许多不同的答案。这是另一个答案。）

使用生成文件列表find -type f（应该在几个小时内完成），将其拆分为小块，然后使用传输每个块rsync --files-from=...。

— 点
source

3

你考虑过sneakernet吗？这样，我的意思是将所有内容转移到同一驱动器上，然后将其物理移动。

大约一个月前，三星推出了16 TB驱动器（技术上为15.36 TB），该驱动器也是SSD：http：//www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -驱动器16TB

我认为此驱动器将为此目的。您仍然必须复制所有文件，但是由于您没有网络延迟并且可能可以使用SATA或类似的快速技术，因此它应该快很多。

— 恩扎尔
source

2

如果在重复数据删除时有机会获得较高的成功率，则可以使用borgbackup或Attic之类的方法。

如果不是，请检查netcat + tar + pbzip2解决方案，根据您的硬件调整压缩选项-检查什么瓶颈（CPU？网络？IO？）。pbzip2可以很好地跨越所有CPU，从而提供更好的性能。

— 中性
source

lzma（xz）的解压缩速度比bzip2快，并且在大多数输入上效果都很好。不幸的是，xz尚未实现的多线程选项。

— 彼得·科德斯

通常，压缩阶段需要比解压缩更多的功率，因此，如果CPU是限制因素，则pbzip2将导致更好的整体性能。如果两台机器都相似，则减压不会影响该过程。

— neutrinus

是的，我的意思是没有一个单流多线程lzma令人遗憾。尽管对于此用例，传输数据的整个文件系统pigz可能会出现问题。成为您要使用的最慢的压缩机。甚至lz4。（有一个lz4mt单线程多线程可用。它不是非常有效地线程化（非常频繁地产生新线程），但是确实获得了明显的加速）

— Peter Cordes

2

您正在使用RedHat Linux，因此这将不适用，但是作为另一种选择：

使用ZFS来保存数百万个文件已经取得了很大的成功，因为inode并不是问题。

如果您可以选择这样做，则可以拍摄快照并使用zfs发送增量更新。使用这种方法传输和存档数据我取得了很多成功。

ZFS主要是Solaris文件系统，但可以在illumos（Sun的OpenSolaris的开源分支）中找到。我知道在BSD和Linux（使用FUSE？）下使用ZFS也很幸运-但我没有尝试过的经验。

— 昏昏欲睡
source

3

ZFS的非FUSE本机Linux端口已有相当一段时间了：zfsonlinux.org

— EEAA

1

rsync在目标计算机上启动守护程序。这将大大加快转移过程。

— 海科·维斯纳（Heiko Wiesner）
source

-1

您可以仅使用tar和ssh来执行此操作，如下所示：

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

或者，如果您要保留单个文件：

tar zcf - <your files> | ssh <destination host> "tar zxf -"

— 法比奥·布里托（Fabio Brito）
source

1

仅使用一个CPU不会进行重复数据删除，也无法恢复。

— neutrinus