Este artigo comparará ferramentas de backup, mas primeiro você deve descobrir com que rapidez e eficiência elas lidam com a restauração de dados de backups.
Para facilitar a comparação, consideraremos a restauração a partir de um backup completo, especialmente porque todos os candidatos suportam esse modo de operação. Para simplificar, os números já foram calculados em média (a média aritmética de várias execuções). Os resultados serão resumidos em uma tabela, que também conterá informações sobre as capacidades: presença de interface web, facilidade de configuração e operação, capacidade de automatização, presença de diversos recursos adicionais (por exemplo, verificação de integridade de dados) , etc. Os gráficos mostrarão a carga no servidor onde os dados serão usados (não no servidor para armazenar cópias de backup).
Recuperação de dados
rsync e tar serão usados como ponto de referência, pois scripts simples para fazer cópias de segurança.
Rsync lidou com o conjunto de dados de teste em 4 minutos e 28 segundos, mostrando
uma carga dessas
O processo de recuperação atingiu uma limitação do subsistema de disco do servidor de armazenamento de backup (gráficos dente de serra). Você também pode ver claramente o carregamento de um kernel sem problemas (baixo iowait e softirq - sem problemas com disco e rede, respectivamente). Como os outros dois programas, nomeadamente rdiff-backup e rsnapshot, são baseados em 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.
Alcatrão fiz isso um pouco mais rápido
2 minutos e 43 segundos:
A carga total do sistema foi maior em média 20% devido ao aumento do softirq - os custos indiretos durante a operação do subsistema de rede aumentaram.
Se o arquivo for ainda mais compactado, o tempo de recuperação aumenta para 3 minutos e 19 segundos.
com tal carga no servidor principal (descompactação na lateral do servidor principal):
O processo de descompactação ocupa ambos os núcleos do processador porque há dois processos em execução. Em geral, este é o resultado esperado. Além disso, um resultado comparável (3 minutos e 20 segundos) foi obtido ao executar o gzip no lado do servidor com backups; o perfil de carga no servidor principal foi muito semelhante ao da execução do tar sem o compressor gzip (veja o gráfico anterior).
В rdiff-backup você pode sincronizar o último backup feito usando o rsync normal (os resultados serão semelhantes), mas os backups mais antigos ainda precisam ser restaurados usando o programa rdiff-backup, que completou a restauração em 17 minutos e 17 segundos, mostrando
esta carga:
Talvez a intenção fosse, pelo menos, limitar a velocidade dos autores . O processo de restauração de uma cópia de backup em si ocupa um pouco menos da metade de um núcleo, com desempenho proporcionalmente comparável (ou seja, 2 a 5 vezes mais lento) em disco e rede com rsync.
Rinstantâneo Para recuperação, sugere o uso de rsync regular, para que seus resultados sejam semelhantes. Em geral, foi assim que aconteceu.
Arrotar Concluí a tarefa de restaurar um backup em 7 minutos e 2 segundos com
com esta carga:
Funcionou muito rapidamente e, pelo menos, é muito mais conveniente do que o rsync puro: você não precisa se lembrar de nenhum sinalizador, uma interface CLI simples e intuitiva, suporte integrado para múltiplas cópias - embora seja duas vezes mais lento. Se precisar restaurar dados do último backup feito, você pode usar o rsync, com algumas ressalvas.
O programa mostrou aproximadamente a mesma velocidade e carga Backup PC ao ativar o modo de transferência rsync, implantando o backup para
7 minutos e 42 segundos:
Mas no modo de transferência de dados, o BackupPC lidou com o tar mais lentamente: em 12 minutos e 15 segundos, a carga do processador foi geralmente menor
uma vez e meia:
Duplicidade sem criptografia apresentou resultados um pouco melhores, restaurando um backup em 10 minutos e 58 segundos. Se você ativar a criptografia usando gpg, o tempo de recuperação aumenta 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 que será usado ao dividir o fluxo de dados de entrada. Em geral, em discos rígidos convencionais, também devido ao modo de operação single-threaded, não há muita diferença. Pode aparecer em diferentes tamanhos de bloco quando o armazenamento híbrido é usado. A carga no servidor principal durante a recuperação foi a seguinte:
sem criptografia
com criptografia
Duplicati mostrou uma taxa de recuperação comparável, completando-a em 13 minutos e 45 segundos. Demorou cerca de 5 minutos para verificar a exatidão dos dados recuperados (um total de cerca de 19 minutos). A carga foi
bastante alto:
Quando a criptografia aes foi habilitada internamente, o tempo de recuperação foi de 21 minutos e 40 segundos, com utilização máxima da CPU (ambos os núcleos!) durante a recuperação; Ao verificar os dados, apenas um thread 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).
resultado
duplicati foi um pouco mais rápido com a recuperação ao usar o 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 dos dados em 6 minutos. A carga foi
tal:
AMANDA, usando tar, completou em 2 minutos e 49 segundos, o que, em princípio, é muito próximo do alcatrão normal. Carregar no sistema em princípio
o mesmo:
Ao restaurar um backup usando zbackup Os seguintes resultados foram obtidos:
criptografia, compactação lzma
Tempo de execução 11 minutos e 8 segundos
Criptografia AES, compactação lzma
Tempo de trabalho 14 minutos
Criptografia AES, compactação lzo
Tempo de execução 6 minutos e 19 segundos
No geral, não é ruim. Tudo depende da velocidade do processador no servidor de backup, o que pode ser visto claramente pelo tempo de execução do programa com diferentes compressores. No lado do servidor de backup, um tar normal foi lançado, então se você comparar com ele, a recuperação é 3 vezes mais lenta. Pode valer a pena verificar o funcionamento em modo multithread, com mais de dois threads.
BorgBackup no modo não criptografado foi um pouco mais lento que o tar, em 2 minutos e 45 segundos, porém, ao contrário do tar, tornou-se possível desduplicar o repositório. A carga acabou sendo
próximo:
Se você ativar a criptografia baseada em Blake, a velocidade de recuperação do backup será um pouco mais lenta. O tempo de recuperação neste modo é de 3 minutos e 19 segundos e a carga desaparece
assim:
A criptografia AES é um pouco mais lenta, o tempo de recuperação é de 3 minutos e 23 segundos, a carga é especialmente
Não mudou:
Como o Borg pode funcionar no modo multithread, a carga do processador é máxima e, quando funções adicionais são ativadas, o tempo de operação simplesmente aumenta. Aparentemente, vale a pena explorar o multithreading de maneira semelhante ao zbackup.
Resto lidou com a recuperação um pouco mais devagar, o tempo de operação foi de 4 minutos e 28 segundos. A carga parecia
como se segue:
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 normal.
Com urBackup Foi possível restaurar os dados em 8 minutos e 19 segundos, a carga foi
tal:
A carga ainda não é muito elevada, até inferior à do alcatrão. Em alguns lugares há rajadas, mas não mais do que a carga de um núcleo.
Seleção e justificativa de critérios de comparação
Conforme afirmado num dos artigos anteriores, o sistema de backup deve atender aos seguintes critérios:
- Fácil de usar
- versatilidade
- Estabilidade
- Velocidade
Vale a pena considerar cada ponto separadamente com mais detalhes.
De facil operação
É melhor quando há um botão “Faça tudo bem”, mas se você retornar aos programas reais, o mais conveniente será algum princípio operacional familiar e padrão.
A maioria dos usuários provavelmente ficará melhor se não precisar se lembrar de um monte de chaves para cli, configurar um monte de opções diferentes, muitas vezes obscuras, via web ou tui, ou configurar notificações sobre operações malsucedidas. Isto também inclui a capacidade de “encaixar” facilmente uma solução de backup na infraestrutura existente, bem como a automação do processo de backup. Também existe a possibilidade de instalação através de um gerenciador de pacotes, ou em um ou dois comandos como “baixar e descompactar”. curl ссылка | sudo bash - um método complexo, pois é preciso verificar o que chega pelo link.
Por exemplo, dos candidatos considerados, uma solução simples é burp, rdiff-backup e restic, que possuem chaves mnemônicas para diferentes modos de operação. Um pouco mais complexos são borg e duplicidade. A mais difícil foi AMANDA. O resto está em algum lugar intermediário em termos de facilidade de uso. Em qualquer caso, se você precisar de mais de 30 segundos para ler o manual do usuário, ou precisar ir ao Google ou outro mecanismo de busca, e também percorrer uma longa folha de ajuda, a decisão é difícil, de uma forma ou de outra.
Alguns dos candidatos considerados conseguem enviar uma mensagem automaticamente via e-mailjabber, enquanto outros contam com alertas configurados no sistema. Além disso, na maioria das vezes, soluções complexas não possuem configurações de alerta totalmente óbvias. Em qualquer caso, se o programa de backup produzir um código de retorno diferente de zero, que será corretamente compreendido pelo serviço do sistema para tarefas periódicas (uma mensagem será enviada ao administrador do sistema ou diretamente ao monitoramento) - a situação é simples. Mas se o sistema de backup, que não roda em servidor de backup, não puder ser configurado, a maneira óbvia de dizer sobre o problema é que a complexidade já é excessiva. Em qualquer caso, emitir avisos e outras mensagens apenas para a interface web ou para o log é uma má prática, pois na maioria das vezes serão ignorados.
Quanto à automação, um programa simples pode ler variáveis de ambiente que definem seu modo de operação, ou possui um CLI desenvolvido que pode duplicar completamente o comportamento ao trabalhar através de uma interface web, por exemplo. Isto também inclui a possibilidade de operação contínua, a disponibilidade de oportunidades de expansão, etc.
versatilidade
Ecoando parcialmente a subseção anterior sobre automação, não deve ser um problema específico “encaixar” o processo de backup na infraestrutura existente.
Vale ressaltar que o uso de portas não padronizadas (bem, exceto para a interface web) para o trabalho, a implementação da criptografia de forma não padronizada, a troca de dados por meio de um protocolo não padronizado são sinais de um não -solução universal. Na maioria das vezes, todos os candidatos os possuem de uma forma ou de outra pelo motivo óbvio: simplicidade e versatilidade geralmente não andam juntas. Como exceção - arroto, existem outros.
Como sinal - a capacidade de trabalhar usando ssh normal.
Velocidade
O ponto mais polêmico e polêmico. Por um lado, lançamos o processo, funcionou o mais rápido possível e não atrapalhou as tarefas principais. Por outro lado, há um aumento no tráfego e na carga do processador durante o período de backup. Vale ressaltar também que os programas mais rápidos para fazer cópias costumam ser os mais pobres em termos de funções importantes para os usuários. Novamente: se para obter um infeliz arquivo de texto de várias dezenas de bytes com uma senha, e por causa disso todo o serviço custa (sim, sim, eu entendo que o processo de backup geralmente não é o culpado aqui), e você precisa reler sequencialmente todos os arquivos do repositório ou expandir todo o arquivo - 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 de um arquivo. Há aqui uma clara vantagem para quem pode simplesmente copiar ou mover arquivos para o local desejado sem muita manipulação (rsync, por exemplo), mas na maioria das vezes o problema deve ser resolvido de forma organizacional, empiricamente: medindo o tempo de recuperação do backup e informar abertamente os usuários sobre isso.
Estabilidade
Deve ser entendido desta forma: por um lado, deve ser possível implantar a cópia de backup de qualquer forma, por outro lado, deve ser resistente a diversos problemas: interrupção de rede, falha de disco, exclusão de parte do repositório.
Comparação de ferramentas de backup
Hora de criação da cópia
Tempo de recuperação de cópia
Instalação fácil
Fácil configuração
Uso simples
Automação simples
Você precisa de um servidor cliente?
Verificando a integridade do repositório
Cópias diferenciais
Trabalhando via tubulação
versatilidade
Autonomia
Transparência do repositório
Шифрование
compressão
Desduplicação
interface web
Preenchendo até a nuvem
Suporte do Windows
Pontuaçã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
Alcatrão
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
Backup Rdiff
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
Rinstantâneo
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
Arrotar
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
Duplicidade
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
Resto
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
Backup PC
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
alcatrão
12m34s
12m15s
Legenda da tabela:
- Verde, tempo de operação inferior a cinco minutos ou resposta “Sim” (exceto para a coluna “Precisa de um servidor cliente?”), 1 ponto
- Amarelo, tempo de operação de cinco a dez minutos, 0.5 pontos
- Vermelho, o tempo de trabalho é superior a dez minutos ou a resposta é “Não” (exceto a coluna “Você precisa de um servidor cliente?”), 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, os restantes candidatos considerados foram colocados de forma aproximadamente igual com um spread de um ou dois pontos no final.
Agradeço a todos que leram a série até o final, convido vocês a discutir as opções e oferecer as suas, se houver. À medida que a discussão avança, a tabela pode ser ampliada.
O resultado da série será o artigo final, no qual se tentará desenvolver uma ferramenta de backup ideal, rápida e gerenciável que permita implantar uma cópia de volta no menor tempo possível e ao mesmo tempo ser conveniente e fácil para configurar e manter.
Anúncio
Backup Parte 6: Comparando ferramentas de backup
Backup Parte 7: Conclusões
Fonte: habr.com