Neste artigo, serão abordados os recursos de backup que realizam o armazenamento através da criação de arquivos em um servidor de backup.
Entre aqueles que atendem aos requisitos estão o duplicity (que possui uma interface agradável chamada deja dup) e o duplicati.
Outro recurso de backup notável é o dar, mas como ele possui uma lista extensa de opções — a metodologia de teste cobre no máximo 10% do que ele pode fazer — não o testaremos neste ciclo.
Resultados Esperados
Uma vez que ambos os candidatos criam arquivos, o tar convencional pode ser usado como referência.
Adicionalmente, avaliaremos como o armazenamento de dados no servidor de backup é otimizado, criando cópias de segurança que contêm apenas a diferença entre a cópia completa e o estado atual dos arquivos, ou entre arquivos de backup passados e atuais (incrementais, decrementais, etc.).
Comportamento ao criar backups:
- Um número relativamente pequeno de arquivos no servidor de backup (comparável ao número de backups ou ao tamanho dos dados em GB), mas com um tamanho bastante grande (dezenas a centenas de megabytes).
- O tamanho do repositório incluirá apenas as alterações — duplicatas não serão armazenadas, portanto, o tamanho do repositório será menor do que ao usar software baseado em rsync.
- Esperamos uma grande carga no processador ao usar compressão e/ou criptografia, além de provavelmente uma carga considerável na rede e na subsistema de disco, caso o processo de arquivamento e/ou criptografia ocorra no servidor de backup.
Como valor de referência, executaremos o seguinte comando:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Os resultados da execução foram:
O tempo de execução foi de 3m12s. É evidente que a velocidade foi limitada pela subsistema de disco do servidor de backup, assim como no exemplo com . Apenas um pouco mais rápido, pois a gravação se dá em um único arquivo.
Para avaliar a compressão, também executaremos a mesma variante, mas ativaremos a compressão no lado do servidor de backup:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Os resultados são os seguintes:
O tempo de execução foi de 10m11s. Provavelmente, o gargalo é o compressor de um único thread do lado receptor.
O mesmo comando, mas transferindo a compressão para o servidor com os dados fonte, para verificar a hipótese de que o gargalo é o compressor de um único thread.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"O resultado foi o seguinte:
O tempo de execução foi de 9m37s. É claramente visível a carga de um núcleo pelo compressor, já que a velocidade de transferência pela rede e a carga no subsistema de discos fonte são semelhantes.
Para avaliar a criptografia, pode-se usar openssl ou gpg, conectando um comando adicional openssl ou gpg no pipe. Para referência, o comando seria assim:
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 2 processos foram iniciados no lado receptor — o gargalo novamente é o compressor de um único thread, além de pequenas sobrecargas da criptografia.
UPD: Atendendo ao pedido de bliznezz, estou adicionando testes com pigz. Se usar apenas o compressor, o tempo foi de 6m30s, e se adicionar a criptografia — aproximadamente 7m. A queda no gráfico inferior é o cache de disco não descarregado:
Teste de duplicity
Duplicity é um software em python para backup criando arquivos criptografados no formato tar.
Para arquivos incrementais, usa-se librsync, portanto, pode-se esperar o comportamento descrito na .
Os backups podem ser criptografados e assinados com gnupg, o que é importante ao usar diferentes provedores para armazenamento de backups (s3, backblaze, gdrive, etc.)
Vamos ver quais serão os resultados:
Os resultados obtidos ao executar sem criptografia
spoiler
Tempo de execução de cada teste:
Execução 1
Execução 2
Execução 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
E aqui estão os resultados com a criptografia gnupg, com tamanho de chave de 2048 bits:
Tempo de execução com os mesmos dados, com criptografia:
Execução 1
Execução 2
Execução 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m35s
5m30s
Um tamanho de bloco de 512 megabytes foi especificado, o que é claramente visível nos gráficos; a carga da CPU manteve-se em cerca de 50%, o que significa que o programa não utiliza mais de um núcleo de processador.
Também se vê bem o princípio de funcionamento do programa: pegar um pedaço de dados, compactá-lo, enviá-lo para o servidor de backup, que pode ser consideravelmente lento.
Outra característica é 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 especialmente o tempo de execução do programa, mas elevou a carga da CPU em cerca de 10%, o que pode ser um bom bônus.
Infelizmente, este programa não conseguiu detectar corretamente a situação de renomeação do diretório, e o tamanho resultante do repositório foi igual ao tamanho das alterações (ou seja, todos os 18 GB), mas a possibilidade de usar um servidor não confiável para backup definitivamente supera esse comportamento.
Teste do duplicati
Este software é escrito em C#, e é executado utilizando uma coleção de bibliotecas do Mono. Há uma versão GUI, assim como uma versão CLI.
A lista aproximada das principais funcionalidades é semelhante à do duplicity, incluindo diversos provedores para armazenamento de backups, no entanto, ao contrário do duplicity, a maioria das funcionalidades está disponível sem ferramentas externas. Se isso é um ponto positivo ou negativo depende do caso específico, mas para iniciantes, provavelmente é mais fácil ter uma lista de todas as funcionalidades à vista do que instalar pacotes para python, como é o caso do duplicity.
Mais uma pequena nuance — o programa escreve ativamente um banco de dados sqlite local em nome do usuário que inicia o backup, portanto, é necessário acompanhar a indicação correta do banco necessário a cada execução do processo usando CLI. Ao operar pela GUI ou WEBGUI, os detalhes serão ocultados do usuário.
Vamos ver quais indicadores esta solução pode fornecer:
Se a criptografia for desativada (embora a WEBGUI não recomende isso), os resultados são os seguintes:
Tempo de execução:
Execução 1
Execução 2
Execução 3
20m43s
20m13s
20m28s
5m21s
5m35s
3m33s
7m36s
7m54s
7m49s
Com a criptografia ativada, utilizando aes, os resultados são:
Tempo de execução:
Execução 1
Execução 2
Execução 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
E se utilizar o programa externo gnupg, os resultados são os seguintes:
Execução 1
Execução 2
Execução 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m35s
8m12s
8m42s
8m15s
Como pode ser visto, o programa consegue operar em múltiplos threads, mas não se torna uma solução mais eficiente, e se compararmos a operação da criptografia — a execução do programa externo
resultou ser mais rápida do que a aplicação da biblioteca do conjunto Mono. Provavelmente, isso se deve ao fato de que o programa externo é mais otimizado.
Um aspecto positivo foi que o tamanho do repositório ocupou exatamente o que realmente foi alterado, ou seja, o Duplicati detectou a renomeação do diretório e tratou corretamente a situação. Isso pode ser visto na execução do segundo teste.
De modo geral, as impressões sobre o programa são bastante positivas, incluindo uma amigabilidade suficiente para iniciantes.
Resultados
Ambos os candidatos trabalharam de forma relativamente lenta, mas, em comparação com o tar convencional, há progresso, pelo menos no caso do Duplicati. O preço desse progresso também é claro — uma carga notável
no processador. No geral, não há desvios especiais na previsão dos resultados.
Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.
Se não houver pressa, e se houver capacidade no processador — qualquer uma das soluções consideradas será adequada. De qualquer forma, foi feito um trabalho considerável que não vale a pena repetir escrevendo scripts de envolvimento sobre o tar. A presença de criptografia é uma característica muito necessária se o servidor para armazenamento de backups não puder ser totalmente confiável.
Se comparado a soluções baseadas — o desempenho pode ser várias vezes pior, embora o tar puro tenha funcionado mais rápido que o rsync em 20-30%.
Há economia no tamanho do repositório, mas apenas no Duplicati.
Anúncio
Backup, parte 3: Revisão e teste do Duplicity, Duplicati, Deja Dup
Backup, parte 4: Visão geral e teste do zbackup, restic, borgbackup,
Backup, parte 5: Teste do bacula e veeam backup for linux
Backup, Parte 6: Comparação de ferramentas de backup
Backup, parte 7: Conclusões
Autor da publicação: Pavel Demkovich
Fonte: habr.com
