Este artigo considerará um software de backup que, ao dividir o fluxo de dados em componentes separados (pedaços), forma um repositório.
Os componentes do repositório podem ser ainda mais compactados e criptografados e, o mais importante - durante processos repetidos de backup - reutilizados.
Uma cópia de backup em tal repositório é uma cadeia nomeada de componentes conectados entre si, por exemplo, com base em várias funções hash.
Existem diversas soluções semelhantes, vou focar em 3: zbackup, borgbackup e restic.
Resultados Esperados
Como todos os candidatos exigem a criação de um repositório de uma forma ou de outra, um dos fatores mais importantes será estimar o tamanho do repositório. Idealmente, seu tamanho não deve ser superior a 13 GB de acordo com a metodologia aceita, ou até menos - sujeito a uma boa otimização.
Também é altamente desejável poder criar cópias de backup de arquivos diretamente, sem usar arquivadores como tar, bem 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 menos.
- É esperada uma carga pesada de CPU ao usar compactação e/ou criptografia, e é provável que haja uma carga bastante alta de rede e disco se o processo de arquivamento e/ou criptografia estiver sendo executado em um servidor de armazenamento de backup.
- Se o repositório estiver danificado, é provável que ocorra um erro atrasado tanto ao criar novos backups quanto ao tentar restaurar. É necessário planejar medidas adicionais para garantir a integridade do repositório ou utilizar ferramentas integradas para verificar sua integridade.
Trabalhar com tar é tomado como valor de referência, conforme mostrado em um dos artigos anteriores.
Testando zbackup
O mecanismo geral do zbackup é que o programa encontra no fluxo de dados de entrada áreas que contêm os mesmos dados e, opcionalmente, os compacta e criptografa, salvando cada área apenas uma vez.
A desduplicação usa uma função hash de anel de 64 bits com uma janela deslizante para verificar correspondências byte a byte em blocos de dados existentes (semelhante à forma como o rsync a implementa).
Lzma e lzo multithread são usados para compactação e aes para criptografia. As versões mais recentes têm a capacidade de excluir dados antigos do repositório no futuro.
O programa é escrito em C++ com dependências mínimas. O autor aparentemente se inspirou no unix-way, então o programa aceita dados no stdin ao criar backups, produzindo um fluxo de dados semelhante no stdout ao restaurar. Assim, o zbackup pode ser usado como um “bloco de construção” muito bom ao escrever suas próprias soluções de backup. Por exemplo, o autor do artigo utiliza este programa como principal ferramenta de backup para máquinas domésticas desde aproximadamente 2014.
O fluxo de dados será um tar regular, salvo indicação em contrário.
Vamos ver quais são os resultados:
O trabalho foi verificado em 2 opções:
- um repositório é criado e o zbackup é iniciado no servidor com os dados de origem e, em seguida, o conteúdo do repositório é transferido para o servidor de armazenamento de backup.
- um repositório é criado no servidor de armazenamento de backup, o zbackup é iniciado via ssh no servidor de armazenamento de backup e os dados são enviados a ele via pipe.
Os resultados da primeira opção 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 originais foi a seguinte (um exemplo com lzma é mostrado; com lzo havia aproximadamente a mesma imagem, mas a participação do rsync foi de cerca de um quarto do tempo):
É claro que esse processo de backup só é adequado para alterações pequenas e relativamente raras. Também é altamente recomendável limitar o zbackup a 1 thread, caso contrário haverá uma carga de CPU muito alta, porque O programa é muito bom para trabalhar em vários threads. A carga no disco era pequena, o que em geral não seria perceptível em um subsistema de disco moderno baseado em SSD. Você também pode ver claramente o início do processo de sincronização de dados do repositório com um servidor remoto; a velocidade de operação é comparável ao rsync normal e depende do desempenho do subsistema de disco do servidor de armazenamento de backup. A desvantagem desta abordagem é o armazenamento de um repositório local e, como resultado, a duplicação de dados.
Mais interessante e aplicável na prática é a segunda opção, executar o zbackup diretamente no servidor de armazenamento de backup.
Primeiro, verificaremos o funcionamento sem usar criptografia com o compressor lzma:
Tempo de execução de cada execução de teste:
Lançamento 1
Lançamento 2
Lançamento 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Se você ativar a criptografia usando aes, os resultados serão bem próximos:
Tempo de operação nos mesmos dados, com criptografia:
Lançamento 1
Lançamento 2
Lançamento 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Se a criptografia for combinada com a compactação usando lzo, ficará assim:
Horas:
Lançamento 1
Lançamento 2
Lançamento 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
O tamanho do repositório resultante foi relativamente o mesmo, 13 GB. Isso significa que a desduplicação está funcionando corretamente. Além disso, em dados já compactados, o uso de lzo produz um efeito perceptível; em termos de tempo total de operação, o zbackup chega perto da duplicidade/duplicação, mas fica 2 a 5 vezes atrás daqueles baseados em librsync.
As vantagens são óbvias: economia de espaço em disco no servidor de armazenamento de backup. Quanto às ferramentas de verificação de repositório, o autor do zbackup não as fornece; é recomendado usar uma matriz de disco tolerante a falhas ou um provedor de nuvem.
No geral, uma impressão muito boa, apesar do projeto estar parado há cerca de 3 anos (o último pedido de funcionalidade foi há cerca de um ano, mas sem resposta).
Testando borgbackup
Borgbackup é uma bifurcação do sótão, outro sistema semelhante ao zbackup. Escrito em python, possui uma lista de recursos semelhantes ao zbackup, mas também pode:
- Monte backups via fusível
- Verifique o conteúdo do repositório
- Trabalhe no modo cliente-servidor
- Use vários compressores de dados, bem como determinação heurística do tipo de arquivo ao compactá-los.
- 2 opções de criptografia, aes e blake
- Ferramenta integrada para
verificações de desempenho
benchmark borgbackup crud ssh://backup_server/repo/path local_dir
Os resultados foram os seguintes:
CZ-BIG 96.51 MB/s (10 Arquivos totalmente zero de 100.00 MB: 10.36s)
RZ-BIG 57.22 MB/s (10 Arquivos totalmente zero de 100.00 MB: 17.48s)
UZ-BIG 253.63 MB/s (10 Arquivos totalmente zero de 100.00 MB: 3.94s)
DZ-BIG 351.06 MB/s (10 Arquivos totalmente zero de 100.00 MB: 2.85s)
CR-BIG 34.30 MB/s (10 Arquivos aleatórios de 100.00 MB: 29.15s)
RR-BIG 60.69 MB/s (10 Arquivos aleatórios de 100.00 MB: 16.48s)
UR-BIG 311.06 MB/s (10 Arquivos aleatórios de 100.00 MB: 3.21s)
DR-BIG 72.63 MB/s (10 Arquivos aleatórios de 100.00 MB: 13.77s)
CZ-MÉDIO 108.59 MB/s (1000 Arquivos totalmente zero de 1.00 MB: 9.21s)
RZ-MÉDIO 76.16 MB/s (1000 Arquivos totalmente zero de 1.00 MB: 13.13s)
UZ-MÉDIO 331.27 MB/s (1000 Arquivos totalmente zero de 1.00 MB: 3.02s)
DZ-MÉDIO 387.36 MB/s (1000 Arquivos totalmente zero de 1.00 MB: 2.58s)
CR-MÉDIO 37.80 MB/s (1000 Arquivos aleatórios de 1.00 MB: 26.45s)
RR-MÉDIO 68.90 MB/s (1000 Arquivos aleatórios de 1.00 MB: 14.51s)
UR-MEDIUM 347.24 MB/s (1000 Arquivos aleatórios de 1.00 MB: 2.88s)
DR-MÉDIO 48.80 MB/s (1000 Arquivos aleatórios de 1.00 MB: 20.49s)
CZ-PEQUENO 11.72 MB/s (10000 Arquivos totalmente zero de 10.00 kB: 8.53s)
RZ-SMALL 32.57 MB/s (10000 Arquivos totalmente zero de 10.00 kB: 3.07s)
UZ-PEQUENO 19.37 MB/s (10000 Arquivos totalmente zero de 10.00 kB: 5.16s)
DZ-SMALL 33.71 MB/s (10000 Arquivos totalmente zero de 10.00 kB: 2.97s)
CR-SMALL 6.85 MB/s (10000 Arquivos aleatórios de 10.00 kB: 14.60s)
RR-PEQUENO 31.27 MB/s (10000 Arquivos aleatórios de 10.00 kB: 3.20s)
UR-SMALL 12.28 MB/s (10000 Arquivos aleatórios de 10.00 kB: 8.14s)
DR-SMALL 18.78 MB/s (10000 Arquivos aleatórios de 10.00 kB: 5.32s)
Durante o teste, a heurística de compactação será usada para determinar o tipo de arquivo (compactação automática) e os resultados serão os seguintes:
Primeiro, vamos verificar como funciona sem criptografia:
Horas:
Lançamento 1
Lançamento 2
Lançamento 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Se você habilitar a autorização do repositório (modo autenticado), os resultados serão próximos:
Horas:
Lançamento 1
Lançamento 2
Lançamento 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Quando a criptografia aes foi ativada, os resultados não pioraram muito:
Lançamento 1
Lançamento 2
Lançamento 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
E se você mudar aes para blake, a situação vai melhorar completamente:
Horas:
Lançamento 1
Lançamento 2
Lançamento 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Como no caso do zbackup, o tamanho do repositório era de 13 GB e até um pouco menos, o que geralmente é esperado. Fiquei muito satisfeito com o tempo de execução; é comparável a soluções baseadas em librsync, proporcionando capacidades muito mais amplas. Também fiquei satisfeito com a capacidade de definir vários parâmetros por meio de variáveis de ambiente, o que oferece uma vantagem muito séria ao usar o borgbackup no modo automático. Também fiquei satisfeito com a carga durante o backup: a julgar pela carga do processador, o borgbackup funciona em 1 thread.
Não houve desvantagens específicas ao usá-lo.
teste restic
Apesar de o Restic ser uma solução relativamente nova (os 2 primeiros candidatos eram conhecidos em 2013 e anteriores), tem características bastante boas. Escrito em Go.
Quando comparado com o zbackup, também oferece:
- Verificação da integridade do repositório (incluindo check-in de peças).
- Uma enorme lista de protocolos e provedores suportados para armazenamento de backups, bem como suporte para rclone - rsync para soluções em nuvem.
- Comparando 2 backups entre si.
- Montando o repositório via fusível.
Em geral, a lista de recursos é bastante próxima do borgbackup, em alguns lugares mais, em outros menos. Uma das características é que não há como desabilitar a criptografia e, portanto, as cópias de backup sempre serão criptografadas. Vamos ver na prática o que pode ser extraído deste software:
Os resultados foram os seguintes:
Horas:
Lançamento 1
Lançamento 2
Lançamento 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Os resultados de desempenho também são comparáveis aos de soluções baseadas em rsync e, em geral, muito próximos do borgbackup, mas a carga da CPU é maior (múltiplos threads em execução) e dente de serra.
Muito provavelmente, o programa é limitado pelo desempenho do subsistema de disco no servidor de armazenamento de dados, como já acontecia com o rsync. O tamanho do repositório era de 13 GB, assim como zbackup ou borgbackup, não houve desvantagens óbvias ao usar esta solução.
Descobertas
Na verdade, todos os candidatos obtiveram resultados semelhantes, mas a preços diferentes. O Borgbackup teve o melhor desempenho de todos, o Restic foi um pouco mais lento, provavelmente não vale a pena começar a usar o zbackup,
e se já estiver em uso, tente alterá-lo para borgbackup ou restic.
Descobertas
A solução mais promissora parece ser restrita, porque... é ele quem tem a melhor relação entre capacidades e velocidade operacional, mas não vamos nos apressar em tirar conclusões gerais por enquanto.
O Borgbackup basicamente não é pior, mas o zbackup provavelmente é melhor substituído. É verdade que o zbackup ainda pode ser usado para garantir que a regra 3-2-1 funcione. Por exemplo, além dos recursos de backup baseados em (lib)rsync.
Anúncio
Backup Parte 5: Testando bacula e backup veeam para linux
Backup Parte 6: Comparando ferramentas de backup
Backup Parte 7: Conclusões
Postado por: Pavel Demkovich
Fonte: habr.com