Solución 1:
rsync --ignore-existing --sparse ...
Para crear nuevos archivos en modo disperso
Seguido por
rsync --inplace ...
Para actualizar todos los archivos existentes (incluidos los dispersos creados anteriormente) en su lugar.
Solución 2:
Rsync solo transfiere cambios a cada archivo y con --inplace solo debe reescribir los bloques que cambiaron sin volver a crear el archivo. Desde su página de características.
rsync es un programa de transferencia de archivos para sistemas Unix. rsync usa el "algoritmo rsync" que proporciona un método muy rápido para sincronizar archivos remotos. Lo hace enviando solo las diferencias en los archivos a través del enlace, sin requerir que ambos conjuntos de archivos estén presentes en uno de los extremos del enlace de antemano.
Usar --inplace debería funcionar para usted. Esto le mostrará el progreso, comprimirá la transferencia (en el nivel de compresión predeterminado), transferirá el contenido del directorio de almacenamiento local de forma recursiva (la primera barra diagonal importa), realizará los cambios en los archivos en su lugar y usará ssh para el transporte.
rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
[email protected]:/path/to/remote/storage/
A menudo también uso la bandera -a, que hace algunas cosas más. Es equivalente a -rlptgoD. Te dejaré el comportamiento exacto para que lo busques en la página del manual.
Solución 3:
Eche un vistazo a Zumastor Linux Storage Project, implementa una copia de seguridad de "instantánea" usando "rsync" binario a través de ddsnap
herramienta.
Desde la página del manual:
ddsnap proporciona replicación de dispositivos de bloque dada una instalación de instantáneas a nivel de bloque capaz de mantener múltiples instantáneas simultáneas de manera eficiente. ddsnap puede generar una lista de fragmentos de instantáneas que difieren entre dos instantáneas y luego enviar esa diferencia por cable. En un servidor descendente, escriba los datos actualizados en un dispositivo de bloque con instantánea.
Solución 4:
Terminé escribiendo software para hacer esto:
http://www.virtsync.com
Este es un software comercial que cuesta $49 por servidor físico.
Ahora puedo replicar un archivo disperso de 50 GB (que tiene 3 GB de contenido) en menos de 3 minutos a través de banda ancha residencial.
[email protected]:~$ time virtsync -v /var/lib/libvirt/images/vsws.img backup.barricane.com:/home/chris/
syncing /var/lib/libvirt/images/vsws.img to backup.barricane.com:/home/chris/vsws.img (dot = 1 GiB)
[........>.........................................]
done - 53687091200 bytes compared, 4096 bytes transferred.
real 2m47.201s
user 0m48.821s
sys 0m43.915s
Solución 5:
Para sincronizar archivos grandes o dispositivos de bloqueo con diferencias bajas a moderadas, puede hacer una copia simple o usar bdsync, rsync no es apto para este caso en particular*.
bdsync
funcionó para mí, parece lo suficientemente maduro, su historial de errores es alentador (pequeños problemas, resolución rápida). En mis pruebas, su velocidad estuvo cerca del máximo teórico que podría obtener ** (es decir, puede sincronizar aproximadamente el tiempo que necesita para leer el archivo). Finalmente es de código abierto y no cuesta nada.
bdsync
lee los archivos de ambos hosts e intercambia sumas de verificación para compararlos y detectar diferencias. Todo esto al mismo tiempo . Finalmente crea un archivo de parche comprimido en el host de origen. Luego mueve ese archivo al host de destino y ejecuta bdsync por segunda vez para parchear el archivo de destino.
Cuando se usa a través de un enlace bastante rápido (por ejemplo, Ethernet de 100 Mbit) y para archivos con pequeñas diferencias (como suele ser el caso en los discos de VM), reduce el tiempo de sincronización al tiempo que necesita para leer el archivo. En un enlace lento, necesita un poco más de tiempo porque tiene que copiar los cambios comprimidos de un host a otro (parece que puede ahorrar tiempo usando un buen truco pero no lo ha probado). Para archivos con muchos cambios, también se debe tener en cuenta el tiempo para escribir el archivo de parche en el disco (y necesita suficiente espacio libre en ambos hosts para almacenarlo).
Así es como normalmente uso bdsync. Estos comandos se ejecutan en $LOCAL_HOST
para "copiar" $LOCAL_FILE
a $REMOTE_FILE
el $REMOTE_HOST
. Yo uso pigz
(un gzip
más rápido ) para comprimir los cambios, ssh
para ejecutar bdsync en el host remoto y rsync
/ssh
para copiar los cambios. Tenga en cuenta que estoy comprobando si el parche se ha aplicado correctamente, pero solo imprimo "Actualización correcta" cuando lo hace. Es posible que desee hacer algo más elegante en caso de falla.
REMOTE_HOST=1.2.3.4
LOCAL_FILE=/path/to/source/file
REMOTE_FILE=/path/to/destination/file
PATCH=a_file_name
LOC_TMPDIR=/tmp/
REM_TMPDIR=/tmp/
# if you do use /tmp/ make sure it fits large patch files
# find changes and create a compressed patch file
bdsync "ssh $REMOTE_HOST bdsync --server" "$LOCAL_FILE" "$REMOTE_FILE" --diffsize=resize | pigz > "$LOC_TMPDIR/$PATCH"
# move patch file to remote host
rsync "$LOC_TMPDIR/$PATCH" $REMOTE_HOST:$REM_TMPDIR/$PATCH
# apply patch to remote file
(
ssh -T $REMOTE_HOST <<ENDSSH
pigz -d < $REM_TMPDIR/$PATCH | bdsync --patch="$REMOTE_FILE" --diffsize=resize && echo "ALL-DONE"
rm $REM_TMPDIR/$PATCH
ENDSSH
) | grep -q "ALL-DONE" && echo "Update succesful" && rm "$LOC_TMPDIR/$PATCH"
# (optional) update remote file timestamp to match local file
MTIME=`stat "$LOCAL_$FILE" -c %Y`
ssh $REMOTE_HOST touch -c -d @"$MTIME_0" "$REMOTE_FILE" </dev/null
*:rsync es enormemente ineficiente con archivos grandes. Incluso con --inplace, primero leerá el archivo completo en el host de destino, DESPUÉS comenzará a leer el archivo en el host de origen y finalmente transferirá las diferencias (simplemente ejecute dstat o similar mientras ejecuta rsync y observe). El resultado es que, incluso para los archivos con pequeñas diferencias, se tarda aproximadamente el doble del tiempo necesario para leer el archivo para sincronizarlo.
**:bajo el supuesto de que no tiene otra forma de saber qué partes de los archivos han cambiado. Las instantáneas de LVM usan mapas de bits para registrar los bloques modificados para que puedan ser extremadamente más rápidos (el archivo Léame de lvmsync tiene más información).