O caminho rápido
A maneira mais rápida de transferir arquivos em uma LAN provavelmente não é o rsync, a menos que haja poucas mudanças. O rsync gasta um bom tempo fazendo somas de verificação, calculando diferenças, etc. Se você sabe que vai transferir a maioria dos dados de qualquer maneira, faça algo assim (note: existem várias implementações de netcat
; o manual para as opções corretas. Em particular, o seu pode não querer o -p
):
user@dest:/target$ nc -q 1 -l -p 1234 | tar xv
user@source:/source$ tar cv . | nc -q 1 dest-ip 1234
Isso usa o netcat ( nc
) para enviar tar sobre uma conexão TCP bruta na porta 1234. Não há criptografia, verificação de autenticidade, etc., portanto é muito rápido. Se sua conexão cruzada estiver sendo executada em gigabits ou menos, você conectará a rede; se mais, você vai ligar o disco (a menos que você tenha uma matriz de armazenamento ou disco rápido). Os v
sinalizadores para tar fazem com que ele imprima os nomes dos arquivos à medida que vão sendo usados (modo detalhado). Com arquivos grandes, praticamente não há sobrecarga. Se você estivesse fazendo milhares de arquivos pequenos, desligaria isso. Além disso, você pode inserir algo como pv
no pipeline para obter um indicador de progresso:
user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv
É claro que você pode inserir outras coisas, como gzip -1
(e adicionar o z
sinalizador na extremidade de recebimento - o sinal z
na extremidade de envio usaria um nível de compactação maior que 1, a menos que você defina a variável de ambiente GZIP, é claro). Embora o gzip provavelmente seja mais lento, a menos que seus dados sejam realmente compactados.
Se você realmente precisa do rsync
Se você está realmente transferindo apenas uma pequena parte dos dados que foram alterados, o rsync pode ser mais rápido. Você também pode querer olhar para a opção -W
/ --whole-file
, como em uma rede realmente rápida (como uma conexão cruzada) que pode ser mais rápida.
A maneira mais fácil de executar o rsync é por meio do ssh. Você vai querer experimentar com cifras ssh para ver qual é o mais rápido, será AES, ChaCha20 ou Blowfish (embora existam algumas preocupações de segurança com o tamanho de bloco de 64 bits do Blowfish), dependendo se o chip tiver o AES da Intel -NI instruções (e seu OpenSSL usa-los). Em um ssh novo o suficiente, o rsync-over-ssh se parece com isso:
user@source:~$ rsync -e 'ssh -c [email protected]' -avP /source/ user@dest-ip:/target
Para ssh / sshd mais antigo, experimente aes128-ctr
ou aes128-cbc
em vez de [email protected]
.
ChaCha20 seria [email protected]
(também precisa de um novo ssh / sshd) e Blowfish seria blowfish-cbc. O OpenSSH não permite a execução sem uma cifra. É claro que você pode usar qualquer uma das opções de rsync que você preferir no lugar de -avP
. E, claro, você pode ir na outra direção e executar o rsync da máquina de destino (pull) em vez da máquina de origem (push).
Tornando o rsync mais rápido
Se você executar um daemon rsync, poderá se livrar da sobrecarga de criptografia. Primeiro, você criaria um arquivo de configuração do daemon ( /etc/rsyncd.conf
), por exemplo, na máquina de origem (leia a página do manual rsyncd.conf para obter detalhes):
[big-archive]
path = /source
read only = yes
uid = someuser
gid = somegroup
Então, na máquina de destino, você executaria:
user@dest:~$ rsync -avP source-ip::big-archive/ /target
Você pode fazer o inverso também (mas é claro que precisará definir somente leitura como não). Existem opções para autenticação, etc., verifique a página de manual para detalhes.