{"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\/hr\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Backup, dio 6: Usporedba alata za izradu sigurnosnih kopija","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,
\nU ovom \u010dlanku \u0107e se usporediti alati za izradu sigurnosnih kopija, no prvo je va\u017eno saznati kako brzo i efikasno obavljaju oporavak podataka iz sigurnosnih kopija.
\nZa jednostavnost usporedbe razmatrat \u0107e se oporavak iz pune sigurnosne kopije, s obzirom na to da ovu operaciju podr\u017eavaju svi kandidati. Radi jednostavnosti, brojevi su uzeti kao prosjek (aritmeti\u010dka sredina iz nekoliko pokretanja). Rezultati \u0107e biti prikazani u tablici koja \u0107e tako\u0111er sadr\u017eavati informacije o mogu\u0107nostima: postojanje web su\u010delja, jednostavnost postavljanja i rada, mogu\u0107nost automatizacije, kao i razne druge dodatne mogu\u0107nosti (na primjer, provjera cjelovitosti podataka) itd. Grafovi \u0107e prikazivati optere\u0107enje poslu\u017eitelja na kojem \u0107e se podaci primjenjivati (ne na poslu\u017eitelju za pohranu sigurnosnih kopija).
\n<\/a><\/noindex><\/p>\n

Obnova podataka<\/h2>\n

\nKao referentna to\u010dka koristit \u0107e se rsync i tar, budu\u0107i da se na njima obi\u010dno temelje<\/a><\/noindex> najjednostavniji skripti za izradu sigurnosnih kopija.<\/p>\n

Rsync<\/i> je obavio testni skup podataka za 4 minute i 28 sekundi, pokazuju\u0107i <\/p>\n

takvo optere\u0107enje<\/b>\"Backup,
\n
\nProces oporavka nailazi na ograni\u010denja diskovnog sustava poslu\u017eitelja za pohranu sigurnosnih kopija (zuba grafika). Tako\u0111er, jasno je vidljiva optere\u0107enja jednog jezgra bez posebnih problema (nizak iowait i softirq \u2014 nema problema s diskom i mre\u017eom). Budu\u0107i da su dva druga programa, a to su rdiff-backup i rsnapshot, zasnovana na rsync-u i nude rsync kao sredstvo za oporavak, imat \u0107e pribli\u017eno sli\u010dan profil optere\u0107enja i vrijeme oporavka sigurnosne kopije.<\/p>\n

Tar<\/i> je bio malo br\u017ei, za <\/p>\n

2 minute i 43 sekunde:<\/b>\"Backup,
\n
\nPuno optere\u0107enje sustava bilo je vi\u0161e u prosjeku za 20% zbog pove\u0107anog softirq \u2014 pove\u0107ali su se tro\u0161kovi pri radu mre\u017enog sustava.<\/p>\n

Ako se arhiva dodatno komprimira, vrijeme oporavka pove\u0107ava se na 3 minute i 19 sekundi uz
\ntakvo optere\u0107enje na glavnom poslu\u017eitelju (ra\u0161\u010di\u0161\u0107avanje na strani glavnog poslu\u017eitelja):<\/b>\"Backup,
\n
\nProces raspakiranja koristi oba procesorska jezgra jer rade dva procesa. U cjelini, to je o\u010dekivani rezultat. Sli\u010dan rezultat (3 minute i 20 sekundi) dobiven je pokretanjem gzip-a na strani poslu\u017eitelja s sigurnosnim kopijama, a profil optere\u0107enja na glavnom poslu\u017eitelju bio je sli\u010dan pokretanju tar bez gzip kompresora (vidi prethodni grafikon).<\/p>\n

U rdiff-backup<\/i> mo\u017eete sinkronizirati posljednju napravljenu sigurnosnu kopiju koriste\u0107i obi\u010dan rsync (rezultati \u0107e biti sli\u010dni), ali starije sigurnosne kopije i dalje treba vra\u0107ati pomo\u0107u programa rdiff-backup, koji je povratio sigurnosnu kopiju za 17 minuta i 17 sekundi, pokazav\u0161i <\/p>\n

takvo optere\u0107enje:<\/b>\"Backup,
\n
\nMo\u017eda je to tako i zami\u0161ljeno, u svakom slu\u010daju za ograni\u010denje brzine autori predla\u017eu takvo rje\u0161enje<\/a><\/noindex>. Sam proces vra\u0107anja sigurnosne kopije traje ne\u0161to manje od polovice jednog jezgra, s proporcionalno usporedivom izvedbom (tj. 2-5 puta sporije) na disku i mre\u017ei s rsync-om.<\/p>\n

Rsnapshot<\/i> preporu\u010duje kori\u0161tenje obi\u010dnog rsync-a za vra\u0107anje, tako da \u0107e njegovi rezultati biti sli\u010dni. U cjelini, to se i pokazalo.<\/p>\n

Burp<\/i> je s zadatkom vra\u0107anja sigurnosne kopije uspio za 7 minuta i 2 sekunde s
\ntakvim optere\u0107enjem:<\/b>\"Backup,
\n
\nRadio je dovoljno brzo, a barem puno prikladnije od \u010distog rsync-a: ne treba pamtiti nikakve zastavice, jednostavno i intuitivno cli su\u010delje, ugra\u0111ena podr\u0161ka za vi\u0161e kopija, \u2014 istina je dva puta sporije. Ako se podaci trebaju vra\u0107ati iz posljednje napravljene sigurnosne kopije \u2014 mo\u017eete koristiti rsync, uz male napomene.<\/p>\n

Otprilike istu brzinu i optere\u0107enje pokazao je program BackupPC<\/i> uklju\u010duju\u0107i na\u010din prijenosa rsync, rabiv\u0161i sigurnosnu kopiju za <\/p>\n

7 minuta i 42 sekunde:<\/b>\"Backup,
\n
\nAli u na\u010dinu prijenosa podataka s tar-om BackupPC je bio sporiji: za 12 minuta i 15 sekundi, a optere\u0107enje procesora pri tome je u cjelini bilo ni\u017ee <\/p>\n

u jedan i pol puta:<\/b>\"Backup,
\n
\nDuplicity<\/i> bez \u0161ifriranja pokazao je ne\u0161to bolje rezultate, uspjev\u0161i s vra\u0107anjem sigurnosne kopije za 10 minuta i 58 sekundi. Ako aktivirate \u0161ifriranje pomo\u0107u gpg \u2014 vrijeme vra\u0107anja raste na 15 minuta i 3 sekunde. Tako\u0111er, prilikom stvaranja repozitorija za pohranu kopija mo\u017eete navesti veli\u010dinu arhive koja \u0107e se koristiti prilikom dijeljenja toka ulaznih podataka. U cjelini, na obi\u010dnim tvrdom diskovima, kao i zbog jednoprostornog na\u010dina rada, posebna razlika ne postoji. Ona se mo\u017eda pojavi pri razli\u010ditim veli\u010dinama blokova kada se koriste hibridne pohrane. Optere\u0107enje na glavnom serveru prilikom vra\u0107anja bilo je takvo:<\/p>\n

bez \u0161ifriranja<\/b>\"Backup,
\n
\ns \u0161ifriranjem<\/b>\"Backup,
\n
\nDuplicati<\/i> pokazao je sli\u010dnu brzinu vra\u0107anja, uspjev\u0161i za 13 minuta i 45 sekundi. Jo\u0161 oko 5 minuta trajala je provjera ispravnosti vra\u0107enih podataka (ukupno oko 19 minuta). Optere\u0107enje pri tome bilo je <\/p>\n

prili\u010dno visoko:<\/b>\"Backup,
\n
\nKada je \u0161ifriranje aes aktivirano unutarnjim sredstvima, vrijeme vra\u0107anja iznosilo je 21 minutu i 40 sekundi, pri \u010demu je optere\u0107enje na procesoru bilo maksimalno (oba jezgra!) tijekom vra\u0107anja; prilikom provjere podataka bio je aktivan samo jedan tok koji je zauzimao jedno procesorsko jezgro. Provjera podataka nakon vra\u0107anja trajala je istih 5 minuta (ukupno gotovo 27 minuta).<\/p>\n

Rezultat<\/b>\"Backup,
\n
\nMalo br\u017ee duplicati je uspio s vra\u0107anjem prilikom kori\u0161tenja vanjskog programa gpg za \u0161ifriranje, ali u cjelini razlike od prethodnog na\u010dina rada su minimalne. Vrijeme rada iznosilo je 16 minuta i 30 sekundi, s provjerom podataka u 6 minuta. Optere\u0107enje je bilo <\/p>\n

takvo:<\/b>\"Backup,
\n
\nAMANDA<\/i>, koriste\u0107i tar, uspjela je za 2 minute i 49 sekundi, \u0161to je, u na\u010delu, vrlo blizu obi\u010dnom tar-u. Optere\u0107enje na sustav u na\u010delu <\/p>\n

je isto:<\/b>\"Backup,
\n
\nPrilikom vra\u0107anja sigurnosne kopije sredstvima zbackup<\/i> dobiveni su sljede\u0107i rezultati:<\/p>\n

\u0161ifriranje, kompresija lzma<\/b>\"Backup,
\n
\nVrijeme rada 11 minuta i 8 sekundi<\/p>\n

\u0161ifriranje aes, kompresija lzma<\/b>\"Backup,
\n
\nVrijeme rada 14 minuta<\/p>\n

\u0161ifriranje aes, kompresija lzo<\/b>\"Backup,
\n
\nVrijeme rada 6 minuta i 19 sekundi<\/p>\n

U cjelini, nije lo\u0161e. Sve se svodi na brzinu procesora na poslu\u017eitelju za sigurnosno kopiranje, \u0161to je prili\u010dno jasno vidljivo iz vremena rada programa s razli\u010ditim kompresorima. Na strani poslu\u017eitelja za sigurnosno kopiranje pokretala se obi\u010dna tar, pa ako usporedimo s njom \u2014 vra\u0107anje radi 3 puta sporije. Mo\u017eda bi trebalo provjeriti rad u vi\u0161eadnom re\u017eimu, s brojem niti ve\u0107im od dvije.<\/p>\n

BorgBackup<\/i> u re\u017eimu bez enkripcije bio je ne\u0161to sporiji od tarskoga, za 2 minute i 45 sekundi, me\u0111utim, za razliku od istog tara, pojavila se mogu\u0107nost deduplikacije repozitorija. Optere\u0107enje pri tome rezultiralo je <\/p>\n

sljede\u0107im:<\/b>\"Backup,
\n
\nAko aktivirate enkripciju temeljenu na blake, brzina vra\u0107anja sigurnosne kopije malo se usporava. Vrijeme vra\u0107anja u ovom re\u017eimu je 3 minute i 19 sekundi, a optere\u0107enje je bilo <\/p>\n

takvo:<\/b>\"Backup,
\n
\nEnkripcija aes radi malo sporije, vrijeme vra\u0107anja je 3 minute i 23 sekunde, a optere\u0107enje se posebno <\/p>\n

nije promijenilo:<\/b>\"Backup,
\n
\nBudu\u0107i da Borg mo\u017ee raditi u vi\u0161eadnom re\u017eimu \u2014 optere\u0107enje procesora je maksimalno, pri tome se aktivacijom dodatnih funkcija samo pove\u0107ava vrijeme rada. O\u010digledno, treba istra\u017eiti vi\u0161edrednost rada sli\u010dno kao zbackup.<\/p>\n

Restic<\/i> sporije se nosio s vra\u0107anjem, vrijeme rada iznosilo je 4 minute i 28 sekundi. Optere\u0107enje je pritom izgledalo <\/p>\n

tako:<\/b>\"Backup,
\n
\nO\u010digledno je da proces vra\u0107anja radi u nekoliko niti, ali u\u010dinkovitost nije tako visoka kao kod BorgBackup-a, ali je usporediva po vremenu s obi\u010dnim rsync-om.<\/p>\n

Pomo\u0107u UrBackup<\/i> uspjelo je vratiti podatke za 8 minuta i 19 sekundi, a optere\u0107enje je pritom bilo <\/p>\n

takvo:<\/b>\"Backup,
\n
\nJo\u0161 uvijek je vidljivo da nije bilo prevelikog optere\u0107enja, \u010dak i manje nego kod tara. Ponekad su bili vrhovi, ali ne vi\u0161e od optere\u0107enja jedne jezgre.<\/p>\n

Odabir i obrazlo\u017eenje kriterija za usporedbu<\/h2>\n

\nKao \u0161to je re\u010deno u jednom od prethodnih \u010dlanaka, sustav za sigurnosno kopiranje trebao bi zadovoljiti sljede\u0107e kriterije:<\/p>\n