Parte de copia de seguranza 3: revisión e proba de duplicidade, duplicación

Esta nota trata das ferramentas de copia de seguridade que realizan copias de seguridade creando arquivos nun servidor de copia de seguridade.

Entre os que cumpren os requisitos están a duplicidade (que ten unha bonita interface en forma de deja dup) e duplicati.

Outra ferramenta de copia de seguridade moi destacable é dar, pero como ten unha lista moi extensa de opcións -a metodoloxía de proba apenas cobre o 10% do que é capaz- non a estamos probando como parte do ciclo actual.

Resultados esperados

Dado que ambos os candidatos crean arquivos dun xeito ou doutro, pódese usar tar regular como guía.

Ademais, avaliaremos como se optimiza o almacenamento de datos no servidor de almacenamento creando copias de seguridade que conteñan só a diferenza entre unha copia completa e o estado actual dos ficheiros, ou entre os arquivos anteriores e actuais (incrementais, decrecentes, etc.) .

Comportamento ao crear copias de seguridade:

1. Un número relativamente pequeno de ficheiros no servidor de almacenamento de copia de seguridade (comparable ao número de copias de seguridade ou ao tamaño dos datos en GB), pero o seu tamaño é bastante grande (decenas a centos de megabytes).
2. O tamaño do repositorio só incluirá cambios; non se almacenarán duplicados, polo que o tamaño do repositorio será menor que co software baseado en rsync.
3. Espere unha gran carga da CPU cando se use compresión e/ou cifrado, e probablemente unha carga de rede e disco bastante alta se o proceso de arquivo e/ou cifrado se está a executar nun servidor de almacenamento de copia de seguranza.

Imos executar o seguinte comando como valor de referencia:

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

Os resultados da execución foron os seguintes:

Tempo de execución 3m12s. Pódese ver que a velocidade está limitada polo subsistema de discos do servidor de almacenamento de copia de seguridade, como no exemplo con rsync. Só un pouco máis rápido, porque... a gravación vai a un ficheiro.

Ademais, para avaliar a compresión, executemos a mesma opción, pero habilite a compresión no lado do servidor de copia de seguridade:

cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"

Os resultados son:

Tempo de execución 10m11s. O máis probable é que o pescozo de botella sexa o compresor de fluxo único no extremo receptor.

O mesmo comando, pero con compresión transferida ao servidor cos datos orixinais para probar a hipótese de que o pescozo de botella é un compresor dun só fío.

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

Resultou así:

O tempo de execución foi de 9m37s. A carga nun núcleo polo compresor é claramente visible, porque A velocidade de transferencia de rede e a carga no subsistema do disco de orixe son similares.

Para avaliar o cifrado, pode usar openssl ou gpg conectando un comando adicional openssl ou gpg en tubo. Como referencia, haberá un comando coma este:

cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"

Os resultados saíron así:

O tempo de execución resultou ser de 10 minutos e 30 segundos, xa que 2 procesos estaban en execución no lado receptor: o pescozo de botella é de novo un compresor de fío único e unha pequena sobrecarga de cifrado.

ACTUALIZACIÓN: A petición de bliznezz estou engadindo probas con pigz. Se usas só o compresor, levaría 6m30s, se tamén engades cifrado, serían uns 7m. A caída no gráfico inferior é unha caché de disco sen vaciar:

Proba duplicada

Duplicity é un software Python para facer copias de seguridade mediante a creación de arquivos cifrados en formato tar.

Para os arquivos incrementais, utilízase librsync, polo que pode esperar o comportamento descrito en publicación anterior da serie.

As copias de seguranza pódense cifrar e asinar mediante gnupg, o que é importante cando se usan diferentes provedores para almacenar copias de seguridade (s3, backblaze, gdrive, etc.)

Vexamos cales son os resultados:

Estes son os resultados que obtivemos ao executar sen cifrado

spoiler

Tempo de execución de cada proba:

Lanzamento 1
Lanzamento 2
Lanzamento 3

16 min 33 s
17 min 20 s
16 min 30 s

8 min 29 s
9 min 3 s
8 min 45 s

5 min 21 s
6 min 04 s
5 min 53 s

E aquí están os resultados cando o cifrado gnupg está activado, cun tamaño de chave de 2048 bits:

Tempo de funcionamento nos mesmos datos, con cifrado:

Lanzamento 1
Lanzamento 2
Lanzamento 3

17 min 22 s
17 min 32 s
17 min 28 s

8 min 52 s
9 min 13 s
9 min 3 s

5 min 48 s
5 min 40 s
5 min 30 s

Indicou o tamaño do bloque: 512 megabytes, que é claramente visible nos gráficos; A carga do procesador mantívose no 50%, o que significa que o programa non utiliza máis que un núcleo de procesador.

O principio de funcionamento do programa tamén é claramente visible: tomaron un anaco de datos, comprimiuno e enviárono a un servidor de almacenamento de copia de seguridade, o que pode ser bastante lento.
Outra característica é o tempo de execución previsible do programa, que depende só do tamaño dos datos modificados.

A habilitación do cifrado non aumentou significativamente o tempo de execución do programa, pero aumentou a carga do procesador nun 10%, o que pode ser un bo extra.

Desafortunadamente, este programa non puido detectar correctamente a situación co cambio de nome do directorio, e o tamaño do repositorio resultante resultou ser igual ao tamaño dos cambios (é dicir, todos os 18 GB), pero a posibilidade de usar un servidor non fiable para a copia de seguranza claramente cobre este comportamento.

Proba duplicada

Este software está escrito en C# e execútase usando un conxunto de bibliotecas de Mono. Hai unha GUI e unha versión CLI.

A lista aproximada das principais características é semellante á duplicidade, incluíndo varios provedores de almacenamento de copia de seguridade, pero, a diferenza da duplicidade, a maioría das funcións están dispoñibles sen ferramentas de terceiros. Se isto é un plus ou un menos depende do caso específico, pero para os principiantes, o máis probable é que sexa máis fácil ter unha lista de todas as funcións á vez, en lugar de ter que instalar paquetes adicionalmente para Python, como é o caso. o caso da duplicidade.

Outro pequeno matiz: o programa escribe activamente unha base de datos sqlite local en nome do usuario que inicia a copia de seguridade, polo que cómpre asegurarse ademais de que a base de datos necesaria se especifique correctamente cada vez que se inicie o proceso usando o cli. Cando se traballe a través da GUI ou WEBGUI, os detalles ocultaranse ao usuario.

Vexamos que indicadores pode producir esta solución:

Se desactivas o cifrado (e WEBGUI non recomenda facelo), os resultados son os seguintes:

Tempo:

Lanzamento 1
Lanzamento 2
Lanzamento 3

20 min 43 s
20 min 13 s
20 min 28 s

5 min 21 s
5 min 40 s
5 min 35 s

7 min 36 s
7 min 54 s
7 min 49 s

Co cifrado activado, usando aes, ten o seguinte aspecto:

Tempo:

Lanzamento 1
Lanzamento 2
Lanzamento 3

29 min 9 s
30 min 1 s
29 min 54 s

5 min 29 s
6 min 2 s
5 min 54 s

8 min 44 s
9 min 12 s
9 min 1 s

E se usas o programa externo gnupg, saen os seguintes resultados:

Lanzamento 1
Lanzamento 2
Lanzamento 3

26 min 6 s
26 min 35 s
26 min 17 s

5 min 20 s
5 min 48 s
5 min 40 s

8 min 12 s
8 min 42 s
8 min 15 s

Como podes ver, o programa pode funcionar en varios fíos, pero isto non o converte nunha solución máis produtiva e, se comparas o traballo de cifrado, está a lanzar un programa externo.
resultou ser máis rápido que usar a biblioteca do conxunto Mono. Isto pode deberse a que o programa externo está máis optimizado.

Outra cousa agradable foi o feito de que o tamaño do repositorio ocupa exactamente tanto como os datos reais modificados, é dicir. duplicati detectou un cambio de nome do directorio e xestionou esta situación correctamente. Isto pódese ver ao executar a segunda proba.

En xeral, impresións bastante positivas do programa, incluíndo ser bastante amigable cos novatos.

Descubrimentos

Ambos os candidatos traballaron bastante lentamente, pero en xeral, en comparación co alcatrán normal, hai progreso, polo menos con duplicati. O prezo deste progreso tamén está claro: unha carga notable
procesador. En xeral, non hai desviacións especiais na predicción dos resultados.

Descubrimentos

Se non precisa correr a ningún lado, e ademais dispón dun procesador de reposto, calquera das solucións consideradas fará, en todo caso, que se fixo bastante traballo que non se debe repetir escribindo scripts de envoltura enriba de tar . A presenza de cifrado é unha propiedade moi necesaria se non se pode confiar totalmente no servidor para almacenar copias de seguridade.

En comparación con solucións baseadas rsync - O rendemento pode ser varias veces peor, a pesar de que na súa forma pura o alquitrán funcionou un 20-30% máis rápido que rsync.
Hai aforros no tamaño do repositorio, pero só con duplicati.

Anuncio

Copia de seguranza, parte 1: Por que é necesaria a copia de seguridade, unha visión xeral dos métodos e tecnoloxías
Parte 2 da copia de seguranza: revisión e proba de ferramentas de copia de seguridade baseadas en rsync
Parte de copia de seguranza 3: revisión e proba de duplicidade, duplicación, dup
Parte 4 da copia de seguranza: revisión e proba de zbackup, restic e borgbackup
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