快速的Internet备份

备份性能是由许多因素决定的。 带宽就是其中之一。

• 存储写入性能

通常由存储写入性能决定。

• networking带宽

一个好的select是在备份服务器上以守护进程模式运行rsync，这样做可以避免使用ssh。 但是除非你的处理器真的很慢，否则ssh的开销不会很大。

运行rsync作为守护进程启动服务器上的rsync守护进程

rsync --daemon 

默认情况下，它侦听TCP端口873，您可以在rsyncd.conf中更改它。

然后使用rsync作为

  rsync [OPTIONS] source-path \ rsync://backup_username@backup-server:873:destination-path 

没有足够的信息来估计你的预期performance。 然而每天增加1.5TB也不是不可能的。

• 存储IOPS

在备份过程中，您将写入操作与多个文件系统操作相结合。 文件系统查询和更新。 运行几个rsync进程来隐藏文件创build的延迟通常是一个好主意。

你可能想看看文件加速软件。 我认为这个市场有很多玩家，但是我以前见过的玩家是aspera。 这是一个比较aspera sync到rsync的页面（页面底部的比较表）。

http://asperasoft.com/en/products/synchronization_23/aspera_sync_23

此外，请确保没有涉及使用任何真正的旧版本的rsync。 仍然有2.x版本在使用，这使整个链回落到一个更老的，在某些情况下效率远远低于协议版本（如果你被告知“发送增量文件列表”，你是好的。 “发送文件列表”，即使用2.x协议。）

我认为1.5TB增量/天与rsync这样的解决scheme的典型大小有些差距。 SSH的体系结构上限大约为2-3MB / s IIRC，并且在默认的rsync协议之前写入的速度要快得多，但是没有encryption。

您应该真正看看专门devise用于同步这些数据量的解决scheme。 我曾经使用过的Quantum DXi设备是存储设备，但也提供重复数据删除和encryption复制。 你可能想看看这些。

/编辑：为了扩展我的上述说法，在测量SSH速度时考虑以下几点非常重要：

• 速度问题是由于SSH的内部缓冲区结构而发生的，因为它最初并不是通过WAN开发来传输大量数据（请阅读此处了解更多详细信息和可能的解决scheme
• 考虑到RTT。 由于缓冲区问题，WAN上的性能（TO所要求的性能）可能比本地千兆比差很多，即使只增加10ms的RTT
• 压缩：托pipe公司将有很多的文件，不能再压缩像下载已经压缩，电影，图像等。这会减慢整体吞吐量，因为你不能指望数据减less到20％或更less，我估计你可以用50％的压缩率来计算。
• 计数文件/压缩：你显然不能创build一个1,5TB的单个存档并同步。 为什么？ 因为如果这个存档的一个字节被破坏（由于任何原因）整个备份可能是无用的。 所以你必须将增量分成每个客户1个档案，这增加了传输的开销，并且还会使压缩比恶化

重复数据删除的重大优势在于，数据在块级别上进行了重复数据删除。 这意味着如果您要为每个客户创build一个tar（而不是压缩的！），并且将DXi设备之一放在您的主站点上，则该设备将自动消除文件stream中的重复块（例如，100个客户在其tar中具有相同的电影 – 它将只被存储一次，并将被引用另外99次），并且块也将被压缩。

如果您随后在场外添加第二个，则只有唯一的数据块被传输到第二个设备。 因此，您实际上可以在您的主站点执行每日完整备份，并且只有新写入的独特块的大小必须通过WAN传送到站外

这里提到的使用rsync守护进程的人 – 这比通过ssh传输stream量要轻得多。 但即使使用ssh封装传输1.5TB过夜和饱和千兆位链接应该是可行的。

假设你有几个大的文件（可能是错误的假设） – 你应该能够在〜5h内传输有效载荷。 我做了一个快速testing：

 server:/mnt/big/tmp# rsync -av --progress root@otherServer:/big/file ./ receiving incremental file list file 1849044309 100% 74.47MB/s 0:00:23 (xfer#1, to-check=0/1) sent 30 bytes received 1849270109 bytes 75480413.84 bytes/sec total size is 1849044309 speedup is 1.00 

告诉ssh使用较轻的压缩方法：

 server:/mnt/big/tmp# rsync -e "ssh -c arcfour" -av --progress root@otherServer:/big/file ./ receiving incremental file list file 1849044309 100% 106.70MB/s 0:00:16 (xfer#1, to-check=0/1) sent 30 bytes received 1849270109 bytes 112076978.12 bytes/sec total size is 1849044309 speedup is 1.00 

所以假设存储不是瓶颈 – 在5小时内106MB / s〜350GB / h〜1.5TB。

这两个testing都是在Xeon E5430 @ 2.66GHz CPU的闲置机器上完成的。

为了让事情更有效率（如果CPU速度较慢，请使用多个核心），或者只使用更好的可用带宽和IO – 可以为几个文件运行less量并行rsync会话。

我不知道如果你拥有/租用光纤，或只是使用运营商提供的mpls服务，无论这些ssh给你额外的强encryption的好处，而无需设置中间的VPN。