Este artículo analizará las herramientas de software de respaldo que, al dividir el flujo de datos en componentes separados (fragmentos), forman un repositorio.
Los componentes del repositorio también se pueden comprimir y cifrar, y lo más importante, con procesos de copia de seguridad repetidos, reutilizar nuevamente.
Una copia de seguridad en un repositorio similar es una cadena con nombre de componentes relacionados, por ejemplo, basada en varias funciones hash.
Hay varias soluciones similares, me centraré en 3: zbackup, borgbackup y restic.
Resultados esperados
Dado que todos los solicitantes de una forma u otra requieren la creación de un repositorio, uno de los factores más importantes será la estimación del tamaño del repositorio. En el caso ideal, su tamaño no debe ser superior a 13 GB de acuerdo con la metodología aceptada, o incluso menos, sujeto a una buena optimización.
También es altamente deseable poder hacer una copia de seguridad de los archivos directamente, sin usar archivadores tar, así como trabajar con ssh / sftp sin herramientas adicionales como rsync y sshfs.
Comportamiento de respaldo:
- El tamaño del repositorio será igual al tamaño de los cambios, o menos.
- Se espera una gran carga del procesador cuando se usa compresión y / o cifrado, y una carga bastante grande en la red y el subsistema de disco es probable si el proceso de archivo y / o cifrado funcionará en el servidor de almacenamiento de respaldo.
- Si daña el repositorio, es probable que se produzca un error retrasado tanto al crear nuevas copias de seguridad como al intentar restaurar. Es necesario planificar medidas adicionales para garantizar la integridad del repositorio o utilizar los medios integrados para verificar su integridad.
El trabajo con alquitrán se acepta como valor de referencia, como se mostró en uno de los artículos anteriores.
Prueba de respaldo
El mecanismo general de la operación zbackup es que el programa encuentra áreas que contienen los mismos datos en el flujo de datos suministrado en la entrada, luego las comprime y las cifra opcionalmente, ahorrando cada área solo 1 vez.
Para la deduplicación, se utiliza una función hash de anillo de 64 bits con una ventana deslizante para verificar byte en busca de coincidencias con los bloques de datos existentes (similar a cómo se implementa en rsync).
Para la compresión, lzma y lzo se utilizan en la ejecución de subprocesos múltiples y para el cifrado: aes. En las últimas versiones hay una oportunidad en el futuro para eliminar datos antiguos del repositorio.
El programa está escrito en C ++ con dependencias mínimas. Aparentemente, el autor se inspiró en el modo Unix, por lo que el programa recibe datos en stdin al crear copias de seguridad, dando un flujo de datos similar al stdout al restaurar. Por lo tanto, zbackup se puede utilizar como un buen "ladrillo" al escribir sus propias soluciones de copia de seguridad. Por ejemplo, el autor del artículo, este programa es la principal herramienta de respaldo para máquinas domésticas desde aproximadamente 2014.
Se utilizará un alquitrán regular como flujo de datos, a menos que se indique lo contrario.
Veamos cuáles serán los resultados:La verificación del trabajo se realizó en 2 versiones:
- se crea un repositorio y se inicia zbackup en el servidor con los datos de origen, luego los contenidos del repositorio se transfieren al servidor de almacenamiento de respaldo.
- se crea un repositorio en el servidor de almacenamiento de respaldo, zbackup se inicia a través de ssh en el servidor de almacenamiento de respaldo, los datos se le proporcionan a través de una tubería.
Los resultados de la primera opción fueron los siguientes: 43m11s - cuando se usa un repositorio sin cifrar y un compresor lzma, 19m13s - cuando se reemplaza el compresor con lzo.
La carga en el servidor con los datos de origen fue la siguiente (se muestra el ejemplo con lzma, con lzo había aproximadamente la misma imagen, pero la proporción de rsync era aproximadamente un cuarto del tiempo):
Está claro que dicho proceso de copia de seguridad solo es adecuado para cambios relativamente raros y pequeños. También es muy deseable limitar el funcionamiento de zbackup a 1 subproceso, de lo contrario habrá una carga muy alta en el procesador, porque El programa es muy bueno para trabajar en múltiples hilos. La carga del disco fue pequeña, lo que, en general, con un subsistema de disco moderno basado en SSD, no se notará. También puede ver claramente el inicio del proceso de sincronización de los datos del repositorio con un servidor remoto, la velocidad es comparable a la de rsync normal y depende del rendimiento del subsistema de disco del servidor de almacenamiento de respaldo. La desventaja del enfoque es el almacenamiento del repositorio local y, como consecuencia, la duplicación de datos.
Más interesante y práctica en la práctica es la segunda opción con ejecutar zbackup inmediatamente en el servidor de almacenamiento de respaldo.
Primero, verificaremos la operación sin usar cifrado con el compresor lzma:
El tiempo de ejecución de cada prueba:
Si activa el cifrado usando aes, los resultados son bastante cercanos:
Tiempo de funcionamiento en los mismos datos, con cifrado:
Si el cifrado se combina con la compresión en lzo, es así:
Tiempo de trabajo:
El tamaño del repositorio resultante era relativamente el mismo y ascendía a 13 GB. Esto significa que la deduplicación funciona correctamente. Además, en datos ya comprimidos, el uso de lzo produce un efecto notable; en el tiempo operativo total, zbackup se acerca mucho a duplicidad / duplicación, sin embargo, va entre 2 y 5 veces menos que los basados en librsync.
Los beneficios son obvios: ahorrar espacio en disco en el servidor de almacenamiento de respaldo. En cuanto a las herramientas para verificar el repositorio, no son provistas por zbackup, se recomienda utilizar una matriz de discos a prueba de fallas o un proveedor de la nube.
En general, una muy buena impresión, a pesar del hecho de que el proyecto tiene aproximadamente 3 años de ejecución (la última solicitud de función fue hace aproximadamente un año, pero sin respuesta).
Prueba de borgbackup
Borgbackup es una bifurcación de ático, otro sistema similar a zbackup. Está escrito en python, tiene una lista de características similares a zbackup, pero además sabe cómo:
- Montar copias de seguridad a través del fusible
- Verifique el contenido del repositorio
- Trabajar en modo cliente-servidor
- Utilice varios compresores para datos, así como también la definición heurística del tipo de archivo al comprimirlo.
- 2 opciones de cifrado, aes y blake
- Herramienta incorporada para
comprobaciones de rendimientopunto de referencia de borgbackup crud ssh: // backup_server / repo / path local_dir
Los resultados son los siguientes:
CZ-BIG 96.51 MB / s (10 100.00 MB archivos todo-cero: 10.36s)
RZ-BIG 57.22 MB / s (10 100.00 MB archivos todo-cero: 17.48s)
UZ-BIG 253.63 MB / s (10 100.00 MB archivos todo-cero: 3.94s)
DZ-BIG 351.06 MB / s (10 100.00 MB archivos todo-cero: 2.85s)
CR-BIG 34.30 MB / s (10 archivos aleatorios de 100.00 MB: 29.15s)
RR-BIG 60.69 MB / s (10 100.00 MB archivos aleatorios: 16.48s)
UR-BIG 311.06 MB / s (10 archivos aleatorios de 100.00 MB: 3.21s)
DR-BIG 72.63 MB / s (10 archivos aleatorios de 100.00 MB: 13.77s)
CZ-MEDIUM 108.59 MB / s (1000 archivos todo cero de 1.00 MB: 9.21s)
RZ-MEDIUM 76.16 MB / s (1000 archivos todo cero de 1.00 MB: 13.13s)
UZ-MEDIUM 331.27 MB / s (1000 archivos todo cero de 1.00 MB: 3.02s)
DZ-MEDIUM 387.36 MB / s (1000 archivos todo cero de 1.00 MB: 2.58s)
CR-MEDIUM 37.80 MB / s (1000 archivos aleatorios de 1.00 MB: 26.45s)
RR-MEDIUM 68.90 MB / s (1000 archivos aleatorios de 1.00 MB: 14.51s)
UR-MEDIUM 347.24 MB / s (1000 archivos aleatorios de 1.00 MB: 2.88s)
DR-MEDIUM 48.80 MB / s (1000 archivos aleatorios de 1.00 MB: 20.49s)
CZ-SMALL 11.72 MB / s (10000 10.00 kB archivos todo-cero: 8.53s)
RZ-SMALL 32.57 MB / s (10000 10.00 kB archivos todo-cero: 3.07s)
UZ-SMALL 19.37 MB / s (10000 10.00 kB archivos todo-cero: 5.16s)
DZ-SMALL 33.71 MB / s (10000 10.00 kB archivos todo-cero: 2.97s)
CR-SMALL 6.85 MB / s (10000 10.00 kB archivos aleatorios: 14.60s)
RR-SMALL 31.27 MB / s (10000 10.00 kB archivos aleatorios: 3.20s)
UR-SMALL 12.28 MB / s (10000 10.00 kB archivos aleatorios: 8.14s)
DR-SMALL 18.78 MB / s (10000 10.00 kB archivos aleatorios: 5.32s)
Durante las pruebas, la heurística se usará en compresión con la definición del tipo de archivo (compresión automática), y los resultados serán los siguientes:
Primero, verifique la operación sin cifrado:
Tiempo de trabajo:
Si habilita la autorización de repositorio (modo autenticado), los resultados estarán cercanos:
Tiempo de trabajo:
Cuando se activó el cifrado aes, los resultados no se deterioraron mucho:
Y si cambia aes a blake, la situación mejorará por completo:
Tiempo de trabajo:
Como en el caso de zbackup, el tamaño del repositorio era de 13 GB e incluso un poco menos, lo que, en general, se espera. El tiempo de trabajo fue muy satisfactorio, es comparable con soluciones basadas en librsync, brindando posibilidades mucho más amplias. También me complació la capacidad de establecer varios parámetros a través de variables de entorno, lo que brinda una ventaja muy seria cuando se usa borgbackup en modo automático. También satisfecho con la carga durante la copia de seguridad: a juzgar por la carga del procesador, borgbackup funciona en 1 subproceso.
No hubo inconvenientes especiales al usar.
Prueba restic
A pesar de que restic es una solución bastante nueva (los primeros 2 candidatos se conocen desde 2013 y anteriores), tiene características bastante buenas. Escrito en Go.
Cuando se compara con zbackup, también proporciona:
- Comprobación de la integridad del repositorio (incluidas las piezas de comprobación).
- Una gran lista de protocolos y proveedores compatibles para almacenar copias de seguridad, así como el soporte de rclone - rsync para soluciones en la nube.
- Comparación de 2 copias de seguridad entre ellos.
- Montaje del repositorio mediante fusible.
En general, la lista de posibilidades está bastante cerca del borgbackup, en algunos lugares más, en algunos lugares menos. De las características, la falta de la capacidad de deshabilitar el cifrado y, por lo tanto, las copias de seguridad siempre se cifrarán. Veamos en la práctica lo que puede extraer de este software:
Los resultados son los siguientes:
Tiempo de trabajo:
Los resultados también son comparables con las soluciones basadas en rsync y, en general, están muy cerca del borgbackup, pero la carga del procesador es mayor (varios hilos funcionan) y diente de sierra.
Lo más probable es que el programa dependa del rendimiento del subsistema de disco en el servidor de almacenamiento, como ocurrió con rsync. El tamaño del repositorio era de 13 GB, al igual que zbackup o borgbackup, no hubo inconvenientes obvios al usar esta solución.
Resultados
De hecho, todos los candidatos obtuvieron indicadores cercanos, pero a un precio diferente. Borgbackup ha demostrado ser el mejor, un poco más lento: restic, zbackup, probablemente no deberías comenzar a aplicar,
y si ya está en uso, intente cambiar a borgbackup o restic.
Conclusiones
La solución más prometedora es la restic, ya que es él quien tiene la mejor relación de capacidades a velocidad, pero por ahora no apuraremos las conclusiones generales.
Borgbackup, en principio, no es peor, pero zbackup es probablemente mejor para reemplazar. Sin embargo, para garantizar que la regla 3-2-1 funcione, zbackup todavía se puede usar. Por ejemplo, además de las herramientas de respaldo basadas en (lib) rsync.
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
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