Este artículo considerará el software de respaldo que, al dividir el flujo de datos en componentes separados (fragmentos), forma un repositorio.
Los componentes del repositorio se pueden comprimir y cifrar aún más y, lo más importante, durante los procesos de copia de seguridad repetidos, se pueden reutilizar.
Una copia de seguridad en dicho repositorio es una cadena con nombre de componentes conectados entre sí, por ejemplo, en función de varias funciones hash.
Hay varias soluciones similares, me centraré en 3: zbackup, borgbackup y restic.
Resultados esperados
Dado que todos los solicitantes requieren la creación de un repositorio de una forma u otra, uno de los factores más importantes será estimar el tamaño del repositorio. Idealmente, su tamaño no debería superar los 13 GB según la metodología aceptada, o incluso menos, siempre que se realice una buena optimización.
También es muy recomendable poder crear copias de seguridad de archivos directamente, sin utilizar archivadores como tar, así como trabajar con ssh/sftp sin herramientas adicionales como rsync y sshfs.
Comportamiento al crear copias de seguridad:
- El tamaño del repositorio será igual al tamaño de los cambios, o menor.
- Se espera una gran carga de CPU cuando se utiliza compresión y/o cifrado, y es probable que la red y el disco tengan una carga bastante alta si el proceso de archivado y/o cifrado se ejecuta en un servidor de almacenamiento de respaldo.
- Si el repositorio está dañado, 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 herramientas integradas para comprobar su integridad.
Se toma como valor de referencia trabajar con tar, como se mostró en uno de los artículos anteriores.
Probando zbackup
El mecanismo general de zbackup es que el programa encuentra en el flujo de datos de entrada áreas que contienen los mismos datos y luego, opcionalmente, las comprime y cifra, guardando cada área solo una vez.
La deduplicación utiliza una función hash de anillo de 64 bits con una ventana deslizante para verificar coincidencias byte por byte con bloques de datos existentes (similar a cómo lo implementa rsync).
Lzma y lzo de subprocesos múltiples se utilizan para la compresión y aes para el cifrado. Las últimas versiones tienen la capacidad de eliminar datos antiguos del repositorio en el futuro.
El programa está escrito en C++ con dependencias mínimas. El autor aparentemente se inspiró en el estilo Unix, por lo que el programa acepta datos en stdin al crear copias de seguridad, produciendo un flujo de datos similar en stdout al restaurar. Por lo tanto, zbackup se puede utilizar como un muy buen “bloque de construcción” al escribir sus propias soluciones de respaldo. Por ejemplo, el autor del artículo ha utilizado este programa como principal herramienta de copia de seguridad para máquinas domésticas desde aproximadamente 2014.
El flujo de datos será un tar normal a menos que se indique lo contrario.
Veamos cuáles son los resultados:
El trabajo fue revisado en 2 opciones:
- Se crea un repositorio y se inicia zbackup en el servidor con los datos de origen, luego el contenido del repositorio se transfiere al servidor de almacenamiento de respaldo.
- Se crea un repositorio en el servidor de almacenamiento de respaldo, se inicia zbackup a través de ssh en el servidor de almacenamiento de respaldo y se le envían datos a través de una tubería.
Los resultados de la primera opción fueron los siguientes: 43m11s - cuando se usa un repositorio no cifrado y el compresor lzma, 19m13s - cuando se reemplaza el compresor con lzo.
La carga en el servidor con los datos originales fue la siguiente (se muestra un ejemplo con lzma; con lzo había aproximadamente la misma imagen, pero la proporción de rsync fue aproximadamente una cuarta parte del tiempo):
Está claro que un proceso de copia de seguridad de este tipo sólo es adecuado para cambios pequeños y relativamente raros. También es muy recomendable limitar zbackup a 1 subproceso; de lo contrario, habrá una carga de CPU muy alta, porque El programa es muy bueno trabajando en múltiples subprocesos. La carga en el disco era pequeña, lo que en general no se notaría con un subsistema de disco moderno basado en SSD. También puede ver claramente el inicio del proceso de sincronización de los datos del repositorio con un servidor remoto; la velocidad de operación es comparable a la del rsync normal y depende del rendimiento del subsistema de disco del servidor de almacenamiento de respaldo. La desventaja de este enfoque es el almacenamiento en un repositorio local y, como resultado, la duplicación de datos.
Más interesante y aplicable en la práctica es la segunda opción, ejecutar zbackup directamente en el servidor de almacenamiento de respaldo.
Primero, probaremos el funcionamiento sin utilizar cifrado con el compresor lzma:
Tiempo de ejecución de cada prueba:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Si habilita el cifrado usando aes, los resultados son bastante parecidos:
Tiempo de funcionamiento sobre los mismos datos, con cifrado:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Si el cifrado se combina con la compresión usando lzo, se ve así:
Horario:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
El tamaño del repositorio resultante fue relativamente el mismo: 13 GB. Esto significa que la deduplicación está funcionando correctamente. Además, en datos ya comprimidos, el uso de lzo produce un efecto notable; en términos de tiempo total de funcionamiento, zbackup se acerca a duplicity/duplicati, pero va por detrás de aquellos basados en librsync entre 2 y 5 veces.
Las ventajas son obvias: ahorrar espacio en disco en el servidor de almacenamiento de respaldo. En cuanto a las herramientas de verificación del repositorio, el autor de zbackup no las proporciona; se recomienda utilizar una matriz de discos tolerante a fallas o un proveedor de nube.
En general, una muy buena impresión, a pesar de que el proyecto lleva unos 3 años parado (la última solicitud de funciones fue hace aproximadamente un año, pero sin respuesta).
Probando borgbackup
Borgbackup es un fork of atick, otro sistema similar a zbackup. Escrito en Python, tiene una lista de capacidades similares a zbackup, pero además puede:
- Montar copias de seguridad mediante fusible
- Verificar el contenido del repositorio
- Trabajar en modo cliente-servidor
- Utilice varios compresores para datos, así como la determinación heurística del tipo de archivo al comprimirlo.
- 2 opciones de cifrado, aes y blake
- Herramienta incorporada para
controles de rendimiento
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Los resultados fueron los siguientes:
C-Z-BIG 96.51 MB/s (10 Archivos todo cero de 100.00 MB: 10.36 s)
R-Z-BIG 57.22 MB/s (10 Archivos todo cero de 100.00 MB: 17.48 s)
UZ-BIG 253.63 MB/s (10 Archivos todo cero de 100.00 MB: 3.94 s)
DZ-BIG 351.06 MB/s (10 Archivos todo cero de 100.00 MB: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB de archivos aleatorios: 29.15 s)
R-R-GRANDE 60.69 MB/s (10 100.00 MB de archivos aleatorios: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB de archivos aleatorios: 3.21 s)
D-R-BIG 72.63 MB/s (10 100.00 MB de archivos aleatorios: 13.77 s)
CZ-MEDIO 108.59 MB/s (1000 Archivos todo cero de 1.00 MB: 9.21 s)
R-Z-MEDIO 76.16 MB/s (1000 Archivos todo cero de 1.00 MB: 13.13 s)
U-Z-MEDIO 331.27 MB/s (1000 Archivos todo cero de 1.00 MB: 3.02 s)
DZ-MEDIO 387.36 MB/s (1000 Archivos todo cero de 1.00 MB: 2.58 s)
C-R-MEDIO 37.80 MB/s (1000 1.00 MB de archivos aleatorios: 26.45 s)
R-R-MEDIO 68.90 MB/s (1000 1.00 MB de archivos aleatorios: 14.51 s)
U-R-MEDIO 347.24 MB/s (1000 1.00 MB de archivos aleatorios: 2.88 s)
DR-MEDIO 48.80 MB/s (1000 1.00 MB de archivos aleatorios: 20.49 s)
CZ-PEQUEÑO 11.72 MB/s (10000 Archivos todo cero de 10.00 kB: 8.53 s)
R-Z-PEQUEÑO 32.57 MB/s (10000 Archivos todo cero de 10.00 kB: 3.07 s)
U-Z-PEQUEÑO 19.37 MB/s (10000 Archivos todo cero de 10.00 kB: 5.16 s)
D-Z-PEQUEÑO 33.71 MB/s (10000 Archivos todo cero de 10.00 kB: 2.97 s)
CR-PEQUEÑO 6.85 MB/s (10000 Archivos aleatorios de 10.00 kB: 14.60 s)
RR-PEQUEÑO 31.27 MB/s (10000 Archivos aleatorios de 10.00 kB: 3.20 s)
UR-PEQUEÑO 12.28 MB/s (10000 Archivos aleatorios de 10.00 kB: 8.14 s)
DR-PEQUEÑO 18.78 MB/s (10000 Archivos aleatorios de 10.00 kB: 5.32 s)
Al realizar la prueba, se utilizará heurística de compresión para determinar el tipo de archivo (compresión automática) y los resultados serán los siguientes:
Primero, veamos cómo funciona sin cifrado:
Horario:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
4m6s
4m10s
4m5s
Los 56s
Los 58s
Los 54s
1m26s
1m34s
1m30s
Si habilita la autorización del repositorio (modo autenticado), los resultados serán similares:
Horario:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Cuando se activó el cifrado aes, los resultados no empeoraron mucho:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Y si cambias aes por blake, la situación mejorará por completo:
Horario:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
4m33s
4m43s
4m40s
Los 59s
1m0s
1m0s
1m38s
1m43s
1m40s
Como en el caso de zbackup, el tamaño del repositorio era de 13 GB e incluso un poco menos, lo que generalmente se espera. Quedé muy satisfecho con el tiempo de ejecución; es comparable a las soluciones basadas en librsync y ofrece capacidades mucho más amplias. También me complació la capacidad de configurar varios parámetros a través de variables de entorno, lo que brinda una gran ventaja al usar borgbackup en modo automático. También me complació la carga durante la copia de seguridad: a juzgar por la carga del procesador, borgbackup funciona en 1 subproceso.
No hubo desventajas particulares al usarlo.
pruebas resticas
A pesar de que restic es una solución bastante nueva (los 2 primeros candidatos se conocieron en 2013 y antes), tiene características bastante buenas. Escrito en Go.
En comparación con zbackup, también ofrece:
- Comprobación de la integridad del repositorio (incluido el control de piezas).
- Una lista enorme de protocolos y proveedores compatibles para almacenar copias de seguridad, así como soporte para rclone - rsync para soluciones en la nube.
- Comparando 2 copias de seguridad entre sí.
- Montaje del repositorio mediante fusible.
En general, la lista de funciones es bastante parecida a la de borgbackup, en algunos lugares más, en otros menos. Una de las características es que no hay forma de desactivar el cifrado y, por lo tanto, las copias de seguridad siempre estarán cifradas. Veamos en la práctica qué se puede sacar de este software:
Los resultados fueron los siguientes:
Horario:
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
5m25s
5m50s
5m38s
Los 35s
Los 38s
Los 36s
1m54s
2m2s
1m58s
Los resultados de rendimiento también son comparables a los de las soluciones basadas en rsync y, en general, muy cercanos a los de borgbackup, pero la carga de la CPU es mayor (varios subprocesos en ejecución) y en forma de diente de sierra.
Lo más probable es que el programa esté limitado por el rendimiento del subsistema de disco en el servidor de almacenamiento de datos, como ya ocurría con rsync. El tamaño del repositorio era de 13 GB, al igual que zbackup o borgbackup, no hubo desventajas obvias al utilizar esta solución.
resultados
De hecho, todos los candidatos lograron resultados similares, pero a precios diferentes. Borgbackup tuvo el mejor desempeño de todos, restic fue un poco más lento, probablemente no valga la pena comenzar a usar zbackup,
y si ya está en uso, intenta cambiarlo a borgbackup o restic.
Hallazgos
La solución más prometedora parece ser restica, porque... es él quien tiene la mejor relación entre capacidades y velocidad de funcionamiento, pero no nos apresuremos a sacar conclusiones generales por ahora.
Borgbackup básicamente no es peor, pero probablemente sea mejor reemplazar zbackup. Es cierto que zbackup todavía se puede utilizar para garantizar que la regla 3-2-1 funcione. Por ejemplo, además de las funciones de copia de seguridad basadas en (lib)rsync.
anuncio
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