mejorar el rendimiento de la copia de seguridad rsync

¿Cuáles son las mejores técnicas para mejorar rsync sobre la duplicación ssh entre cajas Unix, suponiendo que un sistema siempre tendrá la copia maestra y el otro sistema siempre tendrá una copia reciente (menos de 48 horas)

Además, ¿qué tendría que hacer uno para escalar ese enfoque para manejar docenas de máquinas que reciben esos cambios?

Si :

• La hora de modificación de sus archivos es correcta
• Los archivos no son realmente grandes.
• No se puede perder ningún empuje (o hay algún tipo de procesamiento atrasado)

Puede usar find -ctimeo file -cnewerpara hacer una lista de archivos modificados desde la última ejecución y copiar solo los archivos modificados (solo un empuje diferencial glorificado).

Esto se tradujo bastante bien para varios hosts: simplemente haga un tar diferencial en la fuente y descomprímalo en todos los hosts.

Te da algo así:

find -type f -cnewer /tmp/files_to_send.tar.gz > /tmp/files_to_send.txt
tar zcf /tmp/files_to_send.tar.gz --files-from /tmp/files_to_send.txt 
for HOST in host1 host2 host3 ...
do
    cat /tmp/files_to_send.tar.gz | ssh $HOST "tar xpf -"
done

El guión tiene que ser refinado, pero entiendes la idea.

Suponiendo que los datos que está sincronizando ya no están comprimidos, activar la compresión (-z) probablemente ayudará a transferir la velocidad, a costa de alguna CPU en cada extremo.

Si está transfiriendo archivos muy grandes con muchos cambios, use las opciones --inplace y --whole-file, las uso para mis imágenes VM de 2Gb y me ayudó mucho (principalmente porque el protocolo rsync no estaba haciendo mucho) con pasar datos incrementales con estos archivos). No recomiendo estas opciones para la mayoría de los casos.

use --stats para ver qué tan bien se están transfiriendo sus archivos usando el protocolo incremental rsync.

Otra estrategia es hacer que ssh y rsync sean más rápidos. Si va a través de una red confiable (léase: privada), no es necesario cifrar la carga útil real. Puede usar HPN ssh . Esta versión de ssh solo cifra la autenticación. Además, rsync versión 3 comienza a transferir archivos mientras crea la lista de archivos. Esto, por supuesto, es un gran ahorro de tiempo con respecto a rsync versión 2. No sé si eso es lo que estaba buscando, pero espero que sea útil. Además, rsync admite la multidifusión de alguna manera, aunque no pretendo entender cómo.

Cuando está sincronizando como método de copia de seguridad, el mayor problema con el que se encontrará será si tiene muchos archivos de los que está realizando una copia de seguridad. Rsync puede manejar archivos grandes sin problemas, pero si el número de archivos de los que está haciendo una copia de seguridad es demasiado grande, notará que rsync no se completará en un período de tiempo razonable. Si esto sucede, deberá dividir la copia de seguridad en partes más pequeñas y luego pasar por esas partes, por ejemplo

find /home -mindepth 1 -maxdepth 1 -print0 | xargs -0 -n 1 -I {} -- rsync -a -e ssh {} backup@mybackupserver:/backup/

o reducir el conjunto de archivos para reducir la cantidad de archivos.

En cuanto a que docenas de máquinas obtengan un reflejo de esos cambios, depende de cuán fresca deba ser la copia de seguridad. Un enfoque sería reflejar los cambios desde el servidor primario al servidor de respaldo y luego hacer que los otros servidores retiren sus cambios del servidor de respaldo, ya sea mediante un demonio rsync en el servidor de respaldo inicial y luego programando los otros servidores para que tomen un poco en diferentes momentos o mediante un script, use ssh sin contraseña para conectarse a cada uno de los servidores y dígales que extraigan una copia nueva de la copia de seguridad que ayudaría a evitar abrumar a su servidor de copia de seguridad inicial, pero dependerá de si tiene tantos problemas. en cuántas otras máquinas tiene una copia de la copia de seguridad.

rsync tiene una forma de hacer copias desconectadas . En otras palabras, rsync puede (conceptualmente) diferenciar un árbol de directorios y producir un archivo de parche que luego puede aplicar en cualquier número de archivos que sean idénticos a la fuente original.

Requiere que invoque rsync con el maestro y el espejo con --write-batch; Produce un archivo. Luego transfiere este archivo a cualquier número de otros objetivos, y luego aplica el lote a cada uno de esos objetivos usando --read-batch.

Si mantiene una copia local del último estado sincronizado (es decir, una copia de cómo se ven los espejos en este momento) en la misma máquina que el maestro, puede generar este "parche" en el maestro sin siquiera contactar con ningún espejo:

En el maestro:

rsync --write-batch=my-batch.rsync /master/data /current/mirror

Agregue cualquier otra opción que desee. Esto hará dos cosas:

1. Hará un /current/mirrorcambio para reflejar/master/data
2. Se creará un archivo binario parche (o archivo por lotes) llamado my-batch.rsyncpara su uso posterior.

Transfiera el my-batch.rsyncarchivo del maestro a todos sus espejos, y luego en los espejos, aplique el parche, por así decirlo:

rsync --read-batch=my-batch.rsync /local/mirror

Beneficios de este enfoque:

• el maestro no está inundado
• no es necesario coordinar / tener acceso al maestro / espejo (s) al mismo tiempo
• diferentes personas con diferentes privilegios pueden hacer el trabajo en el maestro y los espejos.
• no es necesario tener un canal TCP (ssh, netcat, lo que sea; el archivo se puede enviar por correo electrónico ;-))
• los espejos sin conexión se pueden sincronizar más tarde (solo conéctelos en línea y aplique el parche)
• todos los espejos garantizados para ser idénticos (ya que aplican el mismo "parche")
• todos los espejos se pueden actualizar simultáneamente (ya --read-batchque solo es intensivo en cpu / io en el espejo en sí)