Este artigo considerará o software de copia de seguridade que, ao dividir o fluxo de datos en compoñentes separados (anacos), forma un repositorio.
Os compoñentes do repositorio pódense comprimir e cifrar aínda máis e, o máis importante, durante os procesos de copia de seguridade repetidos, reutilizalos.
Unha copia de seguridade deste repositorio é unha cadea de compoñentes denominados conectados entre si, por exemplo, baseados en varias funcións hash.
Hai varias solucións similares, centrareime en 3: zbackup, borgbackup e restic.
Resultados esperados
Dado que todos os solicitantes requiren a creación dun repositorio dun xeito ou doutro, un dos factores máis importantes será estimar o tamaño do repositorio. O ideal é que o seu tamaño non supere os 13 GB segundo a metodoloxía aceptada, ou incluso menos, suxeito a unha boa optimización.
Tamén é moi desexable poder crear copias de seguranza dos ficheiros directamente, sen usar arquivadores como tar, así como traballar con ssh/sftp sen ferramentas adicionais como rsync e sshfs.
Comportamento ao crear copias de seguridade:
- O tamaño do repositorio será igual ao tamaño dos cambios, ou menos.
- Espérase unha gran carga da CPU cando se usa a compresión e/ou o cifrado, e é probable que a rede e unha carga de disco bastante alta se o proceso de arquivo e/ou cifrado se executa nun servidor de almacenamento de copia de seguranza.
- Se o repositorio está danado, é probable que se produza un erro atrasado tanto ao crear novas copias de seguranza como ao tentar restauralo. É necesario planificar medidas adicionais para garantir a integridade do repositorio ou utilizar ferramentas integradas para comprobar a súa integridade.
Traballar con tar tómase como valor de referencia, como se amosou nun dos artigos anteriores.
Probando zbackup
O mecanismo xeral de zbackup é que o programa atopa nas áreas de fluxo de datos de entrada que conteñen os mesmos datos, logo comprime e encripta opcionalmente, gardando cada área só unha vez.
A deduplicación usa unha función hash de anel de 64 bits cunha ventá deslizante para comprobar se hai coincidencias byte a byte con bloques de datos existentes (semellante a como o implementa rsync).
Lzma e lzo multifíos úsanse para a compresión e aes para o cifrado. As últimas versións teñen a posibilidade de eliminar datos antigos do repositorio no futuro.
O programa está escrito en C++ con dependencias mínimas. Aparentemente, o autor inspirouse no modo Unix, polo que o programa acepta datos en stdin ao crear copias de seguridade, producindo un fluxo de datos similar en stdout ao restaurar. Así, zbackup pódese usar como un moi bo "bloque de construción" ao escribir as súas propias solucións de copia de seguridade. Por exemplo, o autor do artigo usou este programa como a principal ferramenta de copia de seguridade das máquinas domésticas desde aproximadamente 2014.
O fluxo de datos será un alquitrán normal a menos que se indique o contrario.
Vexamos cales son os resultados:
O traballo comprobouse en dúas opcións:
- créase un repositorio e lánzase zbackup no servidor cos datos de orixe, despois o contido do repositorio transfírese ao servidor de almacenamento de copia de seguridade.
- créase un repositorio no servidor de almacenamento de copia de seguranza, zbackup lánzase a través de ssh no servidor de almacenamento de copia de seguranza e os datos envíanse a el por canalización.
Os resultados da primeira opción foron os seguintes: 43m11s - ao usar un repositorio sen cifrar e o compresor lzma, 19m13s - ao substituír o compresor por lzo.
A carga no servidor cos datos orixinais foi a seguinte (móstrase un exemplo con lzma; con lzo había aproximadamente a mesma imaxe, pero a participación de rsync foi aproximadamente un cuarto do tempo):
Está claro que este proceso de copia de seguridade só é adecuado para cambios relativamente raros e pequenos. Tamén é moi recomendable limitar zbackup a 1 fío, se non, haberá unha carga de CPU moi alta, porque O programa é moi bo para traballar en varios fíos. A carga no disco era pequena, o que en xeral non se notaría cun subsistema de disco moderno baseado en ssd. Tamén pode ver claramente o inicio do proceso de sincronización de datos do repositorio cun servidor remoto; a velocidade de operación é comparable á rsync normal e depende do rendemento do subsistema de discos do servidor de almacenamento de copia de seguridade. A desvantaxe deste enfoque é o almacenamento dun repositorio local e, como resultado, a duplicación de datos.
Máis interesante e aplicable na práctica é a segunda opción, executar zbackup directamente no servidor de almacenamento de copia de seguridade.
En primeiro lugar, comprobaremos o funcionamento sen usar o cifrado co compresor lzma:
Tempo de execución de cada proba:
Lanzamento 1
Lanzamento 2
Lanzamento 3
39 min 45 s
40 min 20 s
40 min 3 s
7 min 36 s
8 min 3 s
7 min 48 s
15 min 35 s
15 min 48 s
15 min 38 s
Se activas o cifrado usando aes, os resultados están bastante próximos:
Tempo de funcionamento nos mesmos datos, con cifrado:
Lanzamento 1
Lanzamento 2
Lanzamento 3
43 min 40 s
44 min 12 s
44 min 3 s
8 min 3 s
8 min 15 s
8 min 12 s
15 min 0 s
15 min 40 s
15 min 25 s
Se o cifrado se combina coa compresión usando lzo, ten o seguinte aspecto:
Tempo:
Lanzamento 1
Lanzamento 2
Lanzamento 3
18 min 2 s
18 min 15 s
18 min 12 s
5 min 13 s
5 min 24 s
5 min 20 s
8 min 48 s
9 min 3 s
8 min 51 s
O tamaño do repositorio resultante era relativamente o mesmo con 13 GB. Isto significa que a deduplicación funciona correctamente. Ademais, en datos xa comprimidos, o uso de lzo dá un efecto notable; en termos de tempo de funcionamento total, zbackup achégase á duplicidade/duplicación, pero queda 2-5 veces por detrás dos baseados en librasync.
As vantaxes son obvias: aforrar espazo no disco no servidor de almacenamento de copia de seguridade. En canto ás ferramentas de verificación do repositorio, o autor de zbackup non as proporciona; recoméndase utilizar unha matriz de discos tolerante a fallos ou un provedor de nube.
En xeral, unha moi boa impresión, a pesar de que o proxecto leva uns 3 anos parado (a última solicitude de funcións foi hai aproximadamente un ano, pero sen resposta).
Probando borgbackup
Borgbackup é unha bifurcación do faiado, outro sistema similar ao zbackup. Escrito en Python, ten unha lista de capacidades similares a zbackup, pero ademais pode:
- Montar copias de seguridade mediante fusible
- Comproba o contido do repositorio
- Traballa en modo cliente-servidor
- Use varios compresores para os datos, así como a determinación heurística do tipo de ficheiro ao comprimilo.
- 2 opcións de cifrado, aes e blake
- Ferramenta integrada para
comprobacións de rendemento
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Os resultados foron os seguintes:
C-Z-BIG 96.51 MB/s (10 100.00 MB de ficheiros totalmente cero: 10.36 s)
R-Z-BIG 57.22 MB/s (10 100.00 MB de ficheiros totalmente cero: 17.48 s)
U-Z-BIG 253.63 MB/s (10 100.00 MB de ficheiros totalmente cero: 3.94 s)
D-Z-BIG 351.06 MB/s (10 100.00 MB de ficheiros totalmente cero: 2.85 s)
C-R-BIG 34.30 MB/s (10 100.00 MB de ficheiros aleatorios: 29.15 s)
R-R-BIG 60.69 MB/s (10 100.00 MB de ficheiros aleatorios: 16.48 s)
U-R-BIG 311.06 MB/s (10 100.00 MB de ficheiros aleatorios: 3.21 s)
D-R-BIG 72.63 MB/s (10 100.00 MB de ficheiros aleatorios: 13.77 s)
C-Z-MEDIO 108.59 MB/s (1000 1.00 MB de ficheiros totalmente cero: 9.21 s)
R-Z-MEDIO 76.16 MB/s (1000 1.00 MB de ficheiros totalmente cero: 13.13 s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB de ficheiros totalmente cero: 3.02 s)
D-Z-MEDIO 387.36 MB/s (1000 1.00 MB de ficheiros totalmente cero: 2.58 s)
C-R-MEDIO 37.80 MB/s (1000 1.00 MB de ficheiros aleatorios: 26.45 s)
R-R-MEDIO 68.90 MB/s (1000 1.00 MB de ficheiros aleatorios: 14.51 s)
U-R-MEDIO 347.24 MB/s (1000 1.00 MB de ficheiros aleatorios: 2.88 s)
D-R-MEDIO 48.80 MB/s (1000 1.00 MB de ficheiros aleatorios: 20.49 s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB ficheiros con cero: 8.53 s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB ficheiros con cero: 3.07 s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB ficheiros con cero: 5.16 s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB ficheiros con cero: 2.97 s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB ficheiros aleatorios: 14.60 s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB ficheiros aleatorios: 3.20 s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB ficheiros aleatorios: 8.14 s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB ficheiros aleatorios: 5.32 s)
Ao realizar a proba, utilizaranse as heurísticas de compresión para determinar o tipo de ficheiro (compresión automática) e os resultados serán os seguintes:
Primeiro, imos comprobar como funciona sen cifrado:
Tempo:
Lanzamento 1
Lanzamento 2
Lanzamento 3
4 min 6 s
4 min 10 s
4 min 5 s
56s
58s
54s
1 min 26 s
1 min 34 s
1 min 30 s
Se habilita a autorización do repositorio (modo autenticado), os resultados estarán próximos:
Tempo:
Lanzamento 1
Lanzamento 2
Lanzamento 3
4 min 11 s
4 min 20 s
4 min 12 s
1 min 0 s
1 min 3 s
1 min 2 s
1 min 30 s
1 min 34 s
1 min 31 s
Cando se activou o cifrado aes, os resultados non se deterioraron moito:
Lanzamento 1
Lanzamento 2
Lanzamento 3
4 min 55 s
5 min 2 s
4 min 58 s
1 min 0 s
1 min 2 s
1 min 0 s
1 min 49 s
1 min 50 s
1 min 50 s
E se cambias aes por blake, a situación mellorará completamente:
Tempo:
Lanzamento 1
Lanzamento 2
Lanzamento 3
4 min 33 s
4 min 43 s
4 min 40 s
59s
1 min 0 s
1 min 0 s
1 min 38 s
1 min 43 s
1 min 40 s
Do mesmo xeito que no caso de zbackup, o tamaño do repositorio era de 13 GB e incluso un pouco menos, o que en xeral se espera. Quedei moi satisfeito co tempo de execución; é comparable ás solucións baseadas en librarsync, que proporciona capacidades moito máis amplas. Tamén quedei satisfeito coa posibilidade de establecer varios parámetros a través de variables de ambiente, o que dá unha vantaxe moi importante ao usar borgbackup en modo automático. Tamén quedei satisfeito coa carga durante a copia de seguridade: a xulgar pola carga do procesador, borgbackup funciona en 1 fío.
Non houbo desvantaxes particulares ao usalo.
probas de resto
A pesar de que restic é unha solución bastante nova (os dous primeiros candidatos coñecíanse en 2 e anteriores), ten unhas características bastante boas. Escrito en Go.
En comparación con zbackup, ofrece ademais:
- Comprobación da integridade do repositorio (incluída a comprobación de partes).
- Unha enorme lista de protocolos e provedores compatibles para almacenar copias de seguridade, así como soporte para rclone - rsync para solucións na nube.
- Comparando 2 copias de seguridade entre si.
- Montaxe do repositorio mediante fusible.
En xeral, a lista de funcións está bastante próxima a borgbackup, nalgúns lugares máis, noutros menos. Unha das características é que non hai forma de desactivar o cifrado e, polo tanto, as copias de seguridade sempre estarán cifradas. Vexamos na práctica o que se pode eliminar deste software:
Os resultados foron os seguintes:
Tempo:
Lanzamento 1
Lanzamento 2
Lanzamento 3
5 min 25 s
5 min 50 s
5 min 38 s
35s
38s
36s
1 min 54 s
2 min 2 s
1 min 58 s
Os resultados de rendemento tamén son comparables ás solucións baseadas en rsync e, en xeral, moi próximos a borgbackup, pero a carga da CPU é maior (en execución de varios fíos) e dente de serra.
O máis probable é que o programa estea limitado polo rendemento do subsistema de disco no servidor de almacenamento de datos, como xa ocorreu con rsync. O tamaño do repositorio era de 13 GB, do mesmo xeito que zbackup ou borgbackup, non había desvantaxes obvias ao usar esta solución.
Descubrimentos
De feito, todos os candidatos lograron resultados similares, pero a prezos diferentes. Borgbackup funcionou o mellor de todo, restic foi un pouco máis lento, zbackup probablemente non valga a pena comezar a usar,
e se xa está en uso, proba cambialo a borgbackup ou restic.
Descubrimentos
A solución máis prometedora parece ser a restía, porque... é el quen ten a mellor relación entre capacidades e velocidade de funcionamento, pero non nos apresuremos a sacar conclusións xerais polo momento.
Borgbackup basicamente non é peor, pero zbackup probablemente sexa mellor substituído. É certo que zbackup aínda se pode usar para garantir que a regra 3-2-1 funcione. Por exemplo, ademais das instalacións de copia de seguridade baseadas en (lib)rsync.
Anuncio
Copia de seguranza Parte 5: probando a copia de seguridade de bacula e veeam para Linux
Copia de seguranza Parte 6: Comparación de ferramentas de copia de seguranza
Copia de seguridade Parte 7: Conclusións
Publicado por: Pavel Demkovich
Fonte: www.habr.com