Este artigo fará uma comparação de ferramentas de backup, mas primeiro é importante entender como elas lidam rapidamente e de forma eficaz com a recuperação de dados a partir de backups.
Para simplificar a comparação, será considerado a recuperação de um backup completo, uma vez que esse modo de operação é suportado por todos os candidatos. Para facilitar, os números foram tomados como médias (média aritmética de várias execuções). Os resultados serão apresentados em uma tabela, que também incluirá informações sobre as funcionalidades: presença de interface web, facilidade de configuração e uso, capacidade de automação, presença de várias funcionalidades adicionais (como verificação de integridade dos dados), etc. Gráficos mostrarão a carga do servidor onde os dados serão aplicados (não o servidor para armazenamento de backups).
Recuperação de dados
Como ponto de referência serão utilizados rsync e tar, uma vez que scripts simples para realizar backups.
O Rsync concluiu o conjunto de dados de teste em 4 minutos e 28 segundos, apresentando
essa carga
O processo de recuperação esbarrou na limitação do subsistema de disco do servidor de armazenamento de backups (gráficos em formato de dente de serra). Também é claramente visível a carga em um núcleo sem grandes problemas (iowait baixo e softirq — sem problemas com disco e rede, respectivamente). Como os outros dois programas, ou seja, rdiff-backup e rsnapshot, são baseados no rsync e também oferecem o rsync comum como meio de recuperação, eles terão um perfil de carga semelhante e tempo de recuperação de backup.
O Tar concluiu um pouco mais rápido, em
2 minutos e 43 segundos:
A carga total do sistema foi em média 20% maior devido ao aumento do softirq — as sobrecargas aumentaram ao trabalhar com o subsistema de rede.
Se o arquivo for compactado adicionalmente, o tempo de recuperação aumenta para 3 minutos e 19 segundos com
essa carga no servidor principal (descompactação no lado do servidor principal):
O processo de descompactação ocupa ambos os núcleos do processador, pois dois processos estão em execução. No geral, é um resultado esperado. Um resultado semelhante (3 minutos e 20 segundos) foi obtido ao executar gzip no lado do servidor com backups, o perfil de carga no servidor principal foi bastante similar ao da execução de tar sem o compressor gzip (veja o gráfico anterior).
Em rdiff-backup é possível sincronizar o último backup realizado usando o rsync comum (os resultados serão semelhantes), mas backups mais antigos ainda precisam ser restaurados com o programa rdiff-backup, que conseguiu a restauração em 17 minutos e 17 segundos, mostrando
tal carga:
Pode ser que essa tenha sido a intenção, de qualquer forma, para limitar a velocidade os autores . O próprio processo de restauração do backup leva um pouco menos da metade de um núcleo, com desempenho proporcionalmente comparável (ou seja, de 2 a 5 vezes mais lento) em disco e rede com rsync.
Rsnapshot para a restauração propõe usar o rsync comum, então seus resultados serão semelhantes. No geral, foi exatamente assim que aconteceu.
Burp resolveu a tarefa de restauração do backup em 7 minutos e 2 segundos com
tal carga:
Funcionou bastante rápido e, pelo menos, é muito mais conveniente do que o rsync puro: não é preciso lembrar de nenhuma flag, interface cli simples e intuitiva, suporte embutido para várias cópias — embora seja cerca de duas vezes mais lento. Se os dados precisam ser restaurados do último backup feito — pode-se usar o rsync, com pequenas ressalvas.
Um desempenho e carga semelhantes foram mostrados pelo programa BackupPC ao ativar o modo de transmissão rsync, finalizando o backup em
7 minutos e 42 segundos:
Já no modo de transmissão de dados com tar, o BackupPC se saiu mais devagar: em 12 minutos e 15 segundos, com a carga do processador sendo, no geral, inferior
em uma vez e meia:
Duplicity sem criptografia, mostrou resultados ligeiramente melhores, completando a restauração do backup em 10 minutos e 58 segundos. Ao ativar a criptografia usando gpg, o tempo de restauração aumenta para 15 minutos e 3 segundos. Além disso, ao criar um repositório para armazenar os backups, é possível especificar o tamanho do arquivo que será utilizado na divisão do fluxo de dados de entrada. No geral, em discos rígidos comuns, e devido ao modo de operação de um único thread, não há uma diferença significativa. Essa diferença pode surgir com tamanhos de bloco diferentes, quando são usados armazenamentos híbridos. A carga no servidor principal durante a restauração foi a seguinte:
sem criptografia
com criptografia
Duplicati mostrou uma velocidade de restauração comparável, completando em 13 minutos e 45 segundos. Mais cerca de 5 minutos foram gastos na verificação da integridade dos dados restaurados (totalizando cerca de 19 minutos). A carga, nesse caso, foi
bastante alta:
Quando a criptografia aes foi ativada por meios internos, o tempo de restauração foi de 21 minutos e 40 segundos, com a carga da CPU sendo máxima (ambos os núcleos!) durante a restauração; na verificação dos dados, apenas um thread estava ativo, ocupando um núcleo de processador. A verificação dos dados após a restauração levou os mesmos 5 minutos (totalizando quase 27 minutos).
Resultado
Um pouco mais rápido, o duplicati se saiu na restauração ao usar um programa externo gpg para a criptografia, mas, no geral, as diferenças em relação ao modo anterior são mínimas. O tempo total foi de 16 minutos e 30 segundos, com a verificação dos dados em 6 minutos. A carga foi
a seguinte:
AMANDA, que usa tar, completou em 2 minutos e 49 segundos, o que, em princípio, é bastante próximo ao tar comum. A carga no sistema, em princípio, é
a mesma:
Ao restaurar o backup usando zbackup os seguintes resultados foram obtidos:
criptografia, compressão lzma
O tempo de operação foi de 11 minutos e 8 segundos
criptografia aes, compressão lzma
O tempo de operação foi de 14 minutos
criptografia aes, compressão lzo
O tempo de operação foi de 6 minutos e 19 segundos
Em geral, não está ruim. Tudo depende da velocidade do processador no servidor de backup, o que é claramente visível pelo tempo de execução do programa com diferentes compactadores. Do lado do servidor de backup, foi utilizado o tar comum, então, se comparado a ele, a restauração funciona três vezes mais devagar. Talvez valha a pena verificar o desempenho em modo multithread, com mais de dois threads.
BorgBackup no modo sem criptografia foi um pouco mais lento do que o tar, levando 2 minutos e 45 segundos, no entanto, ao contrário do tar, tornou-se possível a deduplicação do repositório. A carga resultante foi
a seguinte:
Se a criptografia baseada em blake for ativada, a velocidade de restauração do backup diminui ligeiramente. O tempo de restauração nesse modo é de 3 minutos e 19 segundos, e a carga foi
a seguinte:
A criptografia aes funciona um pouco mais lenta, o tempo de restauração é de 3 minutos e 23 segundos, a carga não
mudou muito:
Como o Borg pode operar em modo multithread, a carga da CPU é máxima, e ao ativar recursos adicionais, o tempo de execução simplesmente aumenta. Aparentemente, vale a pena investigar a multithread como é feito no zbackup.
Restic desempenhou a recuperação um pouco mais devagar, levando 4 minutos e 28 segundos. A carga nesse caso foi
assim:
Aparentemente o processo de restauração funciona em múltiplos threads, mas a eficiência não é tão alta quanto a do BorgBackup, mas é comparável em tempo ao rsync comum.
Com UrBackup conseguiu recuperar os dados em 8 minutos e 19 segundos, a carga nesse caso foi
a seguinte:
Ainda é visível uma carga não tão alta, até menor que a do tar. Em certos momentos houve picos, mas não mais que a carga de um núcleo.
Escolha e justificativa de critérios para comparação
Como foi mencionado em um dos artigos anteriores, o sistema de backup deve atender aos seguintes critérios:
- Facilidade de trabalho
- Versatilidade
- Estabilidade
- Rapidez
Vale a pena considerar cada item separadamente com mais detalhes.
Facilidade de uso
É melhor quando há um botão 'Fazer tudo certo', mas se voltarmos às aplicações reais, o princípio de operação mais confortável será algum padrão e familiar.
A maior parte dos usuários provavelmente se beneficiará mais se não precisar memorizar uma quantidade de chaves para o CLI, configurar várias opções diferentes, muitas vezes pouco claras, através da web ou TUI e configurar notificações sobre falhas. Isso também inclui a possibilidade de integrar facilmente uma solução de backup na infraestrutura existente, bem como a automação do processo de backup. Igualmente, a instalação via gerenciador de pacotes ou em um ou dois comandos como "baixar e descompactar". curl link | sudo bash — é um método complexo, pois é necessário verificar o que está sendo baixado pelo link.
Por exemplo, entre os candidatos analisados, uma solução simples é o burp, rdiff-backup e restic, que têm chaves mnemônicas fáceis de lembrar para diferentes modos de operação. Um pouco mais complexos são o borg e o duplicity. O mais complexo foi o AMANDA. Os outros estão em um nível médio em termos de facilidade de uso. De qualquer forma, se levar mais de 30 segundos para ler o manual do usuário ou se precisar consultar o Google ou outro motor de busca, além de folhear uma longa folha de ajuda, a solução é complexa de qualquer maneira.
Parte dos candidatos analisados conseguem enviar automaticamente mensagens por e-mail/jabber, enquanto outros dependem de notificações configuradas no sistema. Na maioria das vezes, soluções complexas têm configurações de notificações que não são exatamente claras. De qualquer forma, se o programa de backup retornar um código de saída diferente de zero, que seja corretamente interpretado pelo serviço de sistema de tarefas periódicas (uma mensagem será enviada ao administrador do sistema ou imediatamente para o monitoramento) — a situação é simples. Já se o sistema de backup, que não está no servidor de backups, não consegue comunicar o problema de forma clara e sem configuração, a complexidade é excessiva. De qualquer forma, emitir avisos e outras mensagens apenas na interface da web ou no log é uma má prática, pois elas geralmente serão ignoradas.
No que diz respeito à automação, um programa simples deve ser capaz de ler variáveis de ambiente que definem seu modo de operação, ou ter um CLI avançado que pode replicar completamente o comportamento quando operado via interface web, por exemplo. Isso também inclui a capacidade de operar em fluxo contínuo, disponibilidade para extensão, etc.
Versatilidade
Parcialmente relacionado à seção anterior em termos de automação, não deve haver um problema especial em 'encaixar' o processo de backup na infraestrutura existente.
Vale a pena notar que o uso de portas não padrão (exceto para a interface da web) para funcionamento, a implementação de criptografia de forma não convencional, e a troca de dados por protocolos não padrões — são sinais de uma solução não universal. Na maior parte, todos os candidatos possuem esses sinais de alguma forma, por uma razão óbvia: simplicidade e universalidade costumam ser incompatíveis. Como exceção — burp, existem outras também.
Um sinal é a possibilidade de funcionar usando ssh comum.
Velocidade de operação
O ponto mais controverso e debatido. Por um lado — o processo foi iniciado, funcionou da forma mais rápida possível e não interfere nas tarefas principais. Por outro — um aumento de tráfego e carga no processador durante o backup. Também vale a pena notar que os programas mais rápidos para realização de cópias geralmente têm menos funcionalidades, que são importantes para os usuários. Novamente: se para obter um único arquivo de texto miserável de alguns dezenas de bytes com uma senha, e por causa disso todo o serviço para, (sim, eu entendo que o processo de backup raramente é o culpado aqui), e é necessário ler todos os arquivos no repositório sequencialmente ou extrair um arquivo inteiro — o sistema de backup definitivamente não é rápido. Outro ponto que frequentemente se torna um obstáculo é a velocidade de restauração de um backup a partir de um arquivo. Aqui há uma clara vantagem para aqueles que podem simplesmente copiar ou mover arquivos para o lugar necessário sem muita manipulação (rsync, por exemplo), mas na maioria das vezes o problema precisa ser resolvido de forma organizacional, empiricamente: medir o tempo de restauração do backup e comunicar isso abertamente aos usuários.
Estabilidade
Deve-se entender assim: por um lado, deve haver a possibilidade de restaurar o backup a qualquer momento, por outro lado — resistência a diversos problemas: queda de rede, falha do disco, exclusão de parte do repositório.
Comparação de ferramentas de backup
Tempo de criação da cópia
Tempo de recuperação da cópia
Instalação simples
Configuração simples
Uso simples
Automatização simples
É necessário um cliente-servidor?
Verificação de integridade do repositório
Cópias diferenciais
Operar através do pipe
Versatilidade
Autonomia
Transparência do repositório
Criptografia
Compressão
— criação de um arquivo sem arquivos duplicados (se o deduplicador souber onde o pacote original pode ser baixado, ele reduz as duplicatas do arquivo).
Interface web
Envio para a nuvem
Suporte a Windows
Pontuação
O Rsync
4m15s
4m28s
sim
não
não
não
sim
não
não
sim
não
sim
sim
não
não
não
não
não
sim
6
O Tar
puro
3m12s
2m43s
sim
não
não
não
não
não
sim
sim
não
sim
não
não
não
não
não
não
sim
8,5
gzip
9m37s
3m19s
sim
Rdiff-backup
16m26s
17m17s
sim
sim
sim
sim
sim
não
sim
não
sim
não
sim
não
sim
sim
sim
não
sim
11
Rsnapshot
4m19s
4m28s
sim
sim
sim
sim
não
não
sim
não
sim
não
sim
não
não
sim
sim
não
sim
12,5
Burp
11m9s
7m2s
sim
não
sim
sim
sim
sim
sim
não
sim
sim
não
não
sim
não
sim
não
sim
10,5
Duplicity
sem criptografia
16m48s
10m58s
sim
sim
não
sim
não
sim
sim
não
não
sim
não
sim
sim
não
sim
não
sim
11
gpg
17m27s
15m3s
Duplicati
sem criptografia
20m28s
13m45s
não
sim
não
não
não
sim
sim
não
não
sim
não
sim
sim
sim
sim
sim
sim
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
Zbackup
sem criptografia
40m3s
11m8s
sim
sim
não
não
não
sim
sim
sim
não
sim
não
sim
sim
sim
não
não
não
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
sem criptografia
4m7s
2m45s
sim
sim
sim
sim
sim
sim
sim
sim
sim
sim
não
sim
sim
sim
sim
não
sim
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
sim
sim
sim
sim
não
sim
sim
sim
sim
sim
não
sim
não
sim
não
sim
sim
15,5
UrBackup
8m21s
8m19s
sim
sim
sim
não
sim
não
sim
não
sim
sim
não
sim
sim
sim
sim
não
sim
12
Amanda
9m3s
2m49s
sim
não
não
sim
sim
sim
sim
não
sim
sim
sim
sim
sim
não
sim
sim
sim
13
BackupPC
rsync
12m22s
7m42s
sim
não
sim
sim
sim
sim
sim
não
sim
não
não
sim
sim
não
sim
não
sim
10,5
tar
12m34s
12m15s
Legenda da tabela:
- Verde, tempo de operação menor que cinco minutos, ou resposta "Sim" (exceto na coluna "Necessita cliente-servidor?"), 1 ponto
- Amarelo, tempo de operação de cinco a dez minutos, 0,5 pontos
- Vermelho, tempo de operação superior a dez minutos, ou resposta "Não" (exceto na coluna "Necessita cliente-servidor?"), 0 pontos
De acordo com a tabela acima, a ferramenta mais simples, rápida e ao mesmo tempo conveniente e poderosa para backup é o BorgBackup. O segundo lugar foi ocupado pelo Restic, e os demais candidatos analisados ficaram aproximadamente iguais com uma variação de um a dois pontos no final.
Agradeço a todos que leram a série até o fim, proponho discutir opções e sugerir as suas, se houver. À medida que a discussão avança, a tabela pode ser complementar.
O resultado da série será um artigo final, no qual tentaremos determinar a ferramenta ideal, rápida e gerenciável para backup, permitindo a restauração rápida de uma cópia e, ao mesmo tempo, oferecendo conforto e facilidade na configuração e na manutenção.
Anúncio
Backup, Parte 6: Comparação de ferramentas de backup
Backup, parte 7: Conclusões
Fonte: habr.com
