Este artigo continua
ciclo de backup- 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 da ferramenta de backup baseada 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 6: Comparando ferramentas de backup
- Backup Parte 7: Conclusões
Como já escrevemos no primeiro artigo, há um número muito grande de programas de backup baseados no rsync.
Daqueles que são mais adequados para nossas condições, considerarei 3: rdiff-backup, rsnapshot e arroto.
Conjuntos de arquivos de teste
Os conjuntos de arquivos de teste serão os mesmos para todos os candidatos, incluindo artigos futuros.O primeiro conjunto : 10 GB de arquivos de mídia e cerca de 50 MB - o código-fonte do site em php, tamanhos de arquivo de alguns kilobytes para o código-fonte, a dezenas de megabytes para arquivos de mídia. O objetivo é simular um site com estática.
O segundo conjunto : obtido a partir do primeiro ao renomear um subdiretório com arquivos de mídia de 5 GB. O objetivo é estudar o comportamento do sistema de backup ao renomear um diretório.
Terceiro conjunto : obtido a partir do primeiro, excluindo 3 GB de arquivos de mídia e adicionando novos 3 GB de arquivos de mídia. O objetivo é estudar o comportamento do sistema de backup durante uma operação típica de atualização do site.
Obtendo resultados
Qualquer backup é realizado pelo menos três vezes e é acompanhado por uma redefinição dos caches do sistema de arquivos com os
echo 3 > /proc/sys/vm/drop_caches sync e
echo 3 > /proc/sys/vm/drop_caches no servidor de teste e no servidor de armazenamento de backup.
No servidor que será a fonte dos backups, o software de monitoramento está instalado - netdata, com o qual a carga no servidor será estimada durante o backup; isso é necessário para avaliar a carga no servidor pelo processo de backup.
Também acho que o servidor de armazenamento de backup é mais lento que o servidor principal, mas possui discos mais espaçosos com uma velocidade de gravação aleatória relativamente baixa - a situação mais comum ao fazer backup e pelo fato de o servidor de backup não fazer nada de bom Não monitorarei a carga além do backup, não monitorarei sua carga usando o netdata.
Além disso, meus servidores foram alterados, nos quais vou verificar vários sistemas para backup.
Agora eles têm as seguintes característicasCPU sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 2 Initializing random number generator from current time Prime numbers limit: 20000 Initializing worker threads... Threads started! CPU speed: events per second: 1081.62 General statistics: total time: 30.0013s total number of events: 32453 Latency (ms): min: 1.48 avg: 1.85 max: 9.84 95th percentile: 2.07 sum: 59973.40 Threads fairness: events (avg/stddev): 16226.5000/57.50 execution time (avg/stddev): 29.9867/0.00
RAM, lendo ... sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Running memory speed test with the following options: block size: 1KiB total size: 102400MiB operation: read scope: global Initializing worker threads... Threads started! Total operations: 104857600 (5837637.63 per second) 102400.00 MiB transferred (5700.82 MiB/sec) General statistics: total time: 17.9540s total number of events: 104857600 Latency (ms): min: 0.00 avg: 0.00 max: 66.08 95th percentile: 0.00 sum: 18544.64 Threads fairness: events (avg/stddev): 26214400.0000/0.00 execution time (avg/stddev): 4.6362/0.12
... e gravação sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Running memory speed test with the following options: block size: 1KiB total size: 102400MiB operation: write scope: global Initializing worker threads... Threads started! Total operations: 91414596 (3046752.56 per second) 89272.07 MiB transferred (2975.34 MiB/sec) General statistics: total time: 30.0019s total number of events: 91414596 Latency (ms): min: 0.00 avg: 0.00 max: 1022.90 95th percentile: 0.00 sum: 66430.91 Threads fairness: events (avg/stddev): 22853649.0000/945488.53 execution time (avg/stddev): 16.6077/1.76
Disco no servidor de origem de dados sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Extra file open flags: (none) 128 files, 8MiB each 1GiB total file size Block size 4KiB Number of IO requests: 0 Read/Write ratio for combined random IO test: 1.50 Periodic FSYNC enabled, calling fsync() each 100 requests. Calling fsync() at the end of test, Enabled. Using synchronous I/O mode Doing random r/w test Initializing worker threads... Threads started! File operations: reads/s: 4587.95 writes/s: 3058.66 fsyncs/s: 9795.73 Throughput: read, MiB/s: 17.92 written, MiB/s: 11.95 General statistics: total time: 60.0241s total number of events: 1046492 Latency (ms): min: 0.00 avg: 0.23 max: 14.45 95th percentile: 0.94 sum: 238629.34 Threads fairness: events (avg/stddev): 261623.0000/1849.14 execution time (avg/stddev): 59.6573/0.00
Disco no servidor de armazenamento de backup sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Extra file open flags: (none) 128 files, 8MiB each 1GiB total file size Block size 4KiB Number of IO requests: 0 Read/Write ratio for combined random IO test: 1.50 Periodic FSYNC enabled, calling fsync() each 100 requests. Calling fsync() at the end of test, Enabled. Using synchronous I/O mode Doing random r/w test Initializing worker threads... Threads started! File operations: reads/s: 11.37 writes/s: 7.58 fsyncs/s: 29.99 Throughput: read, MiB/s: 0.04 written, MiB/s: 0.03 General statistics: total time: 73.8868s total number of events: 3104 Latency (ms): min: 0.00 avg: 78.57 max: 3840.90 95th percentile: 297.92 sum: 243886.02 Threads fairness: events (avg/stddev): 776.0000/133.26 execution time (avg/stddev): 60.9715/1.59
Velocidade de rede entre servidores iperf3 -c backup Connecting to host backup, port 5201 [ 4] local xxxx port 59402 connected to yyyy port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 419 MBytes 3.52 Gbits/sec 810 182 KBytes [ 4] 1.00-2.00 sec 393 MBytes 3.30 Gbits/sec 810 228 KBytes [ 4] 2.00-3.00 sec 378 MBytes 3.17 Gbits/sec 810 197 KBytes [ 4] 3.00-4.00 sec 380 MBytes 3.19 Gbits/sec 855 198 KBytes [ 4] 4.00-5.00 sec 375 MBytes 3.15 Gbits/sec 810 182 KBytes [ 4] 5.00-6.00 sec 379 MBytes 3.17 Gbits/sec 765 228 KBytes [ 4] 6.00-7.00 sec 376 MBytes 3.15 Gbits/sec 810 180 KBytes [ 4] 7.00-8.00 sec 379 MBytes 3.18 Gbits/sec 765 253 KBytes [ 4] 8.00-9.00 sec 380 MBytes 3.19 Gbits/sec 810 239 KBytes [ 4] 9.00-10.00 sec 411 MBytes 3.44 Gbits/sec 855 184 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 sender [ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec receiver
Metodologia de teste
- Um sistema de arquivos com o primeiro conjunto de testes é preparado no servidor de teste e o repositório é inicializado no servidor de armazenamento de backup, se necessário.
O processo de backup é iniciado e seu tempo é medido. - Os arquivos são migrados para o segundo conjunto de testes no servidor de teste. O processo de backup é iniciado e seu tempo é medido.
- O servidor de teste migra para o terceiro conjunto de testes. O processo de backup é iniciado e seu tempo é medido.
- O terceiro conjunto de testes resultante é aceito pelo novo primeiro; os pontos 1-3 são repetidos mais 2 vezes.
- Os dados são inseridos na tabela dinâmica, gráficos com netdata são adicionados.
- Um relatório é preparado usando um método de backup separado.
Resultados esperados
Como todos os três candidatos são baseados na mesma tecnologia (rsync), espera-se que os resultados sejam próximos do rsync usual, incluindo todas as suas vantagens, a saber:
- Os arquivos no repositório serão armazenados "como estão".
- O tamanho do repositório aumentará apenas incluindo a diferença entre os backups.
- Haverá uma carga relativamente grande na rede ao transmitir dados, bem como uma carga pequena no processador.
A execução de teste de um rsync regular será usada como referência, seus resultados
estes são
O gargalo estava no servidor de armazenamento de backup na forma de um disco baseado em HDD, que é claramente visível nos gráficos na forma de uma serra.
Os dados foram copiados em 4 minutos e 15 segundos.
Testando o rdiff-backup
O primeiro candidato é rdiff-backup, um script python que faz backup de um diretório para outro. Ao mesmo tempo, a cópia de backup atual é armazenada "como está", e os backups feitos anteriormente são armazenados em um subdiretório especial de forma incremental e, portanto, o espaço é economizado.
Verificaremos o modo típico de operação, ou seja, o início do processo de backup é iniciado pelo cliente por conta própria e, no lado do servidor, o processo que recebe dados é iniciado para backup.
Vamos ver
do que ele é capaz nas nossas condições.
O tempo de execução de cada execução de teste:
O Rdiff-backup reage muito dolorosamente a qualquer grande alteração de dados e também não utiliza completamente a rede.
Testando o rsnapshot
O segundo candidato, rsnapshot, é um script perl cujo principal requisito para um trabalho eficaz é o suporte a links físicos. Isso economiza espaço em disco. Ao mesmo tempo, os arquivos que não foram alterados desde o backup anterior serão referenciados ao arquivo original usando links físicos.
A lógica do processo de backup também é invertida: o servidor "caminha" ativamente em seus próprios clientes e coleta dados.
Resultados do teste
Funcionou muito, muito rápido, muito mais rápido que o rdiff-backup e muito próximo do rsync puro.
Teste de arroto
Outra opção é a implementação C na parte superior do librsync - burp, que possui uma arquitetura cliente-servidor, incluindo autorização do cliente, além de uma interface da web (não incluída no pacote base). Outro recurso interessante é o backup sem o direito de recuperação dos clientes.
Vamos olhar
performance.
Funcionou 2 vezes mais devagar que o rsnapshot, mas também muito rápido e, certamente, o rdiff-backup mais rápido. Os gráficos são um pouco impressionantes - o desempenho repousa novamente no subsistema de disco do servidor de armazenamento de backup, embora isso não seja tão pronunciado quanto o do rsnapshot.
Resultados
O tamanho dos repositórios para todos os candidatos era aproximadamente o mesmo, ou seja, no início, aumentava até 10 GB, depois aumentava até 15 GB, depois aumentava até 18 GB, etc., o que está relacionado à peculiaridade do rsync. Também vale a pena notar o encadeamento único de todos os candidatos (a utilização da CPU é de cerca de 50% com uma máquina de núcleo duplo). Todos os três candidatos ofereceram a oportunidade de restaurar o último backup "como estão", ou seja, foi possível restaurar arquivos sem usar nenhum programa de terceiros, incluindo os usados para criar repositórios. Este também é o "legado genérico" do rsync.
Conclusões
Quanto mais complexo o sistema de backup e mais recursos diversos, mais lento ele funcionará, mas para projetos não muito exigentes, qualquer um deles fará, exceto, possivelmente, o backup de rdiff.
Anúncio
Esta nota continua o ciclo de backup.
Backup, parte 1: Por que você precisa de um backup, uma visão geral de métodos, tecnologiasBackup, Parte 2: Visão geral e teste das ferramentas de backup baseadas em rsyncBackup, Parte 3: Visão geral e teste de duplicidade, duplicatiBackup, Parte 4: Visão geral e testes zbackup, restic, borgbackupBackup, Parte 5: Testando o Bacula e o Veeam Backup para LinuxBackup: parte solicitada pelos leitores: revisão da AMANDA, UrBackup, BackupPCBackup, Parte 6: Comparando ferramentas de backupBackup Parte 7: ConclusõesPostado por Finnix