¿Alguien ha logrado una verdadera sincronización diferencial con rsync en ESXi?

Más tarde me regañó por el hecho de que estoy usando la consola de servicio para hacer cualquier cosa en ESXi ...

Tengo un binario rsync que funciona (v3.0.4) que puedo usar en ESXi 4.1U1. Tiendo a usar rsync sobre cp cuando copio máquinas virtuales o copias de seguridad de un almacén de datos local a otro almacén de datos local. He usado rsync para copiar datos de un cuadro de ESXi a otro, pero eso fue solo para archivos pequeños.

Ahora trato de hacer verdaderas sincronizaciones diferenciales de copias de seguridad tomadas a través de ghettoVCB entre mi máquina ESXi primaria y una secundaria. Pero incluso cuando hago esto localmente (un almacén de datos en otro almacén de datos en la misma máquina ESXi) parece que rsync copia los archivos en su totalidad. Tengo dos de VMDK totalmente 80GB de tamaño, y rsync todavía se lleva a cualquier lugar entre 1 y 2 horas, pero los de VMDK no están creciendo que tanto diaria.

A continuación se muestra el comando rsync que estoy ejecutando. Estoy copiando localmente porque finalmente estos archivos se copiarán en un almacén de datos creado a partir de un LUN en un sistema remoto. No es un rsync que será atendido por un demonio rsync en un 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

¿Es esto porque ESXi está haciendo tantos cambios en los VMDK que, en lo que respecta a rsync, todo el archivo tiene que ser retransmitido?

¿Alguien ha logrado realmente la sincronización de diferencias real con ESXi?

Parece que solo has transferido 2 GB de cambios incrementales. Recuerde que rsync todavía tiene que leer en un archivo completo y sumarlo para que tenga que leer 80 GB de datos. Verifique las estadísticas de su servidor durante el rsync. ¿Está CPU o IO obligado durante la operación? ¿Qué tan rápido puede leer el archivo de 80GB en el disco? Eso estará cerca de su tiempo de transferencia mínimo absoluto.

También es de destacar que rsync hace una copia del archivo durante la transferencia y luego mueve el archivo final a su lugar en una operación atómica. Puede ver esto al ver un nombre de archivo similar con un sufijo aleatorio durante la transferencia en el directorio de destino. Esto significa que debe leer 160 GB de datos (80 GB cada uno para cada origen y destino) y escribir 80 GB en el lado del destino. ¿Has mirado la opción --inplace? Puede ser beneficioso aquí.

En resumen, es posible que solo tenga 2 GB de cambios, pero rsync está haciendo MUCHO trabajo. Probablemente esté obligado a IO ya que toda esa lectura y escritura en el mismo disco podría causar mucha contención y desaceleración.

Este hilo es muy antiguo, pero puede ayudar a alguien.

Como ESX está bloqueando el sistema de archivos en cada escritura de nuevos bloques, el rendimiento no es tan bueno, con la opción: en el lugar puede obtener mejores resultados, pero tenga en cuenta que si cancela la sincronización, el archivo no será consistente más. Acerca de la coherencia, rsync de un archivo abierto podría ser inconsistente de cualquier manera -> mejor usar la instantánea antes de rsync.

Saludos cordiales Marc

Por lo que parece, está haciendo una copia local a local con rsync. En ese caso, el comportamiento predeterminado de rsynces desactivar el algoritmo de transferencia delta y realizar transferencias de "archivo completo". La razón de este comportamiento predeterminado es que las transferencias locales a locales que usan el algoritmo delta-xfer generalmente serían más lentas que simplemente copiar los archivos completos, ya que el algoritmo delta implica mucho más procesamiento de la CPU que simplemente hacer la copia de todo el archivo.

Si cree que una copia local a local se beneficiaría con el uso del algoritmo delta-xfer, puede forzar rsyncsu uso especificando la opción --no-W(o --no-whole-file).