{"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\/sl\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","title":{"rendered":"Varnostno kopiranje, del 4: Pregled in testiranje zbackup, restic, borgbackup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Varnostno<\/p>\n

<\/p>\n

V tem \u010dlanku bomo obravnavali programska sredstva za varnostno kopiranje, ki z razbitjem toka podatkov na posamezne komponente (chunks) oblikujejo repozitorij.<\/p>\n

<\/p>\n

Komponente repozitorija se lahko dodatno stisnejo in \u0161ifrirajo, najpomembnej\u0161e pa je, da se lahko pri ponovnih procesih varnostnega kopiranja ponovno uporabijo.<\/p>\n

<\/p>\n

Varnostna kopija v takem repozitoriju je poimenovana veriga povezanih komponent, na primer, na osnovi razli\u010dnih hash-funkcij.<\/p>\n

<\/p>\n

Obstaja ve\u010d tak\u0161nih re\u0161itev, osredoto\u010dil se bom na 3: zbackup, borgbackup in restic.<\/p>\n

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

Pri\u010dakovani rezultati<\/h3>\n

<\/p>\n

Ker vsi kandidati na tak ali druga\u010den na\u010din zahtevajo ustvarjanje repozitorija, bo eden najpomembnej\u0161ih dejavnikov ocena velikosti repozitorija. V idealnem primeru ne sme biti ve\u010dji od 13 GB v skladu s sprejeto metodologijo, lahko pa je tudi manj \u2014 ob dobri optimizaciji.<\/p>\n

<\/p>\n

Prav tako je zelo za\u017eeleno imeti mo\u017enost ustvarjati varnostne kopije datotek neposredno, brez uporabe arhivatorjev, kot je tar, ter delovati z ssh\/sftp brez dodatnih sredstev, kot sta rsync in sshfs.<\/p>\n

<\/p>\n

Obna\u0161anje pri ustvarjanju varnostnih kopij:<\/strong><\/p>\n

<\/p>\n

    \n
  1. Velikost repozitorija bo enaka velikosti sprememb ali manj\u0161a.<\/li>\n
  2. Pri\u010dakuje se velika obremenitev procesorja pri uporabi stiskanja in\/ali \u0161ifriranja, prav tako je verjetna precej\u0161nja obremenitev omre\u017eja in diska, \u010de bo postopek arhiviranja in\/ali \u0161ifriranja potekal na stre\u017eniku za shranjevanje varnostnih kopij.<\/li>\n
  3. \u010ce se repozitorij po\u0161koduje, obstaja verjetnost zamudne napake tako pri ustvarjanju novih varnostnih kopij kot pri poskusu obnovitve. Treba je na\u010drtovati dodatne ukrepe za zagotavljanje celovitosti repozitorija ali uporabiti vgrajena orodja za preverjanje njegove celovitosti.<\/li>\n<\/ol>\n

    <\/p>\n

    Kot referen\u010dna vrednost je bila sprejeta uporaba tar, kot je bilo prikazano v enem od prej\u0161njih \u010dlankov.<\/p>\n

    <\/p>\n

    Testiranje zbackup<\/h3>\n

    <\/p>\n

    Splo\u0161ni mehanizem delovanja zbackup je, da program v toku podatkov, ki se dovaja na vhodu, najde podro\u010dja z enakimi podatki, jih po potrebi stisne, \u0161ifrira in shranjuje vsako podro\u010dje le enkrat.<\/p>\n

    <\/p>\n

    Za deduplikacijo se uporablja 64-bitna kro\u017ena hash-funkcija s pomi\u010dnim oknom za byte-po-byte preverjanje ujemanja z \u017ee obstoje\u010dimi bloki podatkov (podobno, kot je to izvedeno v rsync).<\/p>\n

    <\/p>\n

    Za stiskanje se uporablja lzma in lzo v ve\u010dnitnem izvajanja, za \u0161ifriranje pa aes. V zadnjih razli\u010dicah je prisotna mo\u017enost v prihodnosti odstraniti stare podatke iz repozitorija.
    \nProgram je napisana u C++ s minimalnim zavisnostima. Autor je o\u010digledno inspirisan unix-way, tako da program prihvata podatke na stdin prilikom izrade rezervnih kopija, izdaju\u0107i sli\u010dan tok podataka u stdout prilikom obnavljanja. Tako se zbackup mo\u017ee koristiti kao vrlo dobar 'kamen' prilikom pisanja sopstvenih re\u0161enja za rezervne kopije. Na primer, kod autora ovog \u010dlanka, ova aplikacija je osnovni alat za rezervne kopije za ku\u0107ne ma\u0161ine otprilike od 2014. godine.<\/p>\n

    <\/p>\n

    Kot podatkovni tok se bo uporabil obi\u010dajen tar, \u010de ne bo druga\u010de navedeno.<\/p>\n

    \nPoglejmo, kak\u0161ni bodo rezultati:<\/b><\/p>\n

    Preverjanje delovanja je potekalo v 2 razli\u010dicah:<\/p>\n

    <\/p>\n

      \n
    1. ustvari se repozitorij in za\u017eene zbackup na stre\u017eniku s prvotnimi podatki, nato se vsebina repozitorija prenese na stre\u017enik za shranjevanje varnostnih kopij.<\/li>\n
    2. ustvari se repozitorij na stre\u017eniku za shranjevanje varnostnih kopij, zbackup se za\u017eene preko ssh na stre\u017eniku za shranjevanje varnostnih kopij, podatki pa se mu posredujejo preko pipe.<\/li>\n<\/ol>\n

      <\/p>\n

      Rezultati prve razli\u010dice so bili tak\u0161ni: 43m11s \u2014 pri uporabi ne\u0161ifriranega repozitorija in stiskalnika lzma, 19m13s \u2014 pri zamenjavi stiskalnika z lzo.<\/p>\n

      <\/p>\n

      Obremenitev na stre\u017eniku s prvotnimi podatki je bila naslednja (prikazan je primer z lzma, z lzo je bila slika pribli\u017eno enaka, vendar je dele\u017e rsync zna\u0161al pribli\u017eno \u010detrtino \u010dasa):<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Jasno je da je takav proces izrade sigurnosnih kopija koristan samo pri relativno rijetkim i malim promjenama. Tako\u0111er, vrlo je po\u017eeljno ograni\u010diti rad zbackup-a na 1 nit, ina\u010de \u0107e optere\u0107enje CPU-a biti vrlo visoko, jer program vrlo dobro radi s vi\u0161e niti. Optere\u0107enje diska je bilo malo, \u0161to \u0107e u cijelosti biti neprimjetno uz moderni diskski sustav temeljen na SSD-u. Tako\u0111er je jasno pokrenut proces sinkronizacije podataka repozitorija na udaljeni server, brzina rada usporediva je s obi\u010dnim rsync-om i ograni\u010dena je performansama diskskog sustava servera za pohranu sigurnosnih kopija. Nedostatak pristupa je pohranjivanje lokalnog repozitorija i, kao posljedica, - dupliciranje podataka.<\/p>\n

      <\/p>\n

      Zanimljivija i primjenjivija opcija u praksi je druga varijanta s pokretanjem zbackup-a odmah na serveru za pohranu sigurnosnih kopija.<\/p>\n

      <\/p>\n

      Za po\u010detak \u0107e biti provjerena funkcionalnost bez kori\u0161tenja \u0161ifriranja s kompresorom lzma:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Vrijeme rada svakog testnog pokretanja:<\/p>\n

      <\/p>\n

      Pokretanje 1
      \nPokretanje 2
      \nPokretanje 3<\/p>\n

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

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

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

      <\/p>\n

      Ako aktivirate \u0161ifriranje pomo\u0107u aes, rezultati su prili\u010dno bliski:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Vrijeme rada na istim podacima, s \u0161ifriranjem:<\/p>\n

      <\/p>\n

      Pokretanje 1
      \nPokretanje 2
      \nPokretanje 3<\/p>\n

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

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

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

      <\/p>\n

      Ako \u0161ifriranje spojite s kompresijom na lzo, ispadne ovako:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Vrijeme rada:<\/p>\n

      <\/p>\n

      Pokretanje 1
      \nPokretanje 2
      \nPokretanje 3<\/p>\n

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

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

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

      <\/p>\n

      Veli\u010dina rezultantnog repozitorija bila je relativno ista i iznosila je 13GB. To zna\u010di da deduplikacija radi ispravno. Tako\u0111er, na ve\u0107 komprimiranim podacima primjena lzo daje zna\u010dajan u\u010dinak, ukupno vrijeme rada zbackup-a pribli\u017eava se duplicity\/duplicati, ali zaostaje za onima temeljenima na librsync-u 2-5 puta.<\/p>\n

      <\/p>\n

      Prednosti su o\u010digledne - u\u0161teda prostora na disku na serveru za pohranu sigurnosnih kopija. \u0160to se ti\u010de alata za provjeru repozitorija - autor zbackup-a ih nije predvidio, preporu\u010duje se kori\u0161tenje otpornog diskskog niza ili cloud provajdera.<\/p>\n

      <\/p>\n

      U cjelini vrlo dobar dojam, unato\u010d tome \u0161to projekt otprilike 3 godine stagnira (posljednji zahtjev za funkcionalno\u0161\u0107u je bio prije otprilike godinu dana, ali bez odgovora).<\/p>\n

      <\/p>\n

      Testiranje borgbackup-a<\/h3>\n

      <\/p>\n

      Borgbackup je fork attic-a, jo\u0161 jednog sustava sli\u010dnog zbackup-u. Napisan je na pythonu, ima sli\u010dan popis mogu\u0107nosti kao zbackup, ali dodatno zna:<\/p>\n

      <\/p>\n