在本地复制大型目录树? cp或rsync?

我必须复制大约1.8TB的大型目录树。 这都是本地的。 出于习惯,我会使用rsync ,但是我不知道是否有很多要点,如果我宁愿使用cp

我很担心权限和uid / gid,因为它们必须保存在副本中(我知道rsync是这样做的)。 以及像符号链接的东西。

目的地是空的,所以我不必担心有条件地更新一些文件。 这都是本地磁盘,所以我不必担心ssh或networking。

我之所以被rsync吸引,是因为rsync可能比我需要的要多。 rsync校验和文件。 我不需要这个,担心这可能需要比cp更长的时间。

那么你认为, rsynccp

我会使用rsync,因为这意味着如果由于任何原因而中断,那么您可以很轻松地重新启动它,只需很less的成本。 而作为rsync,它甚至可以重新启动一个大文件的一部分。 正如其他人所说,它可以轻松地排除文件。 保存大多数东西最简单的方法是使用-a标志 – “档案”。 所以:

 rsync -a source dest 

尽pipeUID / GID和符号链接由-a保存(请参阅-lpgo ),但您的问题意味着您可能需要完整的文件系统信息副本; -a不包括硬链接,扩展属性或ACL(在Linux上)或上述资源分支(在OS X上)。因此,对于文件系统的健壮副本,您需要包含这些标志:

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

默认的cp会再次启动,但-u标志只会在“源文件比目标文件更新或目标文件丢失时才复制” 。 而-a (归档)标志将recursion,而不是重新复制文件,如果你必须重新启动并保留权限。 所以:

 cp -au source dest 

当我不得不复制大量的数据时,我通常使用tar和rsync的组合。 第一遍是tar,像这样:

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

通常有大量的文件,会有一些tar无法处理的原因。 或者,也许进程会中断,或者如果是文件系统迁移,则可能需要在实际迁移步骤之前执行初始副本。 无论如何,在最初的拷贝之后,我做了一个rsync步骤来同步它:

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

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

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

rsync的

这里是我使用的rsync,我更喜欢简单的命令,而不是这个。

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

的cpio

这是一个更安全的方式,cpio。 它和焦油一样快,也许快一点。

 $ 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 - 

注意这些都是本地拷贝。

rsync -aPhW --protocol=28有助于使用RSYNC加速这些大型副本。 我总是去rsync,因为90GiB中途的想法,它打破了我离开CP

不pipe你喜欢什么 当您决定使用cp时,请不要忘记-a开关。

如果你真的需要一个答案:我会使用rsync,因为它更灵活。 复制完成之前需要closures吗? 只需按Ctrl-C,并尽快恢复。 需要排除一些文件? 只要使用--exclude-from 。 需要改变所有权或权限? rsync会为你做到这一点。

rsync非常棒,但是由于它将树存储在内存中,所以会遇到真正大的目录树的问题。 我只是想看看他们是否会解决这个问题,当我发现这个线程。

我还发现:

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

你也可以手动分解树并运行多个rsyncs。

rsync总是校验和传输的每个字节。

校验和命令行选项只涉及是否使用文件校验和来确定要传输的文件,即:

“-c, – 基于校验和的校验跳过,而不是mod-time&size”

该手册还说这个:

“请注意,rsync总是通过检查其全文校验和来validation每个传输的文件是否在接收端被正确地重build,但是传输之后的自动validation与该选项在传输之前没有任何关系。”此文件需要更新?“检查”。

所以rsync也一样,即使在-c / –checksum选项closures的情况下,也总是在接收端计算整个文件的校验和。

当做一个本地目录拷贝时,我的经验是“cp -van src dest”比rsync快了20%。 就可重启性而言,这就是“-n”所做的。 你只需要rm部分复制的文件。 不痛苦,除非它是一个ISO或一些这样的。

ARJ就是这么老的学校! 我真的怀疑,ARJ和/或rsync会给性能。

绝对我总是做的是使用cpio:

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

这比CP快得多,肯定比焦油还要快,而且没有任何pipe道。

这个线程是非常有用的,因为有这么多的选项来实现的结果,我决定基准其中几个。 我相信我的结果可以帮助别人有一个更快的工作感。

为了移动分布在1753200个文件中的532Gb数据,我们有了那些时间:

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

在我的情况下,我更喜欢使用rsync + parallel 。 我希望这些信息能帮助更多的人select这些替代品。

完整的基准在这里发布

两者都可以正常工作。

tar也会做这个工作,但不会像rsync那样会被打断。

如果你使用ARJ呢?

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

其中-jm -m1是压缩级别, -je使其成为可执行文件。 现在你有一个封装的文件的bash。

然后提取到目标地图

 filepack -y 

源地图将在哪里制作(其中-y总是接受,覆盖,跳过等)

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