{"id":35003,"date":"2019-10-31T22:01:46","date_gmt":"2019-10-31T19:01:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup\/"},"modified":"2019-10-31T22:01:46","modified_gmt":"2019-10-31T19:01:46","slug":"rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","title":{"rendered":"Backup, parte 4: Vis\u00e3o geral e teste do zbackup, restic, borgbackup,","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,<\/p>\n

<\/p>\n

Neste artigo, ser\u00e3o discutidos os softwares para backup que, ao dividir o fluxo de dados em componentes individuais (chunks), formam um reposit\u00f3rio.<\/p>\n

<\/p>\n

Os componentes do reposit\u00f3rio podem ser comprimidos e criptografados adicionalmente, e o mais importante \u2014 em processos repetidos de backup \u2014 podem ser reutilizados.<\/p>\n

<\/p>\n

Um backup em tal reposit\u00f3rio \u00e9 uma sequ\u00eancia nomeada de componentes inter-relacionados, por exemplo, com base em diferentes fun\u00e7\u00f5es hash.<\/p>\n

<\/p>\n

Existem v\u00e1rias solu\u00e7\u00f5es semelhantes, e vou me concentrar em 3: zbackup, borgbackup e restic.<\/p>\n

<\/a><\/noindex><\/p>\n

Resultados Esperados<\/h3>\n

<\/p>\n

Uma vez que todos os candidatos, de uma forma ou de outra, exigem a cria\u00e7\u00e3o de um reposit\u00f3rio, um dos fatores mais importantes ser\u00e1 a avalia\u00e7\u00e3o do tamanho do reposit\u00f3rio. Idealmente, seu tamanho n\u00e3o deve ultrapassar 13 GB de acordo com a metodologia adotada, e at\u00e9 menos \u2014 com uma boa otimiza\u00e7\u00e3o.<\/p>\n

<\/p>\n

Al\u00e9m disso, \u00e9 extremamente desej\u00e1vel ter a capacidade de criar backups de arquivos diretamente, sem o uso de arquivadores como o tar, assim como trabalhar com ssh\/sftp sem ferramentas adicionais como rsync e sshfs.<\/p>\n

<\/p>\n

Comportamento ao criar backups:<\/strong><\/p>\n

<\/p>\n

    \n
  1. O tamanho do reposit\u00f3rio ser\u00e1 igual ao tamanho das altera\u00e7\u00f5es, ou menor.<\/li>\n
  2. Esperamos uma grande carga no processador ao usar compress\u00e3o e\/ou criptografia, al\u00e9m de uma carga significativa na rede e no subsistema de disco, caso o processo de arquivamento e\/ou criptografia ocorra no servidor de armazenamento de backups.<\/li>\n
  3. Se o reposit\u00f3rio for corrompido, um erro latente pode ocorrer tanto ao criar novos backups quanto ao tentar restaur\u00e1-los. \u00c9 necess\u00e1rio planejar medidas adicionais para garantir a integridade do reposit\u00f3rio, ou usar ferramentas integradas para verificar sua integridade.<\/li>\n<\/ol>\n

    <\/p>\n

    Como refer\u00eancia, foi adotado o trabalho com tar, como foi demonstrado em um dos artigos anteriores.<\/p>\n

    <\/p>\n

    Testando zbackup<\/h3>\n

    <\/p>\n

    O mecanismo geral de funcionamento do zbackup \u00e9 que o programa encontra no fluxo de dados fornecido \u00e1reas que cont\u00eam dados id\u00eanticos, opcionalmente comprime, criptografa, mantendo cada \u00e1rea apenas uma vez.<\/p>\n

    <\/p>\n

    Para deduplica\u00e7\u00e3o, utiliza-se uma fun\u00e7\u00e3o hash de 64 bits com janela deslizante para verifica\u00e7\u00e3o byte a byte da correspond\u00eancia com blocos de dados j\u00e1 existentes (semelhante ao que \u00e9 realizado no rsync).<\/p>\n

    <\/p>\n

    Para compress\u00e3o, s\u00e3o aplicados lzma e lzo em execu\u00e7\u00e3o multithread, e para criptografia \u2014 aes. Nas vers\u00f5es mais recentes, h\u00e1 a possibilidade de remover dados antigos do reposit\u00f3rio no futuro.
    \nO programa foi escrito em C++ com depend\u00eancias m\u00ednimas. O autor aparentemente se inspirou no unix-way, portanto, o programa aceita dados via stdin ao criar backups, emitindo um fluxo de dados semelhante em stdout ao restaurar. Assim, o zbackup pode ser utilizado como um excelente 'tijolo' na elabora\u00e7\u00e3o de suas pr\u00f3prias solu\u00e7\u00f5es de backup. Por exemplo, para o autor do artigo, este programa tem sido a principal ferramenta de backup para m\u00e1quinas dom\u00e9sticas desde aproximadamente 2014.<\/p>\n

    <\/p>\n

    Como fluxo de dados, ser\u00e1 utilizado o tar comum, a menos que indicado de outra forma.<\/p>\n

    \nVamos ver quais ser\u00e3o os resultados:<\/b><\/p>\n

    A verifica\u00e7\u00e3o do funcionamento foi realizada em 2 variantes:<\/p>\n

    <\/p>\n

      \n
    1. \u00e9 criado um reposit\u00f3rio e o zbackup \u00e9 iniciado no servidor com os dados de origem, depois o conte\u00fado do reposit\u00f3rio \u00e9 transferido para o servidor de armazenamento de backups.<\/li>\n
    2. \u00e9 criado um reposit\u00f3rio no servidor de armazenamento de backups, o zbackup \u00e9 iniciado via ssh no servidor de armazenamento de backups, recebendo os dados atrav\u00e9s de pipe.<\/li>\n<\/ol>\n

      <\/p>\n

      Os resultados da primeira variante foram os seguintes: 43m11s \u2014 ao usar um reposit\u00f3rio n\u00e3o criptografado e o compressor lzma, 19m13s \u2014 ao substituir o compressor por lzo.<\/p>\n

      <\/p>\n

      A carga no servidor com os dados de origem foi a seguinte (mostramos um exemplo com lzma, com lzo foi uma imagem semelhante, mas a parte do rsync foi aproximadamente um quarto do tempo):<\/p>\n

      <\/p>\n

      \"Backup,<\/a><\/noindex><\/p>\n

      <\/p>\n

      \u00c9 claro que tal processo de backup \u00e9 apropriado apenas para mudan\u00e7as relativamente raras e pequenas. Al\u00e9m disso, \u00e9 extremamente desej\u00e1vel limitar o funcionamento do zbackup a 1 thread; caso contr\u00e1rio, haver\u00e1 uma carga bastante alta no processador, uma vez que o programa consegue trabalhar muito bem em m\u00faltiplas threads. A carga no disco foi baixa, o que no geral, dado o subsistema de disco moderno baseado em ssd, ser\u00e1 impercept\u00edvel. Tamb\u00e9m \u00e9 claramente vis\u00edvel o in\u00edcio do processo de sincroniza\u00e7\u00e3o de dados do reposit\u00f3rio para o servidor remoto, e a velocidade de opera\u00e7\u00e3o \u00e9 compar\u00e1vel ao rsync comum, estando restrita pela performance do subsistema de disco do servidor de armazenamento de backups. A desvantagem desse m\u00e9todo \u00e9 o armazenamento do reposit\u00f3rio local e, como consequ\u00eancia, a duplica\u00e7\u00e3o de dados.<\/p>\n

      <\/p>\n

      A segunda op\u00e7\u00e3o, que envolve executar o zbackup diretamente no servidor de armazenamento de backups, \u00e9 mais interessante e aplic\u00e1vel na pr\u00e1tica.<\/p>\n

      <\/p>\n

      Para come\u00e7ar, ser\u00e1 verificado o funcionamento sem o uso de criptografia com o compressor lzma:<\/p>\n

      <\/p>\n

      \"Backup,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Tempo de execu\u00e7\u00e3o de cada teste:<\/p>\n

      <\/p>\n

      Execu\u00e7\u00e3o 1
      \nExecu\u00e7\u00e3o 2
      \nExecu\u00e7\u00e3o 3<\/p>\n

      39m45s
      \n40m20s
      \n40m3s<\/p>\n

      7m36s
      \n8m3s
      \n7m48s<\/p>\n

      15m35s
      \n15m48s
      \n15m38s<\/p>\n

      <\/p>\n

      Se a criptografia utilizando aes for ativada, os resultados s\u00e3o bastante pr\u00f3ximos:<\/p>\n

      <\/p>\n

      \"Backup,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Tempo de execu\u00e7\u00e3o com os mesmos dados, com criptografia:<\/p>\n

      <\/p>\n

      Execu\u00e7\u00e3o 1
      \nExecu\u00e7\u00e3o 2
      \nExecu\u00e7\u00e3o 3<\/p>\n

      43m40s
      \n44m12s
      \n44m3s<\/p>\n

      8m3s
      \n8m15s
      \n8m12s<\/p>\n

      15m0s
      \n15m40s
      \n15m25s<\/p>\n

      <\/p>\n

      Se a criptografia for combinada com a compress\u00e3o lzo, os resultados s\u00e3o:<\/p>\n

      <\/p>\n

      \"Backup,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Tempo de execu\u00e7\u00e3o:<\/p>\n

      <\/p>\n

      Execu\u00e7\u00e3o 1
      \nExecu\u00e7\u00e3o 2
      \nExecu\u00e7\u00e3o 3<\/p>\n

      18m2s
      \n18m15s
      \n18m12s<\/p>\n

      5m13s
      \n5m24s
      \n5m20s<\/p>\n

      8m48s
      \n9m3s
      \nO tamanho do reposit\u00f3rio resultante foi relativamente igual e totalizou 13GB. Isso significa que a deduplica\u00e7\u00e3o est\u00e1 funcionando corretamente. Al\u00e9m disso, aplicar lzo em dados j\u00e1 comprimidos proporciona um efeito significativo, fazendo com que o tempo total de execu\u00e7\u00e3o do zbackup se aproxime do duplicity\/duplicati, embora fique atr\u00e1s dos baseados em librsync de 2 a 5 vezes.<\/p>\n

      <\/p>\n

      As vantagens s\u00e3o claras \u2014 economia de espa\u00e7o em disco no servidor de armazenamento de backups. Quanto \u00e0s ferramentas de verifica\u00e7\u00e3o do reposit\u00f3rio \u2014 n\u00e3o est\u00e3o previstas pelo autor do zbackup, sendo recomendado o uso de um arranjo de disco redundante ou provedor de nuvem.<\/p>\n

      <\/p>\n

      No geral, uma impress\u00e3o bastante boa, apesar de o projeto estar estagnado h\u00e1 cerca de 3 anos (o \u00faltimo pedido de funcionalidade foi h\u00e1 cerca de um ano, mas sem resposta).<\/p>\n

      <\/p>\n

      Testando borgbackup<\/p>\n

      <\/p>\n

      O Borgbackup \u00e9 um fork do attic, outro sistema semelhante ao zbackup. Escrito em python, possui uma lista de funcionalidades semelhante \u00e0 do zbackup, mas tamb\u00e9m tem a capacidade de:<\/h3>\n

      <\/p>\n

      Montar backups via fuse<\/p>\n

      <\/p>\n