{"id":38746,"date":"2019-10-31T22:25:40","date_gmt":"2019-10-31T19:25:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya\/"},"modified":"2019-10-31T22:25:40","modified_gmt":"2019-10-31T19:25:40","slug":"rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Kopie zapasowe, cz\u0119\u015b\u0107 6: Por\u00f3wnanie narz\u0119dzi do tworzenia kopii zapasowych","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kopie
\nW tym artykule por\u00f3wnamy narz\u0119dzia do tworzenia kopii zapasowych, ale najpierw warto pozna\u0107, jak szybko i skutecznie radz\u0105 sobie z przywracaniem danych z kopii zapasowych.
\nDla uproszczenia por\u00f3wnania skupimy si\u0119 na przywracaniu z pe\u0142nej kopii zapasowej, tym bardziej, \u017ce ten tryb pracy wspieraj\u0105 wszyscy kandydaci. Dla uproszczenia, liczby zosta\u0142y u\u015brednione (\u015brednia z kilku uruchomie\u0144). Wyniki zostan\u0105 przedstawione w tabeli, kt\u00f3ra r\u00f3wnie\u017c zawiera informacje o mo\u017cliwo\u015bciach: dost\u0119pno\u015b\u0107 interfejsu webowego, \u0142atwo\u015b\u0107 konfiguracji i u\u017cytkowania, zdolno\u015b\u0107 do automatyzacji, dost\u0119pno\u015b\u0107 r\u00f3\u017cnych dodatkowych funkcji (na przyk\u0142ad sprawdzanie integralno\u015bci danych) itp. Wykresy b\u0119d\u0105 pokazywa\u0107 obci\u0105\u017cenie serwera, na kt\u00f3rym dane b\u0119d\u0105 zastosowane (nie serwera do przechowywania kopii zapasowych).
\n<\/a><\/noindex><\/p>\n

Odzyskiwanie danych<\/h2>\n

\nJako punkt odniesienia zostan\u0105 u\u017cyte rsync i tar, poniewa\u017c to na nich zazwyczaj opieraj\u0105 si\u0119<\/a><\/noindex> najprostsze skrypty do tworzenia kopii zapasowych.<\/p>\n

Rsync<\/i> poradzi\u0142 sobie z testowym zestawem danych w 4 minuty i 28 sekund, pokazuj\u0105c <\/p>\n

takie obci\u0105\u017cenie.<\/b>\"Kopie
\n
\nProces przywracania napotka\u0142 ograniczenie subsystems dyskowego serwera przechowuj\u0105cego kopie zapasowe (z\u0119bate wykresy). R\u00f3wnie\u017c wyra\u017anie wida\u0107 obci\u0105\u017cenie jednego rdzenia bez wi\u0119kszych problem\u00f3w (niski iowait i softirq \u2014 brak problem\u00f3w z dyskiem i sieci\u0105). Poniewa\u017c dwa inne programy, mianowicie rdiff-backup i rsnapshot, opieraj\u0105 si\u0119 na rsync, a tak\u017ce oferuj\u0105 jako narz\u0119dzie do przywracania standardowy rsync, \u2014 b\u0119d\u0105 mia\u0142y zbli\u017cony profil obci\u0105\u017cenia i czas przywracania kopii zapasowej.<\/p>\n

Tar<\/i> poradzi\u0142 sobie nieco szybciej, w czasie <\/p>\n

2 minuty i 43 sekundy:<\/b>\"Kopie
\n
\n\u015arednie obci\u0105\u017cenie systemu by\u0142o wy\u017csze o 20% z powodu wzrostu softirq \u2014 wzros\u0142y koszty operacyjne zwi\u0105zane z dzia\u0142aniem subsystemu sieciowego.<\/p>\n

Je\u015bli archiwum zostanie dodatkowo skompresowane, czas przywracania wzrasta do 3 minut i 19 sekund z
\ntakim obci\u0105\u017ceniem na g\u0142\u00f3wnym serwerze (rozpakowywanie po stronie g\u0142\u00f3wnego serwera):<\/b>\"Kopie
\n
\nProces rozpakowywania zajmuje oba rdzenie procesora, poniewa\u017c dzia\u0142a dwa procesy. Og\u00f3lnie \u2014 to oczekiwany rezultat. Por\u00f3wnywalny wynik (3 minuty i 20 sekund) uzyskano r\u00f3wnie\u017c przy uruchomieniu gzip po stronie serwera z kopiami zapasowymi, profil obci\u0105\u017cenia na g\u0142\u00f3wnym serwerze by\u0142 do\u015b\u0107 podobny do uruchomienia tar bez kompresora gzip (zob. poprzedni wykres).<\/p>\n

W rdiff-backup<\/i> mo\u017cna zsynchronizowa\u0107 ostatni\u0105 wykonan\u0105 kopi\u0119 zapasow\u0105 za pomoc\u0105 zwyk\u0142ego rsync (wyniki b\u0119d\u0105 podobne), ale starsze kopie zapasowe i tak nale\u017cy przywraca\u0107 za pomoc\u0105 programu rdiff-backup, kt\u00f3ry poradzi\u0142 sobie z przywracaniem w 17 minut i 17 sekund, pokazuj\u0105c <\/p>\n

takie obci\u0105\u017cenie:<\/b>\"Kopie
\n
\nMo\u017cliwe, \u017ce takie mia\u0142o by\u0107 zamierzenie, w ka\u017cdym razie aby ograniczy\u0107 pr\u0119dko\u015b\u0107 autorzy proponuj\u0105 takie rozwi\u0105zanie<\/a><\/noindex>. Sam proces przywracania kopii zapasowej zajmuje troch\u0119 mniej ni\u017c po\u0142ow\u0119 jednego rdzenia, przy proporcjonalnie por\u00f3wnywalnej wydajno\u015bci (tj. 2-5 razy wolniej) zar\u00f3wno na dysku, jak i w sieci z rsync.<\/p>\n

Rsnapshot<\/i> do przywracania oferuje u\u017cywanie zwyk\u0142ego rsync, dlatego jego wyniki b\u0119d\u0105 podobne. Og\u00f3lnie rzecz bior\u0105c, tak w\u0142a\u015bnie wysz\u0142o.<\/p>\n

Burp<\/i> z zadaniem przywracania kopii zapasowej poradzi\u0142 sobie w 7 minut i 2 sekundy z
\ntakim obci\u0105\u017ceniem:<\/b>\"Kopie
\n
\nZadzia\u0142a\u0142 do\u015b\u0107 szybko, a przynajmniej o wiele wygodniej ni\u017c czysty rsync: nie trzeba pami\u0119ta\u0107 \u017cadnych flag, prosty i intuicyjny interfejs cli, wbudowane wsparcie dla wielu kopii, \u2014 prawda, dwa razy wolniej. Je\u015bli dane trzeba przywraca\u0107 z ostatnio wykonanej kopii zapasowej \u2014 mo\u017cna skorzysta\u0107 z rsync, z niewielkimi zastrze\u017ceniami.<\/p>\n

Podobn\u0105 szybko\u015b\u0107 i obci\u0105\u017cenie pokaza\u0142 program BackupPC<\/i> w trybie przesy\u0142ania rsync, przywracaj\u0105c kopi\u0119 zapasow\u0105 w <\/p>\n

7 minut i 42 sekundy:<\/b>\"Kopie
\n
\nNatomiast w trybie przesy\u0142ania danych z tar BackupPC poradzi\u0142 sobie wolniej: w 12 minut i 15 sekund, a obci\u0105\u017cenie procesora w tym przypadku by\u0142o w sumie ni\u017csze <\/p>\n

o p\u00f3\u0142tora raza:<\/b>\"Kopie
\n
\nDuplicity<\/i> bez szyfrowania osi\u0105gn\u0105\u0142 nieco lepsze wyniki, poradziwszy sobie z przywracaniem kopii zapasowej w ci\u0105gu 10 minut i 58 sekund. Je\u015bli aktywowa\u0107 szyfrowanie za pomoc\u0105 gpg \u2014 czas przywracania wzrasta do 15 minut i 3 sekund. Mo\u017cna r\u00f3wnie\u017c wskaza\u0107 rozmiar archiwum, kt\u00f3re zostanie u\u017cyte do podzia\u0142u strumienia danych wej\u015bciowych podczas tworzenia repozytorium do przechowywania kopii. Og\u00f3lnie, na zwyk\u0142ych dyskach twardych, z uwagi na jednopoziomowy tryb pracy, nie ma szczeg\u00f3lnej r\u00f3\u017cnicy. Mo\u017ce ona pojawi\u0107 si\u0119 przy r\u00f3\u017cnych rozmiarach blok\u00f3w, gdy u\u017cywane s\u0105 hybrydowe magazyny. Obci\u0105\u017cenie g\u0142\u00f3wnego serwera przy przywracaniu wynios\u0142o:<\/p>\n

bez szyfrowania<\/b>\"Kopie
\n
\nz szyfrowaniem<\/b>\"Kopie
\n
\nDuplicati<\/i> pokaza\u0142 por\u00f3wnywaln\u0105 pr\u0119dko\u015b\u0107 przywracania, poradziwszy sobie w 13 minut i 45 sekund. Oko\u0142o 5 minut zaj\u0119\u0142o sprawdzenie poprawno\u015bci przywr\u00f3conych danych (\u0142\u0105cznie oko\u0142o 19 minut). Obci\u0105\u017cenie przy tym by\u0142o <\/p>\n

do\u015b\u0107 wysokie:<\/b>\"Kopie
\n
\nKiedy szyfrowanie aes aktywowa\u0142o si\u0119 wewn\u0119trznymi \u015brodkami, czas przywracania wyni\u00f3s\u0142 21 minut 40 sekund, przy czym obci\u0105\u017cenie procesora by\u0142o maksymalne (oba rdzenie!) podczas przywracania; podczas sprawdzania danych aktywny by\u0142 tylko jeden w\u0105tek, zajmuj\u0105cy jeden rdze\u0144 procesora. Sprawdzanie danych po przywr\u00f3ceniu zaj\u0119\u0142o tyle samo 5 minut (\u0142\u0105cznie prawie 27 minut).<\/p>\n

Wynik<\/b>\"Kopie
\n
\nNieco szybciej duplicati poradzi\u0142 sobie z przywracaniem przy u\u017cyciu zewn\u0119trznego programu gpg do szyfrowania, ale w sumie r\u00f3\u017cnice w por\u00f3wnaniu do poprzedniego trybu s\u0105 minimalne. Czas pracy wyni\u00f3s\u0142 16 minut 30 sekund, z sprawdzaniem danych w czasie 6 minut. Obci\u0105\u017cenie by\u0142o <\/p>\n

takie:<\/b>\"Kopie
\n
\nAMANDA<\/i>, u\u017cywaj\u0105ca tar, poradzi\u0142a sobie w 2 minuty 49 sekund, co w zasadzie jest do\u015b\u0107 bliskie zwyk\u0142emu tar. Obci\u0105\u017cenie systemu w zasadzie <\/p>\n

jest takie same:<\/b>\"Kopie
\n
\nPodczas przywracania kopii zapasowej za pomoc\u0105 zbackup<\/i> uzyskano nast\u0119puj\u0105ce wyniki:<\/p>\n

szyfrowanie, kompresja lzma<\/b>\"Kopie
\n
\nCzas pracy 11 minut i 8 sekund<\/p>\n

szyfrowanie aes, kompresja lzma<\/b>\"Kopie
\n
\nCzas pracy 14 minut<\/p>\n

szyfrowanie aes, kompresja lzo<\/b>\"Kopie
\n
\nCzas pracy 6 minut, 19 sekund<\/p>\n

Og\u00f3lnie rzecz bior\u0105c, nie\u017ale. Wszystko sprowadza si\u0119 do pr\u0119dko\u015bci procesora na serwerze kopii zapasowej, co wyra\u017anie wida\u0107 po czasie pracy programu z r\u00f3\u017cnymi kompresorami. Po stronie serwera kopii zapasowej uruchamiano zwyk\u0142y tar, wi\u0119c je\u015bli por\u00f3wnamy to z nim \u2014 przywracanie dzia\u0142a trzy razy wolniej. By\u0107 mo\u017ce warto sprawdzi\u0107 dzia\u0142anie w trybie wielow\u0105tkowym, z liczb\u0105 w\u0105tk\u00f3w wi\u0119ksz\u0105 ni\u017c dwa.<\/p>\n

BorgBackup<\/i> w trybie bez szyfrowania poradzi\u0142 sobie nieco wolniej ni\u017c tar, w czasie 2 minut 45 sekund, jednak w odr\u00f3\u017cnieniu od tar pojawi\u0142a si\u0119 mo\u017cliwo\u015b\u0107 deduplikacji repozytorium. Obci\u0105\u017cenie przy tym wynios\u0142o <\/p>\n

nast\u0119puj\u0105ce:<\/b>\"Kopie
\n
\nJe\u015bli aktywowa\u0107 szyfrowanie oparte na blake, to pr\u0119dko\u015b\u0107 przywracania kopii zapasowej nieco spowalnia. Czas przywracania w tym trybie wynosi 3 minuty 19 sekund, a obci\u0105\u017cenie wynios\u0142o <\/p>\n

takie:<\/b>\"Kopie
\n
\nSzyfrowanie aes dzia\u0142a nieco wolniej, czas przywracania wynosi 3 minuty 23 sekundy, a obci\u0105\u017cenie szczeg\u00f3lnie <\/p>\n

si\u0119 nie zmieni\u0142o:<\/b>\"Kopie
\n
\nPoniewa\u017c Borg mo\u017ce dzia\u0142a\u0107 w trybie wielow\u0105tkowym \u2014 obci\u0105\u017cenie procesora jest maksymalne, przy tym aktywacja dodatkowych funkcji po prostu wyd\u0142u\u017ca czas dzia\u0142ania. Najwyra\u017aniej warto zbada\u0107 wielow\u0105tkowo\u015b\u0107 dzia\u0142ania analogicznie do zbackup.<\/p>\n

Restic<\/i> poradzi\u0142 sobie z przywracaniem nieco wolniej, czas pracy wyni\u00f3s\u0142 4 minuty 28 sekund. Obci\u0105\u017cenie przy tym wygl\u0105da\u0142o <\/p>\n

tak:<\/b>\"Kopie
\n
\nNajwyra\u017aniej proces przywracania dzia\u0142a w kilku w\u0105tkach, ale efektywno\u015b\u0107 nie jest tak wysoka jak w BorgBackup, ale czasowo por\u00f3wnywalna z zwyk\u0142ym rsync.<\/p>\n

Dzi\u0119ki UrBackup<\/i> uda\u0142o si\u0119 przywr\u00f3ci\u0107 dane w czasie 8 minut i 19 sekund, przy tym obci\u0105\u017cenie wynios\u0142o <\/p>\n

takie:<\/b>\"Kopie
\n
\nWci\u0105\u017c wida\u0107 niewielkie obci\u0105\u017cenie, nawet ni\u017csze ni\u017c u tar. Miejscami wzrosty, ale nie przekraczaj\u0105ce obci\u0105\u017cenia jednego rdzenia.<\/p>\n

Wyb\u00f3r i uzasadnienie kryteri\u00f3w por\u00f3wnania<\/h2>\n

\nJak powiedziano w jednym z wcze\u015bniejszych artyku\u0142\u00f3w, system tworzenia kopii zapasowych powinien odpowiada\u0107 nast\u0119puj\u0105cym kryterium:<\/p>\n