Restic: Datos de una instantánea incompleta.

Ah, hm. ¿Necesita un archivo específico o simplemente "todos los datos que hay"? Los datos están ahí, y restic tiene todos los medios para extraerlos, pero eso significaría programar alrededor de restic (que será muy lento) o agregar código personalizado para restic.

Pregunta honesta: ¿qué importancia tienen los datos para usted? Podría dedicar algo de tiempo hoy a hackear algo para ti, lo que debería darte acceso a casi todos los datos que se han subido al repositorio, pero probablemente no esté tan "listo para la producción" como la mayoría del código. :)

Los datos son muy importantes para mí y lamentablemente no hay otra copia. Sé que eso no es ideal, pero era un problema que estaba intentando resolver. Estoy buscando una solución de hardware para intentar volver a poner el volumen en línea, pero eso no parece demasiado esperanzador en este momento. Si hubiera una manera de especificar un directorio y poder acceder y descargar todo dentro de ese directorio, sería un gran salvavidas. Son muchos datos (muchos de ellos son proyectos de video), por lo que sería preferible la opción más rápida. Dicho esto, realmente no sé cuánto trabajo tomaría y aprecio que este sea software libre, pero estaría muy agradecido si esto pudiera ser posible.

ok, veré qué puedo hacer.

Muchas gracias.

Puede comenzar ejecutando restic rebuild-index , por lo que tenemos un índice nuevo que cubre todos los paquetes en el repositorio.

Empezando ahora.

Vaya, eso es muy generoso de tu parte @ fd0.

Si puedo ayudar a probar algo relacionado con esto, hágamelo saber.

¿Debería restic rebuild-index pedirme la contraseña del repositorio? Aún no lo ha hecho. Sospecho que puede llevar bastante tiempo debido a la cantidad de datos en el repositorio. Estoy perfectamente contento de dejarlo correr todo el fin de semana, o hasta la próxima semana si es necesario. Solo quiero estar seguro de que no necesita mi contraseña antes de dejarlo desatendido durante un largo período de tiempo.

Hm, debería pedir una contraseña desde el principio. Necesita descifrar todos los encabezados de todos los archivos en el repositorio. ¿Quizás tiene la variable de entorno RESTIC_PASSWORD exportada, por lo que no necesita una contraseña suya?

Debería imprimir algo como esto desde el principio:

repository ed6136ad opened successfully, password is correct

Al menos cuando se ejecuta de forma interactiva (sin redirección de stdout a un archivo de registro).

También puede omitir el rebuild-index si los últimos 15 minutos de los datos cargados no son tan importantes, siempre podemos hacerlo más adelante.

No tengo ese conjunto de variables de entorno RESTIC_PASSWORD , pero lo estableceré y dejaré que se ejecute el comando. No devolvió nada durante unos 10 minutos, así que le di un ctrl-c y lo intenté de nuevo. Mi sintaxis es correcta, ¿verdad? restic -r b2:MY_BUCKET_NAME:/ rebuild-index En cualquier caso, los últimos 15 minutos de datos deberían ser muy pequeños en comparación con el total de datos cargados, por lo que estaría perfectamente feliz de volver a esto más adelante.

ok, entonces no ejecutes rebuild-index todavía, para que podamos probar el código de recuperación :)

He enviado un compromiso a la rama recover-data , solo compile restic ( go run build.go ) y llámelo así:

$ restic -r b2:MY_BUCKET_NAME:/ recover

Luego, debe enumerar todos los árboles en el repositorio, encontrar los árboles raíz y crear una nueva instantánea que haga referencia a todos los árboles raíz:

repository abe002d6 opened successfully, password is correct
load index files
load 543 trees
tree (543/543)
done
found 2 roots
save tree with 2 nodes
saved new snapshot 26f25bf1

Luego, tiene una instantánea ( 26f25bf1 en este caso) que puede restaurar, o simplemente use restic mount para navegar en ella. También puede simplemente enumerarlo:

$ restic ls -l 26f25bf1 /
repository abe002d6 opened successfully, password is correct
snapshot aac6d0ed of [/recover] filtered by [/] at 2018-08-23 22:23:56.903268714 +0200 CEST):
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /0b9e25fb
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /d0d9386a

Los directorios de nivel superior llevan el nombre de los ID de árbol, por lo que son un poco crípticos, pero el siguiente nivel tiene nombres normales.

¡Avísame si eso te ayuda!

Entonces, para agregar un poco de historia de fondo: leí el número de github, luego me di una ducha y pensé: "hm, eso no es tan difícil de hacer". Resulta que tenía razón y no fue así. Si esta funcionalidad es útil para otros, podemos convertirla en un comando adecuado más adelante, pero por ahora espero que funcione para usted y pueda acceder a los datos que ya están cargados en B2.

¿Cuántos datos eran? ¿Cuánto recuperaste?

¡Buena suerte!

¡Guauu! ¡Eso fue rápido! Muchas gracias! Acabo de clonar el repositorio y voy a intentar construirlo ahora. También descubrí por qué rebuild-index no funcionaba. Fue un problema de DNS en la red en la que se encuentra nuestro servidor. Lo arreglé y obtuve Fatal: unable to create lock in backend: repository is already locked by PID 41208 así que aparentemente mi carga no se detuvo correctamente después de todo. El comando unlock parece haber aclarado eso y rebuild-index se está ejecutando actualmente.

Hoy haré todo lo que pueda, pero me iré al norte de Michigan para el fin de semana en unos 15 minutos y no creo que mi acceso a Internet sea muy bueno allí. Esto llamará toda mi atención el lunes cuando regrese y les daré más detalles :-)

muchas gracias por esto! Lamento dejarte colgando, pero estaré en contacto el lunes.

Si esta funcionalidad es útil para otros, podemos convertirla en un comando adecuado más adelante.

Me encantaría ayudar con esto en todo lo que pueda. Mi velocidad de carga aquí es de 1 Mbps, por lo que mis copias de seguridad iniciales pueden tardar entre 3 y 6 meses. Tener una forma de restaurar antes de que se complete sería una característica excelente, especialmente si no es demasiado difícil, como usted dice. ¡Déjame saber cómo puedo ser de utilidad! ¡Muchas gracias por trabajar en esto! :RE

Además, creo que su solución es bastante brillante. Elegante y bastante simple.

Lamento dejarte colgando, pero estaré en contacto el lunes.

No te preocupes por eso, solo tengo curiosidad por saber si funciona: gafas de sol:

Los datos están seguros en B2 y no desaparecerán. Incluso el comando recover no cambiará ningún dato, solo lo leerá, agregará otro archivo y una instantánea, y eso es todo.

Entonces, para darle un poco de antecedentes (tal vez expandiré esto en una publicación de blog más adelante): Bajo el capó, un repositorio restic contiene diferentes tipos de archivos, por ejemplo snapshot y data archivos:

• data archivos contienen un montón de tree o data blobs más cortos, con un encabezado al final que describe lo que hay en el archivo y dónde exactamente
• snapshot archivos tree

Cuando un archivo se guarda con restic, se corta en data blobs, que se recopilan y guardan juntos en uno o más archivos en el repositorio. El nombre del archivo junto con la lista de referencias (ID) a los blobs data se guarda en un árbol. Cuando restic termina de archivar el directorio, la lista de archivos (nombres y referencias para data blobs) se guarda como un blob tree en otro archivo data .

Para los subdirectorios, restic almacena el nombre del subdirectorio junto con la referencia del blob tree describe el contenido en otro tree .

Al final de la ejecución restic backup tenemos una raíz tree que no es referenciada por ningún otro árbol, pero contiene todas las referencias a todos los árboles de nivel superior y por lo tanto (indirectamente) a todos los archivos y subdirectorios en la copia de seguridad. Como último paso, restic crea un nuevo archivo snapshot que hace referencia a la raíz tree .

Si le dice a restic que se olvide de una instantánea en particular, ya no se hace referencia al árbol raíz. restic prune detecta esto y elimina el árbol y todos los demás tree y data blobs innecesarios.

En general, un tree solo se guarda en el repositorio cuando todos los archivos y subdirectorios que contiene se han guardado correctamente. Entonces, tan pronto como haya un blob tree , podemos asumir que los datos a los que hace referencia (incluidos los subdirectorios) también están allí.

Cuando se cancela restic durante la copia de seguridad, habrá un montón de tree blobs en el repositorio, junto con los datos de los archivos a los que hacen referencia. Entonces, para recuperar los datos, restic solo necesita hacer lo siguiente:

• Haga una lista de todos los ID de árboles, observe a qué árboles se ha hecho referencia (inicialmente: ninguno)
• para cada árbol:
  
  
  
  • cargar el árbol
  
  
  • para cada entrada en el árbol:
    
    
    
    
    
    • si es un directorio, hace referencia a otro árbol, marque ese árbol como referenciado en la lista
    
    
    
  
  

A continuación, revise la lista de árboles nuevamente, deseche todos los que hemos visto referencias. Los árboles restantes son los árboles raíz, lo que significa árboles que son (o han sido) directamente referenciados por una instantánea, o que están "colgando" como resultado de una ejecución abortada de restic backup .

Como último paso, cree un nuevo árbol que enumere todos los árboles raíz, guárdelo en el repositorio y luego cree una nueva instantánea que haga referencia a este nuevo árbol.

Luego, puede usar esta nueva instantánea normalmente, excepto por los nombres crípticos de los directorios (que son solo los ID de árbol cortos de los árboles raíz que encontramos).

Antes de fusionar esto con master, creo que deberíamos hacer lo siguiente:

• Agregue una opción a recover que excluye los árboles raíz a los que se hace referencia en las instantáneas existentes, por lo que solo obtendremos árboles raíz realmente colgantes. Quizás este comportamiento debería ser el predeterminado, la mayoría de los usuarios probablemente no estén tan interesados ​​en los datos a los que pueden acceder a través de instantáneas existentes ...
• También haga que los blobs data referencia estén disponibles en la nueva instantánea, para que los usuarios puedan juntar partes de archivos que aún no se incluyeron en un objeto tree .
• Establezca metadatos sensibles tanto para el nuevo árbol como para la nueva instantánea. Por el momento eso es muy feo (solo lo suficiente para que funcione).
• Mejores informes de progreso, eso es muy complicado en este momento

Pequeña actualización sobre esto: comencé un rebuild-index antes de irme el jueves pasado. Eso murió antes de que yo regresara con un read: connection reset by peer . Lo reinicié ayer con un número mayor de conexiones paralelas a b2 y parece que funciona bien. Ahora es solo del 5%, pero espero que tarde un poco. El depósito b2 tiene aproximadamente 90 TB y los directorios de los que estaba haciendo una copia de seguridad probablemente tenían entre 110 y 120 TB.

Honestamente, estoy muy impresionado de que restic se haya mantenido tan estable durante la carga. Probé Cloudberry para Mac antes de probar Restic y no pude hacerlo funcionar con tantos datos. Utilizo restic para hacer una copia de seguridad de mi computadora portátil en casa y me encanta, así que pensé en darle una oportunidad. Como ni siquiera he terminado mi carga inicial, no tengo idea de cómo saldrá algo como prune , pero estaré encantado de mantenerlo actualizado si necesita datos sobre cómo se comporta restic con grandes volúmenes de datos . Si puedo lograr que complete todas las operaciones necesarias para mantener una copia de seguridad semanal en menos de una semana, creo que será un gran candidato para manejar estas copias de seguridad.

Por el momento, tengo algunas preguntas: ¿Debo dejar que este rebuild-index se complete antes de probar un recover ? ¿Perderé algo si no lo hago? He estado pensando en esto y creo que me gustaría recuperar tanto como sea posible en el primer intento, si es posible, ya que las cosas tardan un poco en ejecutarse con esta cantidad de datos, pero si es mejor eliminar esto, ejecute recover primero y rebuild-index después, puedo hacer eso. ¿Ejecutar rebuild-index o recover con una bandera --quiet acelerará las cosas como lo hace con el comando backup ?

¡Está bien! Recomendaría hacer lo siguiente:

• Abortar el rebuild-index
• Ejecutar restic recover
• Eche un vistazo a los datos que contiene la instantánea recién creada

Si desea probar, puede ejecutar rebuild-index nuevamente y extraer los megabytes restantes de datos del repositorio. Probablemente sea menos de unos cientos de megabytes, y es probable que esto no revele ningún dato nuevo que aún no esté contenido en la instantánea. Pero puedes probarlo :)

Mientras se esté ejecutando rebuild-index , no puede acceder al repositorio.

¿La ejecución de rebuild-index o la recuperación con un indicador --quiet acelerará las cosas como lo hace con el comando de copia de seguridad?

No

Dejé que todo funcionara durante la noche y parece que se llenó el disco duro y falló:

found 755 roots Fatal: unable to save new tree to the repo: fs.TempFile: open /var/folders/tq/67qp8py137n_5nzf563qlylr0000gn/T/restic-temp-pack-913168611: no space left on device

¿Existe una manera fácil de saber cuántos datos tendrá que descargar esta operación o alguna manera de reducir la cantidad que se descarga?

Además, si quiero liberar este espacio en disco, ¿es restic cache --cleanup la forma de hacerlo?

No, eso solo elimina los directorios de caché que no se han utilizado durante 30 días. Simplemente elimine el directorio de caché, que debería estar en algún lugar de su directorio de inicio.

¿Qué comando ejecutó exactamente? Tanto rebuild-index como recover no deberían guardar muchos datos en el disco duro, a excepción de la caché de metadatos ...

No en mi escritorio en este momento. pero era algo como: ./restic -o b2.connections=x -r b2:mybucket:/ recover Creo que tenía x configurado en algo enorme. Eso puede haber sido parte del problema. Puedo reiniciarlo sin el bit -o b2.connections=x . Encontré el directorio de caché y lo borré.

En primer lugar, una herramienta increíble.
También necesito hacer una copia de seguridad de terabytes de datos a través de una conexión lenta y tengo la posibilidad de que la copia de seguridad falle mientras aún no esté completa. ¿Existe una forma recomendada de hacer una copia de seguridad de unos pocos archivos a la vez?

¿Existe una forma recomendada de hacer una copia de seguridad de unos pocos archivos a la vez?

Lo que generalmente funciona (he escuchado) es guardar partes individuales de los datos de origen (por ejemplo, directorios individuales) y cuando eso se completa, guardar todos los directorios juntos. Cuando los datos de origen no han cambiado, restic no debería cargar casi nada debido a la deduplicación incorporada.

Un lugar mejor para tales preguntas sería el foro en https://forum.restic.net , la pregunta (¡y las respuestas!) Son mucho más fáciles de descubrir allí.

@pauletg entonces, ¿cómo te fue?

He propuesto el nuevo comando recover en # 2056.

No he avanzado mucho en la recuperación del descanso desde mi última publicación. La buena noticia es que hemos logrado reactivar el servidor y los datos no se dañaron en el accidente, así que tengo mis datos. El comando de recuperación parece llenar el disco duro de mi máquina, antes de que pudiera completarse. Esto podría haber sido causado por varios factores: mi copia de seguridad era enorme y estaba usando una gran cantidad de conexiones a b2 para la carga y el disco duro en la máquina que estaba usando para la recuperación era relativamente pequeño. Estoy seguro de que probablemente funcionaría muy bien si mi copia de seguridad tuviera un tamaño más razonable. Avíseme si hay más información que pueda serle útil. Realmente aprecio que haya trabajado en esto y tener esta función disponible para las copias de seguridad de mi computadora portátil es realmente bueno.

¡Gracias por la respuesta! Si lo desea (y tiene mucho tiempo), puede volver a intentarlo con --no-cache , pero tardará aún más. Cerraré este problema cuando se fusione # 2056.

Háganos saber si tiene comentarios adicionales. :)