{"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\/et\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Varundamine, osa 6: Varundamise t\u00f6\u00f6riistade v\u00f5rdlus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Varundamine,
\nSelles artiklis v\u00f5rreldakse varundustarkvara, kuid esmalt tasub teada saada, kui kiiresti ja t\u00f5husalt nad andmeid varukoopiatest taastavad.
\nV\u00f5rdluse lihtsustamiseks k\u00e4sitletakse taastamist t\u00e4ielikust varukoopiast, sest see t\u00f6\u00f6re\u017eiim on toetatud k\u00f5igi kandidaatide poolt. Numbrid on lihtsustamise huvides v\u00f5etud juba keskmistena (mitme k\u00e4ivitamise aritmeetiline keskmine). Tulemused koondatakse tabelisse, kus on lisainfot ka v\u00f5imaluste kohta: veebiliidese olemasolu, seadistamise ja kasutamise lihtsus, automatiseerimise v\u00f5imekus, erinevate lisav\u00f5imaluste olemasolu (nt andmete terviklikkuse kontroll) jne. Diagrammid n\u00e4itavad serveri koormust, kus andmeid rakendatakse (mitte varukoopiate salvestamise serverit).
\n<\/a><\/noindex><\/p>\n

Andmete taastamine<\/h2>\n

\nTugipunktidena kasutatakse rsynci ja tari, kuna need on tavaliselt aluseks<\/a><\/noindex> lihtsaimatele varundamise skriptidele.<\/p>\n

Rsync<\/i> t\u00e4itis testandmete kogumi 4 minuti ja 28 sekundiga, n\u00e4idates <\/p>\n

sellist koormust.<\/b>\"Varundamine,
\n
\nTaastamisprotsess j\u00e4i pidama varukoopiate salvestamise serveri kettas\u00fcsteemi piirangu taha (sahvatavad diagrammid). Samuti on selgelt n\u00e4ha \u00fche tuuma koormus ilma eriliste probleemideta (madal iowait ja softirq \u2014 ei esine probleeme ketta ja v\u00f5rguga vastavalt). Kuna kaks muud programmi, nimelt rdiff-backup ja rsnapshot, p\u00f5hinevad rsyncil ning pakuvad taastamisvahendina tavalist rsynci, on nende koormuse profiil ja varukoopia taastamise aeg ligikaudu samasugused.<\/p>\n

Tar<\/i> t\u00e4itis pisut kiiremini, ajaga <\/p>\n

2 minutit ja 43 sekundit:<\/b>\"Varundamine,
\n
\nS\u00fcsteemi kogukoormus oli keskmiselt 20% suurem suurenenud softirq t\u00f5ttu \u2014 v\u00f5rgualase t\u00f6\u00f6 t\u00f5ttu tekkisid lisakulud.<\/p>\n

Kui arhiivi veel edasi tihendada, suureneb taastamisaeg 3 minutile ja 19 sekundile sellise koormuse juures peamisel serveril (dekompressioon peamise serveri k\u00fcljel):
\n\u0442\u0430\u043a\u043e\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u043e\u0439 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0435 (\u0440\u0430\u0441\u043f\u0430\u043a\u043e\u0432\u043a\u0430 \u043d\u0430 \u0441\u0442\u043e\u0440\u043e\u043d\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u0441\u0435\u0440\u0432\u0435\u0440\u0430):<\/b>\"Varundamine,
\n
\nPakkimisprotsess kasutab kahte protsessori tuuma, kuna t\u00f6\u00f6tab kaks protsessi. Kokkuv\u00f5ttes on see oodatav tulemus. Samuti saadi sarnane tulemus (3 minutit ja 20 sekundit), kui k\u00e4ivitati gzip serveripoolel varukoopiate tegemiseks, p\u00f5hiserveri koormus oli \u00fcsna sarnane tar-i k\u00e4ivitamisele ilma gzip kompressorita (vt eelmist graafikut).<\/p>\n

Uues rdiff-backup<\/i> Viimast tehtud varukoopiat saab s\u00fcnkroniseerida tavalise rsync abil (tulemused on sarnased), kuid vanemaid varukoopiaid tuleb ikkagi taastada rdiff-backup programmi kaudu, mis suutis taastamise teha 17 minuti ja 17 sekundiga, n\u00e4idates <\/p>\n

sellist koormust:<\/b>\"Varundamine,
\n
\nV\u00f5ib-olla oli see t\u00f5esti nii m\u00f5eldud, v\u00e4hemalt kiiruspiirangu osas, mida autorid pakuvad selle lahendusena<\/a><\/noindex>. Varukoopia taastamise protsess ise v\u00f5tab aega veidi v\u00e4hem kui pool tuuma, suheline j\u00f5udlus on sarnane (st 2-5 korda aeglasem) m\u00f5lemal, nii kettal kui v\u00f5rgus rsynciga.<\/p>\n

Rsnapshot<\/i> pakub taastamiseks kasutada tavap\u00e4rast rsync'i, seega on tema tulemused sarnased. Kokkuv\u00f5ttes on see just nii l\u00e4inudki.<\/p>\n

Burp<\/i> sai varukoopia taastamise \u00fclesande 7 minuti ja 2 sekundi jooksul tehtud
\nsellise koormusega:<\/b>\"Varundamine,
\n
\nT\u00f6\u00f6tas piisavalt kiiresti ning v\u00e4hemalt on see palju mugavam kui puhas rsync: ei pea m\u00e4letama mingeid lippe, lihtne ja intuitiivne CLI-liides, sisseehitatud tugi mitme koopia jaoks \u2014 kuigi see on kahekordselt aeglasem. Kui andmeid tuleb taastada viimati tehtud varukoopiast \u2013 saab kasutada rsync'i, v\u00e4ikeste eranditega.<\/p>\n

Umbes sama kiirus ja koormus n\u00e4itas programm BackupPC<\/i> kui rsync \u00fclekande re\u017eiim oli aktiivne, rajades varukoopia <\/p>\n

7 minuti ja 42 sekundi jooksul:<\/b>\"Varundamine,
\n
\nAga tar andmeedastuse re\u017eiimis saavutas BackupPC aeglasema tulemuse: 12 minuti ja 15 sekundi jooksul, protsessori koormus oli sel juhul \u00fcldiselt madalam <\/p>\n

poolteist korda:<\/b>\"Varundamine,
\n
\nDuplicity<\/i> ilma kr\u00fcpteerimist n\u00e4itas veidi paremaid tulemusi, taastades varukoopia 10 minuti ja 58 sekundi jooksul. Kui aktiveerida kr\u00fcpteerimine gpg abil, ulatub taastamisaeg 15 minuti ja 3 sekundini. Samuti saab varahoidla loomisel m\u00e4\u00e4rata arhiveerimise suuruse, mida kasutatakse siseneva andmevoo jagamisel. Kokkuv\u00f5ttes, tavalistel k\u00f5vaketastel, samuti \u00fchesuunalise t\u00f6\u00f6re\u017eiimi t\u00f5ttu, ei ole erilist erinevust. See v\u00f5ib ilmuda erinevate plokkide suurustega, kui kasutatakse h\u00fcbriidhoidlaid. Peamise serveri koormus taastamise ajal oli j\u00e4rgmine:<\/p>\n

ilma kr\u00fcpteerimiseta<\/b>\"Varundamine,
\n
\nkr\u00fcpteerimisega<\/b>\"Varundamine,
\n
\nDuplicati<\/i> n\u00e4itas v\u00f5rreldavat taastamiskiirus, tehes seda 13 minuti ja 45 sekundi jooksul. Veel umbes 5 minutit kulus taastatud andmete korrektuse kontrollimiseks (kokku umbes 19 minutit). Sealjuures oli koormus <\/p>\n

oluliselt k\u00f5rge:<\/b>\"Varundamine,
\n
\nKui kr\u00fcpteerimine aes aktiviseeriti sisemiste vahenditega, siis taastamisaeg oli 21 minutit ja 40 sekundit, samas kui protsessori koormus oli maksimaalne (m\u00f5lemad tuumad!) taastamise ajal; andmete kontrollimiseks oli aktiivne ainult \u00fcks voog, kasutades \u00fchte protsessorituuma. Andmete kontrollimine p\u00e4rast taastamist kestis sama palju aega, umbes 5 minutit (kokku pea 27 minutit).<\/p>\n

Tulemus<\/b>\"Varundamine,
\n
\nVeidi kiiremini haldas duplicati taastamist, kasutades kr\u00fcpteerimiseks v\u00e4list programmi gpg, kuid \u00fcldiselt on erinevused eelneva re\u017eiimiga minimaalset. T\u00f6\u00f6tlemisaeg oli 16 minutit ja 30 sekundit, koos andmete kontrollimisega 6 minuti jooksul. Koormus oli <\/p>\n

j\u00e4rgnev:<\/b>\"Varundamine,
\n
\nAMANDA<\/i>, kasutades tar, haldas 2 minuti ja 49 sekundi jooksul, mis on \u00fcldiselt \u00fcsna l\u00e4hedane tavalisele tar-ile. S\u00fcsteemi koormus on kokkuv\u00f5ttes <\/p>\n

sama:<\/b>\"Varundamine,
\n
\nVarukoopiate taastamisel kasutades zbackup<\/i> saadi j\u00e4rgmised tulemused:<\/p>\n

kr\u00fcpteerimine, kompressioon lzma<\/b>\"Varundamine,
\n
\nT\u00f6\u00f6tlemisaeg 11 minutit ja 8 sekundit<\/p>\n

kr\u00fcpteerimine aes, kompressioon lzma<\/b>\"Varundamine,
\n
\nT\u00f6\u00f6tlemisaeg 14 minutit<\/p>\n

kr\u00fcpteerimine aes, kompressioon lzo<\/b>\"Varundamine,
\n
\nT\u00f6\u00f6tlemisaeg 6 minutit, 19 sekundit<\/p>\n

Kokkuv\u00f5ttes pole paha. K\u00f5ik s\u00f5ltub varundusserveri protsessorikiirusest, mida on \u00fcsna selgelt n\u00e4ha programmi t\u00f6\u00f6 ajas erinevate tihendajatega. Varundusserveris k\u00e4ivitati tavaline tar, seega, kui v\u00f5rrelda sellega \u2014 taastamine t\u00f6\u00f6tab 3 korda aeglasemalt. V\u00f5ib-olla tasuks kontrollida t\u00f6\u00f6 tegemist mitme l\u00f5ime re\u017eiimis, kus l\u00f5imede arv on suurem kui kaks.<\/p>\n

BorgBackup<\/i> ilma kr\u00fcpteerimiseta t\u00f6\u00f6tas veidi aeglasemalt kui tar, aega kulus 2 minutit ja 45 sekundit, kuid erinevalt tar-st avanes v\u00f5imalus dedupplikatsiooni jaoks. Koormus oli <\/p>\n

j\u00e4rgnev:<\/b>\"Varundamine,
\n
\nKui aktiveerida blake-p\u00f5hine kr\u00fcpteerimine, siis varukoopia taastamise kiirus veidi aeglustub. Taastamisaeg selles re\u017eiimis on 3 minutit ja 19 sekundit, koormus j\u00e4i <\/p>\n

selliseks:<\/b>\"Varundamine,
\n
\nAES-i kr\u00fcpteerimine t\u00f6\u00f6tab veidi aeglasemalt, taastamisaeg on 3 minutit ja 23 sekundit, koormus eriti <\/p>\n

ei muutunud:<\/b>\"Varundamine,
\n
\nKuna Borg v\u00f5ib t\u00f6\u00f6tada mitme l\u00f5ime re\u017eiimis, on protsessori koormus maksimaalne, samal ajal kui t\u00e4iendavate funktsioonide aktiveerimisel lihtsalt suureneb t\u00f6\u00f6aeg. Tundub, et tasub uurida ka mitme l\u00f5ime t\u00f6\u00f6tlemist sarnaselt zbackup-iga.<\/p>\n

Restic<\/i> t\u00f6\u00f6tas taastamisega veidi aeglasemalt, t\u00f6\u00f6aeg oli 4 minutit ja 28 sekundit. Koormus n\u00e4gi v\u00e4lja <\/p>\n

nii:<\/b>\"Varundamine,
\n
\nTundub, et taastamisprotsess t\u00f6\u00f6tab mitme l\u00f5imega, kuid efektiivsus ei ole nii k\u00f5rge kui BorgBackup-is, kuid ajaliselt sarnane tavalise rsync-iga.<\/p>\n

EL-i abil UrBackup<\/i> suudeti andmed taastada 8 minutiga ja 19 sekundiga, koormus oli sel ajal <\/p>\n

j\u00e4rgnev:<\/b>\"Varundamine,
\n
\nJ\u00e4tkuvalt on n\u00e4htav mitte liiga k\u00f5rge koormus, isegi madalam kui tar-l. Kohati on \u00e4kilisi t\u00f5use, kuid mitte rohkem kui \u00fche tuuma koormus.<\/p>\n

Kriteeriumide valik ja p\u00f5hjendamine<\/h2>\n

\nKuidas varem \u00f6eldud, peab varunduss\u00fcsteem vastama j\u00e4rgmistele kriteeriumidele:<\/p>\n