Backup, Parte 6: Comparando ferramentas de backup

Este artigo irá comparar as ferramentas de backup, mas primeiro você precisa descobrir como elas lidam rápida e bem com a recuperação de dados dos backups.
Para facilitar a comparação, a recuperação de um backup completo será considerada, especialmente porque todos os candidatos suportam esse modo de operação. Para simplificar, os números já estão em média (média aritmética de várias partidas). Os resultados serão resumidos em uma tabela, que também conterá informações sobre os recursos: presença de uma interface da Web, facilidade de configuração e operação, capacidade de automatização, presença de vários recursos adicionais (por exemplo, verificação da integridade dos dados), etc. Os gráficos mostrarão a carga do servidor, onde os dados serão usados ​​(não o servidor para armazenar backups).

Recuperação de dados

O Rsync e o tar serão usados ​​como um ponto de referência, pois é nesses que os scripts de backup mais simples geralmente se baseiam .

O Rsync concluiu o conjunto de dados de teste em 4 minutos e 28 segundos, mostrando


O processo de recuperação encontrou uma limitação do subsistema de disco do servidor de armazenamento de backup (gráficos em dente de serra). Você também pode ver claramente o carregamento de um núcleo sem problemas (baixo iowait e softirq - não há problemas com o disco e a rede, respectivamente). Como os outros dois programas, como rdiff-backup e rsnapshot, são baseados no rsync e também oferecem rsync regular como ferramenta de recuperação, eles terão aproximadamente o mesmo perfil de carga e tempo de recuperação de backup.

Tar lidou um pouco mais rápido por


A carga total do sistema foi mais alta em média 20% devido ao aumento do softirq - aumento da sobrecarga durante a operação do subsistema de rede.

Se o arquivo compactado for adicionalmente compactado, o tempo de recuperação aumentará para 3 minutos e 19 segundos com

O processo de descompactação ocupa os dois núcleos do processador, pois dois processos funcionam. Em geral, o resultado esperado. Além disso, foi obtido um resultado comparável (3 minutos e 20 segundos) ao executar o gzip no lado do servidor com backups; o perfil de carga no servidor principal era muito semelhante ao do tar sem o compressor gzip (veja o gráfico anterior).

No rdiff-backup, você pode sincronizar o último backup feito usando o rsync regular (os resultados serão semelhantes), mas os backups mais antigos ainda precisam ser restaurados usando o programa rdiff-backup, que conseguiu restaurar em 17 minutos e 17 segundos, mostrando


Talvez isso tenha sido concebido, em qualquer caso, os autores propõem uma solução para limitar a velocidade. O processo de restauração de um backup ocupa um pouco menos da metade de um núcleo, com desempenho proporcionalmente comparável (ou seja, 2-5 vezes mais lento) em um disco e na rede com o rsync.

O Rsnapshot para recuperação sugere o uso regular do rsync, portanto seus resultados serão semelhantes. Em geral, foi assim que aconteceu.

O Burp lidou com a tarefa de restaurar um backup em 7 minutos e 2 segundos com

Funcionou rápido o suficiente e pelo menos muito mais conveniente do que o puro rsync: você não precisa se lembrar de nenhum sinalizador, uma interface cli simples e intuitiva, suporte embutido para várias cópias - é verdade duas vezes mais lento. Se você precisar restaurar os dados do último backup feito, poderá usar o rsync, com algumas ressalvas.

O BackupPC mostrou a mesma velocidade e carga ao ativar o modo de transferência rsync, implantando um backup para


Mas no modo de transferência de dados com o tar BackupPC lidou mais devagar: em 12 minutos e 15 segundos, a carga do processador era geralmente menor


A duplicidade sem criptografia mostrou resultados um pouco melhores, tendo conseguido restaurar um backup em 10 minutos e 58 segundos. Se você ativar a criptografia usando o gpg - o tempo de recuperação aumentará para 15 minutos e 3 segundos. Além disso, ao criar um repositório para armazenar cópias, você pode especificar o tamanho do arquivo morto, que será usado ao dividir o fluxo de dados recebidos. Em geral, em discos rígidos comuns, também devido ao modo de operação de thread único, não há muita diferença. Pode aparecer com tamanhos de bloco diferentes ao usar o armazenamento híbrido. A carga no servidor principal durante a recuperação foi a seguinte:



Duplicati mostrou uma velocidade de recuperação comparável, lidando em 13 minutos e 45 segundos. Outros 5 minutos fizeram a verificação da correção dos dados recuperados (um total de aproximadamente 19 minutos). A carga foi


Quando a criptografia Aes foi ativada internamente, o tempo de recuperação foi de 21 minutos e 40 segundos e a carga do processador foi máxima (ambos os núcleos!) Durante a recuperação; ao verificar os dados, apenas um encadeamento estava ativo, ocupando um núcleo do processador. A verificação dos dados após a recuperação levou os mesmos 5 minutos (quase 27 minutos no total).


A Duplicati lidou com a recuperação um pouco mais rápido ao usar um programa gpg externo para criptografia, mas em geral as diferenças em relação ao modo anterior são mínimas. O tempo de operação foi de 16 minutos e 30 segundos, com verificação de dados em 6 minutos. A carga foi


A AMANDA , usando alcatrão, administrou em 2 minutos e 49 segundos, o que, em princípio, está muito próximo do alcatrão comum. Carga do sistema em princípio


Ao restaurar um backup usando o zbackup , foram obtidos os seguintes resultados:




Em suma, nada mal. Tudo depende da velocidade do processador no servidor de backup, que é claramente visível no momento em que o programa é executado com diferentes compressores. No lado do servidor de backup, um tar regular foi lançado; portanto, se você comparar com ele, a recuperação funcionará três vezes mais lenta. Pode valer a pena verificar o trabalho no modo multithread, com mais de dois threads.

O BorgBackup no modo não criptografado conseguiu um pouco mais lento que o tar, em 2 minutos e 45 segundos, no entanto, ao contrário do mesmo tar, tornou-se possível desduplicar o repositório. A carga ao mesmo tempo acabou


Se você ativar a criptografia baseada em blake, a velocidade de restauração de um backup diminuirá um pouco. O tempo de recuperação neste modo é de 3 minutos a 19 segundos e a carga é liberada


A criptografia AES funciona um pouco mais devagar, tempo de recuperação de 3 minutos e 23 segundos, especialmente carregamento


Como o Borg pode funcionar no modo multiencadeado - a carga do processador é máxima, enquanto que quando você ativa funções adicionais, o tempo de operação simplesmente aumenta. Aparentemente, vale a pena explorar o trabalho multithreading de maneira semelhante ao zbackup.

Restic lidou com a recuperação um pouco mais devagar, o tempo de operação foi de 4 minutos e 28 segundos. A carga parecia


Aparentemente, o processo de recuperação funciona em vários threads, mas a eficiência não é tão alta quanto a do BorgBackup, mas é comparável em tempo ao rsync usual.

Usando o UrBackup, consegui recuperar dados em 8 minutos e 19 segundos, enquanto a carga estava


Ainda é visível uma carga não muito alta, ainda mais baixa que a do alcatrão. Em alguns lugares, explode, mas não mais do que carregar um único núcleo.

Seleção e justificativa de critérios para comparação

Conforme mencionado em um artigo anterior, o sistema de backup deve atender aos seguintes critérios:

• Simplicidade no trabalho
• Versatilidade
• Estabilidade
• Velocidade

Vale a pena considerar cada item separadamente com mais detalhes.

Simplicidade do trabalho

É melhor quando existe um botão "Tornar tudo bom", mas se você retornar a programas reais, será mais conveniente ter algum princípio familiar e padrão de operação.
A maioria dos usuários provavelmente ficará melhor se não precisar memorizar um monte de chaves para o CLI, configurar um monte de opções diferentes e muitas vezes obscuras via web ou tui e configurar alertas sobre falhas na operação. Isso também inclui a capacidade de "encaixar" facilmente uma solução de backup em uma infraestrutura existente, além de automatizar o processo de backup. Imediatamente a capacidade de instalar um gerenciador de pacotes ou em um ou dois comandos do tipo "baixar e descompactar". curl | sudo bash curl | sudo bash é um método complicado porque você precisa verificar se ele chega por referência.

Por exemplo, dos candidatos considerados, uma solução simples é burp, rdiff-backup e restic, que lembraram mnemicamente as chaves para diferentes modos de operação. Um pouco mais complicado são borg e duplicidade. O mais difícil foi a AMANDA. O restante da facilidade de uso está em algum lugar no meio. De qualquer forma, se você precisar de mais de 30 segundos para ler o manual do usuário ou precisar acessar o Google ou outro mecanismo de pesquisa e também rolar a longa folha de ajuda, a solução é complicada, de uma maneira ou de outra.

Alguns dos candidatos considerados podem enviar automaticamente uma mensagem por e-mail \ jabber, enquanto outros contam com alertas configurados no sistema. Além disso, na maioria das vezes decisões complexas não possuem configurações de notificação bastante óbvias. De qualquer forma, se o programa de backup fornecer um código de retorno diferente de zero, que será entendido corretamente pelo serviço do sistema em tarefas periódicas (a mensagem será transferida para o administrador do sistema ou imediatamente para o monitoramento) - a situação é simples. Mas se o sistema de backup, que não funciona no servidor de backup, não puder ser configurado de maneira óbvia, a complexidade já será excessiva. De qualquer forma, emitir avisos e outras mensagens apenas para a interface da web e / ou para o log é uma prática recomendada, pois eles geralmente são ignorados.

Quanto à automação, um programa simples pode ler variáveis ​​de ambiente que especificam seu modo de operação, ou possui um CLI desenvolvido que pode duplicar completamente o comportamento ao trabalhar através de uma interface da Web, por exemplo. Isso também inclui a possibilidade de trabalho contínuo, a disponibilidade de oportunidades de expansão, etc.

Versatilidade

Repete parcialmente a subseção anterior em termos de automação, não deve ser um problema especial "ajustar" o processo de backup à infraestrutura existente.
Vale ressaltar que o uso de portas não padrão (bem, exceto a interface da web) para o trabalho, a implementação da criptografia de maneira não padrão, a troca de dados com um protocolo não padrão são sinais de uma solução não universal. Na maioria dos casos, todos os candidatos têm um caminho ou outro pelo motivo óbvio: simplicidade e versatilidade geralmente não são compatíveis. Burp é uma exceção, existem outros.

Como um sinal - a capacidade de trabalhar usando ssh regular.

Velocidade de trabalho

O ponto mais controverso e controverso. Por um lado, eles iniciaram o processo, funcionou o mais rápido possível e não interfere nas tarefas principais. Por outro lado, há um aumento no tráfego e na carga da CPU durante o backup. Também é importante notar que os programas de cópia mais rápidos geralmente são os mais pobres em recursos importantes para os usuários. Novamente: se, para obter um arquivo de texto infeliz, o tamanho de várias dezenas de bytes com uma senha, e por causa disso todo o serviço custa (sim, eu entendo que aqui o processo de backup geralmente não é culpado), e você precisa reler seqüencialmente todos os arquivos no repositório ou implantar todo o arquivo morto - o sistema de backup nunca é rápido. Outro ponto que muitas vezes se torna um obstáculo é a velocidade de implantação de um backup a partir do arquivo morto. Há uma clara vantagem para quem pode simplesmente copiar ou mover arquivos para o lugar certo sem manipulações especiais (rsync, por exemplo), mas na maioria das vezes o problema deve ser resolvido de forma organizacional, empiricamente: meça o tempo de recuperação do backup e informe abertamente os usuários.

Estabilidade

Deve ser entendido da seguinte maneira: por um lado, deve ser possível implantar o backup de volta de qualquer maneira; por outro lado, resistência a vários problemas: quebra de rede, falha no disco, exclusão de parte do repositório.

Comparação de ferramentas de backup

Legenda da tabela:

• Verde, o tempo de operação é inferior a cinco minutos ou a resposta é "Sim" (exceto a coluna "Precisa de um cliente \ servidor?"), 1 ponto
• Amarelo, tempo de operação de cinco a dez minutos, 0,5 pontos
• Vermelho, o tempo de operação é superior a dez minutos ou a resposta é "Não" (exceto a coluna "Precisa de um cliente \ servidor?"), 0 pontos

De acordo com a tabela acima, a ferramenta de backup mais simples, rápida e ao mesmo tempo conveniente e poderosa é o BorgBackup. Restic ficou em segundo lugar, o restante dos candidatos considerados foi colocado aproximadamente o mesmo com uma dispersão de um ou dois pontos no final.

Agradeço a todos que leram o ciclo até o final, sugiro discutir opções, sugerindo as suas, se houver. À medida que a discussão avança, a tabela pode ser complementada.

O resultado do ciclo será o artigo final, no qual haverá uma tentativa de criar uma ferramenta de backup ideal, rápida e gerenciável que permita implantar rapidamente uma cópia de volta e, ao mesmo tempo, ter a conveniência e a simplicidade da configuração e manutenção.

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 backup veeam 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