{"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\/pl\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","title":{"rendered":"Kopia zapasowa, cz\u0119\u015b\u0107 4: Przegl\u0105d i testowanie zbackup, restic, borgbackup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kopia<\/p>\n

<\/p>\n

W tym artykule om\u00f3wimy narz\u0119dzia programowe do tworzenia kopii zapasowych, kt\u00f3re, dziel\u0105c dane na indywidualne komponenty (chunks), tworz\u0105 repozytorium.<\/p>\n

<\/p>\n

Komponenty repozytorium mog\u0105 by\u0107 dodatkowo kompresowane i szyfrowane, a co najwa\u017cniejsze \u2014 podczas kolejnych proces\u00f3w tworzenia kopii zapasowych \u2014 mog\u0105 by\u0107 wielokrotnie wykorzystywane.<\/p>\n

<\/p>\n

Kopia zapasowa w takim repozytorium to nazwany \u0142a\u0144cuch powi\u0105zanych ze sob\u0105 komponent\u00f3w, na przyk\u0142ad oparty na r\u00f3\u017cnych funkcjach skr\u00f3tu hash.<\/p>\n

<\/p>\n

Istnieje kilka takich rozwi\u0105za\u0144, skupi\u0119 si\u0119 na 3: zbackup, borgbackup i restic.<\/p>\n

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

Oczekiwane wyniki<\/h3>\n

<\/p>\n

Poniewa\u017c wszyscy kandydaci w mniejszym lub wi\u0119kszym stopniu wymagaj\u0105 utworzenia repozytorium, jednym z najwa\u017cniejszych czynnik\u00f3w b\u0119dzie ocena rozmiaru repozytorium. W idealnym przypadku jego rozmiar powinien wynosi\u0107 nie wi\u0119cej ni\u017c 13 GB zgodnie z przyj\u0119t\u0105 metod\u0105, a nawet mniej \u2014 przy dobrej optymalizacji.<\/p>\n

<\/p>\n

Bardzo po\u017c\u0105dane jest r\u00f3wnie\u017c, aby m\u00f3c tworzy\u0107 kopie zapasowe plik\u00f3w bezpo\u015brednio, bez u\u017cycia archiwizator\u00f3w takich jak tar, oraz korzysta\u0107 z ssh\/sftp bez dodatkowych narz\u0119dzi, takich jak rsync i sshfs.<\/p>\n

<\/p>\n

Zachowanie przy tworzeniu kopii zapasowych:<\/strong><\/p>\n

<\/p>\n

    \n
  1. Rozmiar repozytorium b\u0119dzie r\u00f3wny rozmiarowi zmian lub mniejszy.<\/li>\n
  2. Oczekiwane jest du\u017ce obci\u0105\u017cenie procesora przy u\u017cyciu kompresji i\/lub szyfrowania, a tak\u017ce prawdopodobnie do\u015b\u0107 du\u017ce obci\u0105\u017cenie sieci i podsystemu dyskowego, je\u015bli proces archiwizacji i\/lub szyfrowania b\u0119dzie dzia\u0142a\u0142 na serwerze przechowuj\u0105cym kopie zapasowe.<\/li>\n
  3. Je\u015bli uszkodzimy repozytorium \u2014 prawdopodobna jest op\u00f3\u017aniona awaria zar\u00f3wno podczas tworzenia nowych kopii zapasowych, jak i podczas pr\u00f3by przywracania. Nale\u017cy zaplanowa\u0107 dodatkowe \u015brodki zapewniaj\u0105ce integralno\u015b\u0107 repozytorium lub skorzysta\u0107 z wbudowanych narz\u0119dzi do sprawdzania jego integralno\u015bci.<\/li>\n<\/ol>\n

    <\/p>\n

    Jako warto\u015b\u0107 odniesienia przyj\u0119to prac\u0119 z tar, jak pokazano w jednym z wcze\u015bniejszych artyku\u0142\u00f3w.<\/p>\n

    <\/p>\n

    Testowanie zbackup<\/h3>\n

    <\/p>\n

    Og\u00f3lny mechanizm dzia\u0142ania zbackup polega na tym, \u017ce program znajduje w strumieniu danych dostarczanym na wej\u015bciu obszary zawieraj\u0105ce te same dane, a nast\u0119pnie opcjonalnie je kompresuje, szyfruje, zachowuj\u0105c ka\u017cdy obszar tylko raz.<\/p>\n

    <\/p>\n

    Do deplikacji u\u017cywana jest 64-bitowa funkcja skr\u00f3tu z pier\u015bcieniem o zmiennym oknie do bajtowego sprawdzania zgodno\u015bci z ju\u017c istniej\u0105cymi blokami danych (podobnie jak w rsync).<\/p>\n

    <\/p>\n

    Do kompresji u\u017cywane s\u0105 lzma i lzo w wielow\u0105tkowym wykonaniu, a do szyfrowania \u2014 aes. W najnowszych wersjach istnieje mo\u017cliwo\u015b\u0107 w przysz\u0142o\u015bci usuwania starych danych z repozytorium.
    \nProgram jest napisana w C++ z minimalnymi zale\u017cno\u015bciami. Autor najwyra\u017aniej inspirowa\u0142 si\u0119 podej\u015bciem unixowym, dlatego program przyjmuje dane z stdin podczas tworzenia kopii zapasowych, wydaj\u0105c podobny strumie\u0144 danych w stdout podczas przywracania. Dzi\u0119ki temu zbackup mo\u017cna wykorzysta\u0107 jako ca\u0142kiem niez\u0142y \u201eklocka\u201d przy pisaniu w\u0142asnych rozwi\u0105za\u0144 do tworzenia kopii zapasowych. Na przyk\u0142ad, dla autora artyku\u0142u ten program jest g\u0142\u00f3wnym narz\u0119dziem do tworzenia kopii zapasowych dla domowych komputer\u00f3w od oko\u0142o 2014 roku.<\/p>\n

    <\/p>\n

    Jako strumie\u0144 danych b\u0119dzie u\u017cywany standardowy tar, je\u015bli nie powiedziano inaczej.<\/p>\n

    \nZobaczymy, jakie b\u0119d\u0105 wyniki:<\/b><\/p>\n

    Testowanie dzia\u0142ania odbywa\u0142o si\u0119 w 2 wariantach:<\/p>\n

    <\/p>\n

      \n
    1. tworzy si\u0119 repozytorium i uruchamia zbackup na serwerze z danymi \u017ar\u00f3d\u0142owymi, a nast\u0119pnie zawarto\u015b\u0107 repozytorium zostaje przes\u0142ana na serwer przechowywania kopii zapasowych.<\/li>\n
    2. tworzy si\u0119 repozytorium na serwerze przechowywania kopii zapasowych, uruchamia si\u0119 zbackup przez ssh na serwerze przechowywania kopii zapasowych, kt\u00f3remu przez pipe wydawane s\u0105 dane.<\/li>\n<\/ol>\n

      <\/p>\n

      Wyniki pierwszej opcji by\u0142y nast\u0119puj\u0105ce: 43m11s \u2014 przy u\u017cyciu niezaszyfrowanego repozytorium i kompresora lzma, 19m13s \u2014 przy wymianie kompresora na lzo.<\/p>\n

      <\/p>\n

      Obci\u0105\u017cenie na serwerze z danymi \u017ar\u00f3d\u0142owymi by\u0142o nast\u0119puj\u0105ce (pokazany przyk\u0142ad z lzma, z lzo obraz by\u0142 podobny, ale cz\u0119\u015b\u0107 rsync wynosi\u0142a oko\u0142o jednej czwartej czasu):<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Wyra\u017anie wida\u0107, \u017ce taki proces tworzenia kopii zapasowej nadaje si\u0119 tylko przy stosunkowo rzadkich i niewielkich zmianach. Wysoce zaleca si\u0119 tak\u017ce ograniczenie pracy zbackup do 1 w\u0105tku, w przeciwnym razie obci\u0105\u017cenie procesora b\u0119dzie do\u015b\u0107 wysokie, poniewa\u017c program bardzo dobrze potrafi dzia\u0142a\u0107 w wielu w\u0105tkach. Obci\u0105\u017cenie dysku by\u0142o niewielkie, co w przypadku nowoczesnego systemu dyskowego opartego na SSD b\u0119dzie w og\u00f3le niezauwa\u017calne. R\u00f3wnie\u017c wyra\u017anie wida\u0107 rozpocz\u0119cie procesu synchronizacji danych repozytorium na zdalnym serwerze, a pr\u0119dko\u015b\u0107 pracy jest por\u00f3wnywalna z zwyk\u0142ym rsync i napotyka na wydajno\u015b\u0107 systemu dyskowego serwera przechowywania kopii zapasowych. Minusem podej\u015bcia jest przechowywanie lokalnego repozytorium i, co za tym idzie, \u2014 duplikacja danych.<\/p>\n

      <\/p>\n

      Bardziej interesuj\u0105c\u0105 i praktyczn\u0105 opcj\u0105 jest drugi wariant uruchomienia zbackup bezpo\u015brednio na serwerze przechowywania kopii zapasowych.<\/p>\n

      <\/p>\n

      Na pocz\u0105tek sprawdzimy dzia\u0142anie bez u\u017cycia szyfrowania z kompresorem lzma:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Czas pracy ka\u017cdego testu:<\/p>\n

      <\/p>\n

      Uruchomienie 1
      \nUruchomienie 2
      \nUruchomienie 3<\/p>\n

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

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

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

      <\/p>\n

      Je\u015bli aktywujemy szyfrowanie z zastosowaniem aes, wyniki s\u0105 wystarczaj\u0105co zbli\u017cone:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Czas pracy na tych samych danych ze szyfrowaniem:<\/p>\n

      <\/p>\n

      Uruchomienie 1
      \nUruchomienie 2
      \nUruchomienie 3<\/p>\n

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

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

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

      <\/p>\n

      Je\u015bli po\u0142\u0105czymy szyfrowanie z kompresj\u0105 w lzo, otrzymujemy takie wyniki:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Czas pracy:<\/p>\n

      <\/p>\n

      Uruchomienie 1
      \nUruchomienie 2
      \nUruchomienie 3<\/p>\n

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

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

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

      <\/p>\n

      Rozmiar wynikowego repozytorium by\u0142 stosunkowo jednorodny i wynosi\u0142 13 GB. Oznacza to, \u017ce deduplikacja dzia\u0142a poprawnie. R\u00f3wnie\u017c na ju\u017c skompresowanych danych zastosowanie lzo przynosi zauwa\u017calny efekt, a ca\u0142kowity czas pracy zbackup zbli\u017ca si\u0119 do duplicity\/duplicati, pozostaj\u0105c jednak z ty\u0142u w por\u00f3wnaniu do system\u00f3w opartych na librsync od 2 do 5 razy.<\/p>\n

      <\/p>\n

      Zalety s\u0105 oczywiste \u2014 oszcz\u0119dno\u015b\u0107 miejsca na dysku na serwerze przechowywania kopii zapasowych. Je\u015bli chodzi o narz\u0119dzia do weryfikacji repozytorium \u2014 autor zbackup ich nie przewidzia\u0142, zaleca si\u0119 korzystanie z rozwi\u0105za\u0144 RAID lub dostawcy chmurowego.<\/p>\n

      <\/p>\n

      Og\u00f3lnie rzecz bior\u0105c, wywar\u0142o to do\u015b\u0107 dobre wra\u017cenie, mimo \u017ce projekt od oko\u0142o 3 lat stoi w miejscu (ostatnie \u017c\u0105danie funkcjonalno\u015bci mia\u0142o miejsce oko\u0142o roku temu, ale bez odpowiedzi).<\/p>\n

      <\/p>\n

      Testowanie borgbackup<\/h3>\n

      <\/p>\n

      Borgbackup jest fork'iem attic, jeszcze jednego, podobnego do zbackup systemu. Napisany w Pythonie, ma podobn\u0105 list\u0119 mo\u017cliwo\u015bci jak zbackup, ale dodatkowo potrafi:<\/p>\n

      <\/p>\n