标签: file-transfer

我必须复制一个大目录树，大约 1.8 TB。都是本地的。出于习惯，我会使用rsync，但是我想知道是否有很多意义，以及我是否应该使用cp.

我担心权限和 uid/gid，因为它们必须保留在副本中（我知道 rsync 会这样做）。以及符号链接之类的东西。

目的地是空的，所以我不必担心有条件地更新一些文件。都是本地磁盘，所以不用担心ssh或网络。

我不想使用 rsync 的原因是因为 rsync 可能做的比我需要的多。rsync 校验和文件。我不需要那个，我担心它可能需要比 cp 更长的时间。

那你怎么看，rsync或者cp？

我正在尝试将robocopy单个文件从一个位置传输到另一个位置，但robocopy似乎认为我总是在指定一个文件夹。下面是一个例子：

robocopy "c:\transfer_this.txt" "z:\transferred.txt"

但是我收到了这个错误：

2009/08/11 15:21:57 ERROR 123 (0x0000007B) Accessing Source Directory c:\transfer_this.txt\

（注意\末尾的transfer_this.txt）

但如果我把它当作一个完整的文件夹：

robocopy "c:\folder" "z:\folder"

它有效，但随后我必须传输文件夹中的所有内容。

我怎样才能只传输一个文件robocopy？

我需要在两个服务器 (Ubuntu) 之间传输大量 mp3。我所说的巨大是指大约一百万个平均为 300K 的文件。我尝试过，scp但大约需要一周时间。（大约 500 KB/s）如果我通过 HTTP 传输单个文件，我得到 9-10 MB/s，但我不知道如何传输所有文件。

有没有办法快速转移所有这些？

我正在将我的服务器从美国迁移到英国，从一个数据中心迁移到另一个数据中心。我的主持人说我应该能够达到每秒 11 兆字节。

操作系统为两端的Windows Server 2008。

我的平均文件大小约为 100 MB，数据分布在五个 2 TB 驱动器上。

传输这些文件的推荐方式是什么？

• FTP
• 中小企业
• Rsync / Robocopy
• 其他？

我不太担心安全性，因为无论如何这些都是公共文件，但我只是想要一个可以推动完整 11 MB/s 传输速率以最小化总传输时间的解决方案。

我正在将数据从一台服务器归档到另一台服务器。最初我开始了rsync一份工作。仅为 5 TB 数据构建文件列表就花了 2 周时间，而传输 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 进行条带化。但是，现在我了解了我将来可以使用的所有这些不错的工具。

我目前有两台 CentOS 服务器。我需要知道如何以及最快的方法是“tar”图像目录并对其进行 SCP 处理？

这是我刚刚建议的最快方法吗，因为 tarring 需要永远......我运行了命令：

tar cvf imagesbackup.tar images

我打算把它scp过去。

让我知道是否有更快的方法。我可以远程/SSH 访问两台机器。

我使用rsync的越多，我就越意识到它是文件传输的瑞士军刀。有很多选择。我最近发现你可以去--remove-source-files，当它被复制时，它会从源中删除一个文件，这使它更像是一个移动，而不是复制程序。:)

你最喜欢的 rsync 小技巧和窍门是什么？

是否有可用于 Windows 的 ssh-copy-id 的等效项或端口？也就是说，有没有一种简单的方法可以在 Windows 下将 SSH 密钥从本地机器传输到远程服务器？

如果有帮助，我已经在使用 Pageant 和Kitty（一种腻子替代品）。

我正在将我的桌面备份到远程机器。我基本上是在做rsync -a ~ example.com:backup/但是有大量的大文件，例如维基百科转储等。我关心的大多数文件都很小，例如 firefox cookie 文件，或.bashrc. 是否有一些对 rsync 的调用会排除超过特定大小的文件？这样我就可以先复制所有小于 10MB 的文件，然后再复制所有文件。这样我就可以对最重要的文件进行快速备份，然后对其他所有文件进行更长的备份。

这看起来与这个有关，但又有些不同。

两个公司站点之间有这个 WAN 链接，我们需要传输一个非常大的文件（Oracle 转储，~160 GB）。

我们有完整的 100 Mbps 带宽（已测试），但由于 TCP 的工作方式（ACK 等），单个 TCP 连接似乎无法将其最大化。我们使用iperf测试了链接，当增加 TCP 窗口大小时，结果发生了显着变化：使用基本设置，我们可以获得 ~5 Mbps 的吞吐量，使用更大的 WS，我们可以获得 ~45 Mbps，但仅此而已。网络延迟约为 10 毫秒。

出于好奇，我们使用多个连接运行 iperf，我们发现，当运行四个连接时，它们确实每个都能达到约 25 Mbps 的速度，填满所有可用带宽；所以关键似乎在于运行多个同时传输。

使用 FTP，情况变得更糟：即使使用优化的 TCP 设置（高窗口大小、最大 MTU 等），我们在单次传输中也无法获得超过 20 Mbps 的速度。我们尝试同时 FTP 传输一些大文件，确实比传输单个文件要好得多；但后来罪魁祸首变成了磁盘 I/O，因为从同一个磁盘读取和写入四个大文件很快就会遇到瓶颈；此外，我们似乎无法将单个大文件拆分为较小的文件然后将其合并回来，至少不能在可接受的时间内（显然我们不能将拼接/合并回文件的时间与转让）。

这里理想的解决方案是一个多线程工具，可以同时传输文件的各个块；有点像 eMule 或 BitTorrent 等点对点程序已经这样做了，但是从单一来源到单一目的地。理想情况下，该工具将允许我们选择要使用的并行连接数，当然还可以优化磁盘 I/O，以免（太）在文件的各个部分之间疯狂跳转。

有谁知道这样的工具？

或者，有人可以提出更好的解决方案和/或我们已经没有尝试过的方法吗？

PS 我们已经考虑将其备份到磁带/磁盘并将其物理发送到目的地；如果 WAN 不切断它，那将是我们的极端措施，但是，正如 AS Tanenbaum 所说，“永远不要低估一辆装满磁带的旅行车在高速公路上疾驰的带宽。”