linux - rsync ssh key

Reanudación de rsync parcial(-P/- parcial) en una transferencia interrumpida (4)

Encontré que agregar - en lugar lo arregla. No estoy seguro de cómo se supone que funcione parcialmente sin él, pero se reanudaron mis transferencias. Sin embargo, mis archivos aún son bastante grandes y me pregunto si terminaré con archivos corruptos si se inicia una transferencia y, horas más tarde, se inicia otra transferencia, pero se ve un archivo incompleto y no se sabe si se está cargando, lo que luego comienza a agregar bytes a eso. ¿Nadie sabe? ¿Tal vez algún script de bash para registrar la identificación del proceso actual y no iniciar otra transferencia?

Estoy tratando de hacer una copia de seguridad de mi servidor de archivos en un servidor de archivos eliminado usando rsync. Rsync no se reanuda correctamente cuando se interrumpe una transferencia. Utilicé la opción parcial pero rsync no encuentra el archivo que ya se inició porque le cambia el nombre a un archivo temporal y cuando se reanuda, crea un nuevo archivo y comienza desde el principio.

Aquí está mi orden:

rsync -avztP -e "ssh -p 2222" /volume1/ myaccont@backup-server-1:/home/myaccount/backup/ --exclude "@spool" --exclude "@tmp"

Cuando se ejecuta este comando, un archivo de copia de seguridad denominado OldDisk.dmg de mi máquina local se crea en la máquina remota como algo parecido a .OldDisk.dmg.SjDndj23 .

Ahora, cuando se interrumpe la conexión a Internet y tengo que reanudar la transferencia, tengo que encontrar dónde rsync quedó al encontrar el archivo temporal como .OldDisk.dmg.SjDndj23 y cambiarle el nombre a OldDisk.dmg para que vea que ya existe un Archivo que puede reanudar.

¿Cómo soluciono esto para no tener que intervenir manualmente cada vez?

Lo siento pero las otras respuestas aquí son demasiado complicadas: -7. Una respuesta más simple que funciona para mí: (usando rsync sobre -e ssh)

# optionally move rsync temp file, then resume using rsync dst$ mv .<filename>.6FuChr <filename> src$ rsync -avhzP --bwlimit=1000 -e ssh <fromfiles> <user@somewhere>:<destdir>/

Funciona también cuando se reanuda desde un scp que fue interrumpido.

Rsync crea un archivo temporal ... El archivo temporal crece rápidamente al tamaño del archivo parcialmente transferido. La transferencia se reanuda.

Scp escribe en el archivo de destino final real. Si se interrumpe la transferencia, este es un archivo truncado.

Explicación de args:

-avhz ... h = humanoide, v = verboso, a = archivo, z = compresión ... el archivo le indica que mantenga los valores de time_t para que, incluso si los relojes están fuera, rsync sepa la fecha verdadera de cada archivo

-P es la abreviatura de --partial --progress. --parcial le dice a rsync que mantenga los archivos parcialmente transferidos (y al reanudar, rsync usará los archivos parcialmente transferidos siempre después de la suma de comprobación de forma segura)

De las páginas de manual: http://ss64.com/bash/rsync_options.html

--partial By default, rsync will delete any partially transferred file if the transfer is interrupted. In some circumstances it is more desirable to keep partially transferred files. Using the --partial option tells rsync to keep the partial file which should make a subsequent transfer of the rest of the file much faster. --progress This option tells rsync to print information showing the progress of the transfer. This gives a bored user something to watch. This option is normally combined with -v. Using this option without the -v option will produce weird results on your display. -P The -P option is equivalent to --partial --progress. I found myself typing that combination quite often so I created an option to make it easier.

NOTA: para una conexión que se interrumpe varias veces: si necesita reanudar después de rsync (después de que se interrumpe la conexión), es mejor cambiar el nombre del archivo temporal en el destino. scp crea un archivo en el destino con el mismo nombre que el archivo final. Si se interrumpe el scp, este archivo es una versión truncada del archivo. Un rsync (-avzhP) se reanudará desde ese archivo, pero comenzará a escribir en un nombre de archivo temporal como ..Yhg7al.

Procedimiento al comenzar con scp:

scp; *interrupt*; rsync; [REPEAT_as_needed: *interrupt*; mv .destfile.tmpzhX destfile; rsync;].

Procedimiento al comenzar con rsync:

rsync; [REPEAT_as_needed: *interrupt*; mv .destfile.tmpzhX destfile; rsync;].

Si tiene miedo de los archivos corruptos después de un currículum, puede agregar --checksum para forzarlo a realizar la suma de comprobación en todo el archivo cada vez. De hecho, le costará algunos ciclos de IO y CPU, pero solo una pequeña sobrecarga de red.

TL; DR : use --timeout=X (X en segundos) para cambiar el tiempo de espera predeterminado del servidor rsync, no --inplace .

El problema es que los procesos del servidor rsync (de los cuales hay dos, vea rsync --server ... en la salida de ps en el receptor) continúan ejecutándose, para esperar a que el cliente rsync envíe datos.

Si los procesos del servidor rsync no reciben datos durante un tiempo suficiente, de hecho se agotarán, se autocompletarán y se limpiarán moviendo el archivo temporal a su nombre "correcto" (por ejemplo, sin sufijo temporal). Entonces podrás reanudar.

Si no desea esperar a que el tiempo de espera predeterminado prolongado haga que el servidor rsync finalice automáticamente, entonces cuando su conexión a Internet vuelva, inicie sesión en el servidor y limpie los procesos del servidor rsync manualmente. Sin embargo, debe finalizar cortésmente rsync; de lo contrario, no colocará el archivo parcial en su lugar; sino más bien, elimínelo (y por lo tanto no hay ningún archivo para reanudar). Para pedir cortésmente a rsync que finalice, no SIGKILL (por ejemplo, -9 ), sino SIGTERM (por ejemplo, pkill -TERM -x rsync - solo un ejemplo, debe tener cuidado de hacer coincidir solo los procesos rsync relacionados con su cliente).

Afortunadamente, hay una forma más fácil: use la --timeout=X (X en segundos); También se pasa a los procesos del servidor rsync.

Por ejemplo, si especifica rsync ... --timeout=15 ... , tanto el proceso rsync del cliente como el del servidor se cerrarán si no envían / reciben datos en 15 segundos. En el servidor, esto significa mover el archivo temporal a la posición, listo para reanudar.

No estoy seguro del valor de tiempo de espera predeterminado de los diversos procesos rsync que intentarán enviar / recibir datos antes de que mueran (puede variar según el sistema operativo). En mis pruebas, los procesos rsync del servidor permanecen ejecutándose durante más tiempo que el cliente local. En una conexión de red "muerta", el cliente termina con una tubería rota (p. Ej., Sin conexión de red) después de unos 30 segundos; Usted podría experimentar o revisar el código fuente. Lo que significa que podría intentar "esquivar" la mala conexión a Internet durante 15-20 segundos.

Si no limpia los procesos rsync del servidor (o espera a que mueran), sino que inicia de inmediato otro proceso de cliente rsync, se iniciarán dos procesos de servidor adicionales (para el otro extremo de su nuevo proceso de cliente). Específicamente, el nuevo cliente rsync no reutilizará / volverá a conectarse a los procesos existentes del servidor rsync. Por lo tanto, tendrá dos archivos temporales (y cuatro procesos del servidor rsync); sin embargo, solo el segundo archivo temporal más nuevo tiene nuevos datos escritos (recibidos de su nuevo proceso de cliente rsync).

Curiosamente, si luego limpia todos los procesos del servidor rsync (por ejemplo, detiene su cliente que detendrá los nuevos servidores rsync, luego SIGTERM los servidores rsync más antiguos, parece que combina (ensambla) todos los archivos parciales en el nuevo archivo con el nombre adecuado) Entonces, imagine una copia parcial de larga ejecución que muera (y usted cree que ha "perdido" todos los datos copiados), y una rsync reiniciada de corta ejecución (¡oops!) .. puede detener el segundo cliente, SIGTERM el Primeros servidores, fusionará los datos y podrá reanudar.

Finalmente, unas breves observaciones:

No utilice --inplace en lugar de solucionar esto. Sin duda tendrá otros problemas como resultado, man rsync para los detalles.
Es trivial, pero -t en sus opciones de rsync es redundante, está implícito por -a .
Una imagen de disco ya comprimida enviada a través de rsync sin compresión puede resultar en un tiempo de transferencia más corto (al evitar la compresión doble). Sin embargo, no estoy seguro de las técnicas de compresión en ambos casos. Yo lo probaria
Por lo que entiendo --checksum / -c , no te ayudará en este caso. Afecta cómo rsync decide si debe transferir un archivo. Sin embargo, después de completar un primer rsync, puede ejecutar un segundo rsync con -c para insistir en las sumas de comprobación, para evitar el extraño caso de que el tamaño del archivo y el tiempo de uso sean los mismos en ambos lados, pero se escribieron datos erróneos.