Esta nota discute ferramentas de backup que executam backups criando arquivos em um servidor de backup.
Entre os que atendem aos requisitos estão o duplicity (que possui uma interface bacana em forma de deja dup) e o duplicati.
Outra ferramenta de backup muito notável é o dar, mas como possui uma lista muito extensa de opções - a metodologia de teste cobre apenas 10% do que é capaz - não a estamos testando como parte do ciclo atual.
Resultados Esperados
Como ambos os candidatos criam arquivos de uma forma ou de outra, o tar regular pode ser usado como guia.
Além disso, avaliaremos até que ponto o armazenamento de dados no servidor de armazenamento é otimizado, criando cópias de backup contendo apenas a diferença entre uma cópia completa e o estado atual dos arquivos, ou entre os arquivos anteriores e atuais (incremental, decremental, etc.) .
Comportamento ao criar backups:
- Um número relativamente pequeno de arquivos no servidor de armazenamento de backup (comparável ao número de cópias de backup ou ao tamanho dos dados em GB), mas seu tamanho é bastante grande (dezenas a centenas de megabytes).
- O tamanho do repositório incluirá apenas alterações - nenhuma duplicata será armazenada, portanto o tamanho do repositório será menor do que com software baseado em rsync.
- Espere uma carga pesada da CPU ao usar compactação e/ou criptografia e, provavelmente, 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.
Vamos executar o seguinte comando como valor de referência:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Os resultados da execução foram os seguintes:
Tempo de execução 3m12s. Pode-se observar que a velocidade é limitada pelo subsistema de disco do servidor de armazenamento de backup, como no exemplo com . Só um pouco mais rápido, porque... a gravação vai para um arquivo.
Além disso, para avaliar a compactação, vamos executar a mesma opção, mas habilite a compactação no lado do servidor de backup:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Os resultados são os seguintes:
Tempo de execução 10m11s. Muito provavelmente o gargalo é o compressor de fluxo único na extremidade receptora.
O mesmo comando, mas com compressão transferida para o servidor com os dados originais para testar a hipótese de que o gargalo é um compressor single-threaded.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Aconteceu assim:
O tempo de execução foi de 9m37s. A carga em um núcleo do compressor é claramente visível, porque A velocidade de transferência da rede e a carga no subsistema do disco de origem são semelhantes.
Para avaliar a criptografia, você pode usar openssl ou gpg conectando um comando adicional openssl ou gpg em tubo. Para referência, haverá um comando como este:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Os resultados saíram assim:
O tempo de execução acabou sendo de 10m30s, já que 2 processos estavam rodando no lado receptor - o gargalo é novamente um compressor single-threaded, além de uma pequena sobrecarga de criptografia.
UPD: A pedido do bliznezz estou adicionando testes com pigz. Se você usar apenas o compressor, levaria 6m30s, se adicionar também criptografia, seriam cerca de 7m. A queda no gráfico inferior é um cache de disco não liberado:
Testes duplicados
Duplicity é um software python para backup criando arquivos criptografados no formato tar.
Para arquivos incrementais, o librsync é usado, portanto você pode esperar o comportamento descrito em .
Os backups podem ser criptografados e assinados usando gnupg, o que é importante ao usar diferentes provedores para armazenar backups (s3, backblaze, gdrive, etc.)
Vamos ver quais são os resultados:
Estes são os resultados que obtivemos ao executar sem criptografia
Spoiler
Tempo de execução de cada execução de teste:
Lançamento 1
Lançamento 2
Lançamento 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
E aqui estão os resultados quando a criptografia gnupg está habilitada, com um tamanho de chave de 2048 bits:
Tempo de operação nos mesmos dados, com criptografia:
Lançamento 1
Lançamento 2
Lançamento 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Foi indicado o tamanho do bloco - 512 megabytes, o que é claramente visível nos gráficos; A carga do processador permaneceu em 50%, o que significa que o programa não utiliza mais do que um núcleo de processador.
O princípio de funcionamento do programa também é bastante visível: eles pegaram um dado, compactaram-no e enviaram-no para um servidor de armazenamento de backup, que pode ser bastante lento.
Outra característica é o tempo de execução previsível do programa, que depende apenas do tamanho dos dados alterados.
A ativação da criptografia não aumentou significativamente o tempo de execução do programa, mas aumentou a carga do processador em cerca de 10%, o que pode ser um ótimo bônus.
Infelizmente, este programa não foi capaz de detectar corretamente a situação com a renomeação do diretório, e o tamanho do repositório resultante acabou sendo igual ao tamanho das alterações (ou seja, todos os 18 GB), mas a capacidade de usar um servidor não confiável para backup claramente cobre esse comportamento.
Testes duplicados
Este software é escrito em C# e roda usando um conjunto de bibliotecas do Mono. Existe uma GUI e também uma versão CLI.
A lista aproximada dos principais recursos é semelhante à duplicidade, incluindo vários provedores de armazenamento de backup, porém, diferentemente da duplicidade, a maioria dos recursos está disponível sem ferramentas de terceiros. Se isso é um sinal de mais ou de menos depende do caso específico, mas para iniciantes, é provavelmente mais fácil ter uma lista de todos os recursos à sua frente de uma vez, em vez de ter que instalar pacotes adicionais para python, como é o caso da duplicidade.
Outra pequena nuance - o programa grava ativamente um banco de dados sqlite local em nome do usuário que inicia o backup, portanto, você precisa garantir adicionalmente que o banco de dados necessário seja especificado corretamente sempre que o processo for iniciado usando o cli. Ao trabalhar através de GUI ou WEBGUI, os detalhes serão ocultados do usuário.
Vejamos quais indicadores esta solução pode produzir:
Se você desativar a criptografia (e a WEBGUI não recomenda fazer isso), os resultados serão os seguintes:
Horas:
Lançamento 1
Lançamento 2
Lançamento 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Com a criptografia habilitada, usando aes, fica assim:
Horas:
Lançamento 1
Lançamento 2
Lançamento 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
E se você usar o programa externo gnupg, surgirão os seguintes resultados:
Lançamento 1
Lançamento 2
Lançamento 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Como você pode ver, o programa pode funcionar em vários threads, mas isso não o torna uma solução mais produtiva, e se você comparar o trabalho de criptografia, ele está lançando um programa externo
acabou sendo mais rápido do que usar a biblioteca do conjunto Mono. Isso pode ser devido ao fato do programa externo ser mais otimizado.
Outra coisa interessante foi o fato de que o tamanho do repositório ocupa exatamente o mesmo tamanho dos dados reais alterados, ou seja, duplicati detectou uma renomeação de diretório e tratou esta situação corretamente. Isso pode ser visto ao executar o segundo teste.
No geral, impressões bastante positivas do programa, incluindo ser bastante amigável com os novatos.
Descobertas
Ambos os candidatos trabalharam de forma bastante lenta, mas em geral, em comparação com o alcatrão normal, há progresso, pelo menos com duplicações. O preço desse progresso também é claro - um fardo considerável
processador. Em geral, não há desvios especiais na previsão dos resultados.
Descobertas
Se você não precisa se apressar para lugar nenhum e também tem um processador sobressalente, qualquer uma das soluções consideradas servirá, em qualquer caso, muito trabalho foi feito que não deve ser repetido escrevendo scripts wrapper em cima do tar . A presença de criptografia é uma propriedade muito necessária se o servidor para armazenar cópias de backup não for totalmente confiável.
Em comparação com soluções baseadas - o desempenho pode ser várias vezes pior, apesar do fato de que em sua forma pura o tar funcionou 20-30% mais rápido que o rsync.
Há economia no tamanho do repositório, mas apenas com duplicatas.
Anúncio
Backup Parte 3: Revisão e teste de duplicidade, duplicati, deja dup
Backup Parte 4: Revendo e testando zbackup, restic, borgbackup
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