En este artículo se realizará una comparación de las herramientas de respaldo, pero primero es importante entender cómo manejan rápidamente y de manera efectiva la recuperación de datos de las copias de seguridad.
Para simplificar la comparación, se considerará la recuperación de una copia de seguridad completa, especialmente porque este modo de operación es compatible con todos los candidatos. Para simplificar, los números se toman ya promediados (media aritmética de varias ejecuciones). Los resultados se presentarán en una tabla, que también incluirá información sobre las capacidades: existencia de una interfaz web, facilidad de configuración y uso, capacidad de automatización, existencia de varias características adicionales (por ejemplo, verificación de integridad de datos), etc. Los gráficos mostrarán la carga del servidor donde se aplicarán los datos (no el servidor de almacenamiento de copias de seguridad).
Recuperación de datos
Como punto de referencia se utilizarán rsync y tar, ya que los scripts más simples para realizar copias de seguridad.
Rsync completó el conjunto de datos de prueba en 4 minutos y 28 segundos, mostrando
tal carga.
El proceso de recuperación se vio limitado por la restricción del subsistema de almacenamiento del servidor de copias de seguridad (gráficos en forma de sierra). También se puede ver claramente la carga de un solo núcleo sin problemas significativos (bajo iowait y softirq — no hay problemas con el disco y la red respectivamente). Dado que otros dos programas, rdiff-backup y rsnapshot, se basan en rsync y también ofrecen el rsync habitual como método de recuperación, tendrán un perfil de carga y tiempo de recuperación de copias de seguridad similar.
Tar fue un poco más rápido, logrando hacerlo en
2 minutos y 43 segundos:
La carga total del sistema fue un 20% mayor de media debido al aumento del softirq — los gastos generales de la red aumentaron.
Si el archivo se comprime adicionalmente, el tiempo de recuperación aumenta a 3 minutos 19 segundos con
esta carga en el servidor principal (descompresión en el lado del servidor principal):
El proceso de descompresión utiliza ambos núcleos del procesador, ya que opera dos procesos. En general, es el resultado esperado. También se obtuvo un resultado comparable (3 minutos y 20 segundos) al ejecutar gzip en el servidor con las copias de seguridad, el perfil de carga en el servidor principal fue bastante similar al ejecutar tar sin el compresor gzip (ver el gráfico anterior).
En rdiff-backup se puede sincronizar la última copia de seguridad realizada utilizando el comando rsync normal (los resultados serán similares), pero las copias de seguridad más antiguas aún deben ser restauradas utilizando el programa rdiff-backup, que logró la restauración en 17 minutos y 17 segundos, mostrando
tal carga:
Quizás así estaba pensado, al menos para limitar la velocidad los autores . El proceso de restauración de la copia de seguridad toma poco menos de la mitad de un núcleo, con un rendimiento proporcionalmente comparable (es decir, de 2 a 5 veces más lento) en disco y red con rsync.
Rsnapshot para la restauración sugiere utilizar rsync normal, por lo que sus resultados serán similares. En general, así fue.
Burp completó la tarea de restauración de la copia de seguridad en 7 minutos y 2 segundos con
tal carga:
Funcionó bastante rápido y, al menos, es mucho más conveniente que rsync limpio: no hay que recordar ninguna bandera, interfaz de línea de comandos simple e intuitiva, soporte interno para múltiples copias, aunque es aproximadamente dos veces más lento. Si los datos deben ser restaurados desde la última copia de seguridad realizada, se puede utilizar rsync, con algunas salvedades.
Un programa similar mostró una velocidad y carga BackupPC al activar el modo de transferencia rsync, restaurando la copia de seguridad en
7 minutos y 42 segundos:
Sin embargo, en el modo de transferencia de datos con tar, BackupPC resultó más lento: en 12 minutos y 15 segundos, la carga del procesador fue significativamente más baja
en un 50%:
Duplicity sin cifrado mostró resultados ligeramente mejores, completando la restauración de la copia de seguridad en 10 minutos y 58 segundos. Al activar el cifrado con gpg, el tiempo de restauración aumenta a 15 minutos y 3 segundos. También al crear un repositorio para almacenar copias se puede especificar el tamaño del archivo que se utilizará al dividir el flujo de datos entrantes. En general, en discos duros normales, así como debido al modo de un solo hilo, no hay una diferencia significativa. Esta podría aparecer con diferentes tamaños de bloques, cuando se utilizan almacenamiento híbrido. La carga en el servidor principal durante la restauración fue la siguiente:
sin cifrado
con cifrado
Duplicati mostró una velocidad de restauración comparable, completando en 13 minutos y 45 segundos. La verificación de la corrección de los datos restaurados tomó aproximadamente 5 minutos (un total de alrededor de 19 minutos). La carga en este caso fue
suficientemente alta:
Cuando el cifrado aes se activó mediante herramientas internas, el tiempo de restauración fue de 21 minutos y 40 segundos, y la carga de la CPU fue máxima (¡ambos núcleos!) durante la restauración; durante la verificación de los datos estaba activo solo un hilo, utilizando un núcleo del procesador. La verificación de los datos después de la restauración tomó los mismos 5 minutos (un total de casi 27 minutos).
Resultado
Un poco más rápido, duplicati manejó la restauración utilizando un programa externo gpg para el cifrado, pero en general las diferencias con el modo anterior son mínimas. El tiempo de trabajo fue de 16 minutos y 30 segundos, con una verificación de datos de 6 minutos. La carga fue
la siguiente:
AMANDA, que utiliza tar, completó en 2 minutos y 49 segundos, lo cual, en principio, es bastante cercano a un tar normal. La carga en el sistema en principio
es la misma:
Durante la restauración de la copia de seguridad con zbackup se obtuvieron los siguientes resultados:
cifrado, compresión lzma
El tiempo de trabajo fue de 11 minutos y 8 segundos
cifrado aes, compresión lzma
El tiempo de trabajo fue de 14 minutos
cifrado aes, compresión lzo
El tiempo de trabajo fue de 6 minutos y 19 segundos
En general, no está mal. Todo depende de la velocidad del procesador en el servidor de respaldo, lo que se puede ver claramente en el tiempo de ejecución del programa con diferentes compresores. Desde el servidor de respaldo se ejecutaba el tar habitual, así que comparándolo, la restauración funciona 3 veces más lenta. Quizás valga la pena probar la operación en modo multihilo, con más de dos hilos.
BorgBackup en modo sin cifrado, fue un poco más lento que tar, tardando 2 minutos y 45 segundos, sin embargo, a diferencia de tar, se ofreció la opción de deduplicación del repositorio. La carga resultante fue
la siguiente:
Si se activa el cifrado basado en blake, la velocidad de restauración de la copia de seguridad se ralentiza un poco. El tiempo de restauración en este modo es de 3 minutos y 19 segundos, y la carga fue
la siguiente:
El cifrado aes funciona un poco más lento, con un tiempo de restauración de 3 minutos y 23 segundos, y la carga no
cambió mucho:
Dado que Borg puede funcionar en modo multihilo, la carga del procesador es máxima, y al activar funciones adicionales simplemente aumenta el tiempo de trabajo. Aparentemente, vale la pena investigar el multihilo de manera similar a zbackup.
Restic se encargó de la restauración un poco más lento, con un tiempo de ejecución de 4 minutos y 28 segundos. La carga durante este tiempo fue
así que:
Aparentemente, el proceso de restauración funciona en varios hilos, pero la eficiencia no es tan alta como en BorgBackup, aunque es comparable en tiempo con el rsync habitual.
Con UrBackup logró restaurar los datos en 8 minutos y 19 segundos, y la carga durante este tiempo fue
la siguiente:
Igualmente se observa una carga no muy alta, incluso más baja que el tar. En algunos momentos hay picos, pero no más que la carga de un núcleo.
Selección y justificación de criterios para la comparación
Como se mencionó en uno de los artículos anteriores, el sistema de copias de seguridad debe cumplir con los siguientes criterios:
- Sencillez en el trabajo
- Versatilidad
- Estabilidad
- Rapidez
Vale la pena revisar cada punto por separado con más detalle.
Facilidad de uso
Lo mejor es tener un solo botón de 'Hacer todo bien', pero volviendo a los programas reales, el principio de operación más cómodo será uno estándar y familiar.
La mayoría de los usuarios, probablemente, preferiría no tener que recordar una multitud de claves para la CLI, configurar diferentes opciones, a menudo poco claras, a través de web o TUI, y establecer alertas sobre fallos en el trabajo. Esto incluye la posibilidad de integrar fácilmente una solución de respaldo en la infraestructura existente, así como la automatización del proceso de respaldo. También aquí se incluye la posibilidad de instalación con un gestor de paquetes o en una o dos órdenes del tipo 'descargar y descomprimir'. curl enlace | sudo bash — un método complicado, ya que es necesario verificar qué llega por el enlace.
Por ejemplo, de los candidatos considerados, las soluciones sencillas son burp, rdiff-backup y restic, que tienen claves mnemotécnicamente memorables para diferentes modos de operación. Un poco más complejos son borg y duplicity. La más complicada fue AMANDA. Los demás se encuentran en un término medio en cuanto a facilidad de uso. En cualquier caso, si se necesita más de 30 segundos para leer la guía del usuario, o se necesita buscar en Google o en otro motor de búsqueda, así como pasar por una 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 e-mail o Jabber, mientras que otros dependen de alertas configuradas en el sistema. La mayoría de las veces, las soluciones complejas tienen configuraciones de alertas no del todo obvias. En cualquier caso, si el programa de respaldo devuelve un código de error distinto de cero, que será correctamente interpretado por el servicio del sistema de tareas periódicas (se enviará un mensaje al administrador del sistema o directamente a la supervisión), la situación es sencilla. Pero si el sistema de respaldo, que no opera en el servidor de copias de seguridad, no puede comunicar un problema de forma obvia sin configuración, la complejidad es excesiva. En cualquier caso, emitir advertencias y otros mensajes solo en la interfaz web y/o en el registro es una mala práctica, ya que la mayoría de las veces serán ignorados.
En cuanto a la automatización, un programa sencillo puede leer variables de entorno que determinan su modo de operación, o tiene una CLI avanzada, capaz de replicar completamente el comportamiento cuando se utiliza a través de la interfaz web, por ejemplo. También incluye la posibilidad de trabajar de manera fluida, tener capacidades de expansión, etc.
Versatilidad
Se superpone parcialmente con la sección anterior en lo que respecta a la automatización, no debería ser un problema «integrar» el proceso de copia de seguridad en la infraestructura existente.
Cabe destacar que el uso de puertos no estándar (además de la interfaz web) para el funcionamiento, la implementación de cifrado de forma no convencional, el intercambio de datos mediante un protocolo no estándar, son signos de una solución no universal. La mayoría de los candidatos poseen características de este tipo por razones obvias: la simplicidad y la universalidad suelen ser incompatibles. Como excepción, está burp, pero hay otros.
Como signo: la posibilidad de trabajar usando ssh común.
Velocidad de funcionamiento
El punto más controvertido y debatido. Por un lado, se lanza el proceso, se ejecuta lo más rápido posible y no interfiere con las tareas principales. Por otro lado, el aumento del tráfico y la carga en el procesador durante la copia de seguridad. También cabe mencionar que los programas más rápidos para hacer copias de seguridad suelen estar escasos de funciones que son importantes para los usuarios. Nuevamente: si para recuperar un miserable archivo de texto de unos pocos decenas de bytes con una contraseña, y debido a él se detiene todo el servicio (sí, entiendo que aquí el proceso de copia de seguridad a menudo no es el culpable), hay que volver a leer secuencialmente todos los archivos en el repositorio o descomprimir todo un archivo—el sistema de copias de seguridad no es en absoluto rápido. Otro punto que a menudo resulta ser una piedra de toque es la velocidad de restauración de la copia de seguridad desde el archivo. Aquí claramente tienen ventaja aquellos que pueden simplemente copiar o mover archivos al lugar deseado sin muchas manipulaciones (por ejemplo, rsync), pero a menudo el problema debe resolverse de forma organizativa, empíricamente: medir el tiempo de recuperación de la copia de seguridad y comunicarlo abiertamente a los usuarios.
Estabilidad
Se debe entender así: por un lado, debe ser posible restaurar la copia de seguridad de cualquier manera, por otro lado, resiliencia ante diversos problemas: corte de red, fallo del disco, eliminación de parte del repositorio.
Comparación de herramientas de copia de seguridad
Tiempo de creación de la copia
Tiempo de restauración de la copia
Instalación sencilla
Configuración sencilla
Uso sencillo
Automatización sencilla
¿Se necesita cliente-servidor?
Verificación de la integridad del repositorio
Copias diferenciales
Trabajo a través de pipes
Versatilidad
Autonomía
Transparencia del repositorio
Cifrado
Compresión
Deduplicación
Interfaz web
Cargado en la nube
Posibilidad de núcleo personalizado
Puntuación
Rsync
4m15s
4m28s
sí
no
no
no
sí
no
no
sí
no
sí
sí
no
no
no
no
no
sí
6
Tar
puro
3m12s
2m43s
sí
no
no
no
no
no
sí
sí
no
sí
no
no
no
no
no
no
sí
8,5
gzip
9m37s
3m19s
sí
Rdiff-backup
16m26s
17m17s
sí
sí
sí
sí
sí
no
sí
no
sí
no
sí
no
sí
sí
sí
no
sí
11
Rsnapshot
4m19s
4m28s
sí
sí
sí
sí
no
no
sí
no
sí
no
sí
no
no
sí
sí
no
sí
12,5
Burp
11m9s
7m2s
sí
no
sí
sí
sí
sí
sí
no
sí
sí
no
no
sí
no
sí
no
sí
10,5
Duplicity
sin cifrado
16m48s
10m58s
sí
sí
no
sí
no
sí
sí
no
no
sí
no
sí
sí
no
sí
no
sí
11
gpg
17m27s
15m3s
Duplicati
sin cifrado
20m28s
13m45s
no
sí
no
no
no
sí
sí
no
no
sí
no
sí
sí
sí
sí
sí
sí
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
Zbackup
sin cifrado
40m3s
11m8s
sí
sí
no
no
no
sí
sí
sí
no
sí
no
sí
sí
sí
no
no
no
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
sin cifrado
4m7s
2m45s
sí
sí
sí
sí
sí
sí
sí
sí
sí
sí
no
sí
sí
sí
sí
no
sí
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
sí
sí
sí
sí
no
sí
sí
sí
sí
sí
no
sí
no
sí
no
sí
sí
15,5
UrBackup
8m21s
8m19s
sí
sí
sí
no
sí
no
sí
no
sí
sí
no
sí
sí
sí
sí
no
sí
12
Amanda
9m3s
2m49s
sí
no
no
sí
sí
sí
sí
no
sí
sí
sí
sí
sí
no
sí
sí
sí
13
BackupPC
rsync
12m22s
7m42s
sí
no
sí
sí
sí
sí
sí
no
sí
no
no
sí
sí
no
sí
no
sí
10,5
tar
12m34s
12m15s
Leyenda de la tabla:
- Verde, tiempo de operación menos de cinco minutos, o respuesta 'Sí' (excepto en la columna '¿Se necesita cliente-servidor?'), 1 punto
- Amarillo, tiempo de operación de cinco a diez minutos, 0.5 puntos
- Rojo, tiempo de operación más de diez minutos, o respuesta 'No' (excepto en la columna '¿Se necesita cliente-servidor?'), 0 puntos
Según la tabla anterior, la herramienta más simple, rápida y, al mismo tiempo, conveniente y poderosa para la copia de seguridad es BorgBackup. En segundo lugar se encuentra Restic, y los demás candidatos considerados se ubicaron aproximadamente igual con una variación de uno o dos puntos al final.
Agradezco a todos los que han leído la serie hasta el final, propongo discutir opciones y proponer las suyas, si las hay. A medida que se discuta, la tabla puede ser completada.
El resultado de la serie será un artículo final, en el que se intentará encontrar la herramienta ideal, rápida y manejable para la copia de seguridad, que permita restaurar una copia rápidamente y al mismo tiempo brinde comodidad y simplicidad en su configuración y mantenimiento.
Anuncio
Copia de seguridad, parte 6: Comparación de herramientas de copia de seguridad
Copia de seguridad, parte 7: Conclusiones
Fuente: habr.com
