Neste artigo, serão discutidos os softwares para backup que, ao dividir o fluxo de dados em componentes individuais (chunks), formam um repositório.
Os componentes do repositório podem ser comprimidos e criptografados adicionalmente, e o mais importante — em processos repetidos de backup — podem ser reutilizados.
Um backup em tal repositório é uma sequência nomeada de componentes inter-relacionados, por exemplo, com base em diferentes funções hash.
Existem várias soluções semelhantes, e vou me concentrar em 3: zbackup, borgbackup e restic.
Resultados Esperados
Uma vez que todos os candidatos, de uma forma ou de outra, exigem a criação de um repositório, um dos fatores mais importantes será a avaliação do tamanho do repositório. Idealmente, seu tamanho não deve ultrapassar 13 GB de acordo com a metodologia adotada, e até menos — com uma boa otimização.
Além disso, é extremamente desejável ter a capacidade de criar backups de arquivos diretamente, sem o uso de arquivadores como o tar, assim como trabalhar com ssh/sftp sem ferramentas adicionais como rsync e sshfs.
Comportamento ao criar backups:
- O tamanho do repositório será igual ao tamanho das alterações, ou menor.
- Esperamos uma grande carga no processador ao usar compressão e/ou criptografia, além de uma carga significativa na rede e no subsistema de disco, caso o processo de arquivamento e/ou criptografia ocorra no servidor de armazenamento de backups.
- Se o repositório for corrompido, um erro latente pode ocorrer tanto ao criar novos backups quanto ao tentar restaurá-los. É necessário planejar medidas adicionais para garantir a integridade do repositório, ou usar ferramentas integradas para verificar sua integridade.
Como referência, foi adotado o trabalho com tar, como foi demonstrado em um dos artigos anteriores.
Testando zbackup
O mecanismo geral de funcionamento do zbackup é que o programa encontra no fluxo de dados fornecido áreas que contêm dados idênticos, opcionalmente comprime, criptografa, mantendo cada área apenas uma vez.
Para deduplicação, utiliza-se uma função hash de 64 bits com janela deslizante para verificação byte a byte da correspondência com blocos de dados já existentes (semelhante ao que é realizado no rsync).
Para compressão, são aplicados lzma e lzo em execução multithread, e para criptografia — aes. Nas versões mais recentes, há a possibilidade de remover dados antigos do repositório no futuro.
O programa é escrito em C++ com dependências mínimas. O autor aparentemente se inspirou na filosofia unix-way, portanto, o programa aceita dados via stdin ao criar backups, emitindo um fluxo de dados semelhante via stdout durante a recuperação. Assim, o zbackup pode ser usado como uma excelente "ferramenta" ao desenvolver soluções de backup próprias. Por exemplo, para o autor deste artigo, este programa tem sido o principal meio de backup para máquinas domésticas desde aproximadamente 2014.
Como fluxo de dados, será utilizado o tar comum, a menos que indicado de outra forma.
Vamos ver quais serão os resultados:
A verificação do funcionamento foi realizada em 2 variantes:
- é criado um repositório e o zbackup é iniciado no servidor com os dados de origem, depois o conteúdo do repositório é transferido para o servidor de armazenamento de backups.
- é criado um repositório no servidor de armazenamento de backups, o zbackup é iniciado via ssh no servidor de armazenamento de backups, recebendo os dados através de pipe.
Os resultados da primeira variante foram os seguintes: 43m11s — ao usar um repositório não criptografado e o compressor lzma, 19m13s — ao substituir o compressor por lzo.
A carga no servidor com os dados de origem foi a seguinte (mostramos um exemplo com lzma, com lzo foi uma imagem semelhante, mas a parte do rsync foi aproximadamente um quarto do tempo):
É claro que tal processo de backup é apropriado apenas para mudanças relativamente raras e pequenas. Além disso, é extremamente desejável limitar o funcionamento do zbackup a 1 thread; caso contrário, haverá uma carga bastante alta no processador, uma vez que o programa consegue trabalhar muito bem em múltiplas threads. A carga no disco foi baixa, o que no geral, dado o subsistema de disco moderno baseado em ssd, será imperceptível. Também é claramente visível o início do processo de sincronização de dados do repositório para o servidor remoto, e a velocidade de operação é comparável ao rsync comum, estando restrita pela performance do subsistema de disco do servidor de armazenamento de backups. A desvantagem desse método é o armazenamento do repositório local e, como consequência, a duplicação de dados.
A segunda opção, que envolve executar o zbackup diretamente no servidor de armazenamento de backups, é mais interessante e aplicável na prática.
Para começar, será verificado o funcionamento sem o uso de criptografia com o compressor lzma:
Tempo de execução de cada teste:
Execução 1
Execução 2
Execução 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Se a criptografia utilizando aes for ativada, os resultados são bastante próximos:
Tempo de execução com os mesmos dados, com criptografia:
Execução 1
Execução 2
Execução 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Se a criptografia for combinada com a compressão lzo, os resultados são:
Tempo de execução:
Execução 1
Execução 2
Execução 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
O tamanho do repositório resultante foi relativamente igual e totalizou 13GB. Isso significa que a deduplicação está funcionando corretamente. Além disso, aplicar lzo em dados já comprimidos proporciona um efeito significativo, fazendo com que o tempo total de execução do zbackup se aproxime do duplicity/duplicati, embora fique atrás dos baseados em librsync de 2 a 5 vezes.
As vantagens são claras — economia de espaço em disco no servidor de armazenamento de backups. Quanto às ferramentas de verificação do repositório — não estão previstas pelo autor do zbackup, sendo recomendado o uso de um arranjo de disco redundante ou provedor de nuvem.
No geral, uma impressão bastante boa, apesar de o projeto estar estagnado há cerca de 3 anos (o último pedido de funcionalidade foi há cerca de um ano, mas sem resposta).
Testando borgbackup
O Borgbackup é um fork do attic, outro sistema semelhante ao zbackup. Escrito em python, possui uma lista de funcionalidades semelhante à do zbackup, mas também tem a capacidade de:
Montar backups via fuse
- Verificar o conteúdo do repositório
- Operar no modo cliente-servidor
- Usar diferentes compressores para os dados, assim como a determinação heurística do tipo de arquivo durante a sua compressão.
- 2 opções de criptografia, aes e blake
- Ferramenta incorporada para
- verificação de desempenho
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Os resultados foram os seguintes:
C-Z-BIG 96.51 MB/s (10
100.00 MB arquivos todos zero: 10.36s) R-Z-BIG 57.22 MB/s (10
100.00 MB arquivos todos zero: 17.48s) U-Z-BIG 253.63 MB/s (10
100.00 MB arquivos todos zero: 3.94s) D-Z-BIG 351.06 MB/s (10
100.00 MB arquivos todos zero: 2.85s) C-R-BIG 34.30 MB/s (10
100.00 MB arquivos aleatórios: 29.15s) R-R-BIG 60.69 MB/s (10
100.00 MB arquivos aleatórios: 16.48s) U-R-BIG 311.06 MB/s (10
100.00 MB arquivos aleatórios: 3.21s) D-R-BIG 72.63 MB/s (10
100.00 MB arquivos aleatórios: 13.77s) C-Z-MEDIUM 108.59 MB/s (1000
1.00 MB arquivos todos zero: 9.21s) R-Z-MEDIUM 76.16 MB/s (1000
1.00 MB arquivos todos zero: 13.13s) U-Z-MEDIUM 331.27 MB/s (1000
1.00 MB arquivos todos zero: 3.02s) D-Z-MEDIUM 387.36 MB/s (1000
1.00 MB arquivos todos zero: 2.58s) C-R-MEDIUM 37.80 MB/s (1000
C-R-MEDIUM 37,80 MB/s (1000 1,00 MB arquivos aleatórios: 26,45s)
R-R-MEDIUM 68,90 MB/s (1000 1,00 MB arquivos aleatórios: 14,51s)
U-R-MEDIUM 347,24 MB/s (1000 1,00 MB arquivos aleatórios: 2,88s)
D-R-MEDIUM 48,80 MB/s (1000 1,00 MB arquivos aleatórios: 20,49s)
C-Z-SMALL 11,72 MB/s (10000 10,00 kB arquivos todos zero: 8,53s)
R-Z-SMALL 32,57 MB/s (10000 10,00 kB arquivos todos zero: 3,07s)
U-Z-SMALL 19,37 MB/s (10000 10,00 kB arquivos todos zero: 5,16s)
D-Z-SMALL 33,71 MB/s (10000 10,00 kB arquivos todos zero: 2,97s)
C-R-SMALL 6,85 MB/s (10000 10,00 kB arquivos aleatórios: 14,60s)
R-R-SMALL 31,27 MB/s (10000 10,00 kB arquivos aleatórios: 3,20s)
U-R-SMALL 12,28 MB/s (10000 10,00 kB arquivos aleatórios: 8,14s)
D-R-SMALL 18,78 MB/s (10000 10,00 kB arquivos aleatórios: 5,32s)
A heurística será utilizada para compressão detectando o tipo de arquivo (compressão automática), e os resultados serão:
Primeiro, vamos verificar o funcionamento sem criptografia:
Tempo de execução:
Execução 1
Execução 2
Execução 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Se a autorização do repositório for ativada (modo autenticado), os resultados se aproximarão:
Tempo de execução:
Execução 1
Execução 2
Execução 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Com a ativação da criptografia AES, os resultados não pioraram muito:
Execução 1
Execução 2
Execução 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Se trocar AES por Blake, a situação melhora:
Tempo de execução:
Execução 1
Execução 2
Execução 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Assim como no caso do zbackup, o tamanho do repositório foi de 13 GB ou até um pouco menos, o que era esperado. O tempo de operação foi bastante satisfatório, sendo comparável a soluções baseadas em librsync, oferecendo recursos muito mais amplos. Também foi um ponto positivo a possibilidade de definir diferentes parâmetros via variáveis de ambiente, o que proporciona uma vantagem significativa ao usar o borgbackup em modo automático. O impacto na carga durante o backup foi também satisfatório: usando a carga da CPU como indicador — o borgbackup opera em 1 thread.
Não foram encontrados problemas significativos durante o uso.
Testando o restic
Apesar de o restic ser uma solução relativamente nova (os primeiros 2 candidatos eram conhecidos desde 2013 ou antes), ele tem características bastante razoáveis. Foi escrito em Go.
Se compararmos com o zbackup, ele oferece também:
- Verificação da integridade do repositório (incluindo verificações por partes).
- Uma enorme lista de protocolos e provedores suportados para armazenamento de backups, além de suporte ao rclone — rsync para soluções "em nuvem".
- Comparação de 2 backups entre si.
- Montagem do repositório através do fuse.
De modo geral, a lista de recursos é bastante semelhante à do borgbackup, em alguns aspectos mais rica, em outros menos. Uma característica é a impossibilidade de desativar a criptografia, portanto, os backups estarão sempre criptografados. Vamos ver na prática o que podemos extrair deste software:
Os resultados foram os seguintes:
Tempo de execução:
Execução 1
Execução 2
Execução 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Os resultados do trabalho também são comparáveis às soluções baseadas em rsync e, em geral, estão muito próximos do borgbackup, mas a carga na CPU é mais alta (opera com várias threads) e apresentou variações.
É provável que o programa dependa da performance do subsistema de disco no servidor de armazenamento, como já ocorreu com rsync. O tamanho do repositório foi de 13GB, assim como no zbackup ou borgbackup, não foram detectadas desvantagens claras ao usar esta solução.
Resultados
Na prática, todos os candidatos apresentaram resultados próximos, mas com preços diferentes. O borgbackup se saiu melhor, um pouco mais lento foi o restic, e o zbackup provavelmente não vale a pena ser implementado,
e se já estiver em uso, vale a pena testar a migração para borgbackup ou restic.
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.
A solução mais promissora parece ser o restic, pois possui a melhor relação entre recursos e velocidade de operação, mas ainda não vamos apressar nossas conclusões gerais.
O Borgbackup, na verdade, não é inferior, mas o zbackup provavelmente deve ser substituído. Contudo, para garantir o funcionamento da regra 3-2-1, o zbackup ainda pode ser utilizado. Por exemplo, em adição às soluções de backup baseadas em (lib)rsync.
Anúncio
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
