Para sincronizar arquivos grandes ou dispositivos de bloco com diferenças de baixa a moderada, você pode fazer uma cópia simples ou usar bdsync , rsync não é absolutamente adequado para este caso em particular *.
bdsync
funcionou para mim, parece maduro o suficiente, sua história de bugs é animadora (pequenos problemas, pronta resolução). Nos meus testes, a velocidade estava próxima do máximo teórico que você poderia obter ** (ou seja, você pode sincronizar o tempo necessário para ler o arquivo). Finalmente é open source e não custa nada.
bdsync
lê os arquivos de ambos os hosts e troca somas de verificação para compará-las e detectar diferenças. Todos estes ao mesmo tempo . Finalmente, cria um arquivo de correção compactado no host de origem. Em seguida, você moverá esse arquivo para o host de destino e executará o bdsync uma segunda vez para corrigir o arquivo de destino.
Ao usá-lo em um link bastante rápido (por exemplo, 100Mbit ethernet) e para arquivos com pequenas diferenças (como ocorre com freqüência em discos VM), ele reduz o tempo de sincronização para o tempo necessário para ler o arquivo. Em um link lento, você precisa de um pouco mais de tempo, porque é necessário copiar as alterações compactadas de um host para o outro (parece que você pode economizar tempo usando um truque legal mas não testei).
*: o rsync é extremamente ineficiente com arquivos enormes. Mesmo com --inplace, ele primeiro lerá todo o arquivo no host de destino, depois de ler o arquivo no host de origem e finalmente transferirá as diferenças (apenas execute dstat ou similar enquanto executa o rsync e observe). O resultado é que, mesmo para arquivos com pequenas diferenças, leva o dobro do tempo necessário para ler o arquivo para sincronizá-lo.
**: Supondo que você não tem outra maneira de saber quais partes dos arquivos foram alteradas. LVM instantâneos usam bitmaps para gravar os blocos alterados para que eles possam ser extremamente mais rápidos (o leiame de lvmsync tem mais informações).