--max‐size
       option, the --ignore‐non‐existing option, and a few others.

BATCH MODE
       Batch mode can be used to apply the same set of updates to many  identi‐
       cal  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.

       Generating the batch file once saves having to perform the file  status,
       checksum,  and data block generation more than once when updating multi‐
       ple destination trees.  Multicast transport protocols  can  be  used  to
       transfer  the  batch update files in parallel to many hosts at once, in‐
       stead of sending the same data to every host individually.

       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 your convenience, a script file is also created when the write‐batch
       option  is  used: it will be named the same as the batch file with ".sh"
       appended.  This script file contains a command‐line suitable for  updat‐
       ing  a destination tree using the associated batch file.  It can be exe‐
       cuted using a Bourne (or Bourne‐like) shell, optionally  passing  in  an
       alternate  destination  tree  pathname which is then used instead of the
       original destination path.  This is useful  when  the  destination  tree
       path  on  the current host differs from the one used to create the batch
       file.

       Examples:

           $ rsync ‐‐write‐batch=foo ‐a host:/source/dir/ /adest/dir/
           $ scp foo* remote:
           $ ssh remote ./foo.sh /bdest/dir/

           $ rsync ‐‐write‐batch=foo ‐a /source/dir/ /adest/dir/
           $ ssh remote rsync ‐‐read‐batch=‐ ‐a /bdest/dir/ <foo

       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:

       o      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 de‐
              sired.

       o      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.

       o      The  second  example  reads  the batch data via standard input so
              that the batch file doesn’t need to be copied to the  remote  ma‐
              chine  first.   This  example avoids the foo.sh script because it
              needed to use a modified --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
              --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