Gracias por informar de este problema, creo que es un error.

Probablemente sucederá siempre que los directorios de nivel superior tengan el mismo nombre. Debido a que no se restaura la ruta completa, solo el directorio de nivel superior.

La solución es reconstruir la ruta completa al restaurar y restaurar cada árbol en la ruta completa. Entonces, la ruta resultante sería como /tmp/restic/tmp/restic/FILESNEW0{1,2}/Dir01/ . Creo que es aceptable.

¿Es necesario implementar el parche como parte de la restauración?
¿O tal vez deba realizarse durante la copia de seguridad mediante la creación de un árbol de nivel superior diferente que incluya los componentes de la ruta completa?

También sospecho que este es el caso. Por el momento, restic funciona así:

Cuando se llama como restic backup A/foo B/foo , crea una estructura de árbol en el repositorio que se ve así:

├── foo
└── foo

Por lo tanto, solo se toma el último componente de la ruta de los argumentos al comando backup , esto genera un problema al restaurar dicha instantánea.

Para corregir esto, propongo implementar el mismo comportamiento que tar , que en este caso crearía el siguiente árbol:

.
├── A
│   └── foo
└── B
    └── foo

Esto requerirá algo de trabajo en la parte archivadora de restic. No creo que necesitemos tocar restaurar en absoluto.

588 informé lo mismo. Pero ese tiene un caso de prueba que puedes usar.

@ fd0 Propongo incluir también una opción (--store-full-path) para realizar una copia de seguridad donde almacena explícitamente la ruta 'real' completa del objetivo de la copia de seguridad.

El razonamiento es que en el caso de tar y con varias otras herramientas de copia de seguridad, puede obtener un árbol de restauración poco complicado. Si bien este es un buen valor predeterminado, personalmente me gustaría que mis restauraciones se parecieran al diseño completo del sistema de archivos original para las copias de seguridad del host. (Aún mejor si la restauración también pudiera anteponer el nombre de host a la ubicación de restauración)

@trbs Creo que el valor predeterminado debe ser almacenar rutas completas, con un interruptor para el caso especial de usar rutas relativas. La razón es que las rutas rel pueden producir un comportamiento inesperado o indefinido, pero los abdominales no. Si desea solicitar prefijos o alguna otra forma de alteración de rutas, le sugiero que sea un problema completamente separado.

He pensado en esto y creo que debemos cambiar el comportamiento de la copia de seguridad para que siempre se guarde la ruta completa (como se indica en la línea de comandos). Eso es lo que hace tar , y funciona muy bien. Desafortunadamente, esto es una reliquia de una mala decisión de diseño al principio del desarrollo de Restic.

+1 por --store-full-path

Odio solo +1, pero también estoy muy interesado en una solución para este error. Tiene varias instalaciones pendientes de restic, donde este error desafortunadamente es un éxito.

Gracias @ fd0 por su trabajo en esto, entiendo que no es fácil relajarse ahora.

-1 por --store-full-path . Preferiría ver la ruta completa siempre en la copia de seguridad y luego tener un --strip-components <N> para quitar las piezas si no las necesita en el momento de la restauración. Esto significa que los datos completos siempre están disponibles en la copia de seguridad y si el usuario quita demasiados componentes de la ruta en el momento de la restauración y, por lo tanto, combina subdirecciones, se convierte en un error de usuario recuperable.

En cuanto al prefijo del nombre de host en la ubicación de la copia de seguridad, parece que se puede hacer fácilmente desde la línea de cmd, ya que la mayoría de las personas saben desde qué host van a restaurar de antemano :)

Dado que aún no es 1.0, voto que, si se debe hacer un cambio importante para obtener la solución ideal, hágalo lo antes posible.

@mholt Estoy de acuerdo, ya estoy trabajando en esto. Como dije, esto se debe a una mala decisión de diseño desde el principio y debe corregirse.

Hey @ fd0 : acabo de ver que se lanzó 0.7. ¿Está esto (y # 910 y # 909) en el mapa para 0.7.1?

Quizás no para 0.7.1, pero para 0.8.0 más o menos. Aunque ya empecé a trabajar en eso. Tal vez un poco de antecedentes: esto es causado por el código del archivador, que es el código más antiguo presente en restic. Desafortunadamente (como estaba comenzando a aprender Regresa en 2013/2014) el código del archivador es muy complejo y cometí muchos errores de principiante (demasiada concurrencia, demasiados canales). También me preocupé por las cosas que resultaron no ser un problema en absoluto y pasé por alto las cosas que se convirtieron en un problema (por ejemplo, el manejo de índices).

Entonces, ya comencé a reimplementar el código del archivador por completo, usando la concurrencia solo cuando tiene sentido (es decir, procesando fragmentos individuales) y no leyendo 20 archivos del disco en paralelo. Este código también incluye la ruta de directorio adecuada e insertará las rutas completas en el repositorio.

Afortunadamente, este es solo el archivador que necesita ser tocado, el resto del código (gracias al diseño de restic y el repositorio) continuará funcionando bien.

¿Afectará este cambio a los repositorios existentes y, de ser así, cómo?

"afectando" en términos de "nuevas copias de seguridad tendrán una estructura ligeramente diferente", sí, pero eso es todo. No migrate ni nada necesario.

Entonces, el # 1209 se ha fusionado y mejora la situación al detectar conflictos de nombres y resolverlos (cambiando el nombre), pero este problema aún no está completamente resuelto. Estoy trabajando en ello :)

@ fd0 ¿ Alguna idea de cuándo podemos esperar instantáneas que contengan la ruta original completa? Actualmente estamos trabajando en la automatización de copias de seguridad y restauraciones usando restic.

Al automatizar la restauración, es fundamental tener la ruta de origen intacta.

Si tengo un servidor con dos directorios de 'datos' que se están respaldando (y esto no es teórico, tenemos varios servidores con directorios de 'datos' de Confluence y JIRA que deben respaldarse), el proceso de restauración debe saber cuál El directorio de datos pertenece a Confluence y qué directorio de datos pertenece a JIRA. Un nombre como 'datos' y 'datos-1' obviamente no es suficiente aquí.

Creo que la mejor solución por ahora es hacer una copia de seguridad de los directorios de datos en instantáneas separadas y etiquetarlas con 'JIRA' o 'Confluence'.

No hay una línea de tiempo, lo siento.

Creo que la mejor solución por ahora es hacer una copia de seguridad de los directorios de datos en instantáneas separadas y etiquetarlas con 'JIRA' o 'Confluence'.

Sí, pero según el número 1225 no podrá fusionarlos fácilmente en un repositorio más adelante.

Con respecto a la opción --store-full-path : rsync tiene esta opción: -R , --relative .
¿Quizás usar el mismo nombre de opción para restic?

Para las copias de seguridad del sistema completo, he descrito una solución aquí: https://forum.restic.net/t/full-system-restore/126/8 No es bonito, pero funcionará hasta que # 1494 esté listo.

Este error me preocupó un poco, pero no puedo reproducirlo en 0.8.3 con los pasos proporcionados. ¿Sigue siendo un tema abierto?

Sí, lamentablemente esto sigue siendo un problema.

Hm, de alguna manera no puedo replicar el problema, así que no estoy seguro de qué estoy haciendo diferente. Adjunté mi guión de prueba.

test_restic_549.zip

Puedes reproducirlo así:

$ mkdir dir1/subdir
$ echo foo > dir1/subdir/foo

$ mkdir dir2/subdir
$ echo bar > dir2/subdir/bar

$ restic backup dir1/subdir dir2/subdir
password is correct
scan [/home/user/dir1/subdir /home/user/dir2/subdir]
scanned 2 directories, 2 files in 0:00
/home/user/dir2: name collision for "subdir", renaming to "subdir-1"
[...]
snapshot f6138d06 saved

Para los dos subdirectorios, restic usa el nombre base del subdirectorio como el directorio de nivel superior en el repositorio, por lo que para dir1/subdir y dir2/subdir ambos son subdir , eso es lo que causa la colisión.

La lista de la última instantánea lo muestra:

$ restic ls latest
password is correct
snapshot f6138d06 of [/home/user/dir1/subdir /home/user/dir2/subdir] at 2018-03-21 20:38:33.58232292 +0100 CET):
/subdir
/subdir/foo
/subdir-1
/subdir-1/bar

En su caso de prueba, los nombres base de $TESTDIR/dir1 y $TESTDIR/dir2 son diferentes ( dir1 vs. dir2 ) por lo que el error no ocurre.

De las notas de lanzamiento de la versión 0.9:

La primera copia de seguridad con esta versión de restic probablemente dará como resultado que todos los archivos se vuelvan a leer localmente, por lo que llevará mucho más tiempo. La siguiente copia de seguridad después de eso será rápida nuevamente.

Solo quiero darte algunas estadísticas:

primera copia de seguridad:

-------------------------------------------------------------
Start: Do 24. Mai 05:15:01 CEST 2018
437 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:38
snapshot f724ff21 saved

Files:         556 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 556 files, 914.493 GiB in 2:15:29
snapshot 3c0e0f1b saved

Files:       11570 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 11570 files, 66.044 GiB in 16:21
snapshot 312fd29c saved

Files:        2309 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 2309 files, 163.332 GiB in 24:13
snapshot 2baab573 saved

Files:         312 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 312 files, 1.503 TiB in 4:48:23
snapshot 02dfe40c saved

Files:       743172 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      84.927 MiB

processed 743172 files, 89.131 GiB in 2:48:59
snapshot dcee3e70 saved

Files:         441 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 441 files, 727.575 GiB in 1:56:36
snapshot 676adc45 saved
End:   Do 24. Mai 17:46:46 CEST 2018
Duration: 12h:31m:45s
-------------------------------------------------------------

segundo:

-------------------------------------------------------------
Start: Fr 25. Mai 05:15:01 CEST 2018
444 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:42
snapshot 9c7cf320 saved

Files:           0 new,     0 changed,   556 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 556 files, 914.493 GiB in 0:15
snapshot 533e2155 saved

Files:           0 new,     0 changed, 11570 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 11570 files, 66.044 GiB in 0:17
snapshot 1c1235c3 saved

Files:           0 new,     0 changed,  2309 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 2309 files, 163.332 GiB in 0:13
snapshot d5ef168d saved

Files:           0 new,     0 changed,   312 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 312 files, 1.503 TiB in 0:16
snapshot 76e94946 saved

Files:         292 new,     0 changed, 743172 unmodified
Dirs:            0 new,     2 changed,     0 unmodified
Added:      32.790 MiB

processed 743464 files, 89.163 GiB in 1:06
snapshot 12fa66e8 saved

Files:           0 new,     0 changed,   441 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 441 files, 727.575 GiB in 0:15
snapshot ab2d29bb saved
End:   Fr 25. Mai 05:19:12 CEST 2018
Duration: 0h:4m:11s
-------------------------------------------------------------

mucho más, significa mucho más :-)
¡Mantener el buen trabajo! 👍

@ fd0 , ¡trabajo increíble! ¡Muchas gracias! Su herramienta de copia de seguridad se ha convertido en mi favorita para todas mis copias de seguridad fuera del sitio (usando b2) :-)