rsync para vários destinos usando a mesma lista de arquivos?

18

Eu estou querendo saber se é possível para o rsync copiar um diretório para vários destinos remotos de uma só vez, ou mesmo em paralelo. (não é necessário, mas seria útil.)

Normalmente, algo como o seguinte funcionaria bem:

$ rsync -Pav /junk user@host1:/backup
$ rsync -Pav /junk user@host2:/backup
$ rsync -Pav /junk user@host3:/backup

E se essa for a única opção, vou usar isso. No entanto, o / junk está localizado em uma unidade lenta com alguns arquivos, e a reconstrução da lista de arquivos de aproximadamente 12.000 arquivos cada vez é agonizantemente lenta (~ 5 minutos) em comparação com a transferência / atualização real. É possível fazer algo assim, para realizar a mesma coisa:

$ rsync -Pav /junk user@host1:/backup user@host2:/backup user@host3:/backup 

Obrigado por procurar!

    
por Jessie 29.04.2010 / 20:00

9 respostas

9

Aqui estão as informações da página man do rsync sobre o modo batch.

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.

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.

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 updating a destination tree using the associated batch file. It can be executed 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:

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

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

  • 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 --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 desti‐ nation trees is encountered the update might be discarded with a warning (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 -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. See also the --protocol option for a way to have the creating rsync generate a batch file that an older rsync can understand. (Note that batch files changed for‐ mat in version 2.6.3, so mixing versions older than that with newer versions will not work.)

    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 --write-batch changes to --read-batch, --files-from is dropped, and the --filter/--include/--exclude options are not needed unless one of the --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 --delete is desired. A normal user can ignore this detail and just use the shell script as an easy way to run the appropriate --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.

Eu imagino que você poderia tentar

rsync --write-batch=foo -Pav /junk user@host1:/backup
foo.sh user@host2:/backup
foo.sh user@host3:/backup
    
por 28.02.2013 / 02:34
4

Você pode tentar usar uníssono . Deve ser muito mais rápido construir a lista de arquivos porque mantém um cache dos arquivos.

    
por 19.08.2010 / 22:52
3

O rsync --batch-mode suporta multicast. Se isso for possível em sua rede, talvez valha a pena investigar isso.

    
por 06.05.2011 / 21:07
2

que tal mudar os sistemas de arquivos?

Algum tempo atrás, eu mudei um FS multi-terabyte de ext3 para XFS. O tempo para escanear os diretórios (com cerca de 600.000 arquivos da última vez que verifiquei) passou de 15-17 minutos para menos de 30 segundos!

    
por 29.04.2010 / 21:53
1

Não é uma resposta direta, mas se você usar o rsync versão 3+, ele começará a transferir antes de gerar toda a lista de arquivos.

Outra opção, ainda não muito eficiente, seria executá-los como trabalhos, para que alguns funcionem ao mesmo tempo.

Além disso, acabei de pensar nessa estranheza se você não se importar em usar tar:

tar cf - . | tee >(ssh localhost 'cat > test1.tar') >(ssh localhost 'cat > test2.tar') >/dev/null

Onde cada localhost seria servidores diferentes, claro (assume login baseado em chave). Nunca usei o anterior antes.

    
por 29.04.2010 / 20:21
1

Que tal executar as tarefas de rsync do host1, host2 e host3? Ou, execute um trabalho para copiar para o host1 e, em seguida, execute-o no host2 e no host3 para obtê-lo do host1.

    
por 29.04.2010 / 21:25
1

Uma solução melhor seria criar um repositório com git e apenas empurrar para os 3 hosts. Mais rápido, você não precisaria da parte da lista de arquivos e consumiria menos recursos.

Boa sorte,
João Miguel Neves

    
por 04.05.2010 / 22:51
1

Ao procurar por essa resposta, eu acho que você precisaria fazer um lote usando o rsync primeiro e depois enviá-lo para todos eles, o que faria com que a lista de arquivos precisasse ser triturada a cada vez, e então você poderia fazer o background de todos os três rsyncs para executá-los em paralelo.

    
por 03.12.2010 / 20:33
1

Outra possível solução é apenas executar tantos processos rsync em paralelo quanto você possui hosts, ou seja, fork.

    
por 28.02.2013 / 01:15

Tags