主页 / server / 问题 / 43014
Accepted
Amandasaurus
Asked: 2009-07-21 06:36:34 +0800 CST

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

  • 772

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

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

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

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

那么你认为呢，rsync或者cp？

linux file-transfer unix files rsync

18 个回答

  1. Best Answer

    我会使用 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
    • 258

  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)

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

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

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

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

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

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

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

    • 85

  4. rsync

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

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

    • 16

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

    为了移动分布在1,753,200 个文件中的532Gb数据，我们遇到了这样的情况：

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

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

    完整的基准在此处发布

    • 14

  6. 无论你喜欢什么。当您决定-a使用cp.

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

    • 7

  7. 该rsync命令总是在它传输的每个字节上计算校验和。

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

    -c, --checksum 根据校验和跳过，而不是 mod-time & size"

    手册页还说：

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

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

    • 7

  8. rsync -aPhW --protocol=28使用 RSYNC 有助于加快这些大型副本的速度。我总是使用 rsync，因为想到要通过 90GiB 并且它的中断让我害怕 CP

    • 6

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

    我还发现：

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

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

    • 5

  10. 你肯定想试试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第一次运行以使其更快。

    • 4

相关问题