rsync，但是我想知道是否有很多用处，是否应该使用cp。在副本中（我知道rsync会这样做）。以及符号链接之类的东西。目标为空，因此我不必担心有条件地更新某些文件。这都是本地磁盘，因此我不必担心ssh或网络。 rsync校验和文件。我不需要它，并且担心它可能需要比cp更长的时间。
那么
rsync或cp您认为呢？#1 楼
我将使用rsync，因为这意味着如果它由于任何原因被中断，那么您可以以很少的成本轻松地重新启动它。而且由于是rsync，它甚至可以通过大文件部分重启。正如其他人提到的那样，它可以轻松排除文件。保留大多数内容的最简单方法是使用-a标志-“ archive”。因此：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
评论
cp的-u标志可能不是最佳解决方案，因为它不会检测到部分复制/损坏的文件。关于rsync的好处是，您可以让md5对文件求和以检测差异。
–乍得·休尼库特（Chad Huneycutt）
09年7月20日在15:10
实际上，rsync可以检测本地传输并启用整个文件复制，而无需自动进行校验和。
–科克曼
2012年10月8日在22:49
和--progress这真的很方便！
–马特
2012年11月28日，3:20
-P或--progress分别显示每个文件的进度。它对于复制大文件很有用，而不是复制许多（数千个）小文件，因为这意味着您将读取更多的输出。它不会显示所有合并文件的总体进度。
– SPRBRN
13年10月10日在8:56
@SPRBRN自rsync版本3.1.0起，它支持rsync --info = progress2，它确实显示了传输的总体进度（尽其所能）。有助于在大传输时给出近似值。
– rlf
17年7月11日在14:33
#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 -)
评论
我遇到以下错误：rsync：--no-compress：未知选项@Ellis Percival。
–警报
18 Mar 3 '18 at 16:31
像@alper一样，--no-compress不是我的rsync版本的选项（在CentOS 7中）；我改用--compress-level = 0。
– Paul
18年7月30日在23:25
以上解决方案-在Mac上为compress-level = 0
–μon
9月11日在1:16
#3 楼
当我不得不复制大量数据时，通常会结合使用tar和rsync。首先是要对其进行tar处理，如下所示：# (cd /src; tar cf - .) | (cd /dst; tar xpf -)
通常，由于文件数量很多，由于某些原因，有些tar无法处理。也许该过程将被中断，或者如果它是文件系统迁移，则您可能需要在实际迁移步骤之前进行初始复制。无论如何，在初始复制之后，我会执行rsync步骤来同步所有内容：
# cd /dst; rsync -avPHSx --delete /src/ .
请注意，
/src/上的斜杠很重要。评论
+1我发现大拷贝的tar通常比rsync快。我也喜欢用最终的rsync结束的想法。
–杰夫·弗里茨（Geoff Fritz）
09年7月20日在16:14
如果目标目录为空，则tar是一个不错的选择。尽管我的方式是：cd $ DSTDIR; tar c -C $ SRCDIR。 |柏油
– asdmin
09年7月20日在19:39
这就是这种方法的优点。您不需要加倍空间，因为您实际上从未创建过中间tar文件。管道之前的tar将数据打包并将其流传输到stdout，管道之后的tar从stdin抓取数据并将其解压缩。
–乍得·休尼库特（Chad Huneycutt）
2012年5月10日0:45
我为12gb的传输做了cp -a，对于42gb的传输做了这种方法。焦油法大约需要1/4的时间。
– NGaida
2014年5月23日在17:20
我还将pv放在中间，以便能够观察进度，并使用df估算所有数据的大小。我还使用了--numeric-owner，因为源磁盘是来自另一个系统，并且我不想tar弄乱所有者：tar -C / old-path --numeric-owner -S -c。 | pv -tpeba -s 100G | tar -C /新路径-数字所有者-S -xp
–石油
16年11月5日在16:47
#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 -
请注意，这些均仅用于本地副本。
评论
为什么要对rsync使用-S和-D标志？
– miyalys
15年7月14日在11:37
D保留Specials和System文件，而S“有效地处理稀疏文件”不确定默认情况下rsync为什么不这样做。
–小马克·卡彭特（Mark Carpenter Jr）
3月16日14:50
#5 楼
该线程非常有用，并且由于有太多选项可以实现结果，因此我决定对其中的几个进行基准测试。我相信我的结果可以使其他人了解更快地工作的方法。 >rsync花了232分钟tar花了206分钟cpio花了225分钟rsync + parallel花了209分钟就我而言，我更喜欢使用
rsync + parallel。我希望这些信息可以帮助更多的人在这些替代方案中做出选择。完整的基准测试在此处发布
评论
404页面不存在
– Amedee Van Gasse
18 Mar 6 '18 at 9:01
谢谢@AmedeeVanGasse URL在您报告后不久已得到解决:)
– arjones
18年4月10日在1:05
为什么不对cp进行基准测试？这是问题的标题！
– calandoa
18年4月17日在13:45
@calandoa我认为cp是不安全的，即：当它中断时，您必须重新开始，这就是我喜欢可以恢复的选项的方式，ergo rsync是我的最爱:)
– arjones
18年4月19日在20:07
在70GB的文件系统上，具有48GB的数据-块大小1024-具有385000个文件和427730个目录-cp比rsync和find + cpio快约3分钟。 18m30s至22min。
– sastorsl
5月27日13:04
#6 楼
无论您喜欢什么。只是在决定使用-a时不要忘记cp开关。如果您确实需要答案：我会使用rsync，因为它更加灵活。需要在复制完成之前关闭吗？只需按ctrl-c，然后尽快恢复。需要排除一些文件吗？只需使用--exclude-from即可。需要更改所有权或权限吗？ rsync将为您做到这一点。评论
-p标志又做什么？
–罗里
09年7月20日在15:32
它将保留服务器的所有权，时间戳和权限。
– innaM
09年7月20日在15:34
cp -a会更好。
– David Pashley
09年7月20日在15:36
确实。答案相应更改。
– innaM
09年7月20日在15:53
#7 楼
rsync命令始终在其传输的每个字节上计算校验和。 命令行选项
--checksum仅与文件的校验和是否用于确定要传输的文件有关，即：-c, --checksum根据校验和跳过，而不是修改时间和大小” 该联机帮助页还说：
请注意，rsync始终会验证每个传输的文件是否正确重建在接收方通过检查其整个文件的校验和来进行确认，但是自动转移后验证与此选项的转移前“是否需要更新此文件？”检查无关。
因此，即使
rsync选项为“ off”，-c/ --checksum也会始终在接收方计算整个文件的校验和。评论
尽管您的帖子在此处添加了一些有趣的信息，但咆哮和侮辱降低了帖子的价值。该网站不是非建设性人士的论坛。如果您能够修改源，那么您是否已将修改作为补丁提交？您是否在github上发布了版本？如果您对此有强烈的信心，那么尝试做一些更具建设性的事情，而不是不必要地侮辱，可能会更好。
– Zoredache
2012年11月29日在21:31
是的，最后一段不是真正必要的。
– Sherwin Flight
2015年10月25日，下午3:57
#8 楼
rsync -aPhW --protocol=28通过RSYNC帮助加快那些大型副本的速度。我始终会进行rsync，因为想到进入90GiB的途中，这种想法使我远离了CP 评论
在该命令字符串中使用旧协议的价值是什么？
–ewwhite
09年11月28日在3:10
在Mac机器上，出厂时的Rsync较旧版本挂在某些较新的rsync协议修订版（例如29）上。告诉它移至较旧的协议，使其不会反复检查。
–oneguynick
2010年1月3日，下午5:52
我猜这个数字28不再有效了吗？
– SPRBRN
13年7月10日在8:59
#9 楼
rsync非常棒，但是对于大型目录树却存在问题，因为它会将树存储在内存中。当我找到此线程时，我只是想看看他们是否可以解决此问题。我还发现：
http://matthew.mceachen.us/geek/gigasync/
您还可以手动分解树并运行多个rsync。
评论
如果使用版本3，则如果版本3很大，它不会将整个树保留在内存中，而是使用增量递归算法：samba.org/ftp/rsync/src/rsync-3.0.0-NEWS
–凯尔·勃兰特（Kyle Brandt）
09年7月20日在17:09
#10 楼
在本地进行本地目录复制时，我的经验是“ cp -van src dest”比rsync快20％。至于可重启性，这就是“ -n”的作用。您只需要rm部分复制的文件。除非是ISO或类似的东西，否则不会感到痛苦。#11 楼
您肯定想尝试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，以使其更快。#12 楼
tar也可以完成这项工作，但不会像rsync那样从中断中恢复。评论
一个旧的答案，但是TAR不是用于创建文件压缩归档的文件吗？如何将其用于传输rsync或cp等文件？
– Sherwin Flight
2015年10月25日下午4:01
@SherwinFlight CD来源; tar cf-。 | （cd dest; tar xf-）
–pgs
15-10-26在6:12
#13 楼
ARJ太老了！我真的怀疑ARJ和/或rsync是否会提高性能。绝对可以，我总是使用cpio：
评论
“原始的cpio和find实用程序是由Dick Haight在AT＆T的Unix支持小组工作时编写的。它们最初出现在1977年的PWB / UNIX 1.0中”-FreeBSD的cpio手册页。
–克里斯S
2012年9月21日，下午2:54
不幸的是，cpio的文件上限为8GB。
–user139948
2012年10月6日在21:24
“没有任何管道” [原文如此]。除了上面列出的find命令以外，其中还有一个管道：find。打印cpio -pdm / target /文件夹
–沃伦
2015年10月7日在17:15
#14 楼
对于需要在两个本地挂载之间复制大量小文件的人（在我的情况下，这是来自云提供商的NAS服务的两个NFS挂载）：cp非常慢。观察网络吞吐量时，我发现它只能饱和大约1 mbps的带宽。然后我尝试使用tar：tar -pc /mnt/old-nas | tar -xpf - -C /mnt/new-nas ，它可以使线路完全饱和，介于250-300 mbps之间。
在两个具有高延迟的安装点之间进行复制时，Tar的性能似乎要好得多。
#15 楼
两者都可以正常工作。#16 楼
如果使用ARJ，该怎么办？arj a -jm -m1 -r -je filepack /source
其中
-jm -m1是压缩级别，而-je使其成为可执行文件。现在您有了一个封装的bash文件。 -y始终接受，覆盖，跳过等）。然后可以将文件包ftp ftp到目标区域并执行（如果可能的话）。
评论
阿吉那不是在80年代消失了吗？
–迈克尔·汉普顿
2012年11月26日在22:02
如果您相信维基百科，也许是90年代初期
–马特
2012年11月28日，下午3:22
假定您有50％的可用磁盘空间用于生成的文件，这在我尝试传输nas时不正确，其次，为什么我不只是做tar文件？
–索伦
11月15日下午16:51
#17 楼
有一些可以应用于rsync的提速方法：避免
传输不是通过网络而是通过RAM。
-z：恢复中断的传输。这听起来像是个好主意，但有一个危险的失败案例：大小等于或大于源的任何目标文件都将被忽略。而且，它会在最后检查整个文件，这意味着在添加危险故障案例的同时，不会明显超过--compress。 使用
--append-verify / --no-whole-file：将空序列转换为稀疏块-S或--sparse，即--partial ：保存任何部分传输的文件以供将来恢复。注意：文件不会具有临时名称，因此请确保在整个副本完成之前，没有其他人期望使用目标。-P，以便需要重发的任何内容都使用增量传输。读取部分传输的文件的一半通常比重新写入要快得多。--partial --progress避免文件复制（但前提是在整个传输完成之前什么都没有读取目标） />#18 楼
如果两个存储都在本地，则cp应该以最大可能的速度传输数据。如果目标目录为空，则不必使用同步器，但是它带来了诸如可重新启动性，排除某些文件的可能性等优点。rsync在通过网络复制（大文件的增量传输）方面很强大）。但是rsync将其内部数据保留在内存中，这可能会导致巨大的目录树出现问题。
如果您对另一个同步器感兴趣，则可以看看Fitus / Zaloha.sh。它在两个目录上都运行find，并使用cp命令准备脚本。它将内部数据保存在文件中，而不是内存中。它的用法如下：
$ Zaloha.sh --sourceDir="test_source" --backupDir="test_backup"
如果您希望它仅生成cp脚本（但不执行它，则需要大量的显示和交互），请使用--noExec选项。
您的用例大概不需要生成还原脚本：请使用--noRestore选项。最后，如果您安装了快速的mawk，请通过--mawk选项使用它。
评论
如果rsync完全按照您的要求进行操作，如果您已经非常熟悉该特定应用程序的用法，并且它的运行速度足够快以适合您的口味，那么到底为什么要切换？因为我担心rsync会比cp花费更长的时间，因为rsync会做很多校验，以确保cp不会执行
与磁盘/网络I / O相比，校验和的CPU开销很小。除非磁盘位于同一系统上，并且操作系统可以在总线控制器中执行一些巧妙的驱动器驱动器复制。
对大小和时间戳检查不同的文件进行校验和。如果您偏执（例如在复制过程中停电之后），则可以对所有文件强制执行校验和，但是在本地传输时，通常比从头开始要慢。
也许他对改善自己的工作流程感到好奇，并没有以为自己知道一切就把头埋在沙子里。这句话让我很烦。