Esta nota analiza las herramientas de respaldo que realizan respaldos mediante la creación de archivos en un servidor de respaldo.
Entre los que cumplen los requisitos se encuentran duplicity (que tiene una bonita interfaz en forma de deja dup) y duplicati.
Otra herramienta de respaldo muy destacable es dar, pero como tiene una lista muy extensa de opciones (la metodología de prueba cubre apenas el 10% de lo que es capaz de hacer), no la estamos probando como parte del ciclo actual.
Resultados esperados
Dado que ambos candidatos crean archivos de una forma u otra, se puede utilizar el tar normal como guía.
Además, evaluaremos qué tan bien se optimiza el almacenamiento de datos en el servidor de almacenamiento mediante la creación de copias de seguridad que contengan solo la diferencia entre una copia completa y el estado actual de los archivos, o entre los archivos anteriores y actuales (incrementales, decrementales, etc.) .
Comportamiento al crear copias de seguridad:
- Una cantidad relativamente pequeña de archivos en el servidor de almacenamiento de respaldo (comparable a la cantidad de copias de respaldo o al tamaño de los datos en GB), pero su tamaño es bastante grande (de decenas a cientos de megabytes).
- El tamaño del repositorio solo incluirá cambios; no se almacenarán duplicados, por lo que el tamaño del repositorio será menor que con el software basado en rsync.
- Espere una gran carga de CPU al utilizar compresión y/o cifrado, y probablemente una carga de red y disco bastante alta si el proceso de archivado y/o cifrado se ejecuta en un servidor de almacenamiento de respaldo.
Ejecutemos el siguiente comando como valor de referencia:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Los resultados de la ejecución fueron los siguientes:
Tiempo de ejecución 3m12s. Se puede ver que la velocidad está limitada por el subsistema de disco del servidor de almacenamiento de respaldo, como en el ejemplo con . Sólo un poco más rápido, porque... la grabación va a un archivo.
Además, para evaluar la compresión, ejecutemos la misma opción, pero habilitemos la compresión en el lado del servidor de respaldo:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Los resultados son los siguientes:
Tiempo de ejecución 10m11s. Lo más probable es que el cuello de botella sea el compresor de flujo único en el extremo receptor.
El mismo comando, pero con compresión transferida al servidor con los datos originales para probar la hipótesis de que el cuello de botella es un compresor de un solo subproceso.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Resultó así:
El tiempo de ejecución fue de 9m37s. La carga en un núcleo por parte del compresor es claramente visible, porque La velocidad de transferencia de la red y la carga en el subsistema del disco de origen son similares.
Para evaluar el cifrado, puede usar openssl o gpg conectando un comando adicional openssl o gpg en tubería. Como referencia habrá un comando como este:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Los resultados salieron así:
El tiempo de ejecución resultó ser de 10m30s, ya que se estaban ejecutando 2 procesos en el lado receptor: el cuello de botella es nuevamente un compresor de un solo subproceso, además de una pequeña sobrecarga de cifrado.
UPD: A pedido de bliznezz estoy agregando pruebas con pigz. Si usas solo el compresor, tardarías 6m30s, si además le añades cifrado, serían unos 7m. La caída en el gráfico inferior es un caché de disco no vaciado:
Pruebas duplicadas
Duplicity es un software de Python para realizar copias de seguridad mediante la creación de archivos cifrados en formato tar.
Para archivos incrementales, se utiliza librsync, por lo que puede esperar el comportamiento descrito en .
Las copias de seguridad se pueden cifrar y firmar usando gnupg, lo cual es importante cuando se utilizan diferentes proveedores para almacenar copias de seguridad (s3, backblaze, gdrive, etc.)
Veamos cuáles son los resultados:
Estos son los resultados que obtuvimos al ejecutar sin cifrado
revelación
Tiempo de ejecución de cada prueba:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Y aquí están los resultados cuando el cifrado gnupg está habilitado, con un tamaño de clave de 2048 bits:
Tiempo de funcionamiento sobre los mismos datos, con cifrado:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Se indicó el tamaño del bloque: 512 megabytes, lo que se ve claramente en los gráficos; En realidad, la carga del procesador se mantuvo en el 50%, lo que significa que el programa no utiliza más de un núcleo de procesador.
El principio de funcionamiento del programa también es bastante visible: tomaron un dato, lo comprimieron y lo enviaron a un servidor de almacenamiento de respaldo, 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.
Habilitar el cifrado no aumentó significativamente el tiempo de ejecución del programa, pero aumentó la carga del procesador en aproximadamente un 10%, lo que puede ser una buena ventaja.
Desafortunadamente, este programa no pudo detectar correctamente la situación con el cambio de nombre del directorio y el tamaño del repositorio resultante resultó ser igual al tamaño de los cambios (es decir, todos los 18 GB), pero la capacidad de usar un servidor que no es de confianza para la copia de seguridad claramente cubre este comportamiento.
Pruebas duplicadas
Este software está escrito en C# y se ejecuta utilizando un conjunto de bibliotecas de Mono. Hay una GUI y una versión CLI.
La lista aproximada de las características principales es similar a la duplicidad, incluidos varios proveedores de almacenamiento de respaldo; sin embargo, a diferencia de la duplicidad, la mayoría de las funciones están disponibles sin herramientas de terceros. Si esto es una ventaja o una desventaja depende del caso específico, pero para los principiantes, lo más probable es que sea más fácil tener una lista de todas las funciones frente a ellos a la vez, en lugar de tener que instalar paquetes adicionales para Python, como es el caso. el caso de la duplicidad.
Otro pequeño matiz: el programa escribe activamente una base de datos sqlite local en nombre del usuario que inicia la copia de seguridad, por lo que debe asegurarse adicionalmente de que la base de datos requerida esté especificada correctamente cada vez que se inicia el proceso usando el cli. Cuando se trabaja a través de GUI o WEBGUI, los detalles estarán ocultos para el usuario.
Veamos qué indicadores puede producir esta solución:
Si desactiva el cifrado (y WEBGUI no recomienda hacerlo), los resultados son los siguientes:
Horario:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Con el cifrado habilitado, usando aes, se ve así:
Horario:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Y si usas el programa externo gnupg, salen los siguientes resultados:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Como puede ver, el programa puede funcionar en varios subprocesos, pero esto no lo convierte en una solución más productiva, y si compara el trabajo de cifrado, está ejecutando un programa externo.
resultó ser más rápido que usar la biblioteca del conjunto Mono. Esto puede deberse a que el programa externo está más optimizado.
Otra cosa buena fue el hecho de que el tamaño del repositorio ocupa exactamente tanto como los datos modificados reales, es decir. duplicati detectó un cambio de nombre de directorio y manejó esta situación correctamente. Esto se puede ver al ejecutar la segunda prueba.
En general, impresiones bastante positivas del programa, incluido el hecho de que es bastante amigable con los novatos.
resultados
Ambos candidatos trabajaron con bastante lentitud, pero en general, en comparación con el alquitrán normal, hay avances, al menos con duplicati. El precio de tal progreso también es claro: una carga notable
procesador. En general, no existen desviaciones especiales en la predicción de los resultados.
Hallazgos
Si no necesita apresurarse a ninguna parte y también tiene un procesador de repuesto, cualquiera de las soluciones consideradas servirá; en cualquier caso, se ha realizado bastante trabajo que no debe repetirse escribiendo scripts contenedores encima de tar. . La presencia de cifrado es una propiedad muy necesaria si no se puede confiar plenamente en el servidor para almacenar copias de seguridad.
En comparación con soluciones basadas - el rendimiento puede ser varias veces peor, a pesar de que en su forma pura tar funcionó entre un 20 y un 30% más rápido que rsync.
Hay ahorros en el tamaño del repositorio, pero sólo con duplicados.
anuncio
Copia de seguridad Parte 3: Revisión y prueba de duplicidad, duplicati, deja dup
Backup Parte 4: Revisión y prueba de zbackup, restic, borgbackup
Copia de seguridad Parte 5: Probando bacula y veeam backup para linux
Copia de seguridad Parte 6: Comparación de herramientas de copia de seguridad
Copia de seguridad Parte 7: Conclusiones
Publicado por: Pavel Demkovich
Fuente: habr.com