Restic: Hacer que la restauración sea reanudable.

Sin duda, esto es posible y una buena idea, gracias por plantear el problema. Durante la restauración, ya tenemos toda la información que necesitamos (metadatos y listas de fragmentos de contenido para los archivos).

Quizás, a prueba de fallas, la restauración debería negarse a restaurar si el directorio de destino no está limpio / vacío, a menos que el operador explícitamente quiera este comportamiento con --resume, por ejemplo

Tengo otro caso de uso para un comportamiento muy similar, pero lo llamaría "revertir" o "deshacer". (Mi caso de uso: el hecho de que restic no distingue semánticamente entre copia de seguridad completa e incremental y la fragmentación inteligente lo hace perfecto para guardar estados de archivos de disco de máquina virtual). En una situación menos que catastrófica, es posible que desee volver al estado de ayer rápidamente, sin tener que borrar los archivos primero, luego descargarlos y restaurarlos por completo.
Supongo que le estoy pidiendo a Restic que sobrescriba algunos de mis datos. Peor aún: un operador podría pensar en mejorar una situación y no darse cuenta de que la está empeorando. Una solución de respaldo nunca debería permitir / arriesgar eso. Por lo tanto, una reversión / reversión siempre debe crear una instantánea del objetivo que va a cambiar y decirlo claramente.
Esto también aclara el punto de qué hacer con los archivos nuevos que aún no estaban allí ayer: elimínelos después de la copia de seguridad.
Me doy cuenta de que esto se está extendiendo no solo para ser una solución de respaldo, sino también un sistema de control de versiones. Puede que esto no sea necesario.

Una "reversión" o "reversión" a una instantánea anterior sería diferente a una "restauración - reanudar" en el sentido de que esperaría que algunos de los datos ya estuvieran en su lugar, crear una instantánea si es necesario y eliminar nuevos archivos una vez que se hayan respaldado.

A veces tengo una conexión de red irregular, y la capacidad de reiniciar de manera confiable una restauración desde s3 sería excelente.

¡Esto será bueno, y ahora que estamos obteniendo un caché, los bloques de construcción fundamentales están comenzando a estar en su lugar! https://github.com/restic/restic/pull/1040

Actualmente estoy intentando restaurar mi copia de seguridad. Desafortunadamente, la conexión del servidor es MUY irregular, por lo que no puedo restaurarla, ya que cada vez que la conexión se interrumpe, el procedimiento de restauración comienza de nuevo.

También me interesa esta función, espero que puedas implementarla pronto

Hice una copia de seguridad de un volumen de más de 10 TB en Backblaze B2, que tardó aproximadamente una semana en cargarse. Ahora no estoy seguro de cómo puedo restaurar esto de manera confiable. Tengo curiosidad por saber cuál es el estado actual de este problema y qué se podría hacer para resolverlo pronto.

@trustin Eso es una gran copia de seguridad, sin duda. Me pregunto si podría escribir un script para restaurar algunos archivos a la vez. La secuencia de comandos se ejecutará repetidamente en cada pequeño conjunto de archivos hasta que se restauren. Puede ser una solución lenta y fea, pero puede ser confiable.

Como solución alternativa, es posible restic mount su repositorio y luego usar algo como rsync para copiar los archivos requeridos.

@alphapapa @dionorgua Gracias por las sugerencias. Déjame probarlos una vez que mi sesión de restauración actual falle.

Como solución alternativa, es posible resticular el montaje de su repositorio y luego usar algo como rsync para copiar los archivos requeridos.

Me pregunto si es una buena idea. ¿Es simplemente mejor que ejecutar restic restore ? Si puede usar FUSE y montarlo y ejecutar rsync , ¿hay alguna razón para no hacerlo? rsync puede reanudar fácilmente las transferencias interrumpidas, incluso después de desmontar y volver a montar.

Espero que el rendimiento sea peor y, en algunos casos, mucho peor al usar restic mount . (Recuerdo que hubo informes sobre retrasos muy largos solo para enumerar el contenido del directorio dentro del repositorio montado).

Por cierto, estoy restaurando en Windows, así que tendré que generar una máquina virtual y montar Samba.

Tengo curiosidad por saber si esto funcionaría:

1. Utilice rclone para copiar todo el repositorio restic en un directorio local y
2. Ejecute restic para restaurar desde el directorio local a otro directorio local.

Estoy preguntando esto porque:

• Restaurar un archivo individual funciona, pero toma demasiado tiempo para que Restic comience a transferir el archivo. Parece gastar demasiada CPU y tiempo para cargar índices.
• Restaurar carpeta por carpeta es más rápido que restaurar un archivo individual, pero requiere demasiadas operaciones manuales dado el tamaño de la copia de seguridad.

Esto funcionará con seguridad. Pero tenga en cuenta que deberá transferir el repositorio completo con todos los datos (todas las instantáneas) porque no sabe qué archivos son necesarios para restaurar lo que necesite.

PD. Hay algún trabajo en curso para mejorar el rendimiento de la restauración: # 1719

Esto no es perfecto, ya que no se reanuda byte a byte, pero cuando hay 1-5 archivos en un segmento o algo así, no debería ser un problema.

Como se menciona en los documentos, check puede segmentar la cuenta de cheques. Supongo que la restauración funciona de la misma manera.
Al restaurar primero, cree un archivo en el directorio vacío, a qué se está restaurando (para evitar sobrescribir al reanudar). El archivo realiza un seguimiento de qué segmento se completa.
Luego comience a descargar en segmentos, divídalo automáticamente en n segmentos, n según el recuento de archivos y el tamaño del trabajo. Escriba n en el archivo.
(segmento de ejemplo) Cuando el segmento n-1 comienza a descargarse o termina de descargarse y se verifica, agregue segment n-1 y su estado al archivo (json). Al reanudar, el archivo podría analizarse para ver qué segmentos se han descargado, qué se han descargado a medias y qué también se ha verificado.
Debido a la adición, obtendrá varios estados de un segmento. Esto podría resolverse mediante la lógica de verified anula downloaded , lo que anula started .

Otras soluciones son bienvenidas, actualmente no estoy en condiciones de implementar esto.

@trustin que probablemente no funcione.

Lo que es una solución alternativa por ahora es montar la copia de seguridad y usar rclone para copiar de mount a local.

Creo que esta es una característica clave para copias de seguridad grandes. Probaré la opción de montaje rsync + cuando se complete mi copia de seguridad, debería funcionar para mí. Otra posibilidad podría ser usar algo como una VPN que pueda manejar una conexión intermitente entre el servidor y el cliente, mientras hace que parezca que hay una red en funcionamiento continuo con pings grandes a veces. (Puede que tenga que ajustar los parámetros de tiempo de espera o algo así). Tengo algo de experiencia con tinc trabajando así.

Por lo tanto, hay una cuestión de qué montaje en la cabeza o en red es mejor para usted.

https://github.com/restic/restic/issues/353 sugiere que el backend rclone podría tener algunas características de resistencia: ¿esto también se aplica a la restauración?

Espero que el rendimiento sea peor y, en algunos casos, mucho peor cuando se usa el montaje restic. (Recuerdo que hubo informes sobre retrasos muy largos solo para enumerar el contenido del directorio dentro del repositorio montado).

En restic 0.10.0 que se lanzó ayer, hay algunas mejoras importantes para montar el rendimiento de navegación.