Restic: Lento, aunque solo está comprobando las marcas de tiempo

Creado en 17 feb. 2016  ·  5Comentarios  ·  Fuente: restic/restic

Tengo 164809 archivos para respaldar regularmente (alrededor de 60 GB) ... Cada vez que ejecuto "restic backup", el informe no supera los 33 MB / sy verificando con strace solo está haciendo llamadas lstat ().

Esto genera unos 20 minutos por copia de seguridad. Me pregunto qué está haciendo restic, porque al estar casi todos los archivos sin modificar, muestra los 33 MB/s constantes y entiendo que solo necesita lstat(), que es exactamente lo que restic ya hace en el primer paso de la copia de seguridad solo para mostrar el tamaño total, en 6 o 7 segundos.

¿Es solo el tiempo de CPU dedicado a verificar el contenido de ese mismo archivo/marca de tiempo que ya está presente en una instantánea anterior restic?

feature enhancement

Comentario más útil

Sí, lo más probable es que esa sea la razón. Para este caso de uso particular, hay una solución alternativa: use la opción -f ( --force ) para el comando backup , que volverá a leer todos los archivos localmente y no cargará los metadatos del repositorio. . Eso debería ser rápido.

Todos 5 comentarios

Por el momento, los metadatos de los archivos y directorios no se almacenan en caché, sino que se cargan (y descifran) desde el repositorio. Esto se hace una vez por directorio. Estoy planeando almacenar en caché los metadatos localmente, que aún no está implementado, pero debería acelerar mucho las copias de seguridad "incrementales".

Hola

¿Podría esto también causar un rendimiento deficiente para las copias de seguridad incrementales a través de una conexión WAN lenta?

Acabo de hacer una copia de seguridad de una carpeta con algo más de 9000 archivos y 250 MB en un servidor s3 remoto. Ambos equipos están conectados con una conexión a internet asimétrica de 50/5 mbit/s de bajada y subida.

La copia de seguridad inicial tomó alrededor de 5 minutos y parecía bastante razonable. ¡Pero una segunda copia de seguridad poco después tomó casi el doble de tiempo! Una carpeta con menos archivos parece ser mucho más rápida.

Sí, lo más probable es que esa sea la razón. Para este caso de uso particular, hay una solución alternativa: use la opción -f ( --force ) para el comando backup , que volverá a leer todos los archivos localmente y no cargará los metadatos del repositorio. . Eso debería ser rápido.

¡Muchas gracias! ¡Funciona de maravilla!

Agregamos un caché de metadatos local (ver #1040) en la rama maestra, creo que este problema está resuelto y, por lo tanto, lo cerraré. ¡Gracias!

¿Fue útil esta página
0 / 5 - 0 calificaciones