Em rsync , -z compactará os dados do arquivo durante a transferência.
Se eu entendi corretamente, -z compactar arquivos antes da transferência e depois descompactá-los após a transferência. O tempo reduzido durante a transferência devido a compressão outweight o tempo de compressão e descompressão?
A resposta para a pergunta depende se eu fizer backup para um disco rígido externo via usb (2.0 ou 3.0) ou para um servidor pelo ssh através da internet?
É uma questão geral. A compactação e a descompactação nos pontos de extremidade melhoram a largura de banda efetiva de um link?
A banda efetiva (percebida) de um link que faz compressão e descompactação nos pontos finais é uma função de:
A função é descrita com este gráfico 3D, que você pode querer consultar para sua situação específica:
Ográficoseoriginacomoartigode2005
Se você tem uma conexão muito lenta (pense em GPRS), você definitivamente quer comprimir seus dados o máximo possível, caso contrário sua conexão irá atrasar as coisas.
Se você tem uma CPU muito lenta e uma conexão rápida (como um dispositivo de rede embarcado), normalmente não quer compactar seus dados, caso contrário, sua CPU diminuirá a velocidade.
Sim, a velocidade da conexão determina se a velocidade aumenta. Será sobrecarga apenas para backup USB, porque não os discos infla os dados, mas o processo que grava os dados. Então, a mesma máquina que lê e desinfeta, tem que inflar e escrever também. O rsync ainda é dois processos, mas sua memória para entregar dados de um processo para outro é rápida o suficiente e o processador precisa de mais tempo para compactá-lo (enquanto o lê na mesma memória que depois o entrega:).
A compactação só ajuda quando você tem um remetente e um receptor rsync e alguma rede mais lenta no meio. 1Gbit pode já ser rápido o suficiente quando você tem um NAS local, por exemplo, 10Gbit já é a velocidade SATA bruta. Portanto, a compactação só é necessária quando você tem 100Mbit ou menos de conectividade e só faz sentido quando os dados compactados são compactáveis.
Eu acho que o rsync pode notar que ele não roda em duas máquinas, exceto uma, e ignora a compressão, mas não tem certeza.
Depende de quão compressíveis são seus dados e o poder de processamento de sua origem e destino. Um backup de disco completo em minha experiência será compactado em cerca de 30 a 50% de seu tamanho original, por isso pode valer a pena dar uma chance. Caso contrário, não se incomode com a compressão. Pode valer a pena testar sua taxa de compactação com pigz -c <your file> | wc -c e comparar o tamanho retornado com o tamanho original.
tl; dr Sobre links de transferência lentos, comprima, caso contrário não. Abaixo está um teste de velocidade de compressão, um link para uma ferramenta de conversão de largura de banda e algumas informações.
Usar a compactação com rsync só acelerará se o link intermediário for "lento o suficiente", ou seja, se a máquina em uma extremidade for capaz de produzir um fluxo de dados compactado rápido o suficiente para saturar o link de comunicação.
Então, qual é o link mais lento no qual eu deveria usar compressão para ganhar alguma coisa?
O seguinte é um teste muito pouco científico, que mostrará com que rapidez gzip pode produzir dados e o que isso significa para saber se você deve compactar suas transferências em massa de rede em geral.
Os dados de entrada irão alterar o resultado do teste muito . Eu estou usando um arquivo regular (!) Descompactado no meu computador que pode ser representativo do tipo de dados que eu geralmente transfiro através de redes. Usar /dev/zero (produzindo zeros ilimitados) seria enganoso, pois um fluxo de zeros seria muito fácil de compactar, e usar /dev/random seria enganoso pela razão oposta. Então, ao invés disso, eu uso um arquivo tar do meu diretório $HOME/local , que contém o software que eu instalei no meu $HOME . O arquivo é descompactado por si só, mas contém uma mistura de arquivos binários, pequenos arquivos compactados e arquivos fonte / texto, e eu o comprimiria com a configuração padrão para gzip que iria encolher 67% de 64 MiB para 22 MiB. / p>
$ gzip -c local.tar | dd of=/dev/null
43092+4 records in
43093+1 records out
22063854 bytes transferred in 2.819 secs (7825741 bytes/sec)
Eu faço isso algumas vezes para ter uma ideia do que a média pode ser, e chega a cerca de 7800000 bytes / s.
Depois, uso uma calculadora de largura de banda de rede para ver em que isso se converte. Neste caso em particular, ele está apenas sob a capacidade de um link com fio "100Mb Ethernet", apenas mais rápido que um link "VDSL Download", um pouco mais rápido que um link sem fio "802.11 [a / g]" e em algum lugar entre "Bluetooth v3.0" (mais lento) e "USB 2.0" (mais rápido).
Isso significa que, se eu estiver usando compactação sobre qualquer coisa mais rápido , a compactação provavelmente diminuirá a transferência do arquivo.
rsync pode não estar usando as mesmas exatas bibliotecas como gzip para fazer a compactação, mas o acima daria a você uma pequena dica, pelo menos.
rsync faz mais do que a compressão, como você sabe, e o aumento da velocidade do real vem apenas da transferência de [bits de] arquivos que foram alterados.
Em minha própria experiência, o uso da compactação com rsync se tornou menos e menos benéfico nos últimos 10 anos, à medida que a largura de banda das redes aumentou (onde estou).
Para fazer backups incrementais, eu recomendaria definitivamente investigar a opção --link-dest (isso não tem nada a ver com o que é transferido, apenas com a maneira como as coisas são armazenadas no destino). Além disso, se você estiver fazendo isso por SSH, não use a compactação se sua conexão SSH já estiver compactada e apenas comprima conexões SSH (túneis etc.) que estejam sobre links lentos, pelos mesmos motivos acima.
Tags rsync