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

\"Backup,<\/p>\n

<\/p>\n

U ovom \u0107e se \u010dlanku razmatrati softverski alati za izradu sigurnosnih kopija, koji razdvajanjem toka podataka na pojedina\u010dne komponente (chunks) formiraju repozitorij.<\/p>\n

<\/p>\n

Komponente repozitorija mogu se dodatno komprimirati i \u0161ifrirati, a najva\u017enije je da se pri ponovnim procesima izrade sigurnosnih kopija ponovo koriste.<\/p>\n

<\/p>\n

Sigurnosna kopija u takvom repozitoriju je imenovani lanac povezanih komponenti, na primjer, na temelju razli\u010ditih hash funkcija.<\/p>\n

<\/p>\n

Postoji nekoliko sli\u010dnih rje\u0161enja, a ja \u0107u se osvrnuti na 3: zbackup, borgbackup i restic.<\/p>\n

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

O\u010dekivani rezultati<\/h3>\n

<\/p>\n

Budu\u0107i da svi kandidati zahtijevaju stvaranje repozitorija, jedan od najva\u017enijih faktora bit \u0107e procjena veli\u010dine repozitorija. U idealnom slu\u010daju njegova veli\u010dina ne bi trebala biti ve\u0107a od 13 GB prema usvojenoj metodologiji, a mo\u017eda \u010dak i manje \u2014 pod uvjetom dobre optimizacije.<\/p>\n

<\/p>\n

Tako\u0111er, izuzetno je po\u017eeljno imati mogu\u0107nost izrade sigurnosnih kopija datoteka izravno, bez kori\u0161tenja arhivatora poput tar, kao i rad s ssh\/sftp bez dodatnih alata poput rsync i sshfs.<\/p>\n

<\/p>\n

Pona\u0161anje prilikom izrade sigurnosnih kopija:<\/strong><\/p>\n

<\/p>\n

    \n
  1. Veli\u010dina repozitorija bit \u0107e jednaka veli\u010dini promjena, ili manja.<\/li>\n
  2. O\u010dekuje se velika optere\u0107enja procesora prilikom kori\u0161tenja kompresije i\/ili \u0161ifriranja, a tako\u0111er je vjerojatno da \u0107e biti zna\u010dajno optere\u0107enje mre\u017ee i diskovnog sustava, ako proces arhiviranja i\/ili \u0161ifriranja radi na poslu\u017eitelju za pohranu sigurnosnih kopija.<\/li>\n
  3. Ako do\u0111e do o\u0161te\u0107enja repozitorija, mogu se pojaviti odgo\u0111ene gre\u0161ke prilikom izrade novih sigurnosnih kopija, kao i prilikom poku\u0161aja oporavka. Trebalo bi planirati dodatne mjere za osiguranje integriteta repozitorija ili koristiti ugra\u0111ene alate za provjeru njegove cjelovitosti.<\/li>\n<\/ol>\n

    <\/p>\n

    Kao referentna vrijednost uzeta je obrada s tar-om, kako je to pokazano u jednom od prethodnih \u010dlanaka.<\/p>\n

    <\/p>\n

    Testiranje zbackup-a<\/h3>\n

    <\/p>\n

    Op\u0107i mehanizam rada zbackupa sastoji se u tome da program pronalazi u toku podataka, koji se predaje na ulazu, podru\u010dja koja sadr\u017ee jednake podatke, a zatim ih po potrebi komprimira, \u0161ifrira, \u010duvaju\u0107i svako podru\u010dje samo 1 put.<\/p>\n

    <\/p>\n

    Za deduplifikaciju koristi se 64-bitna kru\u017ena hash funkcija sa pomi\u010dnim prozorom za bajt-po-bajt provjeru podudarnosti sa ve\u0107 postoje\u0107im blokovima podataka (sli\u010dno onome kako je to implementirano u rsync-u).<\/p>\n

    <\/p>\n

    Za kompresiju se koristi lzma i lzo u vi\u0161ezada\u0107nom izvo\u0111enju, a za \u0161ifriranje \u2014 aes. U novijim verzijama dodana je mogu\u0107nost budu\u0107eg brisanja starih podataka iz repozitorija.
    \nProgram je napisana na C++ s minimalnim zavisnostima. Autor se o\u010dito inspirirao unix-way, pa program prima podatke preko stdin prilikom stvaranja sigurnosnih kopija, izdaju\u0107i sli\u010dan tok podataka u stdout prilikom vra\u0107anja. Tako se zbackup mo\u017ee koristiti kao vrlo dobar «gra\u0111evni blok» prilikom pisanja vlastitih rje\u0161enja za sigurnosno kopiranje. Na primjer, za autora ovog \u010dlanka, ova je programa glavni alat za sigurnosno kopiranje za ku\u0107ne strojeve otprilike od 2014. godine.<\/p>\n

    <\/p>\n

    Kao tok podataka koristiti \u0107e se obi\u010dni tar, osim ako nije druga\u010dije navedeno.<\/p>\n

    \nPogledajmo kakvi \u0107e biti rezultati:<\/b><\/p>\n

    Provjera rada obavljena je u 2 varijante:<\/p>\n

    <\/p>\n

      \n
    1. stvara se repozitorij i pokre\u0107e zbackup na serveru s izvornih podacima, zatim se sadr\u017eaj repozitorija prenosi na server za pohranu sigurnosnih kopija.<\/li>\n
    2. stvara se repozitorij na serveru za pohranu sigurnosnih kopija, pokre\u0107e se zbackup putem ssh na serveru za pohranu sigurnosnih kopija, a podaci se isporu\u010duju kroz cijev.<\/li>\n<\/ol>\n

      <\/p>\n

      Rezultati prve varijante bili su sljede\u0107i: 43m11s \u2014 pri kori\u0161tenju ne\u0161ifriranog repozitorija i kompresora lzma, 19m13s \u2014 prilikom zamjene kompresora na lzo.<\/p>\n

      <\/p>\n

      Optere\u0107enje na serveru s izvornih podacima bilo je sljede\u0107e (prikazan primjer s lzma, s lzo bio je otprilike sli\u010dno, ali udio rsync bio je otprilike \u010detvrtina vremena):<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Jasno je vidljivo da ovakav proces sigurnosnog kopiranja odgovara samo pri relativno rijetkim i malim promjenama. Tako\u0111er, izuzetno je po\u017eeljno ograni\u010diti rad zbackup-a na 1 tok, ina\u010de \u0107e optere\u0107enje procesora biti vrlo visoko, jer program vrlo dobro radi u nekoliko tokova. Optere\u0107enje na disku bilo je malo, \u0161to u cjelini pri suvremenom diskskom sustavu temeljenom na ssd-u ne\u0107e biti primjetno. Tako\u0111er se jasno vidi pokretanje procesa sinkronizacije podataka repozitorija na udaljeni server, brzina rada usporediva je s obi\u010dnim rsync i ovisi o performansama diskskog sustava servera za pohranu sigurnosnih kopija. Nedostatak pristupa je pohrana lokalnog repozitorija i, kao posljedica toga, \u2014 dupliciranje podataka.<\/p>\n

      <\/p>\n

      Druga opcija koja uklju\u010duje pokretanje zbackup-a izravno na poslu\u017eitelju za pohranu rezervnih kopija je zanimljivija i prakti\u010dnija.<\/p>\n

      <\/p>\n

      Za po\u010detak \u0107e se testirati rad bez kori\u0161tenja enkripcije uz kompresor lzma:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Vrijeme trajanja 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 se aktivira enkripcija pomo\u0107u aes, rezultati su prili\u010dno sli\u010dni:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Vrijeme trajanja na istim podacima s enkripcijom:<\/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 se enkripcija kombinira s kompresijom na lzo, rezultati su sljede\u0107i:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Vrijeme trajanja:<\/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 jednaka i iznosila je 13 GB. To zna\u010di da deduplikacija radi ispravno. Tako\u0111er, primjena lzo na ve\u0107 komprimiranim podacima daje zna\u010dajan u\u010dinak, ukupno vrijeme rada zbackup-a pribli\u017eava se duplicity\/duplicati, ali je 2-5 puta sporiji od rje\u0161enja temeljenih na librsyncu.<\/p>\n

      <\/p>\n

      Prednosti su o\u010dite \u2014 \u0161tednja prostora na disku na poslu\u017eitelju za pohranu rezervnih kopija. \u0160to se ti\u010de alata za provjeru repozitorija \u2014 autor zbackup-a ih nije predvidio, preporu\u010duje se koristiti redundantni diskovni niz ili obla\u010dnog provajdera.<\/p>\n

      <\/p>\n

      Op\u0107enito, dojam je prili\u010dno dobar, unato\u010d tome \u0161to projekt ve\u0107 oko 3 godine stagnira (posljednji zahtjev za novom funkcionalno\u0161\u0107u bio je prije otprilike godine 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 python-u, ima sli\u010dan set mogu\u0107nosti kao zbackup, ali dodatno mo\u017ee:<\/p>\n

      <\/p>\n