Este artigo discutirá as ferramentas de software de backup que, dividindo o fluxo de dados em componentes separados (partes), formam um repositório.
Além disso, os componentes do repositório podem ser compactados e criptografados e, o mais importante - com processos de backup repetidos - reutilizados novamente.
Um backup em um repositório semelhante é uma cadeia nomeada de componentes relacionados, por exemplo, com base em várias funções de hash.
Existem várias soluções semelhantes, vou me concentrar em 3: zbackup, borgbackup e restic.
Resultados esperados
Como todos os candidatos, de uma maneira ou de outra, exigem a criação de um repositório, um dos fatores mais importantes será a estimativa do tamanho do repositório. No caso ideal, 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 fazer backup de arquivos diretamente, sem usar arquivadores tar, além de trabalhar com ssh / sftp sem ferramentas adicionais, como rsync e sshfs.
Comportamento de backup:
- O tamanho do repositório será igual ao tamanho das alterações ou menos.
- Uma carga grande do processador é esperada ao usar compactação e / ou criptografia, e uma carga bastante grande na rede e no subsistema de disco é provável se o processo de arquivamento e / ou criptografia funcionar no servidor de armazenamento de backup.
- Se você danificar o repositório, é provável que ocorra um erro atrasado ao criar novos backups e ao tentar restaurar. É necessário planejar medidas adicionais para garantir a integridade do repositório ou usar os meios internos para verificar sua integridade.
O trabalho com alcatrão é aceito como um valor de referência, como foi mostrado em um dos artigos anteriores.
Teste de Zbackup
O mecanismo geral da operação zbackup é que o programa encontre áreas que contenham os mesmos dados no fluxo de dados fornecido na entrada, depois os comprima e criptografa opcionalmente, economizando cada área apenas 1 vez.
Para desduplicação, uma função de hash de anel de 64 bits com uma janela deslizante é usada para verificar se há coincidência com blocos de dados existentes (semelhante à maneira como é implementada no rsync).
Para compactação, lzma e lzo são usados na execução multithread e para criptografia - aes. Nas versões mais recentes, existe uma oportunidade no futuro de excluir dados antigos do repositório.
O programa é escrito em C ++ com dependências mínimas. O autor aparentemente foi inspirado pela maneira unix, então o programa recebe dados sobre stdin ao criar backups, fornecendo um fluxo de dados semelhante ao stdout ao restaurar. Assim, o zbackup pode ser usado como um bom "bloco" ao escrever suas próprias soluções de backup. Por exemplo, o autor do artigo, este programa é a principal ferramenta de backup para máquinas domésticas desde cerca de 2014.
Um alcatrão regular será usado como o fluxo de dados, a menos que indicado de outra forma.
Vamos ver quais serão os resultados:A verificação do trabalho foi realizada em 2 versões:
- um repositório é criado e o zbackup é iniciado no servidor com os dados de origem; 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 fornecidos através do pipe.
Os resultados da primeira opção foram os seguintes: 43m11s - ao usar um repositório não criptografado e um compressor lzma, 19m13s - ao substituir o compressor por lzo.
A carga no servidor com os dados de origem foi a seguinte (o exemplo com lzma é mostrado, com lzo havia aproximadamente a mesma imagem, mas a proporção de rsync era cerca de um quarto do tempo):
É claro que esse processo de backup é adequado apenas para alterações relativamente raras e pequenas. Também é altamente desejável limitar a operação do zbackup a 1 thread, caso contrário, haverá uma carga muito alta no processador, porque o programa é muito bom em trabalhar em vários threads. A carga do disco foi pequena, o que, em geral, com um subsistema de disco moderno baseado em ssd, não será perceptível. Você também pode ver claramente o início do processo de sincronização dos dados do repositório com um servidor remoto, a velocidade é comparável ao rsync comum e depende do desempenho do subsistema de disco do servidor de armazenamento de backup. A desvantagem da abordagem é o armazenamento do repositório local e, como conseqüência, a duplicação de dados.
Mais interessante e prática na prática é a segunda opção com a execução imediata do zbackup no servidor de armazenamento de backup.
Primeiro, verificaremos a operação sem usar criptografia com o compressor lzma:
O tempo de execução de cada execução de teste:
Se você ativar a criptografia usando aes, os resultados serão bem próximos:
Tempo de operação nos mesmos dados, com criptografia:
Se a criptografia for combinada com a compactação no lzo, será assim:
Tempo de trabalho:
O tamanho do repositório resultante era relativamente igual e totalizava 13 GB. Isso significa que a desduplicação está funcionando corretamente. Além disso, em dados já compactados, o uso de lzo fornece um efeito tangível; em termos de tempo total de operação, o zbackup se aproxima de duplicidade / duplicação; no entanto, fica 2-5 vezes mais atrasado que o baseado em librsync.
Os benefícios são óbvios - economizando espaço em disco no servidor de armazenamento de backup. Quanto às ferramentas para verificar o repositório - elas não são fornecidas pelo zbackup, é recomendável usar uma matriz de disco à prova de falhas ou um provedor de nuvem.
Em geral, uma impressão muito boa, apesar do projeto ter cerca de 3 anos (a última solicitação de recurso ocorreu há cerca de um ano, mas sem resposta).
Testando o borgbackup
Borgbackup é um garfo do sótão, outro sistema semelhante ao zbackup. Está escrito em python, possui uma lista de recursos semelhantes ao zbackup, mas também sabe como:
- Monte backups através de fusíveis
- Verifique o conteúdo do repositório
- Trabalhar no modo cliente-servidor
- Use vários compressores para dados, bem como a definição heurística do tipo de arquivo ao compactá-lo.
- 2 opções para criptografia, aes e blake
- Ferramenta integrada para
verificações de desempenhobenchmark borgbackup crud ssh: // servidor de backup / repo / path local_dir
Os resultados são os seguintes:
CZ-BIG 96,51 MB / s (10 100,00 MB de arquivos com zero: 10,36s)
RZ-BIG 57,22 MB / s (10 100,00 MB arquivos com zero: 17,48s)
UZ-BIG 253,63 MB / s (10 100,00 MB arquivos totalmente zero: 3,94s)
DZ-BIG 351,06 MB / s (10 100,00 MB arquivos totalmente zero: 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 100,00 MB de arquivos aleatórios: 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 100,00 MB de arquivos aleatórios: 13,77s)
CZ-MEDIUM 108,59 MB / s (1000 arquivos totalmente zero de 1,00 MB: 9,21s)
RZ-MEDIUM 76,16 MB / s (1000 arquivos totalmente zero de 1,00 MB: 13,13s)
UZ-MEDIUM 331,27 MB / s (1000 arquivos totalmente zero de 1,00 MB: 3,02s)
DZ-MEDIUM 387,36 MB / s (1000 arquivos totalmente zero de 1,00 MB: 2,58s)
CR-MEDIUM 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-MEDIUM 48,80 MB / s (1000 arquivos aleatórios de 1,00 MB: 20,49s)
CZ-SMALL 11,72 MB / s (10000 10,00 kB arquivos totalmente zero: 8,53s)
RZ-SMALL 32,57 MB / s (10000 arquivos de zero a 10,00 kB: 3,07s)
UZ-PEQUENO 19,37 MB / s (10000 10,00 kB arquivos totalmente zero: 5,16s)
DZ-SMALL 33,71 MB / s (10000 10,00 kB arquivos zero: 2,97s)
CR-SMALL 6,85 MB / s (10000 arquivos aleatórios de 10,00 kB: 14.60s)
RR-SMALL 31,27 MB / s (10000 arquivos aleatórios de 10,00 kB: 3,20s)
UR-PEQUENO 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, as heurísticas serão usadas na compactação com a definição do tipo de arquivo (compactação automática) e os resultados serão os seguintes:
Primeiro, verifique a operação sem criptografia:
Tempo de trabalho:
Se você ativar a autorização do repositório (modo autenticado), os resultados serão fechados:
Tempo de trabalho:
Quando a criptografia aes foi ativada, os resultados não se deterioraram muito:
E se você mudar aes para blake, a situação melhorará completamente:
Tempo de trabalho:
Como no caso do zbackup, o tamanho do repositório era de 13 GB e até um pouco menos, o que, em geral, é esperado. O tempo de trabalho foi muito satisfeito, é comparável a soluções baseadas em librsync, oferecendo possibilidades 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 satisfeito com a carga durante o backup: a julgar pela carga do processador - o borgbackup funciona em 1 thread.
Não houve desvantagens especiais ao usar.
Teste restic
Apesar de restic ser uma solução relativamente nova (os dois primeiros candidatos são conhecidos desde 2013 e anteriores), possui características muito boas. Escrito em Go.
Quando comparado com o zbackup, fornece adicionalmente:
- Verificando a integridade do repositório (incluindo partes de check-in).
- Uma enorme lista de protocolos e provedores suportados para armazenamento de backups, bem como suporte rclone - rsync para soluções em nuvem.
- Comparação de 2 backups entre si.
- Montagem do repositório via fusível.
Em geral, a lista de possibilidades está bem próxima do borgbackup, em alguns lugares mais, em alguns lugares menos. Dos recursos - a falta de capacidade de desativar a criptografia e, portanto, os backups sempre serão criptografados. Vamos ver na prática o que você pode extrair deste software:
Os resultados são os seguintes:
Tempo de trabalho:
Os resultados 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 do processador é maior (vários threads funcionam) e dente de serra.
Provavelmente, o programa depende do desempenho do subsistema de disco no servidor de armazenamento, como era no rsync. O tamanho do repositório era 13 GB, assim como zbackup ou borgbackup, não havia desvios óbvios ao usar esta solução.
Resultados
De fato, todos os candidatos obtiveram indicadores próximos, mas a um preço diferente. O Borgbackup mostrou-se o melhor, um pouco mais lento - restic, zbackup, provavelmente você não deve começar a aplicar,
e se já estiver em uso, tente mudar para borgbackup ou restic.
Conclusões
A solução mais promissora é restic, pois é ele quem tem a melhor proporção de capacidades em relação à velocidade, mas por enquanto não nos apressaremos em chegar a conclusões gerais.
Borgbackup, em princípio, não é pior, mas provavelmente é melhor substituir o zbackup. No entanto, para garantir que a regra 3-2-1 funcione, o zbackup ainda pode ser usado. Por exemplo, além de ferramentas de backup baseadas em (lib) rsync.
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
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