Alguém conseguiu uma verdadeira sincronização diferencial com o rsync no ESXi?

Repreenda-me mais tarde pelo fato de estar usando o console de serviço para fazer qualquer coisa no ESXi ...

Eu tenho um binário rsync funcional (v3.0.4) que posso usar no ESXi 4.1U1. Costumo usar o rsync sobre cp ao copiar VMs ou backups de um armazenamento de dados local para outro. Eu usei o rsync para copiar dados de uma caixa ESXi para outra, mas isso era apenas para arquivos pequenos.

Agora, tentando fazer verdadeiras sincronizações diferenciais de backups feitos via ghettoVCB entre minha máquina ESXi principal e a secundária. Mas mesmo quando eu faço isso localmente (um armazenamento de dados para outro na mesma máquina ESXi), o rsync parece copiar os arquivos por inteiro. Eu tenho dois de VMDK totalmente 80GB de tamanho, e rsync ainda leva em qualquer lugar entre 1 e 2 horas, mas as de VMDK não estão crescendo que muito diária.

Abaixo está o comando rsync que estou executando. Estou copiando localmente porque, em última instância, esses arquivos são copiados para um armazenamento de dados criado a partir de um LUN em um sistema remoto. Não é um rsync que será atendido por um daemon rsync em um sistema remoto.

rsync -avPSI VMBACKUP_2011-06-10_02-27-56/* VMBACKUP_2011-06-01_06-37-11/ --stats --itemize-changes --existing --modify-window=2 --no-whole-file
sending incremental file list
>f..t...... VM-flat.vmdk
 42949672960 100%   15.06MB/s    0:45:20 (xfer#1, to-check=5/6)
>f..t...... VM.vmdk
         556 100%    4.24kB/s    0:00:00 (xfer#2, to-check=4/6)
>f..t...... VM.vmx
        3327 100%   25.19kB/s    0:00:00 (xfer#3, to-check=3/6)
>f..t...... VM_1-flat.vmdk
 42949672960 100%   12.19MB/s    0:56:01 (xfer#4, to-check=2/6)
>f..t...... VM_1.vmdk
         558 100%    2.51kB/s    0:00:00 (xfer#5, to-check=1/6)
>f..t...... STATUS.ok
          30 100%    0.02kB/s    0:00:01 (xfer#6, to-check=0/6)

Number of files: 6
Number of files transferred: 6
Total file size: 85899350391 bytes
Total transferred file size: 85899350391 bytes
Literal data: 2429682778 bytes
Matched data: 83469667613 bytes
File list size: 129
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2432530094
Total bytes received: 5243054

sent 2432530094 bytes  received 5243054 bytes  295648.92 bytes/sec
total size is 85899350391  speedup is 35.24

Isso ocorre porque o próprio ESXi está fazendo tantas alterações nos VMDKs que, no que diz respeito ao rsync, o arquivo inteiro precisa ser retransmitido?

Alguém realmente conseguiu a sincronização de diferenças real com o ESXi?

Parece que você transferiu apenas 2 GB de alterações incrementais. Lembre-se de que o rsync ainda precisa ler um arquivo inteiro e a soma de verificação, para que ele tenha 80GB de dados. Verifique as estatísticas do servidor durante o rsync. Você tem CPU ou IO vinculado durante a operação? Quão rápido você consegue ler o arquivo de 80 GB do disco? Isso estará próximo do seu tempo mínimo absoluto de transferência.

Também é importante notar que o rsync faz uma cópia do arquivo durante a transferência e move o arquivo final para o lugar em uma operação atômica. Você pode ver isso vendo um nome de arquivo semelhante com um sufixo aleatório durante a transferência no diretório de destino. Isso significa que você precisa ler 160 GB de dados (80 GB cada para cada origem e destino) e gravar 80 GB no lado do destino. Você já viu a opção --inplace? Pode ser benéfico aqui.

Em resumo, você pode ter apenas 2 GB de alterações, mas o rsync está fazendo MUITO trabalho. Você provavelmente está vinculado à IO, pois toda a leitura e gravação no mesmo disco poderia causar muita disputa e lentidão.

Este tópico é muito antigo, mas pode ajudar alguém.

Como o ESX está bloqueando o sistema de arquivos a cada gravação de novos blocos, o desempenho não é tão bom, com a opção --inplace você pode obter melhores resultados, mas esteja ciente de que, se você cancelar a sincronização, o arquivo não será consistente Mais. Sobre a consistência, o rsync de um arquivo aberto pode ser inconsistente de qualquer maneira -> use melhor o snapshot antes do rsync.

Atenciosamente Marc

Pelo que parece, você está fazendo uma cópia local para local rsync. Nesse caso, o comportamento padrão de rsyncé desativar o algoritmo de transferência delta e fazer transferências de "arquivo inteiro". A lógica para esse comportamento padrão é que as transferências de local para local usando o algoritmo delta-xfer geralmente seriam mais lentas do que simplesmente copiar os arquivos inteiros, pois o algoritmo delta envolve muito mais processamento da CPU do que apenas a cópia de arquivos inteiros.

Se você acha que uma cópia local para local se beneficiaria do uso do algoritmo delta-xfer, você pode forçar rsynca usá-lo especificando a opção --no-W(ou --no-whole-file).