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

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

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

目的地是空的，因此我不必担心有条件地更新某些文件。这些都是本地磁盘，因此我不必担心ssh或网络。

我之所以会不喜欢rsync，是因为rsync可能做的比我需要的更多。rsync校验和文件。我不需要它，并且担心它可能需要比cp更长的时间。

那么你估计，rsync还是cp？

我将使用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标志将“仅在SOURCE文件比目标文件新或缺少目标文件时复制”。并且-a（存档）标志将是递归的，如果您必须重新启动并保留权限，则不会重新复制文件。所以：

cp -au source dest

复制到本地文件系统时，我总是使用以下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)

我已经看到使用以上rsync设置比以下tar命令将传输速度提高了17％，这是另一个答案所建议的：

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

当我不得不复制大量数据时，通常会结合使用tar和rsync。第一步是将其焦油化，如下所示：

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

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

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

请注意，后面的斜杠/src/很重要。

同步

这是我使用的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 -

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

无论您喜欢什么。-a决定使用时，请不要忘记开关cp。

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

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

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

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

手册页还说：

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

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

rsync -aPhW --protocol=28通过RSYNC帮助加快大型副本的速度。我总是进行rsync，因为想到进入90GiB的途中，它的中断使我远离CP

rsync非常棒，但是对于大型目录树存在问题，因为它会将树存储在内存中。当我找到此线程时，我只是想看看他们是否可以解决此问题。

我还发现：

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

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

该线程非常有用，并且由于有太多选项可以实现结果，因此我决定对其中的几个进行基准测试。我相信我的结果可以帮助其他人更快地了解到什么。

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

• rsync 花了232分钟
• tar 花了206分钟
• cpio 花了225分钟
• rsync + parallel 花了209分钟

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

完整的基准测试在这里发布

在本地进行本地目录复制时，我的经验是“ cp -van src dest”比rsync快20％。至于可重启性，这就是“ -n”的作用。您只需要rm部分复制的文件。除非是ISO或类似的东西，否则不会感到痛苦。

ARJ太老了！！我真的怀疑ARJ和/或rsync是否会提高性能。

绝对我经常使用cpio：

find . -print | cpio -pdm /target/folder

这几乎比CP快，绝对比tar快，而且不需要任何管道。

您肯定想尝试rclone。这东西快疯了：

sudo rclone sync /usr /home/fred/temp -P -L --transfers 64

Transferred:       17.929G / 17.929 GBytes, 100%, 165.692 MBytes/s, ETA 0s
Errors:                75 (retrying may help)
Checks:            691078 / 691078, 100%
Transferred:       345539 / 345539, 100%
Elapsed time:     1m50.8s

这是LITEONIT LCS-256（256GB）SSD的本地副本。

您可以添加--ignore-checksum第一次运行以使其更快。

两者都可以正常工作。

tar 也可以完成这项工作，但不会像rsync那样从中断中恢复。

如果使用ARJ怎么办？

arj a -jm -m1 -r -je filepack /source

-jm -m1压缩级别在哪里并-je使其可执行。现在，您已封装了bash文件。

然后提取到目标地图

filepack -y  

生成源映射的位置-y（始终接受，覆盖，跳过等）

然后，如果可能的话，可以将文件包ftp ftp到目标区域并执行它。

有一些可以应用于的提速rsync：

避免

• -z/ --compress：压缩将只加载CPU，因为传输不是通过网络而是通过RAM。
• --append-verify：恢复中断的传输。这听起来像是个好主意，但它有一个危险的失败案例：任何大小等于或大于源的目标文件都将被忽略。同样，它在最后检查整个文件，这意味着--no-whole-file在添加危险的失败案例时不会明显加快速度。

采用

• -S/ --sparse：将空序列变成稀疏块
• --partial或者-P是--partial --progress：保存任何部分传输的文件以供将来恢复。注意：文件不会有临时名称，因此请确保在整个副本完成之前，没有其他期望使用目标的文件。
• --no-whole-file这样需要重新发送的任何内容都会使用增量传输。读取部分传输的文件的一半通常比重新写入要快得多。
• --inplace 避免文件复制（但前提是在整个传输完成之前没有任何内容读取目标）