{"id":38746,"date":"2019-10-31T22:25:40","date_gmt":"2019-10-31T19:25:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya\/"},"modified":"2019-10-31T22:25:40","modified_gmt":"2019-10-31T19:25:40","slug":"rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Backup, Parte 6: Compara\u00e7\u00e3o de ferramentas de backup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,
\nEste artigo far\u00e1 uma compara\u00e7\u00e3o de ferramentas de backup, mas primeiro \u00e9 importante entender como elas lidam rapidamente e de forma eficaz com a recupera\u00e7\u00e3o de dados a partir de backups.
\nPara simplificar a compara\u00e7\u00e3o, ser\u00e1 considerado a recupera\u00e7\u00e3o de um backup completo, uma vez que esse modo de opera\u00e7\u00e3o \u00e9 suportado por todos os candidatos. Para facilitar, os n\u00fameros foram tomados como m\u00e9dias (m\u00e9dia aritm\u00e9tica de v\u00e1rias execu\u00e7\u00f5es). Os resultados ser\u00e3o apresentados em uma tabela, que tamb\u00e9m incluir\u00e1 informa\u00e7\u00f5es sobre as funcionalidades: presen\u00e7a de interface web, facilidade de configura\u00e7\u00e3o e uso, capacidade de automa\u00e7\u00e3o, presen\u00e7a de v\u00e1rias funcionalidades adicionais (como verifica\u00e7\u00e3o de integridade dos dados), etc. Gr\u00e1ficos mostrar\u00e3o a carga do servidor onde os dados ser\u00e3o aplicados (n\u00e3o o servidor para armazenamento de backups).
\n<\/a><\/noindex><\/p>\n

Recupera\u00e7\u00e3o de dados<\/h2>\n

\nComo ponto de refer\u00eancia ser\u00e3o utilizados rsync e tar, uma vez que eles costumam ser a base de<\/a><\/noindex> scripts simples para realizar backups.<\/p>\n

O Rsync<\/i> concluiu o conjunto de dados de teste em 4 minutos e 28 segundos, apresentando <\/p>\n

essa carga<\/b>\"Backup,
\n
\nO processo de recupera\u00e7\u00e3o esbarrou na limita\u00e7\u00e3o do subsistema de disco do servidor de armazenamento de backups (gr\u00e1ficos em formato de dente de serra). Tamb\u00e9m \u00e9 claramente vis\u00edvel a carga em um n\u00facleo sem grandes problemas (iowait baixo e softirq \u2014 sem problemas com disco e rede, respectivamente). Como os outros dois programas, ou seja, rdiff-backup e rsnapshot, s\u00e3o baseados no rsync e tamb\u00e9m oferecem o rsync comum como meio de recupera\u00e7\u00e3o, eles ter\u00e3o um perfil de carga semelhante e tempo de recupera\u00e7\u00e3o de backup.<\/p>\n

O Tar<\/i> concluiu um pouco mais r\u00e1pido, em <\/p>\n

2 minutos e 43 segundos:<\/b>\"Backup,
\n
\nA carga total do sistema foi em m\u00e9dia 20% maior devido ao aumento do softirq \u2014 as sobrecargas aumentaram ao trabalhar com o subsistema de rede.<\/p>\n

Se o arquivo for compactado adicionalmente, o tempo de recupera\u00e7\u00e3o aumenta para 3 minutos e 19 segundos com
\nessa carga no servidor principal (descompacta\u00e7\u00e3o no lado do servidor principal):<\/b>\"Backup,
\n
\nO processo de descompacta\u00e7\u00e3o ocupa ambos os n\u00facleos do processador, pois dois processos est\u00e3o em execu\u00e7\u00e3o. No geral, \u00e9 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\u00e7\u00e3o de tar sem o compressor gzip (veja o gr\u00e1fico anterior).<\/p>\n

Em rdiff-backup<\/i> \u00e9 poss\u00edvel sincronizar o \u00faltimo backup realizado usando o rsync comum (os resultados ser\u00e3o semelhantes), mas backups mais antigos ainda precisam ser restaurados com o programa rdiff-backup, que conseguiu a restaura\u00e7\u00e3o em 17 minutos e 17 segundos, mostrando <\/p>\n

tal carga:<\/b>\"Backup,
\n
\nPode ser que essa tenha sido a inten\u00e7\u00e3o, de qualquer forma, para limitar a velocidade os autores sugerem essa solu\u00e7\u00e3o<\/a><\/noindex>. O pr\u00f3prio processo de restaura\u00e7\u00e3o do backup leva um pouco menos da metade de um n\u00facleo, com desempenho proporcionalmente compar\u00e1vel (ou seja, de 2 a 5 vezes mais lento) em disco e rede com rsync.<\/p>\n

Rsnapshot<\/i> para a restaura\u00e7\u00e3o prop\u00f5e usar o rsync comum, ent\u00e3o seus resultados ser\u00e3o semelhantes. No geral, foi exatamente assim que aconteceu.<\/p>\n

Burp<\/i> resolveu a tarefa de restaura\u00e7\u00e3o do backup em 7 minutos e 2 segundos com
\ntal carga:<\/b>\"Backup,
\n
\nFuncionou bastante r\u00e1pido e, pelo menos, \u00e9 muito mais conveniente do que o rsync puro: n\u00e3o \u00e9 preciso lembrar de nenhuma flag, interface cli simples e intuitiva, suporte embutido para v\u00e1rias c\u00f3pias \u2014 embora seja cerca de duas vezes mais lento. Se os dados precisam ser restaurados do \u00faltimo backup feito \u2014 pode-se usar o rsync, com pequenas ressalvas.<\/p>\n

Um desempenho e carga semelhantes foram mostrados pelo programa BackupPC<\/i> ao ativar o modo de transmiss\u00e3o rsync, finalizando o backup em <\/p>\n

7 minutos e 42 segundos:<\/b>\"Backup,
\n
\nJ\u00e1 no modo de transmiss\u00e3o 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 <\/p>\n

em uma vez e meia:<\/b>\"Backup,
\n
\nDuplicity<\/i> sem criptografia, mostrou resultados ligeiramente melhores, completando a restaura\u00e7\u00e3o do backup em 10 minutos e 58 segundos. Ao ativar a criptografia usando gpg, o tempo de restaura\u00e7\u00e3o aumenta para 15 minutos e 3 segundos. Al\u00e9m disso, ao criar um reposit\u00f3rio para armazenar os backups, \u00e9 poss\u00edvel especificar o tamanho do arquivo que ser\u00e1 utilizado na divis\u00e3o do fluxo de dados de entrada. No geral, em discos r\u00edgidos comuns, e devido ao modo de opera\u00e7\u00e3o de um \u00fanico thread, n\u00e3o h\u00e1 uma diferen\u00e7a significativa. Essa diferen\u00e7a pode surgir com tamanhos de bloco diferentes, quando s\u00e3o usados armazenamentos h\u00edbridos. A carga no servidor principal durante a restaura\u00e7\u00e3o foi a seguinte:<\/p>\n

sem criptografia<\/b>\"Backup,
\n
\ncom criptografia<\/b>\"Backup,
\n
\nDuplicati<\/i> mostrou uma velocidade de restaura\u00e7\u00e3o compar\u00e1vel, completando em 13 minutos e 45 segundos. Mais cerca de 5 minutos foram gastos na verifica\u00e7\u00e3o da integridade dos dados restaurados (totalizando cerca de 19 minutos). A carga, nesse caso, foi <\/p>\n

bastante alta:<\/b>\"Backup,
\n
\nQuando a criptografia aes foi ativada por meios internos, o tempo de restaura\u00e7\u00e3o foi de 21 minutos e 40 segundos, com a carga da CPU sendo m\u00e1xima (ambos os n\u00facleos!) durante a restaura\u00e7\u00e3o; na verifica\u00e7\u00e3o dos dados, apenas um thread estava ativo, ocupando um n\u00facleo de processador. A verifica\u00e7\u00e3o dos dados ap\u00f3s a restaura\u00e7\u00e3o levou os mesmos 5 minutos (totalizando quase 27 minutos).<\/p>\n

Resultado<\/b>\"Backup,
\n
\nUm pouco mais r\u00e1pido, o duplicati se saiu na restaura\u00e7\u00e3o ao usar um programa externo gpg para a criptografia, mas, no geral, as diferen\u00e7as em rela\u00e7\u00e3o ao modo anterior s\u00e3o m\u00ednimas. O tempo total foi de 16 minutos e 30 segundos, com a verifica\u00e7\u00e3o dos dados em 6 minutos. A carga foi <\/p>\n

a seguinte:<\/b>\"Backup,
\n
\nAMANDA<\/i>, que usa tar, completou em 2 minutos e 49 segundos, o que, em princ\u00edpio, \u00e9 bastante pr\u00f3ximo ao tar comum. A carga no sistema, em princ\u00edpio, \u00e9 <\/p>\n

a mesma:<\/b>\"Backup,
\n
\nAo restaurar o backup usando zbackup<\/i> os seguintes resultados foram obtidos:<\/p>\n

criptografia, compress\u00e3o lzma<\/b>\"Backup,
\n
\nO tempo de opera\u00e7\u00e3o foi de 11 minutos e 8 segundos<\/p>\n

criptografia aes, compress\u00e3o lzma<\/b>\"Backup,
\n
\nO tempo de opera\u00e7\u00e3o foi de 14 minutos<\/p>\n

criptografia aes, compress\u00e3o lzo<\/b>\"Backup,
\n
\nO tempo de opera\u00e7\u00e3o foi de 6 minutos e 19 segundos<\/p>\n

Em geral, n\u00e3o est\u00e1 ruim. Tudo depende da velocidade do processador no servidor de backup, o que \u00e9 claramente vis\u00edvel pelo tempo de execu\u00e7\u00e3o do programa com diferentes compactadores. Do lado do servidor de backup, foi utilizado o tar comum, ent\u00e3o, se comparado a ele, a restaura\u00e7\u00e3o funciona tr\u00eas vezes mais devagar. Talvez valha a pena verificar o desempenho em modo multithread, com mais de dois threads.<\/p>\n

BorgBackup<\/i> no modo sem criptografia foi um pouco mais lento do que o tar, levando 2 minutos e 45 segundos, no entanto, ao contr\u00e1rio do tar, tornou-se poss\u00edvel a deduplica\u00e7\u00e3o do reposit\u00f3rio. A carga resultante foi <\/p>\n

a seguinte:<\/b>\"Backup,
\n
\nSe a criptografia baseada em blake for ativada, a velocidade de restaura\u00e7\u00e3o do backup diminui ligeiramente. O tempo de restaura\u00e7\u00e3o nesse modo \u00e9 de 3 minutos e 19 segundos, e a carga foi <\/p>\n

a seguinte:<\/b>\"Backup,
\n
\nA criptografia aes funciona um pouco mais lenta, o tempo de restaura\u00e7\u00e3o \u00e9 de 3 minutos e 23 segundos, a carga n\u00e3o <\/p>\n

mudou muito:<\/b>\"Backup,
\n
\nComo o Borg pode operar em modo multithread, a carga da CPU \u00e9 m\u00e1xima, e ao ativar recursos adicionais, o tempo de execu\u00e7\u00e3o simplesmente aumenta. Aparentemente, vale a pena investigar a multithread como \u00e9 feito no zbackup.<\/p>\n

Restic<\/i> desempenhou a recupera\u00e7\u00e3o um pouco mais devagar, levando 4 minutos e 28 segundos. A carga nesse caso foi <\/p>\n

assim:<\/b>\"Backup,
\n
\nAparentemente o processo de restaura\u00e7\u00e3o funciona em m\u00faltiplos threads, mas a efici\u00eancia n\u00e3o \u00e9 t\u00e3o alta quanto a do BorgBackup, mas \u00e9 compar\u00e1vel em tempo ao rsync comum.<\/p>\n

Com UrBackup<\/i> conseguiu recuperar os dados em 8 minutos e 19 segundos, a carga nesse caso foi <\/p>\n

a seguinte:<\/b>\"Backup,
\n
\nAinda \u00e9 vis\u00edvel uma carga n\u00e3o t\u00e3o alta, at\u00e9 menor que a do tar. Em certos momentos houve picos, mas n\u00e3o mais que a carga de um n\u00facleo.<\/p>\n

Escolha e justificativa de crit\u00e9rios para compara\u00e7\u00e3o<\/h2>\n

\nComo foi mencionado em um dos artigos anteriores, o sistema de backup deve atender aos seguintes crit\u00e9rios:<\/p>\n