¿Cuál es el rendimiento esperado de obnam? O: ¿por qué es tan lento?

He estado jugando con obnam estos últimos días, y aunque parece muy prometedor y parece ofrecer básicamente todo lo que siempre quise en una herramienta de respaldo, estoy bastante decepcionado por su rendimiento. De hecho, es tan lento, sospecho que aquí ni siquiera es culpa de obnam, pero algo en mi entorno lo está causando.

Así que me pregunto principalmente si alguien más está usando obnam o conoce sus componentes internos lo suficientemente bien como para identificar el problema.

Por lo que pude ver hasta ahora, obnam parece bifurcar un proceso de gpg individual para cada archivo que se respalda. A juzgar por htop, strace e iostat, la velocidad de una copia de seguridad inicial está limitada principalmente por la bifurcación constante, mientras que la CPU y las unidades (sin redes) están inactivas por debajo del 20% de utilización.

Mi copia de seguridad asciende a aproximadamente 500,000 archivos con 170 GiB de datos en total. Entonces, para cada ejecución de respaldo, gpg se bifurca 500,000 veces. En realidad, ni siquiera me sorprende que esto lleve casi un día entero para la ejecución inicial y más de tres horas para otra ejecución con la mayoría de los archivos sin cambios. ¿Pero es este realmente el rendimiento que los usuarios de obnam deben esperar? A modo de comparación: una ejecución incremental de rsnapshot (mismos datos, misma máquina, mismas unidades) tarda unos cuatro minutos. De acuerdo, no hay encriptación involucrada, pero esto no debería ser tan significativo.

Entonces, para preguntar claramente: ¿la máquina de todos los demás no puede ejecutar gpg (encriptar una pequeña porción de datos) más de 50 veces por segundo, lo que hace que obnam sea una herramienta inusualmente lenta? O solo soy yo?

(FWIW, mi máquina es un Core i5-2500 con 8G de RAM y unidades SSD, que ejecuta Gentoo. La copia de seguridad se realiza en un HDD, pero no pude observar ninguna diferencia al hacer una copia de seguridad en la SSD, ya que no es E / S -Unido.)

Aquí hay una buena lectura sobre cómo acelerar obnam (puede ejecutarse hasta 10 veces más rápido): http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

Resumen: agregue "--lru-size = 1024 --upload-queue-size = 512" a su línea de comandos o archivo de configuración. Tenga en cuenta que aumenta un poco el uso de memoria de obnam.

Creo que atacaría este problema de varias maneras. Para empezar, trataría de diagnosticarlo yo mismo usando las siguientes metodologías.

1. registros de obnam

Para empezar, puede registrar mensajes de esta obnammanera:

$ obnam --log obnam.log

También puede aumentar el nivel de registro a través del --log-levelinterruptor para obtener más detalles.

--log=FILE          write log entries to FILE (default is to not write log
                    files at all); use "syslog" to log to system log, or
                    "none" to disable logging
--log-level=LEVEL   log at LEVEL, one of debug, info, warning, error,
                    critical, fatal (default: info)

2. Perfilado

También puede obtener un perfil de lo que obnamestá haciendo de este extracto en las preguntas frecuentes del proyecto :

Si la OBNAM_PROFILEvariable de entorno contiene un nombre de archivo, los datos de creación de perfiles se almacenan allí y se pueden ver más tarde con obnam-viewprof:

  $ OBNAM_PROFILE=obnam.prof obnam ... obnam-viewprof obnam.prof | less

Los problemas de rendimiento que no están relacionados con una configuración en particular también se pueden observar utilizando obnam-benchmark tool.

3. Abra un boleto

Si el rendimiento aún no se determina haciendo una investigación autónoma, abriría un ticket en el sitio web del proyecto . Por lo que pude reunir, los desarrolladores son algo receptivos y probablemente serían los mejores para solucionar los problemas con su proyecto.

obnamparece que solo usa SFTP, por lo que debería ser bastante obvio qué está causando el problema. También consideraría basar el rendimiento de SFTP por sí mismo para que pueda ver cuál debería ser el máximo teórico con su sistema + conexión de red antes de intentar obtener esta información de las obnampruebas.

Puntos de datos adicionales

Encontré esta publicación de blog donde el autor hizo una comparación de varias opciones en esta categoría. El artículo se titula: Comparación de rsnapshot y obnam para copias de seguridad grandes programadas .

El artículo destacó un rendimiento muy pobre, IMO, con lo obnamque parece coincidir con lo que estás describiendo.

obnam performance

Después de realizar una copia de seguridad / inicio por completo (¡que tomó varios días!), Una nueva ejecución, varios días más tarde (tiempo por el comando de tiempo de Linux):

Respaldo 3443706 archivos, subió 94.0 GiB en 127h48m49s a 214.2 KiB / s velocidad promedio 830 archivos; 1.24 GiB (0 B / s) real 7668m56.628s usuario 4767m16.132s sys 162m48.739s

Desde el archivo de registro obname:

   2012-11-17 12:41:34 INFO VFS: baseurl=/home read=0 written=0
   2012-11-21 23:09:36 INFO VFS: baseurl=/backups/backup_home read=2727031576964 written=150015706142 
   2012-11-21 23:09:36 INFO Backup performance statistics: 
   2012-11-21 23:09:36 INFO * files found: 3443706 
   2012-11-21 23:09:36 INFO * uploaded data: 100915247663 bytes (93.9846482715 GiB) 2012-11-21 23:09:36 INFO * duration: 460128.627629s 
   2012-11-21 23:09:36 INFO * average speed: 214.179341663 KiB/s
   2012-11-21 23:09:36 INFO Backup finished. 2012-11-21 23:09:36 INFO Obnam ends
   2012-11-21 23:09:36 INFO obnam version 1.2 ends normally

Entonces: ~ 5 días para respaldar ~ 100 GB de datos modificados ... La carga no fue alta en las máquinas, ni en términos de CPU, ni en términos de RAM. El uso del disco en / backups / backup_home fue de 5.7T, el uso del disco de / home fue de 6.6T, por lo que parece que hay algo de deduplicación.

rendimiento de rsnapshot

Una copia de seguridad completa de / home para (según el archivo de registro):

   [27/Nov/2012:12:55:31] /usr/bin/rsnapshot daily: started   
   [27/Nov/2012:12:55:31] echo 17632 > /var/run/rsnapshot.pid 
   [27/Nov/2012:12:55:31] mkdir -m 0700 -p /backups/backup_home_rsnapshot/    
   [27/Nov/2012:12:55:31] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/ 
   [27/Nov/2012:12:55:31] /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /home /backups/backup_home_rsnapshot/daily.0/localhost/
   [28/Nov/2012:23:16:16] touch /backups/backup_home_rsnapshot/daily.0/
   [28/Nov/2012:23:16:16] rm -f /var/run/rsnapshot.pid
   [28/Nov/2012:23:16:16] /usr/bin/rsnapshot daily: completed successfully

Entonces: ~ 1.5 días para una copia de seguridad completa de 6.3TB. Un respaldo incremental un día después tomó:

     [29/Nov/2012:13:10:21] /usr/bin/rsnapshot daily: started
     [29/Nov/2012:13:10:21] echo 20359 > /var/run/rsnapshot.pid
     [29/Nov/2012:13:10:21] mv /backups/backup_home_rsnapshot/daily.0/ /backups/backup_home_rsnapshot/daily.1/
     [29/Nov/2012:13:10:21] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:10:21] /usr/bin/rsync -a --delete --numeric-ids -- relative --delete-excluded --link-dest=/backups/backup_home_rsnapshot/daily.1/localhost/ /home/backups/backup_home_rsnapshot/daily.0/localhost/
     [29/Nov/2012:13:25:09] touch /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:25:09] rm -f /var/run/rsnapshot.pid
     [29/Nov/2012:13:25:09] /usr/bin/rsnapshot daily: completed successfully

Entonces: 15 minutos ... y los datos modificados ascendieron a 21 GB.

No es tan completo, pero menciona que una de las desventajas de obnames que es muy lento frente attic.

Profesionales de Obnam:

• bien documentada
• lista de correo activa
• paquetes disponibles

Obnam contras:

• muy lento
• grandes copias de seguridad

Ventajas del ático:

• copias de seguridad mucho más pequeñas (incluso sin deduplicación)
• deduplicación mucho mejor
• mucho mas rápido

Contras del ático:

• formato de repositorio no documentado
• no una gran comunidad de usuarios

Se muestran algunos datos de prueba que parecen indicar que obnames realmente lento.

Desde SSD local a HD remoto, a través de una conexión wifi regular:

    rsync:           0:24  0:01
    Attic ssh:       0:28  0:05
    Attic sshfs:     0:51  0:08
    Obnam sftp:      8:45  0:21
    Obnam sshfs:    25:22  0:22

Referencias

• Obnam ajusta la publicación del blog

La configuración predeterminada de Obnam (a partir del 2015-02-08) no funciona bien para realizar copias de seguridad de directorios con una gran cantidad de archivos pequeños. Tuve exactamente el mismo problema que se mencionó anteriormente.

La solución para mí fue agregar --lru-size = 8192 --upload-queue-size = 8192 a la línea de comando. Esto resolvió el problema y convirtió a un frustrado en un usuario muy feliz de Obnam. (Ahora tengo esta configuración en mis archivos de configuración estándar).

Desafortunadamente, el tutorial de Obnam no menciona por adelantado cuán importantes son estas configuraciones. Las preguntas frecuentes dan más detalles. Establecer los parámetros de rendimiento es realmente obligatorio en sistemas con muchos archivos pequeños.