En este artículo se discutirán las herramientas de software para la copia de seguridad, que, dividiendo el flujo de datos en componentes individuales (chunks), forman un repositorio.
Los componentes del repositorio pueden comprimirse y cifrarse adicionalmente, y lo más importante, pueden reutilizarse en procesos de copia de seguridad posteriores.
Una copia de seguridad en un repositorio como este es una cadena nombrada de componentes interconectados, por ejemplo, basada en diferentes funciones hash.
Existen varias soluciones similares; me detendré en 3: zbackup, borgbackup y restic.
Resultados esperados
Dado que todos los candidatos requieren de alguna manera la creación de un repositorio, uno de los factores más importantes será evaluar el tamaño del repositorio. En un caso ideal, su tamaño no debe exceder los 13 GB según la metodología adoptada, y posiblemente menos, en caso de una buena optimización.
También es muy deseable tener la capacidad de 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 carga elevada en la CPU al utilizar compresión y/o cifrado, y también es probable que haya una carga considerable en la red y en el subsistema de discos, si el proceso de archivado y/o cifrado se realiza en el servidor de almacenamiento de copias de seguridad.
- Si el repositorio se daña, es probable que se presenten errores diferidos tanto al crear nuevas copias de seguridad como al intentar restaurarlas. Se deben planificar medidas adicionales para garantizar la integridad del repositorio o utilizar herramientas integradas para verificar su integridad.
Como valor de referencia se tomó el trabajo con tar, tal como se mostró en uno de los artículos anteriores.
Pruebas de zbackup
El mecanismo general de funcionamiento de zbackup consiste en que el programa encuentra en el flujo de datos proporcionado zonas que contienen los mismos datos, luego opcionalmente las comprime, las cifra y guarda cada área solo una vez.
Para la deduplicación se utiliza una función hash de 64 bits en forma de anillo con una ventana deslizante para verificar byte a byte si coincide con bloques de datos ya existentes (similar a lo que se implementa en rsync).
Se utiliza lzma y lzo para la compresión en ejecución multihilo, y aes para el cifrado. En las versiones más recientes, hay una opción para eliminar datos antiguos del repositorio en el futuro.
El programa está escrito en C++ con mínimas dependencias. El autor, aparentemente, se inspiró en el enfoque unix, por lo que el programa recibe datos desde stdin al crear copias de seguridad y emite un flujo de datos similar en stdout al restaurar. Así, zbackup se puede utilizar como un excelente 'bloque' para crear soluciones de copia de seguridad personalizadas. Por ejemplo, para el autor de este artículo, este programa ha sido el principal medio de copia de seguridad para máquinas domésticas desde aproximadamente 2014.
Se utilizará un tar estándar como flujo de datos, a menos que se indique lo contrario.
Veamos cuáles serán los resultados:
La prueba se realizó en 2 variantes:
- se crea un repositorio y se ejecuta zbackup en un servidor con datos originales, luego el contenido del repositorio se transfiere al servidor de almacenamiento de copias de seguridad.
- se crea un repositorio en el servidor de almacenamiento de copias de seguridad, se ejecuta zbackup a través de ssh en el servidor de almacenamiento de copias de seguridad, y se le proporcionan datos a través de un pipe.
Los resultados de la primera variante fueron: 43m11s — al usar un repositorio no cifrado y el compresor lzma, 19m13s — al cambiar el compresor a lzo.
La carga en el servidor con los datos originales fue la siguiente (se muestra un ejemplo con lzma, con lzo fue una imagen similar, pero la parte de rsync fue aproximadamente un cuarto del tiempo):
Queda claro que este proceso de copia de seguridad es adecuado solo para cambios relativamente raros y pequeños. También es muy recomendable limitar el funcionamiento de zbackup a 1 hilo, de lo contrario, habrá una carga bastante alta en el CPU, ya que el programa es bastante eficiente en la ejecución multihilo. La carga en el disco fue baja, lo que en general, con un sistema de discos basado en ssd moderno, será imperceptible. También se observa claramente el inicio del proceso de sincronización de datos del repositorio en un servidor remoto, la velocidad de funcionamiento es comparable a un rsync normal y está limitada por el rendimiento del sistema de discos del servidor de almacenamiento de copias de seguridad. Una desventaja de este enfoque es el almacenamiento de un repositorio local y, como consecuencia, la duplicación de datos.
El segundo enfoque, que consiste en iniciar zbackup directamente en el servidor de almacenamiento de copias de seguridad, es más interesante y aplicable en la práctica.
Primero, se comprobará el funcionamiento sin usar cifrado con el compresor lzma:
El tiempo de cada ejecución de prueba:
Ejecución 1
Ejecución 2
Ejecución 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Si se activa el cifrado utilizando aes, los resultados están bastante cerca:
El tiempo de ejecución con los mismos datos, con encriptación:
Ejecución 1
Ejecución 2
Ejecución 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Si se combina el cifrado con la compresión en lzo, queda así:
Tiempo de ejecución:
Ejecución 1
Ejecución 2
Ejecución 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
El tamaño del repositorio resultante fue relativamente constante, de 13 GB. Esto significa que la deduplicación está funcionando correctamente. Además, la aplicación de lzo en datos ya comprimidos tiene un efecto notable. En términos de tiempo total de ejecución, zbackup se aproxima a duplicity/duplicati, aunque todavía queda atrás de las basadas en librsync de 2 a 5 veces.
Las ventajas son evidentes: ahorro de espacio en disco en el servidor de almacenamiento de copias de seguridad. En cuanto a las herramientas para verificar el repositorio, el autor de zbackup no las ha previsto, se recomienda utilizar un conjunto de discos tolerante a fallos o un proveedor en la nube.
En general, la impresión es bastante buena, a pesar de que el proyecto ha estado estancado durante aproximadamente 3 años (la última solicitud de funciones fue hace alrededor de un año, pero sin respuesta).
Pruebas de borgbackup
Borgbackup es un fork de attic, otro sistema similar a zbackup. Está escrito en Python, tiene una lista de capacidades similar a la de zbackup, pero adicionalmente puede:
- Montar copias de seguridad a través de fuse
- Verificar el contenido del repositorio
- Trabajar en modo cliente-servidor
- Usar diferentes compresores para los datos, así como la detección heurística del tipo de archivo al comprimir.
- 2 opciones de cifrado, aes y blake
- Herramienta integrada para
comprobar el rendimiento
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Los resultados fueron los siguientes:
C-Z-BIG 96.51 MB/s (10 100.00 MB archivos en ceros: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB archivos en ceros: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB archivos en ceros: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB archivos en ceros: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB archivos aleatorios: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB archivos aleatorios: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB archivos aleatorios: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB archivos aleatorios: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB archivos en ceros: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB archivos en ceros: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB archivos en ceros: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB archivos en ceros: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB archivos aleatorios: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB archivos aleatorios: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB archivos aleatorios: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB archivos aleatorios: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB archivos todo ceros: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB archivos todo ceros: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB archivos todo ceros: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB archivos todo ceros: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB archivos aleatorios: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB archivos aleatorios: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB archivos aleatorios: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB archivos aleatorios: 5.32s)
Durante la prueba se utilizará heurística para la compresión con determinación del tipo de archivo (compresión automática), y los resultados serán los siguientes:
Primero probemos el funcionamiento sin cifrado:
Tiempo de ejecución:
Ejecución 1
Ejecución 2
Ejecución 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Si se activa la autorización del repositorio (modo autenticado), los resultados serán similares:
Tiempo de ejecución:
Ejecución 1
Ejecución 2
Ejecución 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Al activar el cifrado AES, los resultados no se deterioraron mucho:
Ejecución 1
Ejecución 2
Ejecución 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Y si cambiamos de AES a Blake, la situación mejora bastante:
Tiempo de ejecución:
Ejecución 1
Ejecución 2
Ejecución 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Al igual que en el caso de zbackup, el tamaño del repositorio fue de 13GB y un poco menos, lo que, en general, era de esperar. El tiempo de ejecución fue bastante alentador, comparándose con soluciones basadas en librsync, ofreciendo una gama mucho más amplia de posibilidades. También fue gratificante la capacidad de definir varios parámetros a través de variables de entorno, lo que brinda una ventaja significativa al usar borgbackup en modo automático. Además, la carga durante la copia de seguridad fue también sorprendente: según la carga del procesador, borgbackup trabaja en un solo thread.
No se encontraron desventajas significativas en su uso.
Pruebas de restic
A pesar de que restic es una solución bastante nueva (los primeros 2 candidatos fueron conocidos desde 2013 y anteriores), tiene características bastante buenas. Está escrito en Go.
Si lo comparamos con zbackup, ofrece adicionalmente:
- Verificación de la integridad del repositorio (incluida la verificación por partes).
- Una enorme lista de protocolos y proveedores compatibles para el almacenamiento de copias de seguridad, además de soporte para rclone: rsync para soluciones 'en la nube'.
- Comparación de 2 copias de seguridad entre sí.
- Montaje del repositorio a través de fuse.
En general, la lista de posibilidades es bastante similar a borgbackup, a veces más, a veces menos. Entre las peculiaridades está la falta de la opción de desactivar el cifrado, por lo tanto, las copias de seguridad siempre estarán cifradas. Veamos en la práctica qué se puede obtener de este software:
Los resultados fueron los siguientes:
Tiempo de ejecución:
Ejecución 1
Ejecución 2
Ejecución 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Los resultados también son comparables a las soluciones basadas en rsync y, en general, son bastante cercanos a borgbackup, pero la carga en el procesador es más alta (funcionando con múltiples hilos) y de forma escalonada.
Lo más probable es que el programa esté limitado por el rendimiento del subsistema de almacenamiento del servidor, como ya ocurría con rsync. El tamaño del repositorio fue de 13 GB, al igual que con zbackup o borgbackup, no se encontraron desventajas evidentes al utilizar esta solución.
Resultados
De hecho, todos los candidatos presentaron estadísticas cercanas, aunque con diferentes precios. Borgbackup se destacó por encima del resto, seguido de restic, mientras que zbackup probablemente no valga la pena aplicarlo.
Y si ya se está utilizando, deberías considerar cambiarlo por borgbackup o restic.
Conclusiones
La solución más prometedora parece ser restic, ya que ofrece la mejor relación entre capacidades y velocidad, pero aún no apresuremos conclusiones generales.
Borgbackup no es inferior, pero zbackup probablemente debería ser reemplazado. Sin embargo, para garantizar el cumplimiento de la regla 3-2-1, zbackup aún puede ser utilizado. Por ejemplo, como complemento a las herramientas de copia de seguridad basadas en (lib)rsync.
Anuncio
Copia de seguridad, parte 5: Prueba de bacula y veeam backup for linux
Copia de seguridad, parte 6: Comparación de herramientas de copia de seguridad
Copia de seguridad, parte 7: Conclusiones
Autor de la publicación: Pavel Demkovich
Fuente: habr.com
