{"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\/ro\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","title":{"rendered":"Backup, partea 4: Revizuirea \u0219i testarea zbackup, restic, borgbackup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,<\/p>\n

<\/p>\n

\u00cen acest articol vor fi discutate instrumentele software pentru backup, care prin fragmentarea fluxului de date \u00een componente separate (chunks), formeaz\u0103 un repository.<\/p>\n

<\/p>\n

Componentele repository-ului pot fi, de asemenea, comprimate \u0219i criptate, iar cel mai important \u2014 \u00een cadrul proceselor repetate de backup \u2014 pot fi reutilizate.<\/p>\n

<\/p>\n

Un backup \u00een acest tip de repository este un lan\u021b denumit de componente interconectate, de exemplu, bazat pe diferite func\u021bii hash.<\/p>\n

<\/p>\n

Exist\u0103 c\u00e2teva solu\u021bii similare, m\u0103 voi opri la 3: zbackup, borgbackup \u0219i restic.<\/p>\n

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

Rezultatele a\u0219teptate<\/h3>\n

<\/p>\n

Deoarece to\u021bi candida\u021bii cer \u00een mod necesar crearea unui repository, unul dintre cei mai importan\u021bi factori va fi estimarea dimensiunii repository-ului. \u00centr-un scenariu ideal, dimensiunea acestuia nu ar trebui s\u0103 dep\u0103\u0219easc\u0103 13 GB conform metodologiei standardizate, sau chiar mai pu\u021bin \u2014 cu condi\u021bia unei bune optimiz\u0103ri.<\/p>\n

<\/p>\n

De asemenea, ar fi foarte de dorit s\u0103 exist\u0103 posibilitatea de a crea backup-uri ale fi\u0219ierelor direct, f\u0103r\u0103 a folosi arhivatoare precum tar, precum \u0219i suport pentru ssh\/sftp f\u0103r\u0103 instrumente adi\u021bionale precum rsync \u0219i sshfs.<\/p>\n

<\/p>\n

Comportamentul la crearea backup-urilor:<\/strong><\/p>\n

<\/p>\n

    \n
  1. Dimensiunea repository-ului va fi egal\u0103 cu dimensiunea modific\u0103rilor sau mai mic\u0103.<\/li>\n
  2. Se a\u0219teapt\u0103 o \u00eenc\u0103rcare mare a procesorului atunci c\u00e2nd se utilizeaz\u0103 comprimarea \u0219i\/sau criptarea, iar, de asemenea, este probabil\u0103 o \u00eenc\u0103rcare semnificativ\u0103 asupra re\u021belei \u0219i subsistemului de disc, dac\u0103 procesul de arhivare \u0219i\/sau criptare se va desf\u0103\u0219ura pe serverul de stocare a backup-urilor.<\/li>\n
  3. Dac\u0103 repository-ul este deteriorat \u2014 este probabil\u0103 o eroare temporal\u0103 at\u00e2t \u00een timpul cre\u0103rii de noi backup-uri, c\u00e2t \u0219i \u00een timpul tentativei de recuperare. Este necesar s\u0103 planific\u0103m m\u0103suri suplimentare pentru asigurarea integrit\u0103\u021bii repository-ului sau s\u0103 folosim instrumentele integrate de verificare a integrit\u0103\u021bii acestuia.<\/li>\n<\/ol>\n

    <\/p>\n

    Ca valoare de referin\u021b\u0103, s-a acceptat lucrul cu tar, a\u0219a cum a fost demonstrat \u00eentr-unul din articolele anterioare.<\/p>\n

    <\/p>\n

    Testarea zbackup<\/h3>\n

    <\/p>\n

    Mecanismul general de func\u021bionare al zbackup const\u0103 \u00een faptul c\u0103 programul identific\u0103 \u00een fluxul de date furnizat la intrare zonele care con\u021bin date identice, apoi le comprim\u0103 op\u021bional, le cripteaz\u0103, p\u0103str\u00e2nd fiecare zon\u0103 o singur\u0103 dat\u0103.<\/p>\n

    <\/p>\n

    Pentru deduplicare se folose\u0219te o func\u021bie hash rotund\u0103 de 64 de bi\u021bi cu fereastr\u0103 mobil\u0103 pentru verificarea pe byte a coresponden\u021belor cu blocurile de date deja existente (asem\u0103n\u0103tor cu ce este implementat \u00een rsync).<\/p>\n

    <\/p>\n

    Pentru compresie se utilizeaz\u0103 lzma \u0219i lzo \u00een execu\u021bie multi-threaded, iar pentru criptare \u2014 aes. \u00cen versiunile recente exist\u0103 posibilitatea de a \u0219terge date vechi din repository \u00een viitor.
    \nProgramul este scris \u00een C++ cu dependen\u021be minime. Autorul pare s\u0103 fi fost inspirat de unix-way, a\u0219a c\u0103 programul prime\u0219te date pe stdin atunci c\u00e2nd creeaz\u0103 copii de rezerv\u0103, gener\u00e2nd un flux de date similar \u00een stdout la restaurare. Astfel, zbackup poate fi folosit ca un «element de baz\u0103» destul de bun pentru a crea solu\u021bii proprii de copiere de rezerv\u0103. De exemplu, pentru autorul articolului, acest program este principalul instrument de copiere de rezerv\u0103 pentru calculatoarele de acas\u0103 din aproximativ 2014.<\/p>\n

    <\/p>\n

    Fluxul de date va fi tar-ul obi\u0219nuit, dac\u0103 nu se specific\u0103 altfel.<\/p>\n

    \nS\u0103 vedem ce rezultate vor fi:<\/b><\/p>\n

    Testarea a fost efectuat\u0103 \u00een 2 variante:<\/p>\n

    <\/p>\n

      \n
    1. se creeaz\u0103 un repository \u0219i se lanseaz\u0103 zbackup pe serverul cu datele originale, apoi con\u021binutul repository-ului este transferat pe serverul de stocare a backup-urilor.<\/li>\n
    2. se creeaz\u0103 un repository pe serverul de stocare a backup-urilor, zbackup este lansat prin ssh pe serverul de stocare a backup-urilor, \u0219i i se furnizeaz\u0103 datele prin pipe.<\/li>\n<\/ol>\n

      <\/p>\n

      Rezultatele primei variante au fost urm\u0103toarele: 43m11s \u2014 folosind repository necriptat \u0219i compresor lzma, 19m13s \u2014 c\u00e2nd compresorul a fost \u00eenlocuit cu lzo.<\/p>\n

      <\/p>\n

      \u00cenc\u0103rcarea pe serverul cu datele originale a fost urm\u0103toarea (exemplul cu lzma este prezentat, cu lzo a fost o imagine similar\u0103, dar partea de rsync a fost de aproximativ un sfert din timp):<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Este clar c\u0103 un astfel de proces de backup este util doar \u00een cazul unor schimb\u0103ri relativ rare \u0219i mici. De asemenea, este extrem de recomandat s\u0103 se limiteze func\u021bionarea zbackup la un singur fir de execu\u021bie, altfel va exista o \u00eenc\u0103rcare destul de mare pe procesor, deoarece programul \u0219tie s\u0103 func\u021bioneze eficient \u00een mai multe fire. \u00cenc\u0103rcarea pe disc a fost mic\u0103, ceea ce \u00een general, av\u00e2nd \u00een vedere sistemele moderne de disc bazate pe SSD, va fi imperceptibil. De asemenea, este clar vizibil \u00eenceputul procesului de sincronizare a datelor din depozitul de date pe serverul remote, viteza de lucru este comparabil\u0103 cu cea a rsync-ului obi\u0219nuit \u0219i este limitat\u0103 de performan\u021ba sistemului de disc al serverului de stocare a backup-urilor. Un dezavantaj al acestei metode este stocarea depozitului local \u0219i, prin urmare, duplicarea datelor.<\/p>\n

      <\/p>\n

      O variant\u0103 mai interesant\u0103 \u0219i aplicabil\u0103 \u00een practic\u0103 este a doua op\u021biune de a rula zbackup direct pe serverul de stocare a backup-urilor.<\/p>\n

      <\/p>\n

      \u00cen primul r\u00e2nd, va fi verificat\u0103 func\u021bionarea f\u0103r\u0103 utilizarea cript\u0103rii cu compresorul lzma:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Timpul de execu\u021bie pentru fiecare test:<\/p>\n

      <\/p>\n

      Execu\u021bie 1
      \nExecu\u021bie 2
      \nExecu\u021bie 3<\/p>\n

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

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

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

      <\/p>\n

      Dac\u0103 activa\u021bi criptarea folosind aes, rezultatele sunt destul de apropiate:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Timpul de lucru cu acelea\u0219i date, cu criptare:<\/p>\n

      <\/p>\n

      Execu\u021bie 1
      \nExecu\u021bie 2
      \nExecu\u021bie 3<\/p>\n

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

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

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

      <\/p>\n

      Dac\u0103 criptarea este combinat\u0103 cu compresia pe lzo, rezultatele sunt urm\u0103toarele:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Timpul de lucru:<\/p>\n

      <\/p>\n

      Execu\u021bie 1
      \nExecu\u021bie 2
      \nExecu\u021bie 3<\/p>\n

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

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

      8m48s
      \n9m3s
      \n8m51s<\/p>\n

      <\/p>\n

      Dimensiunea depozitului rezultat a fost relativ constant\u0103 \u0219i a fost de 13gb. Aceasta \u00eenseamn\u0103 c\u0103 deduplicarea func\u021bioneaz\u0103 corect. De asemenea, aplicarea lzo pe date deja comprimate ofer\u0103 un efect semnificativ, iar timpul total de execu\u021bie al zbackup se apropie de cel al duplicity\/duplicati, de\u0219i este mai lent cu 2-5 ori comparativ cu cele bazate pe librsync.<\/p>\n

      <\/p>\n

      Avantajele sunt evidente \u2014 economisirea spa\u021biului pe disc pe serverul de stocare a backup-urilor. C\u00e2t despre instrumentele de verificare a depozitului \u2014 acestea nu sunt prev\u0103zute de creatorul zbackup, se recomand\u0103 utilizarea unui sistem RAID sau a unui furnizor de cloud.<\/p>\n

      <\/p>\n

      \u00cen general, impresia este destul de pl\u0103cut\u0103, \u00een ciuda faptului c\u0103 proiectul este static de aproximativ 3 ani (ultima cerere de func\u021bionalitate a fost acum aproximativ un an, dar f\u0103r\u0103 r\u0103spuns).<\/p>\n

      <\/p>\n

      Testarea borgbackup<\/h3>\n

      <\/p>\n

      Borgbackup este un fork al attic, un alt sistem similar cu zbackup. Este scris \u00een python, are o list\u0103 similar\u0103 de func\u021bionalit\u0103\u021bi cu zbackup, dar are \u0219i capacitatea suplimentar\u0103 de:<\/p>\n

      <\/p>\n