Restic: manejar ciruela pasa grande mucho más eficiente

Con el rendimiento para restauraciones para grandes repositorios/repos con archivos grandes ahora resueltos por la rama fuera de servicio de @ifedorenko , parece que esta es la próxima roca para usar restic en entornos de varios terabytes donde el repositorio no está en local disco y no se accede a través del servidor REST en una interfaz de bucle invertido.

Actualmente, una poda vacía (poda de una instantánea que era 100 % idéntica a una instantánea anterior) contra un repositorio en un depósito S3 local AZ en instancias de AWS de gama alta con un ancho de banda teórico de 10 gbit/s se ejecuta en:

1) construyendo un nuevo índice -- ~160 paquetes/segundo
2) encontrar datos aún en uso: 56 segundos en total
3) paquetes de reescritura -- ~3 paquetes/segundo

160 paquetes/segundo es lento, pero tolerable (~80 minutos de tiempo de ejecución frente a un repositorio de 3 TB).

Pero la reescritura @ 3 paquetes/segundo se ejecutará durante casi 10 horas, incluso para mi noop prune (eliminará 0 paquetes y reescribirá 111098 paquetes, esto libera 180.699 GiB). Para una reducción significativa en un repositorio grande, congela nuevas copias de seguridad durante más de 24 horas.

Parece que las reescrituras del paquete actualmente ocurren en un solo subproceso, por lo que permitir que se ejecute entre varios trabajadores podría ayudar bastante, incluso si se mantiene el enfoque actual de copia y luego purga.

Personalmente, no gastaría tiempo optimizando la implementación actual de la poda de bloqueo, creo que la poda de no bloqueo es una mejor solución a largo plazo.

He estado trabajando en esto recientemente. Esto es lo que he hecho:

• Cargue el índice existente en lugar de escanear todos los paquetes (y luego escanee los paquetes que no estaban en el índice)
• Análisis en paralelo de las instantáneas en busca de blobs usados
• Reescritura en paralelo de paquetes usados ​​parcialmente
• Escriba el nuevo índice usando la información del índice que ya está en la memoria

Actualmente estoy trabajando para determinar el nivel de paralelismo que se usará para reescribir paquetes parcialmente usados ​​(planeo basarme en la cantidad configurada de conexiones para el backend). También necesito hacer muchas más pruebas en varios escenarios de error.

Estas son algunas cifras de rendimiento (usando un repositorio con 875 GiB de datos, alrededor de 180 000 paquetes y 36 instantáneas, usando un servidor de descanso de loopback como back-end):

• Código actual:
  
  
  
  • 35-40 minutos (cada uno) para construir el índice al principio y al final de la poda (70-80 minutos en total)
  
  
  • 4-5 minutos para encontrar blobs usados
  
  
  • Unos segundos para reescribir paquetes parcialmente usados
  
  
• Mis cambios hasta ahora:
  
  
  
  • Unos segundos para cargar el índice existente (algo más si necesita escanear paquetes no indexados)
  
  
  • Menos de 2 minutos para encontrar blobs usados
  
  
  • Unos segundos para escribir el nuevo índice
  
  

También planeo configurar un caso de prueba generado que implicará mucho más reescritura del paquete.

Courtney:

¡Suena súper prometedor! ¿Quería confirmar que esta es la sucursal en la que está trabajando? Estoy feliz de probar.

https://github.com/cbane/restic/tree/prune-agresivo

No, esa rama es parte de la bifurcación del repositorio principal. Todavía no he enviado mis cambios a ningún lugar público. Debería poder enviar mi versión de trabajo en progreso a GitHub en unos días para que puedas probarla.

Bien, tengo una versión que debería estar lista para que otras personas la prueben. Está en esta rama: https://github.com/cbane/restic/tree/prune-speedup

Limitaciones actuales:

• No he implementado ninguna configuración automática de la cantidad de trabajadores de reempaque. Por ahora, establezca la variable de entorno RESTIC_REPACK_WORKERS en la cantidad de trabajadores que desea usar. Por defecto será 4 si no está configurado.
• Necesito trabajar en el manejo de errores al volver a empacar. No realicé ningún cambio real con respecto al reempaquetado de un solo subproceso existente; Necesito revisar los diversos casos de error y asegurarme de que hacer el reempaquetado en paralelo no cause ningún problema.

Um, eso se ve increíble. ¡Gracias por tu trabajo!

Probé esto un poco con una copia de 3TB+ repo en Amazon S3 y hasta ahora se ve increíble. Una ciruela de reenvasado que hubiera llevado semanas ahora se completa en menos de una hora, y eso es usando EBS relativamente lento como espacio tmp.

¡Un verdadero cambio de juego aquí! ¡Gran trabajo, @cbane!

Eek, me di cuenta de que cronometré mal la carrera.

Un área que todavía tiene un solo subproceso y parece que podría beneficiarse de la paralelización es el paso de "comprobación de paquetes que no están en el índice", que aún puede llevar de 3 a 4 horas en repositorios de varios terabytes, pero esto sigue siendo un enorme, gran mejora, gracias!

@cbane No pude abrir un problema contra su bifurcación, así que avíseme si hay un lugar mejor para esto.

Durante otra ejecución de prueba, el reempaquetado falló al final (reescribiendo el último paquete), ejecutándose con 32 trabajadores:

found 1396709 of 2257203 data blobs still in use, removing 860494 blobs
will remove 0 invalid files
will delete 119301 packs and rewrite 88485 packs, this frees 896.269 GiB
using 32 repack workers
Save(<data/c136027b25>) returned error, retrying after 723.31998ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
Save(<data/09d4692900>) returned error, retrying after 538.771816ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx. Retry again.
Save(<data/23d0d4f842>) returned error, retrying after 617.601934ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
[10:02] 100.00%  88484 / 88485 packs rewritten
panic: reporting in a non-running Progress

goroutine 386596 [running]:
github.com/restic/restic/internal/restic.(*Progress).Report(0xc42011c2c0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0)
        internal/restic/progress.go:122 +0x242
github.com/restic/restic/internal/repository.Repack.func2(0x8, 0xe17f58)
        internal/repository/repack.go:66 +0x136
github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go.func1(0xc4389246c0, 0xc56f509160)
        vendor/golang.org/x/sync/errgroup/errgroup.go:57 +0x57
created by github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go
        vendor/golang.org/x/sync/errgroup/errgroup.go:54 +0x66

Tengo una nueva versión disponible, en la misma sucursal que antes. También rebase contra master .

Estos son los principales cambios con respecto a la versión anterior:

• Convirtió el reempaque de hacer que cada trabajador hiciera todas las etapas del reempaque de un solo paquete a una tubería.
• Se corrigió el bloqueo informado al final del reempaque.
• El reempaquetado ahora escala automáticamente la cantidad de trabajadores para las etapas de canalización en función de la cantidad de CPU y el límite de conexión configurado para el backend. (La variable de entorno RESTIC_REPACK_WORKERS ya no se usa).
• Ajustes menores para encontrar blobs usados.
• Paralelización del escaneo de packs desconocidos.

Todavía quiero trabajar un poco más para encontrar blobs usados. Actualmente, cada instantánea es procesada por un solo trabajador. Esto puede dejar los recursos de la CPU sin usar si hay menos instantáneas que CPU, o si hay grandes diferencias de tamaño entre las instantáneas. Me gustaría que se extendiera el procesamiento de subárboles entre diferentes trabajadores; Creo que sé cómo hacer esto, solo necesito implementarlo.

Me inclinaría por continuar discutiendo cosas sobre este tema (o la futura solicitud de extracción para esto), para que todo permanezca aquí en el repositorio principal en lugar de estar disperso.

Recién probado. Resuelve el bloqueo al final del reempaque y funciona muy, muy bien.

El único lugar adicional que podría beneficiarse de un mayor paralelismo es la eliminación de paquetes, que actualmente es de un solo subproceso.

Esto muerde particularmente fuerte durante la primera poda de un repositorio que no se pudo podar previamente, ya que hay muchos paquetes que necesitan ser eliminados.

Sin embargo, incluso con la eliminación de un solo subproceso, un olvido/poda diario en un repositorio de 1,7 TB y 356 000 paquetes que reescribe 14,7 000 paquetes y elimina 33 000 paquetes ahora lleva poco menos de 20 minutos.
Anteriormente, era imposible podar en absoluto.

Excelente trabajo, gracias!

OK, tengo otra versión disponible. El único cambio real esta vez es que ahora elimina los paquetes no utilizados en paralelo (además de algunos ajustes menores a algunos cambios anteriores). Implementé el escaneo de instantáneas modificado, pero no aceleró lo suficiente y no había una buena manera de informar el progreso al usuario, así que lo eliminé nuevamente.

Estoy planeando abrir una solicitud de incorporación de cambios para esto pronto, asumiendo que nada se rompió. (Sin embargo, primero limpiaré el historial). @fd0 , ¿quieres echarle un vistazo a esto primero?

Funcionó muy bien en nuestra prueba. Reescribió 30k paquetes en 225 segundos, eliminó 73k paquetes en 50 segundos.

El tiempo de ejecución total frente a un repositorio de 1,74 TiB en S3 con 32 instantáneas supervivientes fue de poco más de 6 minutos.

trabajo brillante

@cbane Probé tu sucursal https://github.com/cbane/restic/tree/prune-speedup

pero este es el error que recibo :(

root<strong i="9">@srv</strong> ~/restic-backups # restic --no-cache prune
repository 49b87c6a opened successfully, password is correct
listing files in repo
loading index for repo
[0:28] 1.01%  30 / 2982 index files
pack cbbebd8d already present in the index
github.com/restic/restic/internal/index.(*Index).AddPack
    internal/index/index.go:266
github.com/restic/restic/internal/index.Load.func1
    internal/index/index.go:230
github.com/restic/restic/internal/repository.(*Repository).List.func1
    internal/repository/repository.go:640
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1.1
    internal/backend/backend_retry.go:133
github.com/restic/restic/internal/backend/rest.(*Backend).listv2
    internal/backend/rest/rest.go:423
github.com/restic/restic/internal/backend/rest.(*Backend).List
    internal/backend/rest/rest.go:358
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1
    internal/backend/backend_retry.go:127
github.com/cenkalti/backoff.RetryNotify
    vendor/github.com/cenkalti/backoff/retry.go:37
github.com/restic/restic/internal/backend.(*RetryBackend).retry
    internal/backend/backend_retry.go:36
github.com/restic/restic/internal/backend.(*RetryBackend).List
    internal/backend/backend_retry.go:126
github.com/restic/restic/internal/repository.(*Repository).List
    internal/repository/repository.go:634
github.com/restic/restic/internal/index.Load
    internal/index/index.go:202
main.pruneRepository
    cmd/restic/cmd_prune.go:202
main.runPrune
    cmd/restic/cmd_prune.go:128
main.glob..func18
    cmd/restic/cmd_prune.go:28
github.com/spf13/cobra.(*Command).execute
    vendor/github.com/spf13/cobra/command.go:762
github.com/spf13/cobra.(*Command).ExecuteC
    vendor/github.com/spf13/cobra/command.go:852
github.com/spf13/cobra.(*Command).Execute
    vendor/github.com/spf13/cobra/command.go:800
main.main
    cmd/restic/main.go:86
runtime.main
    /snap/go/3947/src/runtime/proc.go:200
runtime.goexit
    /snap/go/3947/src/runtime/asm_amd64.s:1337

@antetna Parece que su repositorio tiene varios archivos de índice que cubren los mismos paquetes. No sé cómo puede suceder eso, pero agregué un caso de prueba al conjunto de pruebas y puedo reproducir su error. Trabajaré en arreglarlo.

@antetna OK, acabo de enviar una nueva versión a la misma rama (no avance rápido) que funciona con mi caso de prueba de índice duplicado. ¿Podrías intentarlo?

Planeo abrir pronto una solicitud de extracción con la versión actual de esta rama, a menos que alguien más note algún problema.

¡Muchas gracias @cbane! La poda estándar tomó alrededor de ~55 horas para podar mi repositorio de instantáneas de ~860GB 12000+. Con su enfoque paralelo más agresivo, lo redujo a poco más de 3 horas.

¡Hola @cbane , increíble trabajo!

Al ejecutar este PR aquí en Debian 9 amd64, compilado con Go 1.12.1, aparece el siguiente error después de 220 minutos de ejecución en mi repositorio de 30 TB:

checking for packs not in index
[0:52] 16.45%  178 / 1082 packs
[5:23] 100.00%  1082 / 1082 packs
repository contains 3213929 packs (259446787 blobs) with 15.025 TiB
processed 259446787 blobs: 30090 duplicate blobs, 4.906 GiB duplicate
load all snapshots
find data that is still in use for 3 snapshots
[0:04] 0.00%  0 / 3 snapshots
tree 6f144a19eaae0e81518b396bfdfc9dd5c6c035bdba28c6a90d6f70e692aa1c55 not found in repository
github.com/restic/restic/internal/repository.(*Repository).LoadTree
        internal/repository/repository.go:707
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:52
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func4
        internal/restic/find.go:89
gopkg.in/tomb%2ev2.(*Tomb).run
        vendor/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1337

¿Cómo debo recuperarme de esto?

Gracias,
--Durval.

@DurvalMenezes Parece que a su repositorio le faltan algunos archivos del paquete. ¿Lo has podado antes? ¿ restic check tiene éxito? Si no es así, debería darle una idea más detallada de lo que está mal.

Es posible que pueda recuperarse un poco ejecutando restic rebuild-index y luego ejecutando una nueva copia de seguridad. Si algo en los paquetes que faltan todavía está disponible en la ubicación de la que se está realizando la copia de seguridad, una nueva copia de seguridad lo agregará nuevamente al repositorio. Esto podría hacer que sus copias de seguridad existentes vuelvan a funcionar. Si eso no lo soluciona, creo que deberá olvidar las instantáneas afectadas antes de poder hacer una poda.

Gracias por la respuesta, @cbane. Más, a continuación:

¿Lo has podado antes?

No, esta es mi primera ciruela pasa. Para resumir: mi repositorio tiene ~95 instantáneas de 3 árboles de suciedad locales en mi NAS; esos 3 árboles de suciedad tienen un total de ~30 TB y ~60 millones de archivos/subdirectorios, y la copia de seguridad ha tardado cada vez más, hasta el punto de que la copia de seguridad de solo 24 horas de datos nuevos (menos de 10 GB) tardaba más de 24 horas en ejecutarse. El consejo en el foro fue ejecutar restic forget (lo cual hice, dejando solo las últimas 3 instantáneas) y luego restic prune , lo cual hice primero usando restic 0.9.5 (pero abortó después de ~ 24 horas debido a OOM). Luego actualicé la máquina (una VM en Google Compute Cloud) al doble de RAM y luego usé su PR, lo que generó el error anterior.

¿Tiene éxito la comprobación restic? Si no es así, debería darle una idea más detallada de lo que está mal.

Estoy ejecutando restic check durante las últimas 90 horas (también usando su PR), y hasta ahora me ha dado este resultado: restic-check-PARTIAL_output.txt

Como se indica al final del archivo anterior, restic check ha mostrado su último mensaje ("comprobar instantáneas, árboles y blobs") hace más de 3 días... Estoy empezando a preguntarme si está atascado y nunca terminará. :-/ De hecho, un "strace" en el proceso lo muestra abriendo el mismo archivo de caché local una y otra vez:

```fecha; strace -t -f -p 2608 -e abierto en 2>&1 | abrir grep | egrep -v sin terminar\|reanudado | cabeza
mar 23 jul 00:41:59 UTC 2019
[Pid 26508] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2608] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 10
[Pid 2615] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 5482] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2615] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 5482] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 10
[Pid 2608] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-cheque-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / datos / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 11
[Pid 2638] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2638] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5

And then, almost 10 hours later: 

mar 23 jul 10:14:27 UTC 2019
[Pid 2632] 10:14:27 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2639] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2613] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2617] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2611] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
```

Es posible que pueda recuperarse un poco ejecutando restic rebuild-index y luego ejecutando una nueva copia de seguridad. Si algo en los paquetes que faltan todavía está disponible en la ubicación de la que se está realizando la copia de seguridad, una nueva copia de seguridad lo agregará nuevamente al repositorio. Esto podría hacer que sus copias de seguridad existentes vuelvan a funcionar

Creo que probaré esto a continuación; si este restic check no finaliza en las próximas 24 horas, lo SIGUE y luego ejecuto un restic rebuild-index . Para el índice de reconstrucción, ¿debería usar este PR? ¿La cabeza del maestro restic? ¿O algo mas?

Gracias de nuevo,
--Durval.

Sí, eso no parece prometedor. Probablemente lo mejor que puede hacer es hacer restic rebuild-index , luego ejecutar nuevas copias de seguridad de sus tres directorios y luego olvidarse de todas las demás instantáneas. Después de eso, debería poder hacer con éxito un restic prune .

No toqué el código rebuild-index , así que puedes hacerlo con la versión que quieras.

@cbane , solo para mantenerlo informado: comencé un restic rebuild-index usando su PR hace 5 días (entiendo que cualquier versión funcionaría, pero usar la suya simplifica las cosas) y ha estado funcionando desde entonces. Después de los primeros días de desesperación (cuando la extrapolación de los porcentajes parecía indicar que duraría más de 30 días), parece haber cobrado algo de velocidad y debería funcionar 'solo' 10 días más más o menos (al menos en su estado actual). fase 'recuento de archivos en repo').

Suponiendo que este rebuild-index termine bien, el plan es ejecutar un restic prune con su PR. Te dejaré saber cómo va.

Manteniendo a todos actualizados: mi crédito GCloud gratuito de $300 terminó, totalmente devorado por la máquina virtual de 104 GB que tuve que crear para ejecutar el prune (y, supongo, también el rebuild-index ). Me estoy quedando sin opciones :-/ Actualizaré cuando/si encuentro una salida a este lío.

¡Probé la rama "prune-speedup" y los resultados son muy prometedores!

Servidor: S3

# bin/restic version
restic 0.9.5 compiled with go1.12.4 on linux/amd64
# bin/restic prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[1:30:34] 100.00%  319784 / 319784 packs
repository contains 319784 packs (5554019 blobs) with 1.445 TiB
processed 5554019 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 30 snapshots
[3:38:52] 100.00%  30 / 30 snapshots
found 5376708 of 5554019 data blobs still in use, removing 177311 blobs
will remove 0 invalid files
will delete 3526 packs and rewrite 4850 packs, this frees 26.925 GiB
[1:28:21] 100.00%  4850 / 4850 packs rewritten
counting files in repo
[1:20:27] 100.00%  314240 / 314240 packs
finding old index files
saved new indexes as [b7029105 797145b1 0ed8981e 7f19c455 dff4d9be a52d8e7a 0cf9f266 ab32a9e4 f34331b3 84c84cbb 563896c9 9902e35d 817ef96c 6b4dcfef 32d3e18c 1d782d96 b12554dd d4b69bcf 8ec94a43 66cbd035 8e9cb96d d74b5246 ca7d7ca3 1f209708 9fe26189 28414ee2 88ff07fb 24280466 8757a1f9 8706ff35 5fab942b 549409c3 f781a762 9417afec 4b2361aa 6b43f992 8da8dfe7 54ec498e 5be6fb8a 17411b83 270f3ce3 ba520d35 95913ad0 f8f15108 cbc67971 a419ff7c 875cfcc7 13f55ece bd488aa4 7f5b588a cddd40b4 7a79d1ce bd7e3d0f 2cdcd635 ee6e28c3 98146287 50867bde 41a056ae 836ce971 e9451c8b 0f9cc7e6 52dedc04 c4e8e7f6 2e4966f0 ba4fa5b3 ddc9a766 b995fd36 fd6b3ac8 1c12bcc3 4c98c3c9 39ac7cd5 42ebf4c1 1a48465e b5245192 73a73c5e daa6ee8d d26ce697 9f84d9b3 bc371def b141466a 6906b3c1 282ce115 d8024363 10f0b924 ad4fad64 9450aada 31378365 65d785b3 98b085d0 768f420c f22512b3 be3223ba 031d5488 f2b7fcf6 87177471 fd269664 b239b89e 6bf972ea 0d6f8f36 87362542 fff9c2cd 5c85ac76 f91daae1 dc594a83 220bdc83]
remove 1459 old index files
[2:33] 100.00%  8376 / 8376 packs deleted
done
# 

Ahora con la versión dev:

# bin/restic_linux_amd64 version
restic 0.9.5-dev (compiled manually) compiled with go1.12.4 on linux/amd64
# bin/restic_linux_amd64 prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[57:21] 100.00%  314240 / 314240 packs
repository contains 314240 packs (5376708 blobs) with 1.419 TiB
processed 5376708 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 29 snapshots
[1:48:18] 100.00%  29 / 29 snapshots
found 5356653 of 5376708 data blobs still in use, removing 20055 blobs
will remove 0 invalid files
will delete 212 packs and rewrite 1427 packs, this frees 3.114 GiB
[14:16] 100.00%  1427 / 1427 packs rewritten
counting files in repo
[57:47] 100.00%  313618 / 313618 packs
finding old index files
saved new indexes as [004d6eb2 630de131 1b85faed 0fb7a978 bc500e05 34f7d187 447c3b59 ada047d2 5430430e 768f606e a5c341ea a75059c5 71d0fbec c63f5c56 ba43e69d f47699f5 d7cd2587 5826bcae 6250ec67 6af77aa4 cbf8c1f9 a7809b5f c3242748 8bb7d037 8ca69481 5a8877c3 fb30ea48 4bdb6269 eeeba466 7cdc444a bc15ddd5 c5544612 b8a5004c 2879403a c33778b7 e692013a 41ce8a1d 55b4be0a 5714b820 1adca569 b06ccd6b 16467da7 79ed066a 64c7e397 43217ede af7350a4 73c65a0f 35260990 a232ea42 c843bfa5 332aded7 0e294517 26984755 3c36a14b 68b2024e 267bf0b2 a41c4f64 aa46affb c7a6e2ac 0d34c60f 766d21f0 0d7b8b41 4fea4363 a1a3c5cd 73809a0e 56a67410 25314d47 a32ded24 68feae36 78ef5cbb b051a740 6a51f900 d2ee860f 1ad44787 c6c4358d 89de2f69 a157bd2b 77995b94 3bc58934 b905be42 0a1df2e7 ba67a98c 263b5266 7a809abc 34ff6f07 d96adc12 8f69fc74 ebb053eb 8fb68f6a 11224e7d 990f61f8 764941fc ed95513b 1c17c8aa 3226a7cb 76988c78 e4d8f156 b4d4c952 8c379d51 e968f3c9 f9cfff55 464cf3e1 f9d23c32 136957e3 02e397b1]
remove 105 old index files
[0:32] 100.00%  1639 / 1639 packs deleted
done
#

¡Parece una gran mejora! ¡felicitaciones!
Publicaré más resultados si pruebo en más máquinas en las próximas semanas.

@fbarbeira Según el resultado que publicaste, parece que en realidad no estás usando mi versión mejorada. Este es el resultado que obtengo cuando elimino mi gran repositorio en Backblaze B2:

repository 399dfab1 opened successfully, password is correct
listing files in repo
loading index for repo
[0:02] 100.00%  71 / 71 index files
checking for packs not in index
repository contains 208840 packs (1675252 blobs) with 1006.203 GiB
processed 1675252 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 32 snapshots
[0:16] 100.00%  32 / 32 snapshots
found 1675113 of 1675252 data blobs still in use, removing 139 blobs
will remove 0 invalid files
will delete 4 packs and rewrite 24 packs, this frees 26.404 MiB
[3:31] 100.00%  24 / 24 packs rewritten
saving new index
[10:31] 70 index files
remove 71 old index files
[0:04] 100.00%  28 / 28 packs deleted
done

La principal fuente de lentitud en eso es la velocidad de carga limitada a través de mi cable módem.

La salida de restic version también debería verse así:

restic 0.9.5 (v0.9.5-31-g09b92d6d) compiled with go1.11.6 on linux/amd64

¿Alguna intención de fusionar esta actualización @fd0 ?

Agradecería mucho que esta mejora también se convierta en un lanzamiento oficial. La rotación de la copia de seguridad se ha vuelto tan lenta que, lamentablemente, Restic ya no es realmente una opción.

@cbane , un elemento que definitivamente no es un bloqueador, pero pensé que lo marcaría: las reescrituras del paquete de ciruelas se vuelven más lentas a medida que crecen los repositorios.

Por ejemplo, el paso de reescritura de paquetes para un repositorio de 3.984.097 paquetes reescribe paquetes a 110 paquetes/segundo en un i3.8xlarge hablando con un depósito S3 en la misma AZ.

El mismo combo de instancia + tienda de respaldo con un repositorio más pequeño (450,473) se reescribe a 200 paquetes por segundo.

@pmkane , ¿existe esa disparidad de velocidad incluso si están reescribiendo la misma cantidad de paquetes? ¿O siempre está ahí sin importar cuántos paquetes se reescriban? Además, ¿es solo la reescritura del paquete o otras etapas también se ralentizan?

No hay nada obvio en el código que pueda ralentizarlo a medida que el repositorio crece. Agregué soporte de creación de perfiles a la etapa de reescritura del paquete en mi versión local para ayudar a rastrear la fuente de la lentitud. Sin embargo, mi depósito más grande tiene solo alrededor de 200,000 paquetes, lo que no me da una buena comparación de lo que está viendo. ¿Estaría dispuesto a ejecutarlo con la generación de perfiles habilitada y hacer que los archivos de salida estén disponibles?

@cbane , no estoy seguro si es una función de la cantidad de paquetes o el tamaño del repositorio. Puedo ejecutar algunas pruebas en un duplicado de nuestro repositorio más pequeño y ver. Feliz de ejecutar una versión con creación de perfiles y compartir los resultados.

A continuación se muestran algunos tiempos de muestra para el repositorio del paquete de 460k: tiempos de 3,7 mm:

índice de carga para repositorio
[0:01] 100.00% 154 / 154 archivos de índice

encontrar datos que todavía están en uso para 36 instantáneas
[0:34] 100,00% 36 / 36 instantáneas
[0:26] 100,00% 4555 / 4555 paquetes reescritos (175 paquetes/segundo)
[0:21] 151 archivos de índice
[0:01] 100.00% 11401 / 11401 paquetes eliminados

3.752.505 paquete de repo. También vale la pena señalar que el uso de la memoria aumenta de ~ 1 GB de RSS a 8 GB de RSS en el paso "buscar datos que todavía están en uso para 14 instantáneas". Restic finalmente termina en ~ 16 GB de RSS. Tal vez inevitable, dado el gran tamaño del repositorio:

índice de carga para repositorio
[0:33] 100.00% 1188/1188 archivos de índice

encontrar datos que todavía están en uso para 14 instantáneas
[2:12] 100,00% 14 / 14 instantáneas
[49:07] 100,00 % 339187 / 339187 paquetes reescritos (115 paquetes/segundo)
guardando nuevo índice
[10:59] 1176 archivos de índice
eliminar 1188 archivos de índice antiguos
[4:51] 100.00% 409728 / 409728 paquetes eliminados

@cbane , me disculpo. Pista falsa en las velocidades de la ciruela: cuando estaba haciendo un perfil independiente, descubrí que los dos repositorios estaban en AZ diferentes, por lo que la diferencia se debió completamente a la latencia diferente a la AZ más distante.

En nuestro gran repositorio (20.791TiB, 40.522.693 blobs), recibimos el siguiente error al podar en el paso "buscar datos que todavía están en uso":

árbol 5e40b6de93549df6443f55f0f68f24bf36671e28590579c78bc62f7557490c56 no encontrado en el repositorio
github.com/restic/restic/internal/repository.( Repositorio).LoadTreeinterno/repositorio/repositorio.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3interno/restic/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3interno/restic/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4interno/restic/find.go:89gopkg.in/tumba%2ev2.( Tumba).ejecutar
vendedor/gopkg.in/tumba.v2/tumba.go:163
runtime.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

todas las copias de seguridad se completaron con éxito y una verificación restic no arroja ningún error.

¿Alguna excavación adicional que valga la pena hacer aquí, @cbane ?

Un índice de reconstrucción permitió que la poda tuviera éxito. No estoy seguro de si hay una buena manera de hacer que la ciruela pasa sea más resistente, por lo que podría solucionar el problema de forma nativa.

Hmm, tengo el mismo error de nuevo hoy. Se resolvió con un índice de reconstrucción, pero estoy empezando a preguntarme si la ciruela en sí misma podría estar causando el problema. Un cheque restic vuelve limpio cada vez.

árbol 7dc9112b587a2b67a2459e6badf7c14f986408e05dbe8a68e7458a30740ea951 no encontrado en el repositorio
github.com/restic/restic/internal/repository.( Repositorio).LoadTreeinterno/repositorio/repositorio.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3interno/restic/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3interno/restic/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4interno/restic/find.go:89gopkg.in/tumba%2ev2.( Tumba).ejecutar
vendedor/gopkg.in/tumba.v2/tumba.go:163
runtime.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

Realizamos restauraciones completas una vez a la semana para verificar la integridad de la copia de seguridad, para complementar las restauraciones diarias de archivos puntuales.

Si bien la verificación restic no mostró ningún problema con la copia de seguridad, las restauraciones completas fallan debido a la falta de un blob. Así que parece que algo pudo haberse podado en el camino que no debería haberlo hecho.

No está claro si es un error en la rama de aceleración, algo en el código de poda base o algo completamente diferente. Lamentablemente, no tengo un gran caso de prueba reproducible, pero esta es la segunda vez que vemos este tipo de corrupción de repositorios con nuestro repositorio más grande. Nuestros repositorios más pequeños no han mostrado ningún problema.

Desafortunadamente, la prueba con ciruela pasa es imposible debido al tamaño de los repositorios.

Vamos a volver a las instantáneas de EBS, por ahora, pero continuaremos monitoreando este problema y otros y estaremos felices de probar dónde tiene sentido.

Agregué un pequeño PR #2507 que debería mejorar la situación. Agradecería si algunos de ustedes pudieran hacer algunas pruebas sobre esto...
¡Gracias!

Leer el código de poda: el reempaquetado lee los blobs y luego guarda los paquetes nuevos en serie. Si está reempaquetando a través de la red, ese será el cuello de botella.

@DurvalMenezes ¿su NAS está en la red local o en Internet? Si en la red local te conectas a ella por wifi o ethernet?

Parece que una victoria fácil sería paralelizar la lectura de blobs/guardar paquetes en la red.

Por separado, me pregunto si una mejor estrategia sería tratar de hacer que la poda sea incremental. Algo así como la colección de fósiles de dos pasos de duplicación: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

Por separado, me pregunto si una mejor estrategia sería tratar de hacer que la poda sea incremental. Algo así como la colección de fósiles de dos pasos de duplicación: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

Consulte el n.º 1141 para ver una discusión sobre este tema.

Los dos nuevos comandos 'cleanup-index' y 'cleanup-packs' del PR #2513 también deberían mejorar mucho la situación. Con estos comandos, puede hacer una poda sin volver a empaquetar si su repositorio está cuerdo.

Así que accidentalmente hice dos cosas, ejecuté una copia de seguridad cada hora 11 veces por hora en lugar de 1, y no ejecuté mi trabajo de olvido durante los últimos 384 días más o menos. Tengo 101417 instantáneas. Pensé que sería demasiado lento olvidar/eliminar esto, creo que simplemente lo eliminaré.

Puede probar el #2718; sin embargo, no hay ninguna mejora para "olvidar" las instantáneas.
Si el paso de olvidar es su problema, le aconsejo que:

• averigüe qué instantáneas desea conservar, por ejemplo, mirando sus últimos registros de copia de seguridad o simplemente haga otra copia de seguridad.
• elimine todos menos esos archivos manualmente del directorio /snapshots de su repositorio
• después de eso, ejecuta prune (si quieres con #2718)

Solo tenía la intención de mantenerlos durante unos días, así que simplemente eliminaré todo el directorio en S3 y comenzaré de nuevo. Comencé el proceso de olvido y estaba tomando mucho tiempo, pensé que la rama más nueva ayudaría (no lo parece), o al menos alguien podría encontrarlo divertido.

Tengo muchas ganas de probar esta rama (o realmente, desearía que se incluyera en el maestro). Traté de probar y obtener

Fatal: no se puede abrir el archivo de configuración: Estadística: el ID de la clave de acceso de AWS que proporcionó no existe en nuestros registros.

Funciona sin problemas con la versión maestra. También pude usar la sucursal en https://github.com/restic/restic/pull/2340 sin problemas.

Puedo usar esta rama en un repositorio montado en NFS, solo el repositorio almacenado de AWS no funciona. No tengo idea de cómo solucionar problemas...

gracias por todo el buen trabajo independientemente

@ vtwaldo21 ¿Qué sucursal probaste? ¿Era el #2718?
Su mensaje de error indica que tiene algún problema con sus credenciales de AWS. Esto también puede explicar por qué NFS funcionó sin problemas.

¿Funcionan otros comandos restic con su repositorio de AWS?

@aawsome , soy un idiota y transpuse los números de sucursal/problema y realmente confundí las cosas. lo siento.

Branch 2718 funcionó bien (tanto en repositorios respaldados por AWS como por NFS). No puedo decir definitivamente que fue más rápido o no, ya que todavía se está ejecutando
Branch 2340, fue la que tuvo el problema y por qué estaba en este hilo del foro.

Branch 2340 está basado en 0.9.5, por lo que es un poco más antiguo pero no demasiado malo. Estaba haciendo pruebas simples como esta:

La ruta binaria restic se acaba de instalar a través de RPM (0.9.6)

instantáneas estáticas
[obras]
restic.2718/restic instantáneas
[obras]
restic.2340/restic instantáneas
Fatal: no se puede abrir el archivo de configuración: Estadística: el ID de la clave de acceso de AWS que proporcionó no existe en nuestros registros.

Entonces, si bien el error implica algo con las credenciales de AWS, literalmente estoy ejecutando los comandos de forma consecutiva sin cambios en las variables. Parece que hay algo más mal con esta rama.

Mis ciruelas pasas toman días para un repositorio de ~ 2 TB, por lo que estoy muy interesado en que tanto 2718 como 2340 se fusionen en maestro

@cbane muchas gracias por todo tu trabajo! Acabamos de fusionar el #2718, que reelabora el código de poda, y creo que resuelve este problema al igual que el #2340.

Lamento mucho cómo manejamos su contribución, espero que pueda aceptar mis disculpas. :decepcionado:

Hablé con @MichaelEischer , mencionó que el PR #2340 incluye más ideas que aún no se han implementado, por lo que estoy reabriendo este problema.

@cbane , ¿está interesado en trabajar con nosotros para fusionar estas ideas en el código actual? Puedo entender totalmente si no, entonces revisaremos su PR y los extraeremos nosotros mismos :)

También tuvimos una breve discusión ayer y tratamos de identificar qué pudo haber salido mal, para que podamos hacerlo mejor la próxima vez. Algunos puntos que identificamos fueron:

• El PR cambió un área altamente sensible en el código (prune, que en última instancia elimina los datos), por lo que necesita un escrutinio adicional.
• @MichaelEischer y @aawsome intentaron revisar las relaciones públicas y dijeron que era demasiado grande
• El PR fue solo dos confirmaciones, una de ellas reemplazó todo el código con otro código completamente diferente, esto es muy difícil de revisar
• El PR incluyó al menos 4-5 ideas y mejoras diferentes, lo que hace que sea aún más difícil de revisar

¿Alguna otra cosa que me perdí?

Los cambios a cmd_prune.go de #2340 son, hasta donde puedo ver, completamente reemplazados por #2718 y #2842 por @aawsome . #3006 también reemplaza los cambios de index/index.go.

Extraje la implementación de caminata de árbol altamente paralelizado de checker.go (ver https://github.com/MichaelEischer/restic/tree/streamtrees), que permite implementar un FindUsedBlobs paralelo con unos pocos líneas adicionales de código. También es reutilizable para el comando de copia. Mi rama mencionada también unifica el código utilizado para paralelizar el índice y la carga de instantáneas. Dividiré la rama en PR más pequeños.

Eso parece dejar el uso del recuento de conexiones back-end y GOMAXPROCS para ajustarse automáticamente al paralelismo IO/CPU como parte restante de #2340.

He notado que ni #2340 ni el otro prune PR actualmente paralelizan la carga del índice reescrito.