Este artículo describe las herramientas de respaldo que respaldan mediante la creación de archivos en un servidor de respaldo.
De los que satisfacen los requisitos están la duplicidad (que tiene una interfaz agradable en forma de deja dupla) y la duplicación.
Otra herramienta de copia de seguridad muy notable es dar, pero dado que tiene una lista muy extensa de opciones (la metodología de prueba cubre apenas el 10% de lo que es capaz), no la estamos probando en el ciclo actual.
Resultados esperados
Dado que ambos candidatos crean archivos de una forma u otra, puede usar alquitrán ordinario como guía.
Además, evaluamos qué tan bien se optimiza el almacenamiento de datos en el servidor de almacenamiento creando copias de seguridad que contienen solo la diferencia entre la copia completa y el estado actual de los archivos, o entre los archivos pasados y actuales (incremental, decremental, etc.).
Comportamiento de respaldo:
- Un número relativamente pequeño de archivos en el servidor de almacenamiento de respaldo (comparable al número de respaldos o al tamaño de los datos en GB), pero su tamaño es bastante grande (decenas a cientos de megabytes).
- El tamaño del repositorio incluirá solo cambios: los duplicados no se almacenarán, por lo que el tamaño del repositorio será menor que cuando se ejecuta un software basado en rsync.
- Se espera una gran carga en el procesador cuando se usa compresión y / o cifrado, y también, probablemente, una carga suficientemente grande en la red y el subsistema de disco si el proceso de archivo y / o cifrado funcionará en el servidor de almacenamiento de respaldo.
Como valor de referencia, ejecute el siguiente comando:
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 descansaba en el subsistema de disco del servidor de almacenamiento de respaldo, como en el ejemplo de rsync . Solo un poco más rápido, porque el registro va a un archivo.
Además, para evaluar la compresión, ejecutaremos la misma opción, pero habilitaremos la compresión en el lado del servidor de la copia de seguridad:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"
Los resultados son los siguientes:
El tiempo de entrega es de 10m11s. Lo más probable es que el cuello de botella sea un compresor de un solo hilo en el lado receptor.
El mismo comando, pero con la transferencia de compresión al servidor con los datos de origen para probar la hipótesis de que el cuello de botella es un compresor de un solo hilo.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"
Resultó así:
El tiempo de entrega fue de 9m37s. La carga de un núcleo por el compresor es claramente visible, ya que La velocidad de transmisión de red y la carga en el subsistema de disco de la fuente son similares.
Para evaluar el cifrado, puede usar openssl o gpg conectando el comando openssl o gpg opcional a la tubería. Como referencia, habrá un comando de este tipo:
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 de la siguiente manera:
El tiempo de ejecución resultó ser de 10m30s, ya que se iniciaron 2 procesos en el lado receptor: el cuello de botella fue nuevamente un compresor de un solo subproceso, más una pequeña sobrecarga de cifrado.
UPD: A petición de bliznezz, agrego pruebas con pigz. Si usa solo el compresor, resultó durante 6m30s, si también agrega cifrado, aproximadamente 7m. La falla en el gráfico inferior es un caché de disco sin asignar:
Prueba de duplicidad
Duplicity es un software de copia de seguridad de Python al crear archivos tar cifrados.
Para archivos incrementales, se usa librsync, por lo tanto, puede esperar el comportamiento descrito en la nota de bucle anterior .
Las copias de seguridad se pueden cifrar y firmar usando gnupg, lo cual es importante cuando se usan varios proveedores para almacenar copias de seguridad (s3, backblaze, gdrive, etc.)
Veamos cuáles serán los resultados:
Estos son los resultados obtenidos al comenzar sin cifradospoiler
El tiempo de ejecución de cada prueba:
Y aquí están los resultados cuando el cifrado gnupg está habilitado, con un tamaño de clave de 2048 bits:
Tiempo de funcionamiento en los mismos datos, con cifrado:
Se especificó el tamaño del bloque: 512 megabytes, que es claramente visible en los gráficos; la carga del procesador en realidad se mantuvo en el nivel del 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 claramente visible: tomaron un dato, lo sacudieron y lo enviaron al servidor de almacenamiento de respaldo, que puede ser bastante lento.
Otra característica es el tiempo de ejecución predecible del programa, que depende solo del tamaño de los datos modificados.
La habilitación del 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 muy 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 no confiable para la copia de seguridad definitivamente cubre este comportamiento.
Prueba de duplicados
Este software está escrito en C #, se inicia utilizando un conjunto de bibliotecas de Mono. Hay una GUI y una versión cli.
Una lista de muestra de las características principales está cerca de 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. Más o menos: depende del caso específico, sin embargo, para los principiantes, lo más probable es que sea más fácil tener una lista de todas las características a la vez antes de instalar los paquetes para Python, como es el caso de la duplicidad.
Otro pequeño matiz es que el programa escribe activamente la base de datos sqlite local en nombre del usuario que inicia la copia de seguridad, por lo que debe monitorear adicionalmente la indicación correcta de la base de datos deseada cada vez que el proceso comienza a usar cli. Al trabajar a través de la GUI o WEBGUI, los detalles estarán ocultos para el usuario.
Veamos qué indicadores puede dar esta solución:Si desactiva el cifrado (y WEBGUI no lo recomienda), los resultados son los siguientes:
Tiempo de trabajo:
Con el cifrado habilitado, usando aes, resulta así:
Tiempo de trabajo:
Y si usa el programa externo gnupg, obtendrá los siguientes resultados:
Como puede ver, el programa puede funcionar en varios subprocesos, pero esta no es una solución más productiva, y si compara el cifrado, inicia un programa externo
resultó ser más rápido que usar la biblioteca de la suite Mono. Quizás esto se deba al hecho de que el programa externo está más optimizado.
Un momento agradable también fue el hecho de que el tamaño del repositorio toma exactamente la misma cantidad que se modificaron los datos reales, es decir, duplicati detectó un cambio de nombre de directorio y manejó correctamente esta situación. Esto se puede ver al ejecutar la segunda prueba.
En general, una impresión bastante positiva del programa, que incluye la amabilidad suficiente para los principiantes.
Resultados
Ambos candidatos trabajaron bastante lento, pero en general, en comparación con el alquitrán habitual, hay progreso, al menos duplicados. El precio de tal progreso también es comprensible, una carga notable
El procesador. En general, no hay desviaciones particulares en la predicción de los resultados.
Conclusiones
Si no necesita apurarse en ningún lado, y también hay un margen en el procesador, cualquiera de las soluciones consideradas servirá, en cualquier caso, se ha realizado un gran trabajo, que no debe repetirse escribiendo scripts de envoltura sobre el alquitrán. La presencia de cifrado es una propiedad muy necesaria si no se puede confiar completamente en el servidor para almacenar copias de seguridad.
En comparación con las soluciones basadas en rsync , el rendimiento puede ser varias veces peor, a pesar de que, en su forma pura, el alquitrán funcionó un 20-30% más rápido que rsync.
Ahorrar en el tamaño del repositorio es, pero solo para duplicados.
Anuncio
Copia de seguridad, parte 1: ¿Por qué necesita una copia de seguridad, una descripción general de los métodos y las tecnologías?
Copia de seguridad, Parte 2: Descripción general y prueba de herramientas de copia de seguridad basadas en rsync
Copia de seguridad, Parte 3: Descripción general y prueba de duplicidad, duplicati, deja dup
Copia de seguridad, Parte 4: Descripción general y prueba de zbackup, restic, borgbackup
Backup, Parte 5: Prueba de Bacula y Veeam Backup para Linux
Copia de seguridad: parte solicitada por los lectores: revisión de AMANDA, UrBackup, BackupPC
Copia de seguridad, Parte 6: Comparación de herramientas de copia de seguridad
Copia de seguridad Parte 7: Conclusiones
Publicado por Finnix