在本地复制大型目录树？cp 还是 rsync？

Question

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

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

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

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

那你怎么看，rsync或者cp？

Answer 1

我会使用 rsync，因为这意味着如果它因任何原因被中断，那么您可以以很少的成本轻松地重新启动它。作为 rsync，它甚至可以通过一个大文件部分重启。正如其他人提到的，它可以轻松排除文件。保存大多数东西的最简单方法是使用-a标志——“归档”。所以：

rsync -a source dest

尽管 UID/GID 和符号链接由-a（请参阅-lpgo）保留，但您的问题暗示您可能需要文件系统信息的完整副本；并且-a不包括硬链接、扩展属性或 ACL（在 Linux 上）或以上内容，也不包括资源派生（在 OS X 上）。因此，对于文件系统的健壮副本，您需要包括这些标志：

rsync -aHAX source dest # Linux
rsync -aHE source dest  # OS X

默认 cp 将再次启动，尽管该-u标志将“仅在源文件比目标文件新或目标文件丢失时才复制”。-a如果您必须重新启动并保留权限，（归档）标志将是递归的，而不是重新复制文件。所以：

cp -au source dest

Answer 2

复制到本地文件系统时，我倾向于使用带有以下选项的 rsync：

# rsync -avhW --no-compress --progress /src/ /dst/

这是我的推理：

-a is for archive, which preserves ownership, permissions etc.
-v is for verbose, so I can see what's happening (optional)
-h is for human-readable, so the transfer rate and file sizes are easier to read (optional)
-W is for copying whole files only, without delta-xfer algorithm which should reduce CPU load
--no-compress as there's no lack of bandwidth between local devices
--progress so I can see the progress of large files (optional)

正如另一个答案所建议的那样，我已经看到通过以下 tar 命令使用上述 rsync 设置的传输速度提高了 17%：

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

Answer 3

当我必须复制大量数据时，我通常会使用 tar 和 rsync 的组合。第一遍是对它进行 tar 处理，如下所示：

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

通常对于大量文件，会有一些 tar 因任何原因无法处理。或者该过程可能会中断，或者如果它是文件系统迁移，您可能希望在实际迁移步骤之前进行初始复制。无论如何，在初始复制之后，我执行了一个 rsync 步骤来同步它：

# cd /dst; rsync -avPHSx --delete /src/ .

请注意，尾部斜杠/src/很重要。

Answer 4

同步

这是我使用的 rsync，我更喜欢 cp 用于简单命令，而不是这个。

$ rsync -ahSD --ignore-errors --force --delete --stats $SRC/ $DIR/

cpio

这是一种更安全的方法，cpio。它和 tar 一样快，也许快一点。

$ cd $SRC && find . -mount -depth -print0 2>/dev/null | cpio -0admp $DEST &>/dev/null

柏油

这也很好，并且在读取失败时继续。

$ tar --ignore-failed-read -C $SRC -cf - . | tar --ignore-failed-read -C $DEST -xf -

请注意，这些仅适用于本地副本。

Answer 5

这个线程非常有用，因为有很多选项可以实现结果，我决定对其中的几个进行基准测试。我相信我的结果可以帮助其他人了解什么工作得更快。

要移动532Gb之间分布数据的1753200个文件，我们有那些时间：

• rsync 耗时 232 分钟
• tar 耗时 206 分钟
• cpio 耗时 225 分钟
• rsync + parallel 耗时 209 分钟

就我而言，我更喜欢使用rsync + parallel. 我希望这些信息可以帮助更多人在这些替代方案中做出决定。

完整的基准发布在这里

Answer 6

无论你喜欢什么。只是不要忘了-a，当你决定要使用开关cp。

如果您真的需要答案：我会使用 rsync，因为它更灵活。复制完成前需要关机吗？只需 ctrl-c 并尽快恢复。需要排除一些文件？只需使用--exclude-from. 需要更改所有权或权限？rsync 会为你做到这一点。

Answer 7

该rsync命令始终计算其传输的每个字节的校验和。

命令行选项--checksum仅与文件校验和是否用于确定要传输的文件有关，即：

-c, --checksum 根据校验和跳过，而不是修改时间和大小”

手册页还说：

请注意，rsync 始终通过检查其整个文件校验和来验证每个传输的文件是否在接收端正确重建，但自动传输后验证与此选项的传输前“此文件是否需要要被更新？” 查看。

因此rsync，即使-c/ --checksum选项为“关闭” ，也始终在接收方计算整个文件的校验和。

Answer 8

rsync -aPhW --protocol=28使用 RSYNC 帮助加快这些大副本的速度。我总是使用 rsync，因为一想到要达到 90GiB 并且它会中断，我就害怕使用 CP

Answer 9

rsync 很棒，但在处理非常大的目录树时存在问题，因为它将树存储在内存中。当我发现这个线程时，我只是想看看他们是否会解决这个问题。

我还发现：

http://matthew.mceachen.us/geek/gigasync/

您还可以手动分解树并运行多个 rsync。