Usamos rsync para actualizar un espejo de nuestro servidor de archivos principal a un servidor de respaldo ubicado fuera del sitio. Uno de los problemas que tenemos actualmente es que nuestro servidor de archivos tiene > 1 TB de archivos en su mayoría más pequeños (en el rango de 10 a 100 kb), y cuando transferimos esta cantidad de datos, a menudo terminamos con la conexión interrumpida varias horas después. la transferencia. Rsync no tiene una función de reanudación/reintento que simplemente se reconecta al servidor para continuar donde lo dejó; debe pasar por el proceso de comparación de archivos, que termina siendo muy largo con la cantidad de archivos que tenemos.
La solución que se recomienda es dividir su transferencia rsync grande en una serie de transferencias más pequeñas. He pensado que la mejor manera de hacer esto es mediante la primera letra de los nombres de los directorios de nivel superior, lo que no nos da una distribución perfectamente uniforme, pero es lo suficientemente buena.
Me gustaría confirmar si mi metodología para hacer esto es sensata o si hay una forma más sencilla de lograr el objetivo.
Para hacer esto, repito AZ, az, 0-9 para elegir un carácter $prefix. Al principio estaba pensando en simplemente correr
rsync -av --delete --delete-excluded --exclude "*.mp3" "src/$prefix*" dest/
(--exclude "*.mp3" es sólo un ejemplo, ya que tenemos una lista de exclusión más larga para eliminar elementos como archivos temporales)
El problema con esto es que cualquier directorio de nivel superior en dest/ que ya no esté presente en src no será seleccionado por --delete. Para solucionar esto, estoy intentando lo siguiente:
rsync \
--filter 'S /$prefix*' \
--filter 'R /$prefix*' \
--filter 'H /*' \
--filter 'P /*' \
-av --delete --delete-excluded --exclude "*.mp3" src/ dest/
Estoy usando showand hideover includeand exclude, porque de lo contrario --delete-excluded eliminará todo lo que no coincida con $prefix.
¿Es esta la forma más efectiva de dividir rsync en partes más pequeñas? ¿Existe una herramienta más eficaz, o una señal que he pasado por alto, que podría simplificar esto?
Respuesta1
Mi solución a esto fue un enfoque diferente de dos pasos, en el que cedo algo de espacio en disco. Hago rsync --only-write-batch en el servidor, luego sincronizo el archivo por lotes con el destino, realizando un bucle hasta que rsync se realiza correctamente. Una vez que el lote finaliza por completo, rsync --read-batch en el destino recrea todos los cambios.
Esto también tiene algunos beneficios no deseados para mí:
Como me preocupa más que la copia de seguridad "exista" que que sea "utilizable", en realidad no hago el lote de lectura en el extremo receptor todos los días; la mayoría de las veces el lote es relativamente pequeño
He estado experimentando con --checksum-seed=1... Puede que esté leyendo mal la documentación, pero creo que hace que los archivos por lotes sean más sincronizables (es decir, cuando no hago ningún --read-batch). día determinado, el lote del día siguiente se sincroniza más rápido porque el lote del día anterior es una buena base)
Si el lote es demasiado grande para enviarlo "a tiempo" a través de Internet, puedo conectarlo en una unidad externa. Por tiempo me refiero a que si no puedo terminar el lote y leerlo antes de que comience la copia de seguridad del día siguiente.
Aunque yo personalmente no hago esto, podría tener dos copias de seguridad externas en ubicaciones separadas y enviarles el lote a ambas.
Respuesta2
No respondo exactamente a tu pregunta, pero otra opción que uso con bastante frecuencia es hacer esto en un enfoque de dos pasos: primero crear una lista de archivos, luego dividir la lista de archivos que se transferirán e introducir la lista de archivos en rsync/cpio/cp, etc. .
rsync --itemize-changes <rest of options>imprimirá una lista de archivos que se transferirán con un montón de metadatos útiles, de esa salida es bastante fácil extraer los nombres de los archivos y luego hacer la copia real con una rsync --files-fromu otra herramienta.
Podría ser útil para su situación: reanudar una transferencia rota sería mucho más rápido.
Respuesta3
Le sugiero que vigile el problema de conexión, en lugar de intentar resolverlo creando otro "problema".
No es un comportamiento común. ¿Estás usando rsync a través de SSH o rsyncd?
Hasta donde yo sé, la mayoría de las conexiones "cerradas" ocurren cuando no se transfieren datos entre los puntos finales.