a fast, versatile, remote (and local) file-copying tool
This option allows you to choose an alternative remote shell program to use for communication
between the local and remote copies of rsync. Typically, rsync is configured to use ssh by
default, but you may prefer to use rsh on a local network.
If this option is used with [user@]host::module/path, then the remote shell COMMAND will be used
to run an rsync daemon on the remote host, and all data will be transmitted through that remote
shell connection, rather than through a direct socket connection to a running rsync daemon on the
remote host. See the section "USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION" above.
Command-line arguments are permitted in COMMAND provided that COMMAND is presented to rsync as a
single argument. You must use spaces (not tabs or other whitespace) to separate the command and
args from each other, and you can use single- and/or double-quotes to preserve spaces in an
argument (but not backslashes). Note that doubling a single-quote inside a single-quoted string
gives you a single-quote; likewise for double-quotes (though you need to pay attention to which
quotes your shell is parsing and which quotes rsync is parsing). Some examples:
-e 'ssh -p 2234'
-e 'ssh -o "ProxyCommand nohup ssh firewall nc -w1 %h %p"'
(Note that ssh users can alternately customize site-specific connect options in their .ssh/config
You can also choose the remote shell program using the RSYNC_RSH environment variable, which
accepts the same range of values as -e.
See also the --blocking-io option which is affected by this option.
This changes the way rsync checks if the files have been changed and are in need of a transfer.
Without this option, rsync uses a "quick check" that (by default) checks if each file’s size and
time of last modification match between the sender and receiver. This option changes this to
compare a 128-bit checksum for each file that has a matching size. Generating the checksums means
that both sides will expend a lot of disk I/O reading all the data in the files in the transfer
(and this is prior to any reading that will be done to transfer changed files), so this can slow
things down significantly.
The sending side generates its checksums while it is doing the file-system scan that builds the
list of the available files. The receiver generates its checksums when it is scanning for changed
files, and will checksum any file that has the same size as the corresponding sender’s file:
files with either a changed size or a changed checksum are selected for transfer.
Note that rsync always verifies that each transferred file was correctly reconstructed on the
receiving side by checking a whole-file checksum that is generated as the file is transferred, but
that automatic after-the-transfer verification has nothing to do with this option’s
before-the-transfer "Does this file need to be updated?" check.
For protocol 30 and beyond (first supported in 3.0.0), the checksum used is MD5. For older
protocols, the checksum used is MD4.
Output numbers in a more human-readable format. This makes big numbers output using larger units,
with a K, M, or G suffix. If this option was specified once, these units are K (1000), M
(1000*1000), and G (1000*1000*1000); if the option is repeated, the units are powers of 1024
instead of 1000.
This is equivalent to -rlptgoD. It is a quick way of saying you want recursion and want to
preserve almost everything (with -H being a notable omission). The only exception to the above
equivalence is when --files-from is specified, in which case -r is not implied.
Note that -a does not preserve hardlinks, because finding multiply-linked files is expensive. You
must separately specify -H.
This option increases the amount of information you are given during the transfer. By default,
rsync works silently. A single -v will give you information about what files are being transferred
and a brief summary at the end. Two -v options will give you information on what files are being
skipped and slightly more information at the end. More than two -v options should only be used if
you are debugging rsync.
Note that the names of the transferred files that are output are done using a default --out-format
of "%n%L", which tells you just the name of the file and, if the item is a link, where it points.
At the single -v level of verbosity, this does not mention when a file gets its attributes
changed. If you ask for an itemized list of changed attributes (either --itemize-changes or
adding "%i" to the --out-format setting), the output (on the client) increases to mention all
items that are changed in any way. See the --out-format option for more details.
With this option, rsync compresses the file data as it is sent to the destination machine, which
reduces the amount of data being transmitted -- something that is useful over a slow connection.
Note that this option typically achieves better compression ratios than can be achieved by using a
compressing remote shell or a compressing transport because it takes advantage of the implicit
information in the matching data blocks that are not explicitly sent over the connection.
See the --skip-compress option for the default list of file suffixes that will not be compressed.
-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.
This tells rsync to print a verbose set of statistics on the file transfer, allowing you to tell
how effective rsync’s delta-transfer algorithm is for your data.
The current statistics are as follows:
o Number of files is the count of all "files" (in the generic sense), which includes
directories, symlinks, etc.
o Number of files transferred is the count of normal files that were updated via rsync’s
delta-transfer algorithm, which does not include created dirs, symlinks, etc.
o Total file size is the total sum of all file sizes in the transfer. This does not count
any size for directories or special files, but does include the size of symlinks.
o Total transferred file size is the total sum of all files sizes for just the transferred
o Literal data is how much unmatched file-update data we had to send to the receiver for it
to recreate the updated files.
o Matched data is how much data the receiver got locally when recreating the updated files.
o File list size is how big the file-list data was when the sender sent it to the receiver.
This is smaller than the in-memory size for the file list due to some compressing of
duplicated data when rsync sends the list.
o File list generation time is the number of seconds that the sender spent creating the file
list. This requires a modern rsync on the sending side for this to be present.
o File list transfer time is the number of seconds that the sender spent sending the file
list to the receiver.
o Total bytes sent is the count of all the bytes that rsync sent from the client side to the
o Total bytes received is the count of all non-message bytes that rsync received by the
client side from the server side. "Non-message" bytes means that we don’t count the bytes
for a verbose message that the server sent to us, which makes the stats more consistent.
Local: rsync [OPTION...] SRC... [DEST]
Access via remote shell:
Pull: rsync [OPTION...] [USER@]HOST:SRC... [DEST]
Push: rsync [OPTION...] SRC... [USER@]HOST:DEST
Access via rsync daemon:
Pull: rsync [OPTION...] [USER@]HOST::SRC... [DEST]
rsync [OPTION...] rsync://[USER@]HOST[:PORT]/SRC... [DEST]
Push: rsync [OPTION...] SRC... [USER@]HOST::DEST
rsync [OPTION...] SRC... rsync://[USER@]HOST[:PORT]/DEST