En esta nota se examinan las herramientas de copia de seguridad que realizan copias creando archivos en un servidor de respaldo.
Entre los que cumplen con los requisitos se encuentran duplicity (que tiene una interfaz amigable en forma de deja dup) y duplicati.
Otra herramienta de copia de seguridad bastante notable es dar, pero dado que cuenta con una lista extensa de opciones, la metodología de prueba cubre apenas el 10% de lo que es capaz, por lo tanto no la probaremos en este ciclo.
Resultados esperados
Dado que ambos candidatos crean archivos, se puede usar el tar común como referencia.
También evaluaremos qué tan bien se optimiza el almacenamiento de datos en el servidor de almacenamiento mediante copias de seguridad que contienen solo la diferencia entre la copia completa y el estado actual de los archivos, o entre archivos de respaldo pasados y actuales (incrementales, diferenciales, etc.).
Comportamiento al crear copias de seguridad:
- Un número relativamente pequeño de archivos en el servidor de almacenamiento de copias de seguridad (en comparación con el número de copias de seguridad o el tamaño de los datos en GB), pero su tamaño es suficientemente grande (decenas a cientos de megabytes).
- El tamaño del repositorio incluirá solo los cambios; no se almacenarán duplicados, por lo tanto el tamaño del repositorio será menor que cuando se utiliza software basado en rsync.
- Se espera una alta carga en el procesador al utilizar compresión y/o cifrado, así como, probablemente, una carga considerable en la red y en el subsistema de discos si el proceso de archivado y/o cifrado se ejecuta en el servidor de almacenamiento de copias de seguridad.
Como un valor de referencia ejecutaremos el siguiente comando:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Los resultados de la ejecución son los siguientes:
El tiempo de ejecución fue de 3m12s. Se observa que la velocidad se topó con el subsistema de discos del servidor de almacenamiento de copias de seguridad, al igual que en el ejemplo de . Solo un poco más rápido, ya que la escritura se realiza en un solo archivo.
Asimismo, para evaluar la compresión ejecutaremos la misma variante, pero habilitaremos la compresión en el lado del servidor de copias de seguridad:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Los resultados son los siguientes:
El tiempo de ejecución fue de 10m11s. Lo más probable es que el cuello de botella sea el compresor de un solo hilo en el lado receptor.
El mismo comando, pero trasladando la compresión al servidor con los datos originales para comprobar la hipótesis de que el cuello de botella es el compresor de un solo hilo.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Así quedó:
El tiempo de ejecución fue de 9m37s. Se observa claramente la carga de un núcleo por el compresor, ya que la velocidad de transferencia por la red y la carga en la subsistema de disco de origen son similares.
Para evaluar la encriptación se puede usar openssl o gpg, conectando un comando adicional openssl o gpg en pipe. Para referencia, el comando sería:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Los resultados fueron los siguientes:
El tiempo de ejecución fue de 10m30s, ya que se ejecutaron 2 procesos en el lado receptor — el cuello de botella fue nuevamente el compresor de un solo hilo, además de algunos gastos generales por la encriptación.
UPD: A pedido de bliznezz, añado pruebas con pigz. Si usamos solo el compresor, se obtuvo 6m30s, y si también añadimos encriptación, aproximadamente 7m. La caída en el gráfico inferior es el caché de disco no desechado:
Pruebas con duplicity
Duplicity es un software en python para hacer copias de seguridad creando archivos tar encriptados.
Para archivos incrementales se utiliza librsync, por lo tanto, se puede esperar el comportamiento descrito en .
Las copias de seguridad pueden ser encriptadas y firmadas con gnupg, lo cual es importante al utilizar diferentes proveedores para el almacenamiento de copias de seguridad (s3, backblaze, gdrive, etc.)
Veamos cuáles serán los resultados:
Estos son los resultados obtenidos al ejecutar sin encriptación
spoiler
El tiempo de cada ejecución de prueba:
Ejecución 1
Ejecución 2
Ejecución 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Y aquí están los resultados con la encriptación de gnupg, con un tamaño de clave de 2048 bits:
El tiempo de ejecución con los mismos datos, con encriptación:
Ejecución 1
Ejecución 2
Ejecución 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Se especificó un tamaño de bloque de 512 megabytes, lo que se observa claramente en los gráficos; la carga de la CPU se mantuvo en un nivel de 50%, lo que indica que el programa no utiliza más de un núcleo de procesador.
También se puede observar claramente el principio de funcionamiento del programa: tomamos un trozo de datos, lo comprimimos, lo enviamos al servidor de almacenamiento de copias de seguridad, que puede ser bastante lento.
Otra característica es el tiempo de ejecución predecible del programa, que depende únicamente del tamaño de los datos modificados.
La activación del cifrado no aumentó significativamente el tiempo de ejecución del programa, pero incrementó la carga de la CPU en aproximadamente un 10%, lo que puede ser un buen bono.
Lamentablemente, este programa no pudo detectar correctamente la situación de cambio de nombre de directorio, y el tamaño resultante del repositorio fue igual al tamaño de los cambios (es decir, todos 18 GB), pero la posibilidad de usar un servidor no confiable para copias de seguridad sin duda supera tal comportamiento.
Prueba de duplicati
Este software está escrito en C#, se ejecuta utilizando un conjunto de bibliotecas de Mono. Dispone de una versión GUI, así como una versión de línea de comandos.
La lista aproximada de las principales características es similar a la de duplicity, incluyendo varios proveedores para el almacenamiento de copias de seguridad, sin embargo, a diferencia de duplicity, la mayoría de las funciones están disponibles sin herramientas externas. Si esto es una ventaja o desventaja depende del caso específico, sin embargo, para principiantes, probablemente sea más fácil tener a la vista una lista de todas las características desde el principio, en lugar de tener que instalar paquetes para python, como en el caso de duplicity.
Otro pequeño matiz es que el programa escribe activamente en la base de datos sqlite local en nombre del usuario que inicia la copia de seguridad, por lo que es necesario prestar atención a especificar la base de datos correcta en cada inicio del proceso utilizando la línea de comandos. Al trabajar a través de la GUI o WEBGUI, los detalles estarán ocultos al usuario.
Veamos qué métricas puede proporcionar esta solución:
Si se desactiva el cifrado (aunque la WEBGUI no lo recomienda), los resultados son los siguientes:
Tiempo de ejecución:
Ejecución 1
Ejecución 2
Ejecución 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Con cifrado activado, utilizando aes, estos son los resultados:
Tiempo de ejecución:
Ejecución 1
Ejecución 2
Ejecución 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Y si se utiliza el programa externo gnupg, estos son los resultados:
Ejecución 1
Ejecución 2
Ejecución 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Como se puede ver, el programa puede trabajar en varios hilos, pero eso no lo convierte en una solución más eficiente, y si se compara el trabajo de cifrado — iniciar el programa externo
resultó ser más rápido que el uso de la biblioteca del conjunto de Mono. Puede que esto se deba a que el programa externo está más optimizado.
Un punto agradable fue también el hecho de que el tamaño del repositorio ocupa exactamente tanto como los datos que realmente fueron modificados, es decir, duplicati detectó el cambio de nombre del directorio y manejó correctamente esta situación. Esto se puede ver al ejecutar la segunda prueba.
En general, las impresiones sobre el programa son bastante positivas, incluyendo su suficiente amigabilidad para los principiantes.
Resultados
Ambos candidatos trabajaron con bastante calma, pero en general, comparado con el tar habitual, hay un progreso, al menos con duplicati. El precio de tal progreso también es evidente: una carga notable
del procesador. En general, no hay desviaciones particulares al pronosticar resultados.
Conclusiones
Si no hay prisa y también hay capacidad en el procesador, cualquier de las soluciones consideradas servirá. En cualquier caso, se ha realizado un trabajo bastante grande que no vale la pena repetir escribiendo scripts envolventes sobre tar. La presencia de cifrado es una característica muy necesaria si el servidor para almacenar copias de seguridad no puede ser completamente confiable.
Si se compara con soluciones basadas en — el rendimiento puede ser varias veces peor, a pesar de que el tar puro funcionó un 20-30% más rápido que rsync.
Hay ahorro en el tamaño del repositorio, pero solo con duplicati.
Anuncio
Copia de seguridad, parte 3: Revisión y pruebas de duplicity, duplicati, deja dup
Copia de seguridad, parte 4: Revisión y prueba de zbackup, restic, borgbackup
Copia de seguridad, parte 5: Prueba de bacula y veeam backup for linux
Copia de seguridad, parte 6: Comparación de herramientas de copia de seguridad
Copia de seguridad, parte 7: Conclusiones
Autor de la publicación: Pavel Demkovich
Fuente: habr.com
