Salida de restic version

restic 0.8.2

¿Cómo corriste restic exactamente?

% restic -r /tmp/restictest backup $SSHFSMOUNT/directory

El directorio de respaldo es un sistema de archivos montado en sshfs.
El comando se ejecuta varias veces para realizar varias instantáneas.
En mi caso, hay una gran cantidad de datos (1TB +) en el directorio remoto.

¿Qué backend / servidor / servicio usaste para almacenar el repositorio?

Sistema de archivos local ext4.

Comportamiento esperado

Espero que la primera copia de seguridad sea lenta y transfiera muchos datos a través de LAN, mientras que las próximas copias de seguridad deberían ser bastante rápidas y no deberían utilizar mucho ancho de banda.

Comportamiento real

Todas las copias de seguridad tardan horas (si no días) incluso si ningún archivo ha cambiado.

Pasos para reproducir el comportamiento.

• ejecutar una copia de seguridad
• desmontar el sistema de archivos sshfs
• volver a montar el sistema de archivos sshfs
• ejecutar una nueva copia de seguridad

No es 100% reproducible, pero incluso con una pequeña cantidad de datos podría reproducirlo.

Los registros del servidor SFTP muestran que los archivos se recuperan por completo incluso cuando no cambiaron.

¿Tiene alguna idea de qué pudo haber causado esto?

Sí: restic compara los inodos para verificar si los archivos han sido modificados (mensaje de depuración "marca de tiempo, tamaño o inodo cambiado", restic/node.go:551restic.(*Node).IsNewer11node ).

Sin embargo, los inodos pueden cambiar en los montajes del sistema de archivos con sshfs (y probablemente algunos otros sistemas de archivos).

¿Tiene una idea de cómo solucionar el problema?

Comentar la verificación de inodo resolvió el problema por mí.

Me gustaría tener una forma de deshabilitar esta verificación; tal vez una bandera de línea de comandos?

¿Restic te ayudó o te hizo feliz de alguna manera?

¡Claro, es un buen software! Estoy aún más satisfecho desde que encontré una solución ...
¡Sigan con el buen trabajo!