如何在两台服务器之间快速复制大量文件
nic*_*tro 110 linux performance file-transfer
我需要在两个服务器 (Ubuntu) 之间传输大量 mp3。我所说的巨大是指大约一百万个平均为 300K 的文件。我尝试过，scp但大约需要一周时间。（大约 500 KB/s）如果我通过 HTTP 传输单个文件，我得到 9-10 MB/s，但我不知道如何传输所有文件。
有没有办法快速转移所有这些？
Sco*_*ack 140
我会推荐焦油。当文件树已经相似时，rsync 表现得非常好。但是，由于 rsync 会对每个文件进行多次分析，然后复制更改，因此它比初始复制的 tar 慢得多。此命令可能会执行您想要的操作。它将在机器之间复制文件，并保留权限和用户/组所有权。
tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'
根据下面 Mackintosh 的评论，这是您将用于 rsync 的命令
rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir
- +1 tar 选项对于大量小文件的效率要高得多，因为 scp 和 rsync 都会在网络上为每个文件进行更多的往返。 (4认同)
- 此外，如果您有足够的 CPU 可用（两端），但（至少）主机之间的链接较慢，则可能值得在 tar 命令中启用压缩（gzip 或 bzip）。 (4认同)
- @niXar `~` 转义字符仅在 SSH 使用终端时启用。当您指定远程命令时，情况并非如此（除非您传递了 `-t` 选项）。所以你的担心是无效的。 (4认同)
- rsync 比 tar 更适合我 (3认同)
Ada*_*dam 51
外置硬盘驱动器和当日快递。
- Heh heh... 没有什么网络技术比装载磁带的旅行车的带宽能以 90 MPH 的速度运行，是吗？（窃笑）我以为他在 LAN 上，因为他说他使用 HTTP 获得了 9-10MB/秒的速度。 (14认同)
- 我在互联网上获得了那种速度，但我很幸运我住的地方！如果它在局域网上，那么更便宜！ (3认同)
- 啊——没看你的位置。是的——我听说韩国的互联网连接非常壮观。被困在美国，我很高兴通过“网络”获得 900KB/秒的速度…… (3认同)
- 是的，但是您可以在等待下载完成的同时获得美味的墨西哥卷饼，即使在首尔也只有大约三家半体面的墨西哥餐厅...... (3认同)
Eva*_*son 17
我会使用 rsync。
如果您已经通过 HTTP 将它们导出并提供了目录列表，您也可以使用 wget 和 --mirror 参数。
您已经看到 HTTP 比 SCP 更快，因为 SCP 正在加密所有内容（因此成为 CPU 的瓶颈）。HTTP 和 rsync 将变得更快，因为它们没有加密。
以下是在 Ubuntu 上设置 rsync 的一些文档：https : //help.ubuntu.com/community/rsync
这些文档讨论了通过 SSH 隧道传输 rsync，但如果您只是在专用 LAN 上移动数据，则不需要 SSH。（我假设您在专用 LAN 上。如果您通过 Internet 获得 9-10MB/秒的速度，那么我想知道您有什么样的连接！）
以下是一些其他非常基本的文档，它们将允许您设置相对不安全的 rsync 服务器（不依赖于 SSH）：http : //transamrit.net/docs/rsync/
- “您已经看到 HTTP 比 SCP 快，因为 SCP 正在加密所有内容”→ 错误。除非他有 10 年的旧服务器，否则他在这项任务上不受 CPU 限制。 (3认同)
- @RamazanPOLAT - 你的命令行太长了。以不同的方式指定文件选择，它会很适合您。通常，您可以仅在末尾指定带通配符的源目录。您还可以使用“--include”和“--exclude”参数来获得更多细微差别。 (2认同)
Ica*_*pan 17
闲话少说，用netcat，网络瑞士刀。没有协议开销，您直接复制到网络套接字。例子
srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321
srv2$ nc -l -p 4321 |tar xfv -
- 如果您在私有 vlan 和/或通过 VPN 等安全环境中执行此操作，@niXar netcat 很好。 (3认同)
- 不幸的是，从我所注意到的 netcat 效率很低，即使它不应该如此。 (2认同)
- @niXar：如果您只想传输单个文件（无需进一步同步），那么 tarpipe 就是您所需要的。 (2认同)
- netcat 非常适合安全环境，直到您有点颠簸并且整个 1TB 流都很糟糕。我有一个像这样的复杂脚本，带有并行压缩、进度输出（通过 `pv`）和通过 `sha512sum` 进行完整性检查，但是一旦翻转了一点，整个流就坏了，因为无法恢复它。当我们需要低开销时，我们真正需要的是一种轻量级协议，例如用于这些安全环境的流 torrent —— 将检查块（例如，4MB）级别的完整性并在一个块失败时重新发送块的东西。TCP crc 不够强大。 (2认同)
如果您确实使用 rsync，有很多文件，我会尝试在两端都获得版本 3 或更高版本。原因是较小的版本将在开始传输之前枚举每个文件。新功能称为增量递归。
当 rsync 与另一个 3.x 版本通信时，现在使用新的增量递归算法。这会更快地启动传输（在找到所有文件之前），并且需要更少的内存。有关一些限制，请参阅联机帮助页中的 --recursive 选项。
昨天在移动 80 TB 数据（数百万个小文件）时，从 切换rsync到tar 被证明要快得多，因为我们停止尝试
# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01
并切换到tar...
# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/
由于这些服务器位于同一个 LAN 上，因此目标在执行推送的源系统上安装了 NFS。不让它更快，我们决定不保留atime文件：
mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01
下图描述了从 rsync 更改为 tar 的差异。这是我老板的主意，我的同事都执行了它，并在他的博客上写了一篇很棒的文章。我只是喜欢漂亮的图片。:)
rsync，就像其他人已经推荐的那样。如果加密的 CPU 开销是瓶颈，请使用另一种 CPU 密集程度较低的算法，例如河豚。例如类似的东西
rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path
小智 5
在复制大量文件时，我发现 tar 和 rsync 等工具的效率比它们需要的要低，因为打开和关闭许多文件的开销很大。我写了一个名为 fast-archiver 的开源工具，对于这些场景比 tar 更快：https : //github.com/replicon/fast-archiver；它通过执行多个并发文件操作来更快地工作。
这是在备份超过 200 万个文件时使用快速归档程序与 tar 的示例；fast-archiver 需要 27 分钟来存档，而 tar 需要 1 小时 23 分钟。
$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps
$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps
要在服务器之间传输文件，您可以使用带有 ssh 的快速归档程序，如下所示：
ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x
| 归档时间： |
|
| 查看次数： |
196441 次 |
| 最近记录： |