Backup, Parte 3: Visão geral e teste de duplicidade, duplicati

Este artigo descreve as ferramentas de backup que fazem backup criando arquivos em um servidor de backup.

Entre os que atendem aos requisitos, estão a duplicidade (para a qual existe uma interface agradável na forma de déjà dup) e duplicatas.

Outra ferramenta de backup bastante notável é a ousada, mas como possui uma lista muito extensa de opções - a metodologia de teste cobre quase 10% do que é capaz - não a estamos testando no ciclo atual.

Resultados esperados

Como os dois candidatos criam arquivos de uma maneira ou de outra, você pode usar o tar comum como orientação.

Além disso, avaliamos quão bem o armazenamento de dados no servidor de armazenamento é otimizado, criando backups contendo apenas a diferença entre a cópia completa e o estado atual dos arquivos, ou entre os arquivos antigos e atuais (incremental, decremental etc.).

Comportamento de backup:

1. Um número relativamente pequeno de arquivos no servidor de armazenamento de backup (comparável ao número de backups ou ao tamanho dos dados em GB), mas seu tamanho é bastante grande (dezenas a centenas de megabytes).
2. O tamanho do repositório incluirá apenas alterações - duplicatas não serão armazenadas, portanto, o tamanho do repositório será menor que o software baseado em rsync.
3. É esperada uma grande carga do processador ao usar compactação e / ou criptografia, bem como, provavelmente, uma carga suficientemente grande na rede e no subsistema de disco se o processo de arquivamento e / ou criptografia funcionar no servidor de armazenamento de backup.

Como valor de referência, execute o seguinte comando:

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

Os resultados da execução foram os seguintes:

Tempo de execução 3m12s. Pode-se observar que a velocidade descansou no subsistema de disco do servidor de armazenamento de backup, como no exemplo do rsync . Só um pouco mais rápido, porque registro vai para um arquivo.

Além disso, para avaliar a compactação, executaremos a mesma opção, mas habilitaremos a compactação no lado do servidor do backup:

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

Os resultados são os seguintes:

O prazo de entrega é 10m11s. Muito provavelmente, o gargalo é um compressor de rosca única no lado receptor.

O mesmo comando, mas com a transferência de compactação para o servidor com os dados de origem para testar a hipótese de que o gargalo é um compressor de thread único.

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

Aconteceu assim:

O prazo de entrega foi de 9m37s. A carga de um núcleo pelo compressor é claramente visível, como a velocidade de transmissão da rede e a carga no subsistema de disco da fonte são semelhantes.

Para avaliar a criptografia, você pode usar o openssl ou o gpg conectando o comando opcional openssl ou gpg ao canal. Para referência, haverá um comando:

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

Os resultados foram os seguintes:

O tempo de execução foi de 10m30s, pois dois processos foram lançados no lado de recebimento - o gargalo era novamente um compressor de rosca única, além de uma pequena sobrecarga de criptografia.

UPD: A pedido de bliznezz, adiciono testes com pigz. Se você usar apenas o compressor - por 6m30s, se você também adicionar criptografia - cerca de 7m. Falha no gráfico inferior é um cache de disco não alocado:

Testando duplicidade

Duplicity é um software de backup python, criando arquivos tar criptografados.

Para arquivos incrementais, o librsync é usado; portanto, você pode esperar o comportamento descrito na nota de loop anterior .

Os backups podem ser criptografados e assinados usando o gnupg, o que é importante ao usar vários provedores para armazenar backups (s3, backblaze, gdrive etc.)

Vamos ver quais serão os resultados:

O tamanho do bloco foi especificado - 512 megabytes, o que é claramente visível nos gráficos; a carga do processador, na verdade, é mantida no nível de 50%, o que significa que o programa não utiliza mais que um núcleo do processador.

O princípio de funcionamento do programa também é claramente visível: eles pegaram um dado, sacudiram-no, enviaram-no para o servidor de armazenamento de backup, o que pode ser bem lento.
Outro recurso é o tempo de execução previsível do programa, que depende apenas do tamanho dos dados alterados.

A ativação da criptografia não aumentou particularmente o tempo de execução do programa, mas aumentou a carga do processador em cerca de 10%, o que pode ser um bônus muito bom.

Infelizmente, este programa não conseguiu detectar corretamente a situação com a renomeação de diretório e o tamanho do repositório resultante acabou sendo igual ao tamanho das alterações (ou seja, todos os 18 GB), mas a capacidade de usar um servidor não confiável para backup definitivamente cobre esse comportamento.

Testando duplicatas

Este software é escrito em C #, é lançado usando um conjunto de bibliotecas da Mono. Existe uma GUI, bem como uma versão CLI.

Uma lista de amostra dos principais recursos está próxima da duplicidade, incluindo vários provedores de armazenamento de backup; no entanto, diferentemente da duplicidade, a maioria dos recursos está disponível sem ferramentas de terceiros. Mais ou menos - depende do caso específico; no entanto, para iniciantes, é mais fácil ter uma lista de todos os recursos de uma só vez antes de instalar os pacotes para python, como é o caso da duplicidade.

Outra pequena nuance é que o programa grava ativamente o banco de dados sqlite local em nome do usuário que inicia o backup; portanto, é necessário monitorar adicionalmente a indicação correta do banco de dados desejado sempre que o processo começar a usar o cli. Ao trabalhar com a GUI ou WEBGUI, os detalhes serão ocultos do usuário.

Como você pode ver, o programa pode funcionar em vários segmentos, mas essa não é uma solução mais produtiva e, se você comparar a criptografia, inicia um programa externo.
acabou sendo mais rápido do que usar a biblioteca do pacote Mono. Talvez isso se deva ao fato de o programa externo estar mais otimizado.

Um momento agradável também foi o fato de que o tamanho do repositório leva exatamente o mesmo que os dados reais foram alterados, ou seja, duplicati detectou uma renomeação de diretório e lidou corretamente com essa situação. Isso pode ser visto ao executar o segundo teste.

Em geral, uma impressão bastante positiva do programa, incluindo simpatia suficiente para iniciantes.

Resultados

Ambos os candidatos trabalharam bastante devagar, mas em geral, em comparação com o alcatrão usual, há progresso, pelo menos duplicatas. O preço desse progresso também é compreensível - um fardo perceptível
o processador. Em geral, não há desvios particulares na previsão dos resultados.

Conclusões

Se você não precisar se apressar em lugar algum, e também houver uma margem no processador, qualquer uma das soluções consideradas fará, em qualquer caso, muito trabalho foi feito, o que não deve ser repetido escrevendo scripts de wrapper sobre o tar. A presença de criptografia é uma propriedade muito necessária se o servidor para armazenar backups não puder ser totalmente confiável.

Comparado com as soluções baseadas em rsync , o desempenho pode ser várias vezes pior, apesar do fato de que, em sua forma pura, o tar trabalhou 20 a 30% mais rápido que o rsync.
Salvar no tamanho do repositório é, mas apenas para duplicatas.

Anúncio

Backup, parte 1: Por que você precisa de um backup, uma visão geral de métodos, tecnologias
Backup, Parte 2: Visão geral e teste das ferramentas de backup baseadas em rsync
Backup, Parte 3: Visão geral e teste de duplicidade, duplicati, deja dup
Backup, Parte 4: Visão geral e testes zbackup, restic, borgbackup
Backup, Parte 5: Testando o Bacula e o Veeam Backup para Linux
Backup: parte solicitada pelos leitores: revisão da AMANDA, UrBackup, BackupPC
Backup, Parte 6: Comparando ferramentas de backup
Backup Parte 7: Conclusões

Postado por Finnix