Copia de seguridad, Parte 6: Comparación de herramientas de copia de seguridad

Este artículo comparará las herramientas de respaldo, pero primero debe averiguar cómo manejan rápida y adecuadamente la recuperación de datos de los respaldos.
Para facilitar la comparación, se considerará la recuperación de una copia de seguridad completa, especialmente porque todos los candidatos admiten este modo de operación. Para simplificar, los números ya están promediados (promedio aritmético de varios inicios). Los resultados se resumirán en una tabla, que también contendrá información sobre las características: la presencia de una interfaz web, la facilidad de configuración y operación, la capacidad de automatizar, la presencia de varias características adicionales (por ejemplo, verificar la integridad de los datos), etc. Los gráficos mostrarán la carga del servidor, donde se utilizarán los datos (no el servidor para almacenar copias de seguridad).

Recuperación de datos

Rsync y tar se utilizarán como punto de referencia, ya que es en estos en los que generalmente se basan los scripts de copia de seguridad más simples.

Rsync completó el conjunto de datos de prueba en 4 minutos y 28 segundos mostrando


El proceso de recuperación se encontró con una limitación del subsistema de disco del servidor de almacenamiento de respaldo (gráficos de diente de sierra). También puede ver claramente la carga de un núcleo sin ningún problema (bajo iowait y softirq; no hay problemas con el disco y la red, respectivamente). Dado que los otros dos programas, a saber, rdiff-backup y rsnapshot, se basan en rsync y también ofrecen rsync regular como herramienta de recuperación, tendrán aproximadamente el mismo perfil de carga y tiempo de recuperación de respaldo.

Tar repartió un poco más rápido para


La carga total del sistema fue mayor en un promedio del 20% debido al aumento de softirq - aumento de la sobrecarga durante la operación del subsistema de red.

Si el archivo se comprime adicionalmente, el tiempo de recuperación aumenta a 3 minutos y 19 segundos con

El proceso de desempaquetado ocupa ambos núcleos de procesador, ya que funcionan dos procesos. En general, el resultado esperado. Además, se obtuvo un resultado comparable (3 minutos y 20 segundos) al ejecutar gzip en el lado del servidor con copias de seguridad, el perfil de carga en el servidor principal era muy similar a la ejecución de alquitrán sin el compresor gzip (consulte el gráfico anterior).

En rdiff-backup, puede sincronizar la última copia de seguridad realizada utilizando rsync regular (los resultados serán similares), pero las copias de seguridad anteriores aún deben restaurarse utilizando el programa rdiff-backup, que logró restaurar en 17 minutos y 17 segundos, mostrando


Quizás esto fue concebido, en cualquier caso, los autores proponen una solución para limitar la velocidad. El proceso de restauración de una copia de seguridad requiere un poco menos de la mitad de un núcleo, con un rendimiento proporcionalmente comparable (es decir, 2-5 veces más lento) en un disco y una red con rsync.

Rsnapshot for recovery sugiere usar rsync regular, por lo que sus resultados serán similares. En general, así es como sucedió.

Burp hizo frente a la tarea de restaurar una copia de seguridad en 7 minutos y 2 segundos con

Funcionó lo suficientemente rápido, y al menos mucho más convenientemente que rsync puro: no necesita recordar ningún indicador, una interfaz cli simple e intuitiva, soporte incorporado para copias múltiples, es dos veces más lento. Si necesita restaurar datos de la última copia de seguridad realizada, puede usar rsync, con algunas advertencias.

BackupPC mostró aproximadamente la misma velocidad y carga al activar el modo de transferencia rsync mediante la implementación de una copia de seguridad para


Pero en el modo de transferencia de datos con tar BackupPC se enfrentó más lentamente: en 12 minutos y 15 segundos, la carga del procesador fue generalmente menor


La duplicidad sin cifrado mostró resultados ligeramente mejores, ya que se las arregló para restaurar una copia de seguridad en 10 minutos y 58 segundos. Si activa el cifrado mediante gpg, el tiempo de recuperación aumenta a 15 minutos y 3 segundos. Además, al crear un repositorio para almacenar copias, puede especificar el tamaño del archivo, que se utilizará al dividir el flujo de datos entrantes. En general, en los discos duros normales, también debido al modo de operación de un solo subproceso, no hay mucha diferencia. Puede aparecer con diferentes tamaños de bloque cuando se usa almacenamiento híbrido. La carga en el servidor principal durante la recuperación fue la siguiente:



Duplicati mostró una velocidad de recuperación comparable, afrontando 13 minutos y 45 segundos. Otros 5 minutos tomaron la verificación de la exactitud de los datos recuperados (un total de aproximadamente 19 minutos). La carga fue


Cuando el cifrado aes se activó internamente, el tiempo de recuperación fue de 21 minutos y 40 segundos, y la carga del procesador fue máxima (¡ambos núcleos!) Durante la recuperación; Al verificar los datos, solo un hilo estaba activo, ocupando un núcleo de procesador. La verificación de datos después de la recuperación tomó los mismos 5 minutos (casi 27 minutos en total).


Duplicati manejó la recuperación un poco más rápido cuando se usa un programa gpg externo para el cifrado, pero en general las diferencias con el modo anterior son mínimas. El tiempo de funcionamiento fue de 16 minutos y 30 segundos, con verificación de datos en 6 minutos. La carga fue


AMANDA , usando alquitrán, manejó en 2 minutos 49 segundos, que, en principio, está muy cerca del alquitrán regular. Carga del sistema en principio


Al restaurar una copia de seguridad usando zbackup , se obtuvieron los siguientes resultados:




En general, no está mal. Todo depende de la velocidad del procesador en el servidor de respaldo, que es claramente visible cuando el programa se ejecuta con diferentes compresores. Desde el lado del servidor de respaldo, se lanzó un tar regular, por lo que si lo compara, la recuperación funciona 3 veces más lento. Puede valer la pena verificar el trabajo en modo multihilo, con más de dos hilos.

BorgBackup en modo no cifrado logró un poco más lento que el alquitrán, en 2 minutos y 45 segundos, sin embargo, a diferencia del mismo alquitrán, fue posible deduplicar el repositorio. La carga al mismo tiempo resultó


Si activa el cifrado basado en blake, la velocidad de restauración de una copia de seguridad disminuye un poco. El tiempo de recuperación en este modo es de 3 minutos y 19 segundos, y se libera la carga.


El cifrado AES funciona un poco más lento, tiempo de recuperación 3 minutos 23 segundos, especialmente carga


Dado que Borg puede funcionar en modo de subprocesos múltiples: la carga del procesador es máxima, mientras que cuando activa funciones adicionales, el tiempo de funcionamiento simplemente aumenta. Aparentemente, vale la pena explorar el trabajo de subprocesos múltiples de manera similar a zbackup.

Restic hizo frente a la recuperación un poco más lentamente, el tiempo de operación fue de 4 minutos y 28 segundos. La carga parecía


Aparentemente, el proceso de recuperación funciona en varios subprocesos, pero la eficiencia no es tan alta como la de BorgBackup, pero es comparable en el tiempo al rsync habitual.

Usando UrBackup, pude recuperar datos en 8 minutos y 19 segundos, mientras la carga estaba


Todavía no se ve una carga muy alta, incluso más baja que la del alquitrán. En lugares, estalla, pero no más que cargar un solo núcleo.

Selección y justificación de criterios de comparación.

Como se mencionó en un artículo anterior, el sistema de respaldo debe cumplir con los siguientes criterios:

• Simplicidad en el trabajo
• Versatilidad
• Estabilidad
• Velocidad

Vale la pena considerar cada artículo por separado con más detalle.

Simplicidad de trabajo

Es mejor cuando hay un botón "Hacer que todo sea bueno", pero si vuelve a los programas reales, será más conveniente tener un principio de funcionamiento familiar y estándar.
La mayoría de los usuarios probablemente estarán mejor si no necesitan memorizar un montón de claves para cli, configurar un montón de opciones diferentes, a menudo oscuras a través de la web o tui, y configurar alertas sobre la operación fallida. Esto también incluye la capacidad de "adaptar" fácilmente una solución de respaldo en una infraestructura existente, así como también de automatizar el proceso de respaldo. Inmediatamente la capacidad de instalar un administrador de paquetes, o en uno o dos comandos del tipo "descargar y descomprimir". curl | sudo bash curl | sudo bash es un método complicado porque necesita verificar que llegue por referencia.

Por ejemplo, de los candidatos considerados, una solución simple es eructar, rdiff-backup y restic, que tienen claves mnemónicamente recordadas para diferentes modos de operación. Un poco más complicados son el borg y la duplicidad. Lo más difícil fue AMANDA. El resto de la facilidad de uso está en algún punto intermedio. En cualquier caso, si necesita más de 30 segundos para leer el manual del usuario, o si necesita ir a Google u otro motor de búsqueda, y también desplazarse por la larga hoja de ayuda, la solución es complicada, de una forma u otra.

Algunos de los candidatos considerados pueden enviar automáticamente un mensaje por correo electrónico \ jabber, mientras que otros confían en alertas configuradas en el sistema. Además, la mayoría de las veces las decisiones complejas no tienen configuraciones de notificación bastante obvias. En cualquier caso, si el programa de respaldo proporciona un código de retorno distinto de cero, que será entendido correctamente por el servicio del sistema de tareas periódicas (el mensaje volará al administrador del sistema o inmediatamente al monitoreo): la situación es simple. Pero si el sistema de respaldo, que no funciona en el servidor de respaldo, no se puede configurar de una manera obvia, la complejidad ya es excesiva. En cualquier caso, emitir advertencias y otros mensajes solo a la interfaz web y / o al registro es una mala práctica, ya que a menudo se ignorarán.

En cuanto a la automatización, un programa simple puede leer variables de entorno que especifican su modo de operación, o tiene un cli desarrollado que puede duplicar completamente el comportamiento cuando se trabaja a través de una interfaz web, por ejemplo. Esto también incluye la posibilidad de trabajo continuo, la disponibilidad de oportunidades de expansión, etc.

Versatilidad

Se hace eco parcialmente de la subsección anterior en términos de automatización, no debería ser un problema especial "ajustar" el proceso de copia de seguridad en la infraestructura existente.
Vale la pena señalar que el uso de puertos no estándar (bueno, excepto la interfaz web) para el trabajo, la implementación del cifrado de una manera no estándar, el intercambio de datos con un protocolo no estándar son signos de una solución no universal. En su mayor parte, todos los candidatos tienen una forma u otra por la razón obvia: la simplicidad y la versatilidad generalmente no son compatibles. El eructo es una excepción, hay otros.

Como señal, la capacidad de trabajar usando ssh regular.

Velocidad de trabajo

El punto más controvertido y controvertido. Por un lado, comenzaron el proceso, funcionó lo más rápido posible y no interfiere con las tareas principales. Por otro lado, hay un aumento en el tráfico y la carga de la CPU durante la copia de seguridad. También vale la pena señalar que los programas de copia más rápidos suelen ser los más pobres en características que son importantes para los usuarios. Nuevamente: si para obtener un archivo de texto desafortunado del tamaño de varias decenas de bytes con una contraseña, y debido a ello, todo el servicio cuesta (sí, entiendo que aquí el proceso de copia de seguridad a menudo no es culpable), y debe volver a leer secuencialmente todos los archivos en el repositorio o despliegue todo el archivo: el sistema de copia de seguridad nunca es rápido. Otro punto que a menudo se convierte en un obstáculo es la velocidad de implementación de una copia de seguridad desde el archivo. Existe una clara ventaja para aquellos que simplemente pueden copiar o mover archivos al lugar correcto sin manipulaciones especiales (por ejemplo, rsync), pero la mayoría de las veces el problema debe resolverse de forma organizativa, empíricamente: mida el tiempo de recuperación de la copia de seguridad e informe abiertamente a los usuarios al respecto.

Estabilidad

Debe entenderse de la siguiente manera: por un lado, debería ser posible implementar la copia de seguridad de cualquier forma, por otro lado, la resistencia a varios problemas: falla de la red, falla del disco, eliminación de parte del repositorio.

Comparación de herramientas de respaldo

Leyenda de la mesa:

• Verde, el tiempo de funcionamiento es inferior a cinco minutos, o la respuesta es "Sí" (a excepción de la columna "¿Necesita un cliente / servidor?"), 1 punto
• Amarillo, tiempo de operación de cinco a diez minutos, 0.5 puntos
• Rojo, el tiempo de funcionamiento es más de diez minutos, o la respuesta es "No" (a excepción de la columna "¿Necesita un cliente \ servidor?"), 0 puntos

De acuerdo con la tabla anterior, la herramienta de copia de seguridad más simple, rápida y al mismo tiempo conveniente y poderosa es BorgBackup. Restic tomó el segundo lugar, el resto de los candidatos considerados se colocaron aproximadamente igual con una dispersión de uno o dos puntos al final.

Agradezco a todos los que leyeron el ciclo hasta el final, sugiero discutir opciones, sugiriendo la suya, si la hay. A medida que avanza la discusión, la tabla puede complementarse.

El resultado del ciclo será el artículo final, en el que se intentará presentar una herramienta de respaldo ideal, rápida y manejable que le permita implementar rápidamente una copia de respaldo y al mismo tiempo tener la conveniencia y simplicidad de configuración y mantenimiento.

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, duplicación
Copia de seguridad, Parte 4: Descripción general y prueba de zbackup, restic, borgbackup
Copia de seguridad, parte 5: Prueba de copia de seguridad de bacula y veeam 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