Estoy usando rsync para hacer una copia de seguridad en un NAS en mi red local a través de SSH. Sin embargo, cuando ejecuto rsync, encuentro que se atasca en ciertos archivos. Rsync se congelará por completo y se negará a transferir más archivos. Luego tengo que forzar un SIGKILL que hace que todo el trabajo de rsync se reinicie y se quede atascado en el mismo archivo que provocó que se colgara la última vez que lo ejecuté.
Probé varias soluciones pero hasta ahora ninguna ha funcionado. Originalmente pensé que sucedía debido a algún problema de caracteres ilegales entre mi sistema local (OS X 10.11.3 con OS Extended FS y mi NAS con Ubuntu Linux 14.04.1 con unidad ext4 para la copia de seguridad). He notado que cuando rsync se atasca en un archivo que normalmente tiene, el nombre del archivo o la ruta generalmente tiene un '&' 9/10 veces.
Sin embargo, después de observar los procesos de rsync con lsofy htopen el servidor, parece que rsync (la mayoría de las veces, pero no todas) falla en el mismo punto en el que se bloquea el archivo rsync del cliente. Sin embargo, me he dado cuenta de que incluso cuando rsync se bloquea en el lado del cliente, todavía aparece un resultado que lsofmuestra que se está accediendo a los archivos en el lado del servidor.
Este es el comando rsync que estoy usando.
/usr/bin/rsync --bwlimit=1000 --verbose --rsync-path="sudo rsync" --archive --recursive --numeric-ids --human-readable --partial --progress --relative --itemize-changes --stats --files-from=/Users/user/Dropbox/Flex/Scripts/mac/rysnc-backup-to-cp/config/backup_files --exclude-from=/Users/user/Dropbox/Flex/Scripts/mac/rysnc-backup-to-cp/config/exclude -e "ssh -q -p 22 -i /Users/enwhat/.ssh/user" / [email protected]:/media/Backup/_Backup/Machine/
Ejemplo de dónde normalmente se atasca rsync:
<f+++++++ Volumes/Data/Users/user1/Pictures/2013_12_iPhone_Archive/IMG_6993.m4v 17.33M 63% 994.25kB/s 0:00:10
o
<f+++++++ Volumes/Data/Users/user1/Documents/docs/Work/_Sort from USB backup drive/Drive/JOB/CD Album/AAA1834__Album&flyer_15_Years/2-Design/1-D-Visuals/stage 05/AAA_album_12_c.psd 96.40M 50% 1.55MB/s 0:01:00
Intenté eliminarlos --verbose --rsync-path="sudo rsync” --delete-duringtodos individualmente. Cuando elimino estos indicadores de argumentos, el proceso rsync llegará a un archivo determinado y luego se bloqueará.
¿Hay algo más en juego aquí o es muy probable que un carácter ilegal en el nombre del archivo esté causando un problema entre los tipos de FS?
Pensé que Crashplan, que se ejecuta en el servidor, podría haber estado consumiendo demasiados recursos y provocando que rsync fallara. Pero cuando detengo el servicio CrashPlan en el servidor, los recursos se liberan pero rsync aún falla en los mismos archivos. Esta es una nota al margen y está fuera del alcance de la pregunta, pero me pregunto si debería deshacerme de Crashplan y cambiar a Amazon Glacier como servicio de respaldo, ya que Crashplan consume mucha CPU y memoria.
Respuesta1
No sé por qué rsync podría estar bloqueado. Puede intentar ejecutar una copia normal en ese árbol de directorios y ver si tiene algún tipo de error de E/S. Ejecutar una verificación del sistema de archivos no sería una mala idea.
En cuanto al glaciar Amazonas, sí, puedes usarlo. Duplicity admite S3 como destino de copia de seguridad y las reglas del ciclo de vida de S3 le permiten mover los archivos a Glacier automáticamente (configurado a través de la consola web de S3). Debe conservar los archivos de firma y manifiesto en S3 (de lo contrario, la duplicidad no podrá recuperarlos), pero los archivos de volumen solo son necesarios si necesita extraer archivos respaldados, para que puedan almacenarse de forma segura en Glacier. Las reglas del ciclo de vida requieren un prefijo conocido, que no es el comportamiento predeterminado de la duplicidad, así que asegúrese de verificar la configuración de los parámetros.