rsync网络不稳定情况下的大文件传输
由于本人供职的公司提供单机游戏的下载,而单机游戏一般都较大,我们使用了rsync把本地服务器(本地仓库)同步到外国服务器(国外仓库)最后再同步到国外的web前端服务器。
然而总是有某些原因导致外国的有些服务器网络不稳定,再加上同步的文件都较大(30多G的也经常有)。当我们使用rsync -avzP这个命令也会有卡死的时候,那么不妨使用下面的三个参数。
分别为:--inplace , --append ,--append-verify 。具体选哪一个根据实际情况吧。
--inplace
This option changes how rsync transfers a file when its data needs to be updated: instead of the default method of creating a new copy of the file and moving it into place when it is com‐
plete, rsync instead writes the updated data directly to the destination file.
This has several effects:
o Hard links are not broken. This means the new data will be visible through other hard links to the destination file. Moreover, attempts to copy differing source files onto a mul‐
tiply-linked destination file will result in a "tug of war" with the destination data changing back and forth.
o In-use binaries cannot be updated (either the OS will prevent this from happening, or binaries that attempt to swap-in their data will misbehave or crash).
o The file’s data will be in an inconsistent state during the transfer and will be left that way if the transfer is interrupted or if an update fails.
o A file that rsync cannot write to cannot be updated. While a super user can update any file, a normal user needs to be granted write permission for the open of the file for writing
to be successful.
o The efficiency of rsync’s delta-transfer algorithm may be reduced if some data in the destination file is overwritten before it can be copied to a position later in the file. This
does not apply if you use --backup, since rsync is smart enough to use the backup file as the basis file for the transfer.
WARNING: you should not use this option to update files that are being accessed by others, so be careful when choosing to use this for a copy.
This option is useful for transferring large files with block-based changes or appended data, and also on systems that are disk bound, not network bound. It can also help keep a
copy-on-write filesystem snapshot from diverging the entire contents of a file that only has minor changes.
The option implies --partial (since an interrupted transfer does not delete the file), but conflicts with --partial-dir and --delay-updates. Prior to rsync 2.6.4 --inplace was also
incompatible with --compare-dest and --link-dest.
--inplace
此选项会更改rsync在需要更新数据时传输文件的方式:而不是创建文件的新副本的默认方法,并将其移动到完整的位置时,rsync会将更新的数据直接写入目标文件。
这有几个效果:
硬链接不坏。这意味着新数据将通过到目标文件的其他硬链接可见。此外,尝试将不同的源文件复制到多重连接的目标文件将导致目的地数据来回变化的“拔河”。
不能更新使用中的二进制文件(操作系统将防止这种情况发生,或者尝试交换数据的二进制文件将不正常或崩溃)。
文件的数据在传输过程中将处于不一致的状态,如果传输中断或更新失败,将保留该文件的数据。
rsync无法写入的文件无法更新。当超级用户可以更新任何文件时,需要为正常用户授予写入许可,以便文件的打开成功。
如果目标文件中的某些数据被复制到文件中稍后的位置,则rsync的delta传输算法的效率可能会降低。如果使用--backup,这不适用,因为rsync足够聪明,可以将备份文件用作传输的基础文件。
警告:您不应该使用此选项来更新其他人正在访问的文件,因此在选择将其用于副本时请小心。
此选项对于使用基于块的更改或附加数据以及在磁盘绑定而不是网络绑定的系统上传输大型文件非常有用。它还可以帮助保持写时复制文件系统快照,从而分散只有轻微更改的文件的整个内容。
该选项意味着--partial(因为中断的传输不会删除该文件),而是与--partial-dir和--delay更新冲突。之前的rsync 2.6.4 --inplace也与--compare-dest 和--link-dest不兼容。
--append
This causes rsync to update a file by appending data onto the end of the file, which presumes that the data that already exists on the receiving side is identical with the start of the
file on the sending side. If a file needs to be transferred and its size on the receiver is the same or longer than the size on the sender, the file is skipped. This does not interfere
with the updating of a file’s non-content attributes (e.g. permissions, ownership, etc.) when the file does not need to be transferred, nor does it affect the updating of any non-regular
files. Implies --inplace, but does not conflict with --sparse (since it is always extending a file’s length).
--append
这导致rsync通过将数据附加到文件的末尾来更新文件,这假定接收方已经存在的数据与发送方的文件的开头相同。如果文件需要传输,并且其在接收器上的大小与发件人的大小相同或更长,则会跳过该文件。这不会影响文件的非内容属性(例如权限,所有权等)的更新,而不需要传输文件,也不会影响任何非常规文件的更新。言下之意--inplace,但并不冲突--sparse(因为它总是扩展文件的长度)。
如果您不是100%确定更长的文件只能通过将数据附加到最后才能 使用--append可能是危险的。因此,您应该使用include / exclude / filter规则来确保这样的传输仅影响您通过附加数据增长的文件。
--append-verify
This works just like the --append option, but the existing data on the receiving side is included in the full-file checksum verification step, which will cause a file to be resent if the
final verification step fails (rsync uses a normal, non-appending --inplace transfer for the resend).
Note: prior to rsync 3.0.0, the --append option worked like --append-verify, so if you are interacting with an older rsync (or the transfer is using a protocol prior to 30), specifying
either append option will initiate an --append-verify transfer.
--append-verify
这可以像--append选项一样工作,但接收方的现有数据包含在全文件校验和验证步骤中,如果最终验证步骤失败,则会导致重新发送文件(rsync使用正常,非- 重新发送 - 内部传输)。
注:rsync的3.0.0之前,--append选项工作就像 --append-verify,因此,如果您正在使用的旧rsync的相互作用(或转让使用前30的协议),则指定附加选项将启动一个-接受验证传输。
这里给几个示例:
rsync -avzP --append-verify --chmod=ugo=rwx --password-file=/etc/rsyncd.down --port=19873 sync-cdl8.gamersky.cn::gamerskyPcgameCdl8 /home/gamersky/pcgame/cdl8
rsync -avz --inplace --progress --chmod=ugo=rwx --password-file=/etc/rsyncd.down --port=19873 sync-guowai2.gamersky.cn::gamerskyPcgameXcd /home/gamersky/pcgame/xcd
rsync -avzP --append --chmod=ugo=rwx --password-file=/etc/rsyncd.down --port=19873 sync-cdl8.gamersky.cn::gamerskyPcgameCdl8 /home/gamersky/pcgame/cdl8
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
以下为rsync -P参数的一些相关解释
--partial
By default, rsync will delete any partially transferred file if the transfer is interrupted. In some circumstances it is more desirable to keep partially transferred files. Using the
--partial option tells rsync to keep the partial file which should make a subsequent transfer of the rest of the file much faster.
--partial
默认情况下,如果传输中断,rsync将删除任何部分传输的文件。在某些情况下,更需要保留部分传输的文件。使用 --partial选项告诉rsync保留部分文件,这应该使文件的其余部分的后续传输更快。
-P The -P option is equivalent to --partial --progress. Its purpose is to make it much easier to specify these two options for a long transfer that may be interrupted.
-P 该-P选项相当于--partial --progress。其目的是为了更容易地指定这两个可能被中断的长传输的选项。
--progress
This option tells rsync to print information showing the progress of the transfer. This gives a bored user something to watch. Implies --verbose if it wasn’t already specified.
While rsync is transferring a regular file, it updates a progress line that looks like this:
782448 63% 110.64kB/s 0:00:04
In this example, the receiver has reconstructed 782448 bytes or 63% of the sender’s file, which is being reconstructed at a rate of 110.64 kilobytes per second, and the transfer will fin‐
ish in 4 seconds if the current rate is maintained until the end.
These statistics can be misleading if rsync’s delta-transfer algorithm is in use. For example, if the sender’s file consists of the basis file followed by additional data, the reported
rate will probably drop dramatically when the receiver gets to the literal data, and the transfer will probably take much longer to finish than the receiver estimated as it was finishing
the matched part of the file.
When the file transfer finishes, rsync replaces the progress line with a summary line that looks like this:
1238099 100% 146.38kB/s 0:00:08 (xfer#5, to-check=169/396)
In this example, the file was 1238099 bytes long in total, the average rate of transfer for the whole file was 146.38 kilobytes per second over the 8 seconds that it took to complete, it
was the 5th transfer of a regular file during the current rsync session, and there are 169 more files for the receiver to check (to see if they are up-to-date or not) remaining out of the
396 total files in the file-list.
- 进展
此选项指示rsync打印显示传输进度的信息。这给一个无聊的用户观看。使用现代rsync,这与指定 --info = flist2,name,progress一样,但是这些信息标志的任何用户提供的设置都优先(例如“--info = flist0 --progress”)。
当rsync正在传输一个常规文件时,它会更新一个进度行,如下所示:
782448 63%110.64kB / s 0:00:04
在这个例子中,接收机已经重构了782448字节或发送者文件的63%,这个文件正在以每秒110.64千字节的速率重构,如果当前速率保持到最后,传输将在4秒内完成。
如果rsync的delta传输算法正在使用,这些统计信息可能会导致误导。例如,如果发件人的文件由基础文件和其他数据组成,则当接收者获得文字数据时,报告的速度可能会急剧下降,传输可能需要比接收机估计的时间要长得多完成文件的匹配部分。
文件传输完成后,rsync将使用如下所示的摘要行替换进度行:
1,238,099 100%146.38kB / s 0:00:08(xfr#5,to-chk = 169/396)
在这个例子中,这个文件总共是1,238,099个字节,整个文件的平均传输速率是在每8秒钟内完成的时间为146.38千字节,这是在当前rsync中第五次传输一个常规文件会议,还有169个更多的文件供接收者检查(以查看它们是否是最新的)剩余在文件列表中的396个总文件中。
在增量递归扫描中,rsync将不会知道文件列表中的文件总数,直到它到达扫描结束,但是由于它在扫描期间开始传输文件,所以它将显示一行文本“ ir-chk“(用于增量递归检查)而不是”to-chk“,直到它知道列表的全部大小,此时它将切换到使用”to-chk“。因此,看到“ir-chk”可以让您知道文件列表中的文件总数仍然会增加(并且每次都会增加待检查文件的数量将增加)列表)。