mirror of
https://github.com/RsyncProject/rsync.git
synced 2026-01-21 05:18:14 -05:00
1967 lines
92 KiB
Plaintext
1967 lines
92 KiB
Plaintext
mailto(rsync-bugs@samba.org)
|
|
manpage(rsync)(1)(30 Sep 2004)()()
|
|
manpagename(rsync)(faster, flexible replacement for rcp)
|
|
manpagesynopsis()
|
|
|
|
rsync [OPTION]... SRC [SRC]... [USER@]HOST:DEST
|
|
|
|
rsync [OPTION]... [USER@]HOST:SRC DEST
|
|
|
|
rsync [OPTION]... SRC [SRC]... DEST
|
|
|
|
rsync [OPTION]... [USER@]HOST::SRC [DEST]
|
|
|
|
rsync [OPTION]... SRC [SRC]... [USER@]HOST::DEST
|
|
|
|
rsync [OPTION]... rsync://[USER@]HOST[:PORT]/SRC [DEST]
|
|
|
|
rsync [OPTION]... SRC [SRC]... rsync://[USER@]HOST[:PORT]/DEST
|
|
|
|
manpagedescription()
|
|
|
|
rsync is a program that behaves in much the same way that rcp does,
|
|
but has many more options and uses the rsync remote-update protocol to
|
|
greatly speed up file transfers when the destination file is being
|
|
updated.
|
|
|
|
The rsync remote-update protocol allows rsync to transfer just the
|
|
differences between two sets of files across the network connection, using
|
|
an efficient checksum-search algorithm described in the technical
|
|
report that accompanies this package.
|
|
|
|
Some of the additional features of rsync are:
|
|
|
|
itemize(
|
|
it() support for copying links, devices, owners, groups, and permissions
|
|
it() exclude and exclude-from options similar to GNU tar
|
|
it() a CVS exclude mode for ignoring the same files that CVS would ignore
|
|
it() can use any transparent remote shell, including ssh or rsh
|
|
it() does not require root privileges
|
|
it() pipelining of file transfers to minimize latency costs
|
|
it() support for anonymous or authenticated rsync servers (ideal for
|
|
mirroring)
|
|
)
|
|
|
|
manpagesection(GENERAL)
|
|
|
|
There are eight different ways of using rsync. They are:
|
|
|
|
itemize(
|
|
it() for copying local files. This is invoked when neither
|
|
source nor destination path contains a : separator
|
|
it() for copying from the local machine to a remote machine using
|
|
a remote shell program as the transport (such as ssh or
|
|
rsh). This is invoked when the destination path contains a
|
|
single : separator.
|
|
it() for copying from a remote machine to the local machine
|
|
using a remote shell program. This is invoked when the source
|
|
contains a : separator.
|
|
it() for copying from a remote rsync server to the local
|
|
machine. This is invoked when the source path contains a ::
|
|
separator or an rsync:// URL.
|
|
it() for copying from the local machine to a remote rsync
|
|
server. This is invoked when the destination path contains a ::
|
|
separator or an rsync:// URL.
|
|
it() for copying from a remote machine using a remote shell
|
|
program as the transport, using rsync server on the remote
|
|
machine. This is invoked when the source path contains a ::
|
|
separator and the bf(--rsh=COMMAND) (aka "bf(-e COMMAND)") option is
|
|
also provided.
|
|
it() for copying from the local machine to a remote machine
|
|
using a remote shell program as the transport, using rsync
|
|
server on the remote machine. This is invoked when the
|
|
destination path contains a :: separator and the
|
|
bf(--rsh=COMMAND) option is also provided.
|
|
it() for listing files on a remote machine. This is done the
|
|
same way as rsync transfers except that you leave off the
|
|
local destination.
|
|
)
|
|
|
|
Note that in all cases (other than listing) at least one of the source
|
|
and destination paths must be local.
|
|
|
|
manpagesection(SETUP)
|
|
|
|
See the file README for installation instructions.
|
|
|
|
Once installed, you can use rsync to any machine that you can access via
|
|
a remote shell (as well as some that you can access using the rsync
|
|
daemon-mode protocol). For remote transfers, a modern rsync uses ssh
|
|
for its communications, but it may have been configured to use a
|
|
different remote shell by default, such as rsh or remsh.
|
|
|
|
You can also specify any remote shell you like, either by using the bf(-e)
|
|
command line option, or by setting the RSYNC_RSH environment variable.
|
|
|
|
One common substitute is to use ssh, which offers a high degree of
|
|
security.
|
|
|
|
Note that rsync must be installed on both the source and destination
|
|
machines.
|
|
|
|
manpagesection(USAGE)
|
|
|
|
You use rsync in the same way you use rcp. You must specify a source
|
|
and a destination, one of which may be remote.
|
|
|
|
Perhaps the best way to explain the syntax is with some examples:
|
|
|
|
quote(tt(rsync -t *.c foo:src/))
|
|
|
|
This would transfer all files matching the pattern *.c from the
|
|
current directory to the directory src on the machine foo. If any of
|
|
the files already exist on the remote system then the rsync
|
|
remote-update protocol is used to update the file by sending only the
|
|
differences. See the tech report for details.
|
|
|
|
quote(tt(rsync -avz foo:src/bar /data/tmp))
|
|
|
|
This would recursively transfer all files from the directory src/bar on the
|
|
machine foo into the /data/tmp/bar directory on the local machine. The
|
|
files are transferred in "archive" mode, which ensures that symbolic
|
|
links, devices, attributes, permissions, ownerships, etc. are preserved
|
|
in the transfer. Additionally, compression will be used to reduce the
|
|
size of data portions of the transfer.
|
|
|
|
quote(tt(rsync -avz foo:src/bar/ /data/tmp))
|
|
|
|
A trailing slash on the source changes this behavior to avoid creating an
|
|
additional directory level at the destination. You can think of a trailing
|
|
/ on a source as meaning "copy the contents of this directory" as opposed
|
|
to "copy the directory by name", but in both cases the attributes of the
|
|
containing directory are transferred to the containing directory on the
|
|
destination. In other words, each of the following commands copies the
|
|
files in the same way, including their setting of the attributes of
|
|
/dest/foo:
|
|
|
|
quote(
|
|
tt(rsync -av /src/foo /dest)nl()
|
|
tt(rsync -av /src/foo/ /dest/foo)nl()
|
|
)
|
|
|
|
You can also use rsync in local-only mode, where both the source and
|
|
destination don't have a ':' in the name. In this case it behaves like
|
|
an improved copy command.
|
|
|
|
quote(tt(rsync somehost.mydomain.com::))
|
|
|
|
This would list all the anonymous rsync modules available on the host
|
|
somehost.mydomain.com. (See the following section for more details.)
|
|
|
|
manpagesection(ADVANCED USAGE)
|
|
|
|
The syntax for requesting multiple files from a remote host involves using
|
|
quoted spaces in the SRC. Some examples:
|
|
|
|
quote(tt(rsync host::'modname/dir1/file1 modname/dir2/file2' /dest))
|
|
|
|
This would copy file1 and file2 into /dest from an rsync daemon. Each
|
|
additional arg must include the same "modname/" prefix as the first one,
|
|
and must be preceded by a single space. All other spaces are assumed
|
|
to be a part of the filenames.
|
|
|
|
quote(tt(rsync -av host:'dir1/file1 dir2/file2' /dest))
|
|
|
|
This would copy file1 and file2 into /dest using a remote shell. This
|
|
word-splitting is done by the remote shell, so if it doesn't work it means
|
|
that the remote shell isn't configured to split its args based on
|
|
whitespace (a very rare setting, but not unknown). If you need to transfer
|
|
a filename that contains whitespace, you'll need to either escape the
|
|
whitespace in a way that the remote shell will understand, or use wildcards
|
|
in place of the spaces. Two examples of this are:
|
|
|
|
quote(
|
|
tt(rsync -av host:'file\ name\ with\ spaces' /dest)nl()
|
|
tt(rsync -av host:file?name?with?spaces /dest)nl()
|
|
)
|
|
|
|
This latter example assumes that your shell passes through unmatched
|
|
wildcards. If it complains about "no match", put the name in quotes.
|
|
|
|
manpagesection(CONNECTING TO AN RSYNC SERVER)
|
|
|
|
It is also possible to use rsync without a remote shell as the
|
|
transport. In this case you will connect to a remote rsync server
|
|
running on TCP port 873.
|
|
|
|
You may establish the connection via a web proxy by setting the
|
|
environment variable RSYNC_PROXY to a hostname:port pair pointing to
|
|
your web proxy. Note that your web proxy's configuration must support
|
|
proxy connections to port 873.
|
|
|
|
Using rsync in this way is the same as using it with a remote shell except
|
|
that:
|
|
|
|
itemize(
|
|
it() you use a double colon :: instead of a single colon to
|
|
separate the hostname from the path or an rsync:// URL.
|
|
it() the remote server may print a message of the day when you
|
|
connect.
|
|
it() if you specify no path name on the remote server then the
|
|
list of accessible paths on the server will be shown.
|
|
it() if you specify no local destination then a listing of the
|
|
specified files on the remote server is provided.
|
|
)
|
|
|
|
Some paths on the remote server may require authentication. If so then
|
|
you will receive a password prompt when you connect. You can avoid the
|
|
password prompt by setting the environment variable RSYNC_PASSWORD to
|
|
the password you want to use or using the bf(--password-file) option. This
|
|
may be useful when scripting rsync.
|
|
|
|
WARNING: On some systems environment variables are visible to all
|
|
users. On those systems using bf(--password-file) is recommended.
|
|
|
|
manpagesection(CONNECTING TO AN RSYNC SERVER OVER A REMOTE SHELL PROGRAM)
|
|
|
|
It is sometimes useful to be able to set up file transfers using rsync
|
|
server capabilities on the remote machine, while still using ssh or
|
|
rsh for transport. This is especially useful when you want to connect
|
|
to a remote machine via ssh (for encryption or to get through a
|
|
firewall), but you still want to have access to the rsync server
|
|
features (see RUNNING AN RSYNC SERVER OVER A REMOTE SHELL PROGRAM,
|
|
below).
|
|
|
|
From the user's perspective, using rsync in this way is the same as
|
|
using it to connect to an rsync server, except that you must
|
|
explicitly set the remote shell program on the command line with
|
|
bf(--rsh=COMMAND). (Setting RSYNC_RSH in the environment will not turn on
|
|
this functionality.)
|
|
|
|
In order to distinguish between the remote-shell user and the rsync
|
|
server user, you can use '-l user' on your remote-shell command:
|
|
|
|
verb( rsync -av --rsh="ssh -l ssh-user" \
|
|
rsync-user@host::module[/path] local-path)
|
|
|
|
The "ssh-user" will be used at the ssh level; the "rsync-user" will be
|
|
used to check against the rsyncd.conf on the remote host.
|
|
|
|
manpagesection(RUNNING AN RSYNC SERVER)
|
|
|
|
An rsync server is configured using a configuration file. Please see the
|
|
rsyncd.conf(5) man page for more information. By default the configuration
|
|
file is called /etc/rsyncd.conf, unless rsync is running over a remote
|
|
shell program and is not running as root; in that case, the default name
|
|
is rsyncd.conf in the current directory on the remote computer
|
|
(typically $HOME).
|
|
|
|
manpagesection(RUNNING AN RSYNC SERVER OVER A REMOTE SHELL PROGRAM)
|
|
|
|
See the rsyncd.conf(5) man page for full information on the rsync
|
|
server configuration file.
|
|
|
|
Several configuration options will not be available unless the remote
|
|
user is root (e.g. chroot, setuid/setgid, etc.). There is no need to
|
|
configure inetd or the services map to include the rsync server port
|
|
if you run an rsync server only via a remote shell program.
|
|
|
|
To run an rsync server out of a single-use ssh key, see this section
|
|
in the rsyncd.conf(5) man page.
|
|
|
|
manpagesection(EXAMPLES)
|
|
|
|
Here are some examples of how I use rsync.
|
|
|
|
To backup my wife's home directory, which consists of large MS Word
|
|
files and mail folders, I use a cron job that runs
|
|
|
|
quote(tt(rsync -Cavz . arvidsjaur:backup))
|
|
|
|
each night over a PPP connection to a duplicate directory on my machine
|
|
"arvidsjaur".
|
|
|
|
To synchronize my samba source trees I use the following Makefile
|
|
targets:
|
|
|
|
verb( get:
|
|
rsync -avuzb --exclude '*~' samba:samba/ .
|
|
put:
|
|
rsync -Cavuzb . samba:samba/
|
|
sync: get put)
|
|
|
|
this allows me to sync with a CVS directory at the other end of the
|
|
connection. I then do CVS operations on the remote machine, which saves a
|
|
lot of time as the remote CVS protocol isn't very efficient.
|
|
|
|
I mirror a directory between my "old" and "new" ftp sites with the
|
|
command:
|
|
|
|
tt(rsync -az -e ssh --delete ~ftp/pub/samba nimbus:"~ftp/pub/tridge")
|
|
|
|
This is launched from cron every few hours.
|
|
|
|
manpagesection(OPTIONS SUMMARY)
|
|
|
|
Here is a short summary of the options available in rsync. Please refer
|
|
to the detailed description below for a complete description. verb(
|
|
-v, --verbose increase verbosity
|
|
-q, --quiet suppress non-error messages
|
|
-c, --checksum always checksum
|
|
-c, --checksum skip based on checksum, not mod-time & size
|
|
-a, --archive archive mode; same as -rlptgoD (no -H)
|
|
-r, --recursive recurse into directories
|
|
-R, --relative use relative path names
|
|
--no-relative turn off --relative
|
|
--no-implied-dirs don't send implied dirs with -R
|
|
-b, --backup make backups (see --suffix & --backup-dir)
|
|
--backup-dir=DIR make backups into hierarchy based in DIR
|
|
--suffix=SUFFIX backup suffix (default ~ w/o --backup-dir)
|
|
-u, --update skip files that are newer on the receiver
|
|
--inplace update destination files in-place
|
|
-d, --dirs transfer directories without recursing
|
|
-l, --links copy symlinks as symlinks
|
|
-L, --copy-links transform symlink into referent file/dir
|
|
--copy-unsafe-links only "unsafe" symlinks are transformed
|
|
--safe-links ignore symlinks that point outside the tree
|
|
-H, --hard-links preserve hard links
|
|
-K, --keep-dirlinks treat symlinked dir on receiver as dir
|
|
-p, --perms preserve permissions
|
|
-o, --owner preserve owner (root only)
|
|
-g, --group preserve group
|
|
-D, --devices preserve devices (root only)
|
|
-t, --times preserve times
|
|
-O, --omit-dir-times omit directories when preserving times
|
|
-S, --sparse handle sparse files efficiently
|
|
-n, --dry-run show what would have been transferred
|
|
-W, --whole-file copy files whole (without rsync algorithm)
|
|
--no-whole-file always use incremental rsync algorithm
|
|
-x, --one-file-system don't cross filesystem boundaries
|
|
-B, --block-size=SIZE force a fixed checksum block-size
|
|
-e, --rsh=COMMAND specify the remote shell to use
|
|
--rsync-path=PATH specify path to rsync on the remote machine
|
|
--existing only update files that already exist
|
|
--ignore-existing ignore files that already exist on receiver
|
|
--remove-sent-files sent files/symlinks are removed from sender
|
|
--del an alias for --delete-during
|
|
--delete delete files that don't exist on sender
|
|
--delete-before receiver deletes before transfer (default)
|
|
--delete-during receiver deletes during xfer, not before
|
|
--delete-after receiver deletes after transfer, not before
|
|
--delete-excluded also delete excluded files on receiver
|
|
--ignore-errors delete even if there are I/O errors
|
|
--force force deletion of dirs even if not empty
|
|
--max-delete=NUM don't delete more than NUM files
|
|
--max-size=SIZE don't transfer any file larger than SIZE
|
|
--partial keep partially transferred files
|
|
--partial-dir=DIR put a partially transferred file into DIR
|
|
--delay-updates put all updated files into place at end
|
|
--numeric-ids don't map uid/gid values by user/group name
|
|
--timeout=TIME set I/O timeout in seconds
|
|
-I, --ignore-times don't skip files that match size and time
|
|
--size-only skip files that match in size
|
|
--modify-window=NUM compare mod-times with reduced accuracy
|
|
-T, --temp-dir=DIR create temporary files in directory DIR
|
|
-y, --fuzzy find similar file for basis if no dest file
|
|
--compare-dest=DIR also compare received files relative to DIR
|
|
--copy-dest=DIR ... and include copies of unchanged files
|
|
--link-dest=DIR hardlink to files in DIR when unchanged
|
|
-z, --compress compress file data during the transfer
|
|
-C, --cvs-exclude auto-ignore files in the same way CVS does
|
|
-f, --filter=RULE add a file-filtering RULE
|
|
-F same as --filter='dir-merge /.rsync-filter'
|
|
repeated: --filter='- .rsync-filter'
|
|
--exclude=PATTERN exclude files matching PATTERN
|
|
--exclude-from=FILE read exclude patterns from FILE
|
|
--include=PATTERN don't exclude files matching PATTERN
|
|
--include-from=FILE read include patterns from FILE
|
|
--files-from=FILE read list of source-file names from FILE
|
|
-0, --from0 all *from file lists are delimited by nulls
|
|
--version print version number
|
|
--port=PORT specify double-colon alternate port number
|
|
--blocking-io use blocking I/O for the remote shell
|
|
--no-blocking-io turn off blocking I/O when it is default
|
|
--stats give some file-transfer stats
|
|
--progress show progress during transfer
|
|
-P same as --partial --progress
|
|
-i, --itemize-changes output a change-summary for all updates
|
|
--log-format=FORMAT log file-transfers using specified format
|
|
--password-file=FILE read password from FILE
|
|
--list-only list the files instead of copying them
|
|
--bwlimit=KBPS limit I/O bandwidth; KBytes per second
|
|
--write-batch=FILE write a batched update to FILE
|
|
--read-batch=FILE read a batched update from FILE
|
|
--checksum-seed=NUM set block/file checksum seed (advanced)
|
|
-4, --ipv4 prefer IPv4
|
|
-6, --ipv6 prefer IPv6
|
|
-h, --help show this help screen)
|
|
|
|
Rsync can also be run as a daemon, in which case the following options are
|
|
accepted: verb(
|
|
--daemon run as an rsync daemon
|
|
--address=ADDRESS bind to the specified address
|
|
--bwlimit=KBPS limit I/O bandwidth; KBytes per second
|
|
--config=FILE specify alternate rsyncd.conf file
|
|
--no-detach do not detach from the parent
|
|
--port=PORT listen on alternate port number
|
|
-v, --verbose increase verbosity
|
|
-4, --ipv4 prefer IPv4
|
|
-6, --ipv6 prefer IPv6
|
|
-h, --help show this help screen)
|
|
|
|
manpageoptions()
|
|
|
|
rsync uses the GNU long options package. Many of the command line
|
|
options have two variants, one short and one long. These are shown
|
|
below, separated by commas. Some options only have a long variant.
|
|
The '=' for options that take a parameter is optional; whitespace
|
|
can be used instead.
|
|
|
|
startdit()
|
|
dit(bf(-h, --help)) Print a short help page describing the options
|
|
available in rsync.
|
|
|
|
dit(bf(--version)) print the rsync version number and exit.
|
|
|
|
dit(bf(-v, --verbose)) This option increases the amount of information you
|
|
are given during the transfer. By default, rsync works silently. A
|
|
single bf(-v) will give you information about what files are being
|
|
transferred and a brief summary at the end. Two bf(-v) flags will give you
|
|
information on what files are being skipped and slightly more
|
|
information at the end. More than two bf(-v) flags 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 bf(--log-format) of "%n%L", which tells you just the name of the
|
|
file and, if the item is a symlink, where it points. At the single bf(-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
|
|
bf(--itemize-changes) or adding "%i" to the bf(--log-format) setting), the
|
|
output (on the client) increases to mention all items that are changed in
|
|
any way. See the bf(--log-format) option for more details.
|
|
|
|
dit(bf(-q, --quiet)) This option decreases the amount of information you
|
|
are given during the transfer, notably suppressing information messages
|
|
from the remote server. This flag is useful when invoking rsync from
|
|
cron.
|
|
|
|
dit(bf(-I, --ignore-times)) Normally rsync will skip any files that are
|
|
already the same size and have the same modification time-stamp.
|
|
This option turns off this "quick check" behavior.
|
|
|
|
dit(bf(--size-only)) Normally rsync will not transfer any files that are
|
|
already the same size and have the same modification time-stamp. With the
|
|
bf(--size-only) option, files will not be transferred if they have the same size,
|
|
regardless of timestamp. This is useful when starting to use rsync
|
|
after using another mirroring system which may not preserve timestamps
|
|
exactly.
|
|
|
|
dit(bf(--modify-window)) When comparing two timestamps, rsync treats the
|
|
timestamps as being equal if they differ by no more than the modify-window
|
|
value. This is normally 0 (for an exact match), but you may find it useful
|
|
to set this to a larger value in some situations. In particular, when
|
|
transferring to or from an MS Windows FAT filesystem (which represents
|
|
times with a 2-second resolution), bf(--modify-window=1) is useful
|
|
(allowing times to differ by up to 1 second).
|
|
|
|
dit(bf(-c, --checksum)) This forces the sender to checksum all files using
|
|
a 128-bit MD4 checksum before transfer. The checksum is then
|
|
explicitly checked on the receiver and any files of the same name
|
|
which already exist and have the same checksum and size on the
|
|
receiver are not transferred. This option can be quite slow.
|
|
|
|
dit(bf(-a, --archive)) This is equivalent to bf(-rlptgoD). It is a quick
|
|
way of saying you want recursion and want to preserve almost
|
|
everything. The only exception to this is if bf(--files-from) was
|
|
specified, in which case bf(-r) is not implied.
|
|
|
|
Note that bf(-a) bf(does not preserve hardlinks), because
|
|
finding multiply-linked files is expensive. You must separately
|
|
specify bf(-H).
|
|
|
|
dit(bf(-r, --recursive)) This tells rsync to copy directories
|
|
recursively. See also bf(--dirs) (bf(-d)).
|
|
|
|
dit(bf(-R, --relative)) Use relative paths. This means that the full path
|
|
names specified on the command line are sent to the server rather than
|
|
just the last parts of the filenames. This is particularly useful when
|
|
you want to send several different directories at the same time. For
|
|
example, if you used the command
|
|
|
|
quote(tt( rsync /foo/bar/foo.c remote:/tmp/))
|
|
|
|
then this would create a file called foo.c in /tmp/ on the remote
|
|
machine. If instead you used
|
|
|
|
quote(tt( rsync -R /foo/bar/foo.c remote:/tmp/))
|
|
|
|
then a file called /tmp/foo/bar/foo.c would be created on the remote
|
|
machine -- the full path name is preserved. To limit the amount of
|
|
path information that is sent, do something like this:
|
|
|
|
quote(
|
|
tt( cd /foo)nl()
|
|
tt( rsync -R bar/foo.c remote:/tmp/)nl()
|
|
)
|
|
|
|
That would create /tmp/bar/foo.c on the remote machine.
|
|
|
|
dit(bf(--no-relative)) Turn off the bf(--relative) option. This is only
|
|
needed if you want to use bf(--files-from) without its implied bf(--relative)
|
|
file processing.
|
|
|
|
dit(bf(--no-implied-dirs)) When combined with the bf(--relative) option, the
|
|
implied directories in each path are not explicitly duplicated as part
|
|
of the transfer. This makes the transfer more optimal and also allows
|
|
the two sides to have non-matching symlinks in the implied part of the
|
|
path. For instance, if you transfer the file "/path/foo/file" with bf(-R),
|
|
the default is for rsync to ensure that "/path" and "/path/foo" on the
|
|
destination exactly match the directories/symlinks of the source. Using
|
|
the bf(--no-implied-dirs) option would omit both of these implied dirs,
|
|
which means that if "/path" was a real directory on one machine and a
|
|
symlink of the other machine, rsync would not try to change this.
|
|
|
|
dit(bf(-b, --backup)) With this option, preexisting destination files are
|
|
renamed as each file is transferred or deleted. You can control where the
|
|
backup file goes and what (if any) suffix gets appended using the
|
|
bf(--backup-dir) and bf(--suffix) options.
|
|
|
|
dit(bf(--backup-dir=DIR)) In combination with the bf(--backup) option, this
|
|
tells rsync to store all backups in the specified directory. This is
|
|
very useful for incremental backups. You can additionally
|
|
specify a backup suffix using the bf(--suffix) option
|
|
(otherwise the files backed up in the specified directory
|
|
will keep their original filenames).
|
|
If DIR is a relative path, it is relative to the destination directory
|
|
(which changes in a recursive transfer).
|
|
|
|
dit(bf(--suffix=SUFFIX)) This option allows you to override the default
|
|
backup suffix used with the bf(--backup) (bf(-b)) option. The default suffix is a ~
|
|
if no -bf(-backup-dir) was specified, otherwise it is an empty string.
|
|
|
|
dit(bf(-u, --update)) This forces rsync to skip any files which exist on
|
|
the destination and have a modified time that is newer than the source
|
|
file. (If an existing destination file has a modify time equal to the
|
|
source file's, it will be updated if the sizes are different.)
|
|
|
|
In the current implementation of bf(--update), a difference of file format
|
|
between the sender and receiver is always
|
|
considered to be important enough for an update, no matter what date
|
|
is on the objects. In other words, if the source has a directory or a
|
|
symlink where the destination has a file, the transfer would occur
|
|
regardless of the timestamps. This might change in the future (feel
|
|
free to comment on this on the mailing list if you have an opinion).
|
|
|
|
dit(bf(--inplace)) This causes rsync not to create a new copy of the file
|
|
and then move it into place. Instead rsync will overwrite the existing
|
|
file, meaning that the rsync algorithm can't accomplish the full amount of
|
|
network reduction it might be able to otherwise (since it does not yet try
|
|
to sort data matches). One exception to this is if you combine the option
|
|
with bf(--backup), since rsync is smart enough to use the backup file as the
|
|
basis file for the transfer.
|
|
|
|
This option is useful for transfer of large files with block-based changes
|
|
or appended data, and also on systems that are disk bound, not network
|
|
bound.
|
|
|
|
The option implies bf(--partial) (since an interrupted transfer does not delete
|
|
the file), but conflicts with bf(--partial-dir) and bf(--delay-updates).
|
|
Prior to rsync 2.6.4 bf(--inplace) was also incompatible with bf(--compare-dest),
|
|
bf(--copy-dest), and bf(--link-dest).
|
|
|
|
WARNING: The file's data will be in an inconsistent state during the
|
|
transfer (and possibly afterward if the transfer gets interrupted), so you
|
|
should not use this option to update files that are in use. Also note that
|
|
rsync will be unable to update a file in-place that is not writable by the
|
|
receiving user.
|
|
|
|
dit(bf(-d, --dirs)) Tell the sending side to include any directories that
|
|
are encountered. Unlike bf(--recursive), a directory's contents are not copied
|
|
unless the directory was specified on the command-line as either "." or a
|
|
name with a trailing slash (e.g. "foo/"). Without this option or the
|
|
bf(--recursive) option, rsync will skip all directories it encounters (and
|
|
output a message to that effect for each one).
|
|
|
|
dit(bf(-l, --links)) When symlinks are encountered, recreate the
|
|
symlink on the destination.
|
|
|
|
dit(bf(-L, --copy-links)) When symlinks are encountered, the file that
|
|
they point to (the referent) is copied, rather than the symlink. In older
|
|
versions of rsync, this option also had the side-effect of telling the
|
|
receiving side to follow symlinks, such as symlinks to directories. In a
|
|
modern rsync such as this one, you'll need to specify bf(--keep-dirlinks) (bf(-K))
|
|
to get this extra behavior. The only exception is when sending files to
|
|
an rsync that is too old to understand bf(-K) -- in that case, the bf(-L) option
|
|
will still have the side-effect of bf(-K) on that older receiving rsync.
|
|
|
|
dit(bf(--copy-unsafe-links)) This tells rsync to copy the referent of
|
|
symbolic links that point outside the copied tree. Absolute symlinks
|
|
are also treated like ordinary files, and so are any symlinks in the
|
|
source path itself when bf(--relative) is used.
|
|
|
|
dit(bf(--safe-links)) This tells rsync to ignore any symbolic links
|
|
which point outside the copied tree. All absolute symlinks are
|
|
also ignored. Using this option in conjunction with bf(--relative) may
|
|
give unexpected results.
|
|
|
|
dit(bf(-H, --hard-links)) This tells rsync to recreate hard links on
|
|
the remote system to be the same as the local system. Without this
|
|
option hard links are treated like regular files.
|
|
|
|
Note that rsync can only detect hard links if both parts of the link
|
|
are in the list of files being sent.
|
|
|
|
This option can be quite slow, so only use it if you need it.
|
|
|
|
dit(bf(-K, --keep-dirlinks)) On the receiving side, if a symlink is
|
|
pointing to a directory, it will be treated as matching a directory
|
|
from the sender.
|
|
|
|
dit(bf(-W, --whole-file)) With this option the incremental rsync algorithm
|
|
is not used and the whole file is sent as-is instead. The transfer may be
|
|
faster if this option is used when the bandwidth between the source and
|
|
destination machines is higher than the bandwidth to disk (especially when the
|
|
"disk" is actually a networked filesystem). This is the default when both
|
|
the source and destination are specified as local paths.
|
|
|
|
dit(bf(--no-whole-file)) Turn off bf(--whole-file), for use when it is the
|
|
default.
|
|
|
|
dit(bf(-p, --perms)) This option causes rsync to set the destination
|
|
permissions to be the same as the source permissions.
|
|
|
|
Without this option, each new file gets its permissions set based on the
|
|
source file's permissions and the umask at the receiving end, while all
|
|
other files (including updated files) retain their existing permissions
|
|
(which is the same behavior as other file-copy utilities, such as cp).
|
|
|
|
dit(bf(-o, --owner)) This option causes rsync to set the owner of the
|
|
destination file to be the same as the source file. On most systems,
|
|
only the super-user can set file ownership. By default, the preservation
|
|
is done by name, but may fall back to using the ID number in some
|
|
circumstances. See the bf(--numeric-ids) option for a full discussion.
|
|
|
|
dit(bf(-g, --group)) This option causes rsync to set the group of the
|
|
destination file to be the same as the source file. If the receiving
|
|
program is not running as the super-user, only groups that the
|
|
receiver is a member of will be preserved. By default, the preservation
|
|
is done by name, but may fall back to using the ID number in some
|
|
circumstances. See the bf(--numeric-ids) option for a full discussion.
|
|
|
|
dit(bf(-D, --devices)) This option causes rsync to transfer character and
|
|
block device information to the remote system to recreate these
|
|
devices. This option is only available to the super-user.
|
|
|
|
dit(bf(-t, --times)) This tells rsync to transfer modification times along
|
|
with the files and update them on the remote system. Note that if this
|
|
option is not used, the optimization that excludes files that have not been
|
|
modified cannot be effective; in other words, a missing bf(-t) or bf(-a) will
|
|
cause the next transfer to behave as if it used bf(-I), causing all files to be
|
|
updated (though the rsync algorithm will make the update fairly efficient
|
|
if the files haven't actually changed, you're much better off using bf(-t)).
|
|
|
|
dit(bf(-O, --omit-dir-times)) This tells rsync to omit directories when
|
|
it is preserving modification times (see bf(--times)). If NFS is sharing
|
|
the directories on the receiving side, it is a good idea to use bf(-O).
|
|
|
|
dit(bf(-n, --dry-run)) This tells rsync to not do any file transfers,
|
|
instead it will just report the actions it would have taken.
|
|
|
|
dit(bf(-S, --sparse)) Try to handle sparse files efficiently so they take
|
|
up less space on the destination.
|
|
|
|
NOTE: Don't use this option when the destination is a Solaris "tmpfs"
|
|
filesystem. It doesn't seem to handle seeks over null regions
|
|
correctly and ends up corrupting the files.
|
|
|
|
dit(bf(-x, --one-file-system)) This tells rsync not to cross filesystem
|
|
boundaries when recursing. This is useful for transferring the
|
|
contents of only one filesystem.
|
|
|
|
dit(bf(--existing)) This tells rsync not to create any new files --
|
|
only update files that already exist on the destination.
|
|
|
|
dit(bf(--ignore-existing))
|
|
This tells rsync not to update files that already exist on
|
|
the destination.
|
|
|
|
dit(bf(--remove-sent-files)) This tells rsync to remove from the sending
|
|
side the files and/or symlinks that are newly created or whose content is
|
|
updated on the receiving side. Directories and devices are not removed,
|
|
nor are files/symlinks whose attributes are merely changed.
|
|
|
|
dit(bf(--delete)) This tells rsync to delete extraneous files from the
|
|
receiving side (ones that aren't on the sending side), but only for the
|
|
directories that are being synchronized. You must have asked rsync to
|
|
send the whole directory (e.g. "dir" or "dir/") without using a wildcard
|
|
for the directory's contents (e.g. "dir/*") since the wildcard is expanded
|
|
by the shell and rsync thus gets a request to transfer individual files, not
|
|
the files' parent directory. Files that are excluded from transfer are
|
|
also excluded from being deleted unless you use the bf(--delete-excluded)
|
|
option or mark the rules as only matching on the sending side (see the
|
|
include/exclude modifiers in the FILTER RULES section).
|
|
|
|
This option has no effect unless directory recursion is enabled.
|
|
|
|
This option can be dangerous if used incorrectly! It is a very good idea
|
|
to run first using the bf(--dry-run) option (bf(-n)) to see what files would be
|
|
deleted to make sure important files aren't listed.
|
|
|
|
If the sending side detects any I/O errors, then the deletion of any
|
|
files at the destination will be automatically disabled. This is to
|
|
prevent temporary filesystem failures (such as NFS errors) on the
|
|
sending side causing a massive deletion of files on the
|
|
destination. You can override this with the bf(--ignore-errors) option.
|
|
|
|
The bf(--delete) option may be combined with one of the --delete-WHEN options
|
|
without conflict, as well as bf(--delete-excluded). However, if none of the
|
|
--delete-WHEN options are specified, rsync will currently choose the
|
|
bf(--delete-before) algorithm. A future version may change this to choose the
|
|
bf(--delete-during) algorithm. See also bf(--delete-after).
|
|
|
|
dit(bf(--delete-before)) Request that the file-deletions on the receiving
|
|
side be done before the transfer starts. This is the default if bf(--delete)
|
|
or bf(--delete-excluded) is specified without one of the --delete-WHEN options.
|
|
See bf(--delete) (which is implied) for more details on file-deletion.
|
|
|
|
Deleting before the transfer is helpful if the filesystem is tight for space
|
|
and removing extraneous files would help to make the transfer possible.
|
|
However, it does introduce a delay before the start of the transfer,
|
|
and this delay might cause the transfer to timeout (if bf(--timeout) was
|
|
specified).
|
|
|
|
dit(bf(--delete-during, --del)) Request that the file-deletions on the
|
|
receiving side be done incrementally as the transfer happens. This is
|
|
a faster method than choosing the before- or after-transfer algorithm,
|
|
but it is only supported beginning with rsync version 2.6.4.
|
|
See bf(--delete) (which is implied) for more details on file-deletion.
|
|
|
|
dit(bf(--delete-after)) Request that the file-deletions on the receiving
|
|
side be done after the transfer has completed. This is useful if you
|
|
are sending new per-directory merge files as a part of the transfer and
|
|
you want their exclusions to take effect for the delete phase of the
|
|
current transfer.
|
|
See bf(--delete) (which is implied) for more details on file-deletion.
|
|
|
|
dit(bf(--delete-excluded)) In addition to deleting the files on the
|
|
receiving side that are not on the sending side, this tells rsync to also
|
|
delete any files on the receiving side that are excluded (see bf(--exclude)).
|
|
See the FILTER RULES section for a way to make individual exclusions behave
|
|
this way on the receiver, and for a way to protect files from
|
|
bf(--delete-excluded).
|
|
See bf(--delete) (which is implied) for more details on file-deletion.
|
|
|
|
dit(bf(--ignore-errors)) Tells bf(--delete) to go ahead and delete files
|
|
even when there are I/O errors.
|
|
|
|
dit(bf(--force)) This options tells rsync to delete directories even if
|
|
they are not empty when they are to be replaced by non-directories. This
|
|
is only relevant without bf(--delete) because deletions are now done depth-first.
|
|
Requires the bf(--recursive) option (which is implied by bf(-a)) to have any effect.
|
|
|
|
dit(bf(--max-delete=NUM)) This tells rsync not to delete more than NUM
|
|
files or directories. This is useful when mirroring very large trees
|
|
to prevent disasters.
|
|
|
|
dit(bf(--max-size=SIZE)) This tells rsync to avoid transferring any
|
|
file that is larger than the specified SIZE. The SIZE value can be
|
|
suffixed with a letter to indicate a size multiplier (K, M, or G) and
|
|
may be a fractional value (e.g. "bf(--max-size=1.5m)").
|
|
|
|
dit(bf(-B, --block-size=BLOCKSIZE)) This forces the block size used in
|
|
the rsync algorithm to a fixed value. It is normally selected based on
|
|
the size of each file being updated. See the technical report for details.
|
|
|
|
dit(bf(-e, --rsh=COMMAND)) 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 bf([user@]host::module/path), then the
|
|
remote shell em(COMMAND) will be used to run an rsync server 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 server on the remote host. See the section "CONNECTING
|
|
TO AN RSYNC SERVER OVER A REMOTE SHELL PROGRAM" above.
|
|
|
|
Command-line arguments are permitted in COMMAND provided that COMMAND is
|
|
presented to rsync as a single argument. For example:
|
|
|
|
quote(tt( -e "ssh -p 2234"))
|
|
|
|
(Note that ssh users can alternately customize site-specific connect
|
|
options in their .ssh/config file.)
|
|
|
|
You can also choose the remote shell program using the RSYNC_RSH
|
|
environment variable, which accepts the same range of values as bf(-e).
|
|
|
|
See also the bf(--blocking-io) option which is affected by this option.
|
|
|
|
dit(bf(--rsync-path=PATH)) Use this to specify the path to the copy of
|
|
rsync on the remote machine. Useful when it's not in your path. Note
|
|
that this is the full path to the binary, not just the directory that
|
|
the binary is in.
|
|
|
|
dit(bf(-C, --cvs-exclude)) This is a useful shorthand for excluding a
|
|
broad range of files that you often don't want to transfer between
|
|
systems. It uses the same algorithm that CVS uses to determine if
|
|
a file should be ignored.
|
|
|
|
The exclude list is initialized to:
|
|
|
|
quote(quote(tt(RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS .make.state
|
|
.nse_depinfo *~ #* .#* ,* _$* *$ *.old *.bak *.BAK *.orig *.rej
|
|
.del-* *.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core .svn/)))
|
|
|
|
then files listed in a $HOME/.cvsignore are added to the list and any
|
|
files listed in the CVSIGNORE environment variable (all cvsignore names
|
|
are delimited by whitespace).
|
|
|
|
Finally, any file is ignored if it is in the same directory as a
|
|
.cvsignore file and matches one of the patterns listed therein. Unlike
|
|
rsync's filter/exclude files, these patterns are split on whitespace.
|
|
See the bf(cvs(1)) manual for more information.
|
|
|
|
If you're combining bf(-C) with your own bf(--filter) rules, you should
|
|
note that these CVS excludes are appended at the end of your own rules,
|
|
regardless of where the -C was placed on the command-line. This makes them
|
|
a lower priority than any rules you specified explicitly. If you want to
|
|
control where these CVS excludes get inserted into your filter rules, you
|
|
should omit the bf(-C) as a command-line option and use a combination of
|
|
bf(--filter=:C) and bf(--filter=-C) (either on your command-line or by
|
|
putting the ":C" and "-C" rules into a filter file with your other rules).
|
|
The first option turns on the per-directory scanning for the .cvsignore
|
|
file. The second option does a one-time import of the CVS excludes
|
|
mentioned above.
|
|
|
|
dit(bf(-f, --filter=RULE)) This option allows you to add rules to selectively
|
|
exclude certain files from the list of files to be transferred. This is
|
|
most useful in combination with a recursive transfer.
|
|
|
|
You may use as many bf(--filter) options on the command line as you like
|
|
to build up the list of files to exclude.
|
|
|
|
See the FILTER RULES section for detailed information on this option.
|
|
|
|
dit(bf(-F)) The bf(-F) option is a shorthand for adding two bf(--filter) rules to
|
|
your command. The first time it is used is a shorthand for this rule:
|
|
|
|
quote(tt( --filter=': /.rsync-filter'))
|
|
|
|
This tells rsync to look for per-directory .rsync-filter files that have
|
|
been sprinkled through the hierarchy and use their rules to filter the
|
|
files in the transfer. If bf(-F) is repeated, it is a shorthand for this
|
|
rule:
|
|
|
|
quote(tt( --filter='- .rsync-filter'))
|
|
|
|
This filters out the .rsync-filter files themselves from the transfer.
|
|
|
|
See the FILTER RULES section for detailed information on how these options
|
|
work.
|
|
|
|
dit(bf(--exclude=PATTERN)) This option is a simplified form of the
|
|
bf(--filter) option that defaults to an exclude rule and does not allow
|
|
the full rule-parsing syntax of normal filter rules.
|
|
|
|
See the FILTER RULES section for detailed information on this option.
|
|
|
|
dit(bf(--exclude-from=FILE)) This option is similar to the bf(--exclude)
|
|
option, but instead it adds all exclude patterns listed in the file
|
|
FILE to the exclude list. Blank lines in FILE and lines starting with
|
|
';' or '#' are ignored.
|
|
If em(FILE) is bf(-) the list will be read from standard input.
|
|
|
|
dit(bf(--include=PATTERN)) This option is a simplified form of the
|
|
bf(--filter) option that defaults to an include rule and does not allow
|
|
the full rule-parsing syntax of normal filter rules.
|
|
|
|
See the FILTER RULES section for detailed information on this option.
|
|
|
|
dit(bf(--include-from=FILE)) This specifies a list of include patterns
|
|
from a file.
|
|
If em(FILE) is "-" the list will be read from standard input.
|
|
|
|
dit(bf(--files-from=FILE)) Using this option allows you to specify the
|
|
exact list of files to transfer (as read from the specified FILE or "-"
|
|
for standard input). It also tweaks the default behavior of rsync to make
|
|
transferring just the specified files and directories easier:
|
|
|
|
quote(itemize(
|
|
it() The bf(--relative) (bf(-R)) option is implied, which preserves the path
|
|
information that is specified for each item in the file (use
|
|
bf(--no-relative) if you want to turn that off).
|
|
it() The bf(--dirs) (bf(-d)) option is implied, which will create directories
|
|
specified in the list on the destination rather than noisily skipping
|
|
them.
|
|
it() The bf(--archive) (bf(-a)) option's behavior does not imply bf(--recursive)
|
|
(bf(-r)), so specify it explicitly, if you want it.
|
|
))
|
|
|
|
The file names that are read from the FILE are all relative to the
|
|
source dir -- any leading slashes are removed and no ".." references are
|
|
allowed to go higher than the source dir. For example, take this
|
|
command:
|
|
|
|
quote(tt( rsync -a --files-from=/tmp/foo /usr remote:/backup))
|
|
|
|
If /tmp/foo contains the string "bin" (or even "/bin"), the /usr/bin
|
|
directory will be created as /backup/bin on the remote host (but the
|
|
contents of the /usr/bin dir would not be sent unless you specified bf(-r)
|
|
or the names were explicitly listed in /tmp/foo). Also keep in mind
|
|
that the effect of the (enabled by default) bf(--relative) option is to
|
|
duplicate only the path info that is read from the file -- it does not
|
|
force the duplication of the source-spec path (/usr in this case).
|
|
|
|
In addition, the bf(--files-from) file can be read from the remote host
|
|
instead of the local host if you specify a "host:" in front of the file
|
|
(the host must match one end of the transfer). As a short-cut, you can
|
|
specify just a prefix of ":" to mean "use the remote end of the
|
|
transfer". For example:
|
|
|
|
quote(tt( rsync -a --files-from=:/path/file-list src:/ /tmp/copy))
|
|
|
|
This would copy all the files specified in the /path/file-list file that
|
|
was located on the remote "src" host.
|
|
|
|
dit(bf(-0, --from0)) This tells rsync that the filenames it reads from a
|
|
file are terminated by a null ('\0') character, not a NL, CR, or CR+LF.
|
|
This affects bf(--exclude-from), bf(--include-from), bf(--files-from), and any
|
|
merged files specified in a bf(--filter) rule.
|
|
It does not affect bf(--cvs-exclude) (since all names read from a .cvsignore
|
|
file are split on whitespace).
|
|
|
|
dit(bf(-T, --temp-dir=DIR)) This option instructs rsync to use DIR as a
|
|
scratch directory when creating temporary copies of the files
|
|
transferred on the receiving side. The default behavior is to create
|
|
the temporary files in the receiving directory.
|
|
|
|
dit(bf(-y, --fuzzy)) This option tells rsync that it should look for a
|
|
basis file for any destination file that is missing. The current algorithm
|
|
looks in the same directory as the destination file for either a file that
|
|
has an identical size and modified-time, or a similarly-named file. If
|
|
found, rsync uses the fuzzy basis file to try to speed up the transfer.
|
|
|
|
Note that the use of the bf(--delete) option might get rid of any potential
|
|
fuzzy-match files, so either use bf(--delete-after) or specify some
|
|
filename exclusions if you need to prevent this.
|
|
|
|
dit(bf(--compare-dest=DIR)) This option instructs rsync to use em(DIR) on
|
|
the destination machine as an additional hierarchy to compare destination
|
|
files against doing transfers (if the files are missing in the destination
|
|
directory). If a file is found in em(DIR) that is identical to the
|
|
sender's file, the file will NOT be transferred to the destination
|
|
directory. This is useful for creating a sparse backup of just files that
|
|
have changed from an earlier backup.
|
|
|
|
Beginning in version 2.6.4, multiple bf(--compare-dest) directories may be
|
|
provided and rsync will search the list in the order specified until it
|
|
finds an existing file. That first discovery is used as the basis file,
|
|
and also determines if the transfer needs to happen.
|
|
|
|
If em(DIR) is a relative path, it is relative to the destination directory.
|
|
See also bf(--copy-dest) and bf(--link-dest).
|
|
|
|
dit(bf(--copy-dest=DIR)) This option behaves like bf(--compare-dest), but
|
|
rsync will also copy unchanged files found in em(DIR) to the destination
|
|
directory (using the data in the em(DIR) for an efficient copy). This is
|
|
useful for doing transfers to a new destination while leaving existing
|
|
files intact, and then doing a flash-cutover when all files have been
|
|
successfully transferred.
|
|
|
|
If em(DIR) is a relative path, it is relative to the destination directory.
|
|
See also bf(--compare-dest) and bf(--link-dest).
|
|
|
|
dit(bf(--link-dest=DIR)) This option behaves like bf(--copy-dest), but
|
|
unchanged files are hard linked from em(DIR) to the destination directory.
|
|
The files must be identical in all preserved attributes (e.g. permissions,
|
|
possibly ownership) in order for the files to be linked together.
|
|
An example:
|
|
|
|
quote(tt( rsync -av --link-dest=$PWD/prior_dir host:src_dir/ new_dir/))
|
|
|
|
Beginning with version 2.6.4, if more than one bf(--link-dest) option is
|
|
specified, rsync will try to find an exact match to link with (searching
|
|
the list in the order specified), and if not found, a basis file from one
|
|
of the em(DIR)s will be selected to try to speed up the transfer.
|
|
|
|
If em(DIR) is a relative path, it is relative to the destination directory.
|
|
See also bf(--compare-dest) and bf(--copy-dest).
|
|
|
|
Note that rsync versions prior to 2.6.1 had a bug that could prevent
|
|
bf(--link-dest) from working properly for a non-root user when bf(-o) was specified
|
|
(or implied by bf(-a)). You can work-around this bug by avoiding the bf(-o) option
|
|
when sending to an old rsync.
|
|
|
|
dit(bf(-z, --compress)) 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 this this option typically achieves better compression ratios that 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.
|
|
|
|
dit(bf(--numeric-ids)) With this option rsync will transfer numeric group
|
|
and user IDs rather than using user and group names and mapping them
|
|
at both ends.
|
|
|
|
By default rsync will use the username and groupname to determine
|
|
what ownership to give files. The special uid 0 and the special group
|
|
0 are never mapped via user/group names even if the bf(--numeric-ids)
|
|
option is not specified.
|
|
|
|
If a user or group has no name on the source system or it has no match
|
|
on the destination system, then the numeric ID
|
|
from the source system is used instead. See also the comments on the
|
|
"use chroot" setting in the rsyncd.conf manpage for information on how
|
|
the chroot setting affects rsync's ability to look up the names of the
|
|
users and groups and what you can do about it.
|
|
|
|
dit(bf(--timeout=TIMEOUT)) This option allows you to set a maximum I/O
|
|
timeout in seconds. If no data is transferred for the specified time
|
|
then rsync will exit. The default is 0, which means no timeout.
|
|
|
|
dit(bf(--port=PORT)) This specifies an alternate TCP port number to use
|
|
rather than the default of 873. This is only needed if you are using the
|
|
double-colon (::) syntax to connect with an rsync daemon (since the URL
|
|
syntax has a way to specify the port as a part of the URL). See also this
|
|
option in the bf(--daemon) mode section.
|
|
|
|
dit(bf(--blocking-io)) This tells rsync to use blocking I/O when launching
|
|
a remote shell transport. If the remote shell is either rsh or remsh,
|
|
rsync defaults to using
|
|
blocking I/O, otherwise it defaults to using non-blocking I/O. (Note that
|
|
ssh prefers non-blocking I/O.)
|
|
|
|
dit(bf(--no-blocking-io)) Turn off bf(--blocking-io), for use when it is the
|
|
default.
|
|
|
|
dit(bf(-i, --itemize-changes)) Requests a simple itemized list of the
|
|
changes that are being made to each file, including attribute changes.
|
|
This is equivalent to specifying bf(--log-format='%i %n%L'). (See the
|
|
description of what the output of '%i' means in the rsyncd.conf manpage.)
|
|
Rsync also mentions the delete action when an item replaces an item of a
|
|
different type (e.g. a directory replaces a file of the same name).
|
|
|
|
dit(bf(--log-format=FORMAT)) This allows you to specify exactly what the
|
|
rsync client logs to stdout on a per-file basis. This format can be used
|
|
without bf(--verbose) to enable just the outputting of the file-transfer
|
|
information, or it can be used to change how the names are output when
|
|
bf(--verbose) is enabled. Rsync will log the name of an item prior to its
|
|
transfer unless one of the transferred-byte-count values is requested, in
|
|
which case the logging is done at the end of the item's transfer. In this
|
|
late-transfer state, if bf(--progress) is also specified, rsync will output
|
|
just the name of the file prior to the progress information.
|
|
|
|
The log format is specified using the same format conventions as the
|
|
"log format" option in rsyncd.conf, so see that manpage for details.
|
|
(Note that this option does not affect what a daemon logs to its logfile.)
|
|
|
|
dit(bf(--stats)) This tells rsync to print a verbose set of statistics
|
|
on the file transfer, allowing you to tell how effective the rsync
|
|
algorithm is for your data.
|
|
|
|
dit(bf(--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
|
|
bf(--partial) option tells rsync to keep the partial file which should
|
|
make a subsequent transfer of the rest of the file much faster.
|
|
|
|
dit(bf(--partial-dir=DIR)) A better way to keep partial files than the
|
|
bf(--partial) option is to specify a em(DIR) that will be used to hold the
|
|
partial data (instead of writing it out to the destination file).
|
|
On the next transfer, rsync will use a file found in this
|
|
dir as data to speed up the resumption of the transfer and then deletes it
|
|
after it has served its purpose.
|
|
Note that if bf(--whole-file) is specified (or implied), any partial-dir
|
|
file that is found for a file that is being updated will simply be removed
|
|
(since
|
|
rsync is sending files without using the incremental rsync algorithm).
|
|
|
|
Rsync will create the em(DIR) if it is missing (just the last dir -- not
|
|
the whole path). This makes it easy to use a relative path (such as
|
|
"bf(--partial-dir=.rsync-partial)") to have rsync create the
|
|
partial-directory in the destination file's directory when needed, and then
|
|
remove it again when the partial file is deleted.
|
|
|
|
If the partial-dir value is not an absolute path, rsync will also add a directory
|
|
bf(--exclude) of this value at the end of all your existing excludes. This
|
|
will prevent partial-dir files from being transferred and also prevent the
|
|
untimely deletion of partial-dir items on the receiving side. An example:
|
|
the above bf(--partial-dir) option would add an "bf(--exclude=.rsync-partial/)"
|
|
rule at the end of any other filter rules. Note that if you are
|
|
supplying your own filter rules, you may need to manually insert a
|
|
rule for this directory exclusion somewhere higher up in the list so that
|
|
it has a high enough priority to be effective (e.g., if your rules specify
|
|
a trailing bf(--exclude='*') rule, the auto-added rule would never be
|
|
reached).
|
|
|
|
IMPORTANT: the bf(--partial-dir) should not be writable by other users or it
|
|
is a security risk. E.g. AVOID "/tmp".
|
|
|
|
You can also set the partial-dir value the RSYNC_PARTIAL_DIR environment
|
|
variable. Setting this in the environment does not force bf(--partial) to be
|
|
enabled, but rather it effects where partial files go when bf(--partial) is
|
|
specified. For instance, instead of using bf(--partial-dir=.rsync-tmp)
|
|
along with bf(--progress), you could set RSYNC_PARTIAL_DIR=.rsync-tmp in your
|
|
environment and then just use the bf(-P) option to turn on the use of the
|
|
.rsync-tmp dir for partial transfers. The only time that the bf(--partial)
|
|
option does not look for this environment value is (1) when bf(--inplace) was
|
|
specified (since bf(--inplace) conflicts with bf(--partial-dir)), or (2) when
|
|
bf(--delay-updates) was specified (see below).
|
|
|
|
For the purposes of the server-config's "refuse options" setting,
|
|
bf(--partial-dir) does em(not) imply bf(--partial). This is so that a
|
|
refusal of the bf(--partial) option can be used to disallow the overwriting
|
|
of destination files with a partial transfer, while still allowing the
|
|
safer idiom provided by bf(--partial-dir).
|
|
|
|
dit(bf(--delay-updates)) This option puts the temporary file from each
|
|
updated file into a holding directory until the end of the
|
|
transfer, at which time all the files are renamed into place in rapid
|
|
succession. This attempts to make the updating of the files a little more
|
|
atomic. By default the files are placed into a directory named ".~tmp~" in
|
|
each file's destination directory, but you can override this by specifying
|
|
the bf(--partial-dir) option. (Note that RSYNC_PARTIAL_DIR has no effect
|
|
on this value, nor is bf(--partial-dir) considered to be implied for the
|
|
purposes of the server-config's "refuse options" setting.)
|
|
Conflicts with bf(--inplace).
|
|
|
|
This option uses more memory on the receiving side (one bit per file
|
|
transferred) and also requires enough free disk space on the receiving
|
|
side to hold an additional copy of all the updated files. Note also that
|
|
you should not use an absolute path to bf(--partial-dir) unless there is no
|
|
chance of any of the files in the transfer having the same name (since all
|
|
the updated files will be put into a single directory if the path is
|
|
absolute).
|
|
|
|
See also the "atomic-rsync" perl script in the "support" subdir for an
|
|
update algorithm that is even more atomic (it uses bf(--link-dest) and a
|
|
parallel hierarchy of files).
|
|
|
|
dit(bf(--progress)) This option tells rsync to print information
|
|
showing the progress of the transfer. This gives a bored user
|
|
something to watch.
|
|
Implies bf(--verbose) if it wasn't already specified.
|
|
|
|
When the file is transferring, the data looks like this:
|
|
|
|
verb( 782448 63% 110.64kB/s 0:00:04)
|
|
|
|
This tells you the current file size, the percentage of the transfer that
|
|
is complete, the current calculated file-completion rate (including both
|
|
data over the wire and data being matched locally), and the estimated time
|
|
remaining in this transfer.
|
|
|
|
After a file is complete, the data looks like this:
|
|
|
|
verb( 1238099 100% 146.38kB/s 0:00:08 (5, 57.1% of 396))
|
|
|
|
This tells you the final file size, that it's 100% complete, the final
|
|
transfer rate for the file, the amount of elapsed time it took to transfer
|
|
the file, and the addition of a total-transfer summary in parentheses.
|
|
These additional numbers tell you how many files have been updated, and
|
|
what percent of the total number of files has been scanned.
|
|
|
|
dit(bf(-P)) The bf(-P) option is equivalent to bf(--partial) bf(--progress). Its
|
|
purpose is to make it much easier to specify these two options for a long
|
|
transfer that may be interrupted.
|
|
|
|
dit(bf(--password-file)) This option allows you to provide a password
|
|
in a file for accessing a remote rsync server. Note that this option
|
|
is only useful when accessing an rsync server using the built in
|
|
transport, not when using a remote shell as the transport. The file
|
|
must not be world readable. It should contain just the password as a
|
|
single line.
|
|
|
|
dit(bf(--list-only)) This option will cause the source files to be listed
|
|
instead of transferred. This option is inferred if there is no destination
|
|
specified, so you don't usually need to use it explicitly. However, it can
|
|
come in handy for a power user that wants to avoid the "bf(-r --exclude='/*/*')"
|
|
options that rsync might use as a compatibility kluge when generating a
|
|
non-recursive listing.
|
|
|
|
dit(bf(--bwlimit=KBPS)) This option allows you to specify a maximum
|
|
transfer rate in kilobytes per second. This option is most effective when
|
|
using rsync with large files (several megabytes and up). Due to the nature
|
|
of rsync transfers, blocks of data are sent, then if rsync determines the
|
|
transfer was too fast, it will wait before sending the next data block. The
|
|
result is an average transfer rate equaling the specified limit. A value
|
|
of zero specifies no limit.
|
|
|
|
dit(bf(--write-batch=FILE)) Record a file that can later be applied to
|
|
another identical destination with bf(--read-batch). See the "BATCH MODE"
|
|
section for details.
|
|
|
|
dit(bf(--read-batch=FILE)) Apply all of the changes stored in FILE, a
|
|
file previously generated by bf(--write-batch).
|
|
If em(FILE) is "-" the batch data will be read from standard input.
|
|
See the "BATCH MODE" section for details.
|
|
|
|
dit(bf(-4, --ipv4) or bf(-6, --ipv6)) Tells rsync to prefer IPv4/IPv6
|
|
when creating sockets. This only affects sockets that rsync has direct
|
|
control over, such as the outgoing socket when directly contacting an
|
|
rsync daemon. See also these options in the bf(--daemon) mode section.
|
|
|
|
dit(bf(--checksum-seed=NUM)) Set the MD4 checksum seed to the integer
|
|
NUM. This 4 byte checksum seed is included in each block and file
|
|
MD4 checksum calculation. By default the checksum seed is generated
|
|
by the server and defaults to the current time(). This option
|
|
is used to set a specific checksum seed, which is useful for
|
|
applications that want repeatable block and file checksums, or
|
|
in the case where the user wants a more random checksum seed.
|
|
Note that setting NUM to 0 causes rsync to use the default of time()
|
|
for checksum seed.
|
|
enddit()
|
|
|
|
manpagesection(DAEMON OPTIONS)
|
|
|
|
The options allowed when starting an rsync daemon are as follows:
|
|
|
|
startdit()
|
|
dit(bf(--daemon)) This tells rsync that it is to run as a daemon. The
|
|
daemon may be accessed using the bf(host::module) or
|
|
bf(rsync://host/module/) syntax.
|
|
|
|
If standard input is a socket then rsync will assume that it is being
|
|
run via inetd, otherwise it will detach from the current terminal and
|
|
become a background daemon. The daemon will read the config file
|
|
(rsyncd.conf) on each connect made by a client and respond to
|
|
requests accordingly. See the rsyncd.conf(5) man page for more
|
|
details.
|
|
|
|
dit(bf(--address)) By default rsync will bind to the wildcard address
|
|
when run as a daemon with the bf(--daemon) option or when connecting to a
|
|
rsync server. The bf(--address) option allows you to specify a specific IP
|
|
address (or hostname) to bind to. This makes virtual hosting possible
|
|
in conjunction with the bf(--config) option. See also the "address" global
|
|
option in the rsyncd.conf manpage.
|
|
|
|
dit(bf(--bwlimit=KBPS)) This option allows you to specify a maximum
|
|
transfer rate in kilobytes per second for the data the daemon sends.
|
|
The client can still specify a smaller bf(--bwlimit) value, but their
|
|
requested value will be rounded down if they try to exceed it. See the
|
|
client version of this option (above) for some extra details.
|
|
|
|
dit(bf(--config=FILE)) This specifies an alternate config file than
|
|
the default. This is only relevant when bf(--daemon) is specified.
|
|
The default is /etc/rsyncd.conf unless the daemon is running over
|
|
a remote shell program and the remote user is not root; in that case
|
|
the default is rsyncd.conf in the current directory (typically $HOME).
|
|
|
|
dit(bf(--no-detach)) When running as a daemon, this option instructs
|
|
rsync to not detach itself and become a background process. This
|
|
option is required when running as a service on Cygwin, and may also
|
|
be useful when rsync is supervised by a program such as
|
|
bf(daemontools) or AIX's bf(System Resource Controller).
|
|
bf(--no-detach) is also recommended when rsync is run under a
|
|
debugger. This option has no effect if rsync is run from inetd or
|
|
sshd.
|
|
|
|
dit(bf(--port=PORT)) This specifies an alternate TCP port number for the
|
|
daemon to listen on rather than the default of 873. See also the "port"
|
|
global option in the rsyncd.conf manpage.
|
|
|
|
dit(bf(-v, --verbose)) This option increases the amount of information the
|
|
daemon logs during its startup phase. After the client connects, the
|
|
daemon's verbosity level will be controlled by the options that the client
|
|
used and the "max verbosity" setting in the module's config section.
|
|
|
|
dit(bf(-4, --ipv4) or bf(-6, --ipv6)) Tells rsync to prefer IPv4/IPv6
|
|
when creating the incoming sockets that the rsync daemon will use to
|
|
listen for connections. One of these options may be required in older
|
|
versions of Linux to work around an IPv6 bug in the kernel (if you see
|
|
an "address already in use" error when nothing else is using the port,
|
|
try specifying bf(--ipv6) or bf(--ipv4) when starting the daemon).
|
|
|
|
dit(bf(-h, --help)) When specified after bf(--daemon), print a short help
|
|
page describing the options available for starting an rsync daemon.
|
|
enddit()
|
|
|
|
manpagesection(FILTER RULES)
|
|
|
|
The filter rules allow for flexible selection of which files to transfer
|
|
(include) and which files to skip (exclude). The rules either directly
|
|
specify include/exclude patterns or they specify a way to acquire more
|
|
include/exclude patterns (e.g. to read them from a file).
|
|
|
|
As the list of files/directories to transfer is built, rsync checks each
|
|
name to be transferred against the list of include/exclude patterns in
|
|
turn, and the first matching pattern is acted on: if it is an exclude
|
|
pattern, then that file is skipped; if it is an include pattern then that
|
|
filename is not skipped; if no matching pattern is found, then the
|
|
filename is not skipped.
|
|
|
|
Rsync builds an ordered list of filter rules as specified on the
|
|
command-line. Filter rules have the following syntax:
|
|
|
|
quote(
|
|
tt(RULE [PATTERN_OR_FILENAME])nl()
|
|
tt(RULE,MODIFIERS [PATTERN_OR_FILENAME])nl()
|
|
)
|
|
|
|
You have your choice of using either short or long RULE names, as described
|
|
below. If you use a short-named rule, the ',' separating the RULE from the
|
|
MODIFIERS is optional. The PATTERN or FILENAME that follows (when present)
|
|
must come after either a single space or an underscore (_).
|
|
Here are the available rule prefixes:
|
|
|
|
quote(
|
|
bf(exclude, -) specifies an exclude pattern. nl()
|
|
bf(include, +) specifies an include pattern. nl()
|
|
bf(merge, .) specifies a merge-file to read for more rules. nl()
|
|
bf(dir-merge, :) specifies a per-directory merge-file. nl()
|
|
bf(hide, H) specifies a pattern for hiding files from the transfer. nl()
|
|
bf(show, S) files that match the pattern are not hidden. nl()
|
|
bf(protect, P) specifies a pattern for protecting files from deletion. nl()
|
|
bf(risk, R) files that match the pattern are not protected. nl()
|
|
bf(clear, !) clears the current include/exclude list (takes no arg) nl()
|
|
)
|
|
|
|
When rules are being read from a file, empty lines are ignored, as are
|
|
comment lines that start with a "#".
|
|
|
|
Note that the bf(--include)/bf(--exclude) command-line options do not allow the
|
|
full range of rule parsing as described above -- they only allow the
|
|
specification of include/exclude patterns plus a "!" token to clear the
|
|
list (and the normal comment parsing when rules are read from a file).
|
|
If a pattern
|
|
does not begin with "- " (dash, space) or "+ " (plus, space), then the
|
|
rule will be interpreted as if "+ " (for an include option) or "- " (for
|
|
an exclude option) were prefixed to the string. A bf(--filter) option, on
|
|
the other hand, must always contain either a short or long rule name at the
|
|
start of the rule.
|
|
|
|
Note also that the bf(--filter), bf(--include), and bf(--exclude) options take one
|
|
rule/pattern each. To add multiple ones, you can repeat the options on
|
|
the command-line, use the merge-file syntax of the bf(--filter) option, or
|
|
the bf(--include-from)/bf(--exclude-from) options.
|
|
|
|
manpagesection(INCLUDE/EXCLUDE PATTERN RULES)
|
|
|
|
You can include and exclude files by specifying patterns using the "+",
|
|
"-", etc. filter rules (as introduced in the FILTER RULES section above).
|
|
The include/exclude rules each specify a pattern that is matched against
|
|
the names of the files that are going to be transferred. These patterns
|
|
can take several forms:
|
|
|
|
itemize(
|
|
it() if the pattern starts with a / then it is anchored to a
|
|
particular spot in the hierarchy of files, otherwise it is matched
|
|
against the end of the pathname. This is similar to a leading ^ in
|
|
regular expressions.
|
|
Thus "/foo" would match a file called "foo" at either the "root of the
|
|
transfer" (for a global rule) or in the merge-file's directory (for a
|
|
per-directory rule).
|
|
An unqualified "foo" would match any file or directory named "foo"
|
|
anywhere in the tree because the algorithm is applied recursively from
|
|
the
|
|
top down; it behaves as if each path component gets a turn at being the
|
|
end of the file name. Even the unanchored "sub/foo" would match at
|
|
any point in the hierarchy where a "foo" was found within a directory
|
|
named "sub". See the section on ANCHORING INCLUDE/EXCLUDE PATTERNS for
|
|
a full discussion of how to specify a pattern that matches at the root
|
|
of the transfer.
|
|
it() if the pattern ends with a / then it will only match a
|
|
directory, not a file, link, or device.
|
|
it() if the pattern contains a wildcard character from the set
|
|
*?[ then expression matching is applied using the shell filename
|
|
matching rules. Otherwise a simple string match is used.
|
|
it() the double asterisk pattern "**" will match slashes while a
|
|
single asterisk pattern "*" will stop at slashes.
|
|
it() if the pattern contains a / (not counting a trailing /) or a "**"
|
|
then it is matched against the full pathname, including any leading
|
|
directories. If the pattern doesn't contain a / or a "**", then it is
|
|
matched only against the final component of the filename.
|
|
(Remember that the algorithm is applied recursively so "full filename"
|
|
can actually be any portion of a path from the starting directory on
|
|
down.)
|
|
)
|
|
|
|
Note that, when using the bf(--recursive) (bf(-r)) option (which is implied by
|
|
bf(-a)), every subcomponent of every path is visited from the top down, so
|
|
include/exclude patterns get applied recursively to each subcomponent's
|
|
full name (e.g. to include "/foo/bar/baz" the subcomponents "/foo" and
|
|
"/foo/bar" must not be excluded).
|
|
The exclude patterns actually short-circuit the directory traversal stage
|
|
when rsync finds the files to send. If a pattern excludes a particular
|
|
parent directory, it can render a deeper include pattern ineffectual
|
|
because rsync did not descend through that excluded section of the
|
|
hierarchy. This is particularly important when using a trailing '*' rule.
|
|
For instance, this won't work:
|
|
|
|
quote(
|
|
tt(+ /some/path/this-file-will-not-be-found)nl()
|
|
tt(+ /file-is-included)nl()
|
|
tt(- *)nl()
|
|
)
|
|
|
|
This fails because the parent directory "some" is excluded by the '*'
|
|
rule, so rsync never visits any of the files in the "some" or "some/path"
|
|
directories. One solution is to ask for all directories in the hierarchy
|
|
to be included by using a single rule: "+ */" (put it somewhere before the
|
|
"- *" rule). Another solution is to add specific include rules for all
|
|
the parent dirs that need to be visited. For instance, this set of rules
|
|
works fine:
|
|
|
|
quote(
|
|
tt(+ /some/)nl()
|
|
tt(+ /some/path/)nl()
|
|
tt(+ /some/path/this-file-is-found)nl()
|
|
tt(+ /file-also-included)nl()
|
|
tt(- *)nl()
|
|
)
|
|
|
|
Here are some examples of exclude/include matching:
|
|
|
|
itemize(
|
|
it() "- *.o" would exclude all filenames matching *.o
|
|
it() "- /foo" would exclude a file called foo in the transfer-root directory
|
|
it() "- foo/" would exclude any directory called foo
|
|
it() "- /foo/*/bar" would exclude any file called bar two
|
|
levels below a directory called foo in the transfer-root directory
|
|
it() "- /foo/**/bar" would exclude any file called bar two
|
|
or more levels below a directory called foo in the transfer-root directory
|
|
it() The combination of "+ */", "+ *.c", and "- *" would include all
|
|
directories and C source files but nothing else.
|
|
it() The combination of "+ foo/", "+ foo/bar.c", and "- *" would include
|
|
only the foo directory and foo/bar.c (the foo directory must be
|
|
explicitly included or it would be excluded by the "*")
|
|
)
|
|
|
|
manpagesection(MERGE-FILE FILTER RULES)
|
|
|
|
You can merge whole files into your filter rules by specifying either a
|
|
merge (.) or a dir-merge (:) filter rule (as introduced in the FILTER RULES
|
|
section above).
|
|
|
|
There are two kinds of merged files -- single-instance ('.') and
|
|
per-directory (':'). A single-instance merge file is read one time, and
|
|
its rules are incorporated into the filter list in the place of the "."
|
|
rule. For per-directory merge files, rsync will scan every directory that
|
|
it traverses for the named file, merging its contents when the file exists
|
|
into the current list of inherited rules. These per-directory rule files
|
|
must be created on the sending side because it is the sending side that is
|
|
being scanned for the available files to transfer. These rule files may
|
|
also need to be transferred to the receiving side if you want them to
|
|
affect what files don't get deleted (see PER-DIRECTORY RULES AND DELETE
|
|
below).
|
|
|
|
Some examples:
|
|
|
|
quote(
|
|
tt(merge /etc/rsync/default.rules)nl()
|
|
tt(. /etc/rsync/default.rules)nl()
|
|
tt(dir-merge .per-dir-filter)nl()
|
|
tt(dir-merge,n- .non-inherited-per-dir-excludes)nl()
|
|
tt(:n- .non-inherited-per-dir-excludes)nl()
|
|
)
|
|
|
|
The following modifiers are accepted after a merge or dir-merge rule:
|
|
|
|
itemize(
|
|
it() A bf(-) specifies that the file should consist of only exclude
|
|
patterns, with no other rule-parsing except for in-file comments.
|
|
it() A bf(+) specifies that the file should consist of only include
|
|
patterns, with no other rule-parsing except for in-file comments.
|
|
it() A bf(C) is a way to specify that the file should be read in a
|
|
CVS-compatible manner. This turns on 'n', 'w', and '-', but also
|
|
allows the list-clearing token (!) to be specified. If no filename is
|
|
provided, ".cvsignore" is assumed.
|
|
it() A bf(e) will exclude the merge-file name from the transfer; e.g.
|
|
"dir-merge,e .rules" is like "dir-merge .rules" and "- .rules".
|
|
it() An bf(n) specifies that the rules are not inherited by subdirectories.
|
|
it() A bf(w) specifies that the rules are word-split on whitespace instead
|
|
of the normal line-splitting. This also turns off comments. Note: the
|
|
space that separates the prefix from the rule is treated specially, so
|
|
"- foo + bar" is parsed as two rules (assuming that prefix-parsing wasn't
|
|
also disabled).
|
|
it() You may also specify any of the modifiers for the "+" or "-" rules
|
|
(below) in order to have the rules that are read-in from the file
|
|
default to having that modifier set. For instance, "merge,-/ .excl" would
|
|
treat the contents of .excl as absolute-path excludes,
|
|
while "dir-merge,s .filt" and ":sC" would each make all their
|
|
per-directory rules apply only on the server side.
|
|
)
|
|
|
|
The following modifiers are accepted after a "+" or "-":
|
|
|
|
itemize(
|
|
it() A "/" specifies that the include/exclude should be treated as an
|
|
absolute path, relative to the root of the filesystem. For example,
|
|
"-/ /etc/passwd" would exclude the passwd file any time the transfer
|
|
was sending files from the "/etc" directory.
|
|
it() A "!" specifies that the include/exclude should take effect if
|
|
the pattern fails to match. For instance, "-! */" would exclude all
|
|
non-directories.
|
|
it() A bf(C) is used to indicate that all the global CVS-exclude rules
|
|
should be inserted as excludes in place of the "-C". No arg should
|
|
follow.
|
|
it() An bf(s) is used to indicate that the rule applies to the sending
|
|
side. When a rule affects the sending side, it prevents files from
|
|
being transferred. The default is for a rule to affect both sides
|
|
unless bf(--delete-excluded) was specified, in which case default rules
|
|
become sender-side only. See also the hide (H) and show (S) rules,
|
|
which are an alternate way to specify server-side includes/excludes.
|
|
it() An bf(r) is used to indicate that the rule applies to the receiving
|
|
side. When a rule affects the receiving side, it prevents files from
|
|
being deleted. See the bf(s) modifier for more info. See also the
|
|
protect (P) and risk (R) rules, which are an alternate way to
|
|
specify receiver-side includes/excludes.
|
|
)
|
|
|
|
Per-directory rules are inherited in all subdirectories of the directory
|
|
where the merge-file was found unless the 'n' modifier was used. Each
|
|
subdirectory's rules are prefixed to the inherited per-directory rules
|
|
from its parents, which gives the newest rules a higher priority than the
|
|
inherited rules. The entire set of dir-merge rules are grouped together in
|
|
the spot where the merge-file was specified, so it is possible to override
|
|
dir-merge rules via a rule that got specified earlier in the list of global
|
|
rules. When the list-clearing rule ("!") is read from a per-directory
|
|
file, it only clears the inherited rules for the current merge file.
|
|
|
|
Another way to prevent a single rule from a dir-merge file from being inherited is to
|
|
anchor it with a leading slash. Anchored rules in a per-directory
|
|
merge-file are relative to the merge-file's directory, so a pattern "/foo"
|
|
would only match the file "foo" in the directory where the dir-merge filter
|
|
file was found.
|
|
|
|
Here's an example filter file which you'd specify via bf(--filter=". file":)
|
|
|
|
quote(
|
|
tt(merge /home/user/.global-filter)nl()
|
|
tt(- *.gz)nl()
|
|
tt(dir-merge .rules)nl()
|
|
tt(+ *.[ch])nl()
|
|
tt(- *.o)nl()
|
|
)
|
|
|
|
This will merge the contents of the /home/user/.global-filter file at the
|
|
start of the list and also turns the ".rules" filename into a per-directory
|
|
filter file. All rules read-in prior to the start of the directory scan
|
|
follow the global anchoring rules (i.e. a leading slash matches at the root
|
|
of the transfer).
|
|
|
|
If a per-directory merge-file is specified with a path that is a parent
|
|
directory of the first transfer directory, rsync will scan all the parent
|
|
dirs from that starting point to the transfer directory for the indicated
|
|
per-directory file. For instance, here is a common filter (see bf(-F)):
|
|
|
|
quote(tt(--filter=': /.rsync-filter'))
|
|
|
|
That rule tells rsync to scan for the file .rsync-filter in all
|
|
directories from the root down through the parent directory of the
|
|
transfer prior to the start of the normal directory scan of the file in
|
|
the directories that are sent as a part of the transfer. (Note: for an
|
|
rsync daemon, the root is always the same as the module's "path".)
|
|
|
|
Some examples of this pre-scanning for per-directory files:
|
|
|
|
quote(
|
|
tt(rsync -avF /src/path/ /dest/dir)nl()
|
|
tt(rsync -av --filter=': ../../.rsync-filter' /src/path/ /dest/dir)nl()
|
|
tt(rsync -av --filter=': .rsync-filter' /src/path/ /dest/dir)nl()
|
|
)
|
|
|
|
The first two commands above will look for ".rsync-filter" in "/" and
|
|
"/src" before the normal scan begins looking for the file in "/src/path"
|
|
and its subdirectories. The last command avoids the parent-dir scan
|
|
and only looks for the ".rsync-filter" files in each directory that is
|
|
a part of the transfer.
|
|
|
|
If you want to include the contents of a ".cvsignore" in your patterns,
|
|
you should use the rule ":C", which creates a dir-merge of the .cvsignore
|
|
file, but parsed in a CVS-compatible manner. You can
|
|
use this to affect where the bf(--cvs-exclude) (bf(-C)) option's inclusion of the
|
|
per-directory .cvsignore file gets placed into your rules by putting the
|
|
":C" wherever you like in your filter rules. Without this, rsync would
|
|
add the dir-merge rule for the .cvsignore file at the end of all your other
|
|
rules (giving it a lower priority than your command-line rules). For
|
|
example:
|
|
|
|
quote(
|
|
tt(cat <<EOT | rsync -avC --filter='. -' a/ b)nl()
|
|
tt(+ foo.o)nl()
|
|
tt(:C)nl()
|
|
tt(- *.old)nl()
|
|
tt(EOT)nl()
|
|
tt(rsync -avC --include=foo.o -f :C --exclude='*.old' a/ b)nl()
|
|
)
|
|
|
|
Both of the above rsync commands are identical. Each one will merge all
|
|
the per-directory .cvsignore rules in the middle of the list rather than
|
|
at the end. This allows their dir-specific rules to supersede the rules
|
|
that follow the :C instead of being subservient to all your rules. To
|
|
affect the other CVS exclude rules (i.e. the default list of exclusions,
|
|
the contents of $HOME/.cvsignore, and the value of $CVSIGNORE) you should
|
|
omit the bf(-C) command-line option and instead insert a "-C" rule into
|
|
your filter rules; e.g. "--filter=-C".
|
|
|
|
manpagesection(LIST-CLEARING FILTER RULE)
|
|
|
|
You can clear the current include/exclude list by using the "!" filter
|
|
rule (as introduced in the FILTER RULES section above). The "current"
|
|
list is either the global list of rules (if the rule is encountered while
|
|
parsing the filter options) or a set of per-directory rules (which are
|
|
inherited in their own sub-list, so a subdirectory can use this to clear
|
|
out the parent's rules).
|
|
|
|
manpagesection(ANCHORING INCLUDE/EXCLUDE PATTERNS)
|
|
|
|
As mentioned earlier, global include/exclude patterns are anchored at the
|
|
"root of the transfer" (as opposed to per-directory patterns, which are
|
|
anchored at the merge-file's directory). If you think of the transfer as
|
|
a subtree of names that are being sent from sender to receiver, the
|
|
transfer-root is where the tree starts to be duplicated in the destination
|
|
directory. This root governs where patterns that start with a / match.
|
|
|
|
Because the matching is relative to the transfer-root, changing the
|
|
trailing slash on a source path or changing your use of the bf(--relative)
|
|
option affects the path you need to use in your matching (in addition to
|
|
changing how much of the file tree is duplicated on the destination
|
|
host). The following examples demonstrate this.
|
|
|
|
Let's say that we want to match two source files, one with an absolute
|
|
path of "/home/me/foo/bar", and one with a path of "/home/you/bar/baz".
|
|
Here is how the various command choices differ for a 2-source transfer:
|
|
|
|
quote(
|
|
Example cmd: rsync -a /home/me /home/you /dest nl()
|
|
+/- pattern: /me/foo/bar nl()
|
|
+/- pattern: /you/bar/baz nl()
|
|
Target file: /dest/me/foo/bar nl()
|
|
Target file: /dest/you/bar/baz nl()
|
|
)
|
|
|
|
quote(
|
|
Example cmd: rsync -a /home/me/ /home/you/ /dest nl()
|
|
+/- pattern: /foo/bar (note missing "me") nl()
|
|
+/- pattern: /bar/baz (note missing "you") nl()
|
|
Target file: /dest/foo/bar nl()
|
|
Target file: /dest/bar/baz nl()
|
|
)
|
|
|
|
quote(
|
|
Example cmd: rsync -a --relative /home/me/ /home/you /dest nl()
|
|
+/- pattern: /home/me/foo/bar (note full path) nl()
|
|
+/- pattern: /home/you/bar/baz (ditto) nl()
|
|
Target file: /dest/home/me/foo/bar nl()
|
|
Target file: /dest/home/you/bar/baz nl()
|
|
)
|
|
|
|
quote(
|
|
Example cmd: cd /home; rsync -a --relative me/foo you/ /dest nl()
|
|
+/- pattern: /me/foo/bar (starts at specified path) nl()
|
|
+/- pattern: /you/bar/baz (ditto) nl()
|
|
Target file: /dest/me/foo/bar nl()
|
|
Target file: /dest/you/bar/baz nl()
|
|
)
|
|
|
|
The easiest way to see what name you should filter is to just
|
|
look at the output when using bf(--verbose) and put a / in front of the name
|
|
(use the bf(--dry-run) option if you're not yet ready to copy any files).
|
|
|
|
manpagesection(PER-DIRECTORY RULES AND DELETE)
|
|
|
|
Without a delete option, per-directory rules are only relevant on the
|
|
sending side, so you can feel free to exclude the merge files themselves
|
|
without affecting the transfer. To make this easy, the 'e' modifier adds
|
|
this exclude for you, as seen in these two equivalent commands:
|
|
|
|
quote(
|
|
tt(rsync -av --filter=': .excl' --exclude=.excl host:src/dir /dest)nl()
|
|
tt(rsync -av --filter=':e .excl' host:src/dir /dest)nl()
|
|
)
|
|
|
|
However, if you want to do a delete on the receiving side AND you want some
|
|
files to be excluded from being deleted, you'll need to be sure that the
|
|
receiving side knows what files to exclude. The easiest way is to include
|
|
the per-directory merge files in the transfer and use bf(--delete-after),
|
|
because this ensures that the receiving side gets all the same exclude
|
|
rules as the sending side before it tries to delete anything:
|
|
|
|
quote(tt(rsync -avF --delete-after host:src/dir /dest))
|
|
|
|
However, if the merge files are not a part of the transfer, you'll need to
|
|
either specify some global exclude rules (i.e. specified on the command
|
|
line), or you'll need to maintain your own per-directory merge files on
|
|
the receiving side. An example of the first is this (assume that the
|
|
remote .rules files exclude themselves):
|
|
|
|
verb(rsync -av --filter=': .rules' --filter='. /my/extra.rules'
|
|
--delete host:src/dir /dest)
|
|
|
|
In the above example the extra.rules file can affect both sides of the
|
|
transfer, but (on the sending side) the rules are subservient to the rules
|
|
merged from the .rules files because they were specified after the
|
|
per-directory merge rule.
|
|
|
|
In one final example, the remote side is excluding the .rsync-filter
|
|
files from the transfer, but we want to use our own .rsync-filter files
|
|
to control what gets deleted on the receiving side. To do this we must
|
|
specifically exclude the per-directory merge files (so that they don't get
|
|
deleted) and then put rules into the local files to control what else
|
|
should not get deleted. Like one of these commands:
|
|
|
|
verb( rsync -av --filter=':e /.rsync-filter' --delete \
|
|
host:src/dir /dest
|
|
rsync -avFF --delete host:src/dir /dest)
|
|
|
|
manpagesection(BATCH MODE)
|
|
|
|
Batch mode can be used to apply the same set of updates to many
|
|
identical systems. Suppose one has a tree which is replicated on a
|
|
number of hosts. Now suppose some changes have been made to this
|
|
source tree and those changes need to be propagated to the other
|
|
hosts. In order to do this using batch mode, rsync is run with the
|
|
write-batch option to apply the changes made to the source tree to one
|
|
of the destination trees. The write-batch option causes the rsync
|
|
client to store in a "batch file" all the information needed to repeat
|
|
this operation against other, identical destination trees.
|
|
|
|
To apply the recorded changes to another destination tree, run rsync
|
|
with the read-batch option, specifying the name of the same batch
|
|
file, and the destination tree. Rsync updates the destination tree
|
|
using the information stored in the batch file.
|
|
|
|
For convenience, one additional file is creating when the write-batch
|
|
option is used. This file's name is created by appending
|
|
".sh" to the batch filename. The .sh file contains
|
|
a command-line suitable for updating a destination tree using that
|
|
batch file. It can be executed using a Bourne(-like) shell, optionally
|
|
passing in an alternate destination tree pathname which is then used
|
|
instead of the original path. This is useful when the destination tree
|
|
path differs from the original destination tree path.
|
|
|
|
Generating the batch file once saves having to perform the file
|
|
status, checksum, and data block generation more than once when
|
|
updating multiple destination trees. Multicast transport protocols can
|
|
be used to transfer the batch update files in parallel to many hosts
|
|
at once, instead of sending the same data to every host individually.
|
|
|
|
Examples:
|
|
|
|
quote(
|
|
tt($ rsync --write-batch=foo -a host:/source/dir/ /adest/dir/)nl()
|
|
tt($ scp foo* remote:)nl()
|
|
tt($ ssh remote ./foo.sh /bdest/dir/)nl()
|
|
)
|
|
|
|
quote(
|
|
tt($ rsync --write-batch=foo -a /source/dir/ /adest/dir/)nl()
|
|
tt($ ssh remote rsync --read-batch=- -a /bdest/dir/ <foo)nl()
|
|
)
|
|
|
|
In these examples, rsync is used to update /adest/dir/ from /source/dir/
|
|
and the information to repeat this operation is stored in "foo" and
|
|
"foo.sh". The host "remote" is then updated with the batched data going
|
|
into the directory /bdest/dir. The differences between the two examples
|
|
reveals some of the flexibility you have in how you deal with batches:
|
|
|
|
itemize(
|
|
it() The first example shows that the initial copy doesn't have to be
|
|
local -- you can push or pull data to/from a remote host using either the
|
|
remote-shell syntax or rsync daemon syntax, as desired.
|
|
it() The first example uses the created "foo.sh" file to get the right
|
|
rsync options when running the read-batch command on the remote host.
|
|
it() The second example reads the batch data via standard input so that
|
|
the batch file doesn't need to be copied to the remote machine first.
|
|
This example avoids the foo.sh script because it needed to use a modified
|
|
bf(--read-batch) option, but you could edit the script file if you wished to
|
|
make use of it (just be sure that no other option is trying to use
|
|
standard input, such as the "bf(--exclude-from=-)" option).
|
|
)
|
|
|
|
Caveats:
|
|
|
|
The read-batch option expects the destination tree that it is updating
|
|
to be identical to the destination tree that was used to create the
|
|
batch update fileset. When a difference between the destination trees
|
|
is encountered the update might be discarded with no error (if the file
|
|
appears to be up-to-date already) or the file-update may be attempted
|
|
and then, if the file fails to verify, the update discarded with an
|
|
error. This means that it should be safe to re-run a read-batch operation
|
|
if the command got interrupted. If you wish to force the batched-update to
|
|
always be attempted regardless of the file's size and date, use the bf(-I)
|
|
option (when reading the batch).
|
|
If an error occurs, the destination tree will probably be in a
|
|
partially updated state. In that case, rsync can
|
|
be used in its regular (non-batch) mode of operation to fix up the
|
|
destination tree.
|
|
|
|
The rsync version used on all destinations must be at least as new as the
|
|
one used to generate the batch file. Rsync will die with an error if the
|
|
protocol version in the batch file is too new for the batch-reading rsync
|
|
to handle.
|
|
|
|
The bf(--dry-run) (bf(-n)) option does not work in batch mode and yields a runtime
|
|
error.
|
|
|
|
When reading a batch file, rsync will force the value of certain options
|
|
to match the data in the batch file if you didn't set them to the same
|
|
as the batch-writing command. Other options can (and should) be changed.
|
|
For instance bf(--write-batch) changes to bf(--read-batch),
|
|
bf(--files-from) is dropped, and the
|
|
bf(--filter)/bf(--include)/bf(--exclude) options are not needed unless
|
|
one of the bf(--delete) options is specified.
|
|
|
|
The code that creates the BATCH.sh file transforms any filter/include/exclude
|
|
options into a single list that is appended as a "here" document to the
|
|
shell script file. An advanced user can use this to modify the exclude
|
|
list if a change in what gets deleted by bf(--delete) is desired. A normal
|
|
user can ignore this detail and just use the shell script as an easy way
|
|
to run the appropriate bf(--read-batch) command for the batched data.
|
|
|
|
The original batch mode in rsync was based on "rsync+", but the latest
|
|
version uses a new implementation.
|
|
|
|
manpagesection(SYMBOLIC LINKS)
|
|
|
|
Three basic behaviors are possible when rsync encounters a symbolic
|
|
link in the source directory.
|
|
|
|
By default, symbolic links are not transferred at all. A message
|
|
"skipping non-regular" file is emitted for any symlinks that exist.
|
|
|
|
If bf(--links) is specified, then symlinks are recreated with the same
|
|
target on the destination. Note that bf(--archive) implies
|
|
bf(--links).
|
|
|
|
If bf(--copy-links) is specified, then symlinks are "collapsed" by
|
|
copying their referent, rather than the symlink.
|
|
|
|
rsync also distinguishes "safe" and "unsafe" symbolic links. An
|
|
example where this might be used is a web site mirror that wishes
|
|
ensure the rsync module they copy does not include symbolic links to
|
|
bf(/etc/passwd) in the public section of the site. Using
|
|
bf(--copy-unsafe-links) will cause any links to be copied as the file
|
|
they point to on the destination. Using bf(--safe-links) will cause
|
|
unsafe links to be omitted altogether.
|
|
|
|
Symbolic links are considered unsafe if they are absolute symlinks
|
|
(start with bf(/)), empty, or if they contain enough bf("..")
|
|
components to ascend from the directory being copied.
|
|
|
|
manpagediagnostics()
|
|
|
|
rsync occasionally produces error messages that may seem a little
|
|
cryptic. The one that seems to cause the most confusion is "protocol
|
|
version mismatch -- is your shell clean?".
|
|
|
|
This message is usually caused by your startup scripts or remote shell
|
|
facility producing unwanted garbage on the stream that rsync is using
|
|
for its transport. The way to diagnose this problem is to run your
|
|
remote shell like this:
|
|
|
|
quote(tt(ssh remotehost /bin/true > out.dat))
|
|
|
|
then look at out.dat. If everything is working correctly then out.dat
|
|
should be a zero length file. If you are getting the above error from
|
|
rsync then you will probably find that out.dat contains some text or
|
|
data. Look at the contents and try to work out what is producing
|
|
it. The most common cause is incorrectly configured shell startup
|
|
scripts (such as .cshrc or .profile) that contain output statements
|
|
for non-interactive logins.
|
|
|
|
If you are having trouble debugging filter patterns, then
|
|
try specifying the bf(-vv) option. At this level of verbosity rsync will
|
|
show why each individual file is included or excluded.
|
|
|
|
manpagesection(EXIT VALUES)
|
|
|
|
startdit()
|
|
dit(bf(0)) Success
|
|
dit(bf(1)) Syntax or usage error
|
|
dit(bf(2)) Protocol incompatibility
|
|
dit(bf(3)) Errors selecting input/output files, dirs
|
|
dit(bf(4)) Requested action not supported: an attempt
|
|
was made to manipulate 64-bit files on a platform that cannot support
|
|
them; or an option was specified that is supported by the client and
|
|
not by the server.
|
|
dit(bf(5)) Error starting client-server protocol
|
|
dit(bf(10)) Error in socket I/O
|
|
dit(bf(11)) Error in file I/O
|
|
dit(bf(12)) Error in rsync protocol data stream
|
|
dit(bf(13)) Errors with program diagnostics
|
|
dit(bf(14)) Error in IPC code
|
|
dit(bf(20)) Received SIGUSR1 or SIGINT
|
|
dit(bf(21)) Some error returned by waitpid()
|
|
dit(bf(22)) Error allocating core memory buffers
|
|
dit(bf(23)) Partial transfer due to error
|
|
dit(bf(24)) Partial transfer due to vanished source files
|
|
dit(bf(30)) Timeout in data send/receive
|
|
enddit()
|
|
|
|
manpagesection(ENVIRONMENT VARIABLES)
|
|
|
|
startdit()
|
|
dit(bf(CVSIGNORE)) The CVSIGNORE environment variable supplements any
|
|
ignore patterns in .cvsignore files. See the bf(--cvs-exclude) option for
|
|
more details.
|
|
dit(bf(RSYNC_RSH)) The RSYNC_RSH environment variable allows you to
|
|
override the default shell used as the transport for rsync. Command line
|
|
options are permitted after the command name, just as in the bf(-e) option.
|
|
dit(bf(RSYNC_PROXY)) The RSYNC_PROXY environment variable allows you to
|
|
redirect your rsync client to use a web proxy when connecting to a
|
|
rsync daemon. You should set RSYNC_PROXY to a hostname:port pair.
|
|
dit(bf(RSYNC_PASSWORD)) Setting RSYNC_PASSWORD to the required
|
|
password allows you to run authenticated rsync connections to an rsync
|
|
daemon without user intervention. Note that this does not supply a
|
|
password to a shell transport such as ssh.
|
|
dit(bf(USER) or bf(LOGNAME)) The USER or LOGNAME environment variables
|
|
are used to determine the default username sent to an rsync server.
|
|
If neither is set, the username defaults to "nobody".
|
|
dit(bf(HOME)) The HOME environment variable is used to find the user's
|
|
default .cvsignore file.
|
|
enddit()
|
|
|
|
manpagefiles()
|
|
|
|
/etc/rsyncd.conf or rsyncd.conf
|
|
|
|
manpageseealso()
|
|
|
|
rsyncd.conf(5)
|
|
|
|
manpagebugs()
|
|
|
|
times are transferred as unix time_t values
|
|
|
|
When transferring to FAT filesystems rsync may re-sync
|
|
unmodified files.
|
|
See the comments on the bf(--modify-window) option.
|
|
|
|
file permissions, devices, etc. are transferred as native numerical
|
|
values
|
|
|
|
see also the comments on the bf(--delete) option
|
|
|
|
Please report bugs! See the website at
|
|
url(http://rsync.samba.org/)(http://rsync.samba.org/)
|
|
|
|
manpagesection(CREDITS)
|
|
|
|
rsync is distributed under the GNU public license. See the file
|
|
COPYING for details.
|
|
|
|
A WEB site is available at
|
|
url(http://rsync.samba.org/)(http://rsync.samba.org/). The site
|
|
includes an FAQ-O-Matic which may cover questions unanswered by this
|
|
manual page.
|
|
|
|
The primary ftp site for rsync is
|
|
url(ftp://rsync.samba.org/pub/rsync)(ftp://rsync.samba.org/pub/rsync).
|
|
|
|
We would be delighted to hear from you if you like this program.
|
|
|
|
This program uses the excellent zlib compression library written by
|
|
Jean-loup Gailly and Mark Adler.
|
|
|
|
manpagesection(THANKS)
|
|
|
|
Thanks to Richard Brent, Brendan Mackay, Bill Waite, Stephen Rothwell
|
|
and David Bell for helpful suggestions, patches and testing of rsync.
|
|
I've probably missed some people, my apologies if I have.
|
|
|
|
Especial thanks also to: David Dykstra, Jos Backus, Sebastian Krahmer,
|
|
Martin Pool, Wayne Davison, J.W. Schultz.
|
|
|
|
manpageauthor()
|
|
|
|
rsync was originally written by Andrew Tridgell and Paul Mackerras.
|
|
Many people have later contributed to it.
|
|
|
|
Mailing lists for support and development are available at
|
|
url(http://lists.samba.org)(lists.samba.org)
|