{"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: Varundamisvahendite v\u00f5rdlus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Varundamine,
\nSelles artiklis v\u00f5rreldakse varundustarkvara, kuid k\u00f5igepealt on hea m\u00f5ista, kui kiiresti ja t\u00f5husalt nad andmeid varukoopiatest taastavad.
\nV\u00f5rdluse lihtsustamiseks keskendutakse t\u00e4ielikest varukoopiatest taastamisele, kuna seda t\u00f6\u00f6re\u017eiimi toetavad k\u00f5ik kandidaadid. Numbrid on lihtsuse huvides juba keskmistatud (arvutatud mitmest proovist). Tulemused koondatakse tabelisse, kus on ka teave v\u00f5imaluste kohta: veebiliidese olemasolu, seadistamise ja kasutamise lihtsus, automatiseerimisv\u00f5ime, erinevaid t\u00e4iendavaid funktsioone (n\u00e4iteks andmete terviklikkuse kontrollimine) jne. Graafikud n\u00e4itavad serveri koormust, kus andmeid rakendatakse (mitte varukoopiate salvestamise serverit).
\n<\/a><\/noindex><\/p>\n

Andmete taastamine<\/h2>\n

\nViidatud punktidena kasutatakse rsynci ja tar\u2018i, kuna just need on tavaliselt aluseks<\/a><\/noindex> lihtsaimatele varundusskriptidele.<\/p>\n

Rsync<\/i> lahendas testkomplekti andmed 4 minuti ja 28 sekundi jooksul, n\u00e4idates <\/p>\n

sellist koormust<\/b>\"Varundamine,
\n
\nTaasteprotsess j\u00f5udis serveri varukoopia salvestusseadmestiku piirangutesse (saagide graafikud). Samuti on selgelt n\u00e4ha \u00fche tuuma koormust ilma eriliste probleemideta (madal iowait ja softirq \u2014 ei ole probleeme ketaste ja v\u00f5rgu osas vastavalt). Kuna kaks muud programmi, nimelt rdiff-backup ja rsnapshot, p\u00f5hinevad rsync'il ning pakuvad taastamisvahendina tavalist rsync'i, on neil ligikaudu samasugused koormusprofiilid ja varukoopia taastamisaeg.<\/p>\n

Tar<\/i> k\u00f5ikus ka pisut kiiremini, kuludes <\/p>\n

2 minutit ja 43 sekundit:<\/b>\"Varundamine,
\n
\nS\u00fcsteemi t\u00e4iskoormus oli keskmiselt 20% k\u00f5rgem t\u00e4nu suurenenud softirq'le \u2014 v\u00f5rgu alams\u00fcsteemi t\u00f6\u00f6 suurenenud kulu t\u00f5ttu.<\/p>\n

Kui arhiiv t\u00e4iendavalt kokku suruda, siis taastamisaeg t\u00f5useb 3 minutini ja 19 sekundini
\nsellise koormuse all p\u00f5hiserveril (dekompressioon p\u00f5hiserveris):<\/b>\"Varundamine,
\n
\nPakkimisprotsess kasutab m\u00f5lemat protsessorituuma, kuna k\u00e4ivitatakse kaks protsessi. Kokkuv\u00f5ttes on see oodatud tulemus. Samuti saadi sarnane tulemus (3 minutit ja 20 sekundit) gzip'i k\u00e4ivitamisel serveri k\u00fcljel varukoopiate jaoks; p\u00f5hilise serveri koormusprofiil sarnanes v\u00e4ga gzip'i kompressori k\u00e4ivitamisega tar'i puhul (vt eelmist diagrammi).<\/p>\n

V rdiff-backup<\/i> Viimase loodud varukoopia saab s\u00fcnkroonida tavap\u00e4rase rsync'i abil (tulemused on sarnased), kuid vanemad varukoopiad tuleb ikkagi taastada rdiff-backup programmi abil, mis suutis taastamise h\u00f5lpsasti teostada 17 minuti ja 17 sekundi jooksul, n\u00e4idates <\/p>\n

sellist koormust:<\/b>\"Varundamine,
\n
\nV\u00f5ib-olla oli see t\u00f5esti niimoodi m\u00f5eldud, igal juhul soovitavad autorid kiiruspiiranguid sellist lahendust<\/a><\/noindex>. Varukoopia taastamise protsess ise kasutab v\u00e4hem kui pool \u00fche tuuma ressurssidest, pakkudes proportsionaalselt sarnast tootlikkust (st 2-5 korda aeglasem) andmeedastus ja v\u00f5rgu rsync'i kaudu.<\/p>\n

Rsnapshot<\/i> soovitab taastamiseks kasutada tavalist rsync'i, mist\u00f5ttu on selle tulemused sarnased. Kokkuv\u00f5ttes see just nii l\u00e4kski.<\/p>\n

Burp<\/i> sai varukoopia taastamise \u00fclesandega toime tulla 7 minuti ja 2 sekundiga
\nsellise koormuse puhul:<\/b>\"Varundamine,
\n
\nT\u00f6\u00f6tas piisavalt kiiresti ja oli igal juhul palju mugavam kui puhas rsync: ei pea meeles pidama mingeid lippusid, lihtne ja intuitiivne cli-liides, sisseehitatud toetus mitmele koopiale \u2014 t\u00f5si, umbes kaks korda aeglasem. Kui andmeid tuleb taastada eelmisel korral tehtud varukoopiast \u2014 v\u00f5ib kasutada rsync'i, m\u00f5ningate eranditega.<\/p>\n

Umbes sama kiirus ja koormus n\u00e4itas programm BackupPC<\/i> rsync'i \u00fclekande re\u017eiimi sissel\u00fclitamisel, avades varukoopia <\/p>\n

7 minuti ja 42 sekundi jooksul:<\/b>\"Varundamine,
\n
\nKuid andmete \u00fclekande re\u017eiimis tar BackupPC suutis aeglasemalt: 12 minuti ja 15 sekundi jooksul, protsessori koormus oli \u00fcldiselt madalam <\/p>\n

koold poolteist korda:<\/b>\"Varundamine,
\n
\nDuplicity<\/i> ilma kr\u00fcpteeringuta n\u00e4itas veidi paremaid tulemusi, taastades varukoopia 10 minuti ja 58 sekundi jooksul. Kui aktiveerida kr\u00fcpteerimine gpg abil, pikeneb taastamisaeg 15 minutini ja 3 sekundini. Samuti, kui luua varukoopiate salvestamiseks hoidla, saab m\u00e4\u00e4rata arhiivi suuruse, mida kasutatakse siseneva andmevoo jagamisel. \u00dcldiselt ei ole tavaliste k\u00f5vakettade korral, tulenevalt ka \u00fche niidi t\u00f6\u00f6re\u017eiimist, erilist erinevust. See v\u00f5ib ilmneda erinevate plokkide suuruste kasutamisel h\u00fcbriidhoidlate puhul. Peamise serveri koormus taastamise ajal oli selline:<\/p>\n

ilma kr\u00fcpteerimise<\/b>\"Varundamine,
\n
\nkr\u00fcpteerimisega<\/b>\"Varundamine,
\n
\nDuplicati<\/i> n\u00e4itas v\u00f5rreldavat taastamiskiirust, saavutades selle 13 minuti ja 45 sekundi jooksul. Andmete taastamise korrektsuse kontrollimiseks kulus veel umbes 5 minutit (kokku umbes 19 minutit). Koormus oli sel ajal <\/p>\n

piisavalt k\u00f5rge:<\/b>\"Varundamine,
\n
\nKui aes kr\u00fcpteerimine aktiveeriti sisemiste vahenditega, oli taastamisaeg 21 minutit ja 40 sekundit, kusjuures protsessori koormus oli taastamise ajal maksimaalne (kaks tuuma!). Andmete kontrollimisel oli aktiivne ainult \u00fcks l\u00f5ime, mis kasutas \u00fchte protsessorituuma. Andmete kontrollimine p\u00e4rast taastamist kestis sama kaua, 5 minutit (kokku peaaegu 27 minutit).<\/p>\n

Tulemus<\/b>\"Varundamine,
\n
\nVeidi kiiremini kell duplicati saavutas taastamise, kasutades kr\u00fcpteerimisel v\u00e4list programmi gpg, kuid kokkuv\u00f5ttes on erinevused eelmisest re\u017eiimist minimaalsed. T\u00f6\u00f6n\u00e4itajad olid 16 minutit ja 30 sekundit, andmete kontrollimise ajal 6 minutit. Koormus oli <\/p>\n

selline:<\/b>\"Varundamine,
\n
\nAMANDA<\/i>, mis kasutab tar, saavutas aja 2 minutit ja 49 sekundit, mis on p\u00f5him\u00f5tteliselt \u00fcsna l\u00e4hedane tavap\u00e4rasele tar-ile. S\u00fcsteemi koormus on p\u00f5him\u00f5tteliselt <\/p>\n

samuti sama:<\/b>\"Varundamine,
\n
\nTaastamise varukoopia vahenditega zbackup<\/i> saadi j\u00e4rgmised tulemused:<\/p>\n

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

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

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

Kokkuv\u00f5ttes on see \u00fcsna kena. K\u00f5ik s\u00f5ltub backup-serveri protsessori kiirusest, mida on selgelt n\u00e4ha, kui v\u00f5rreldakse erinevate tihenditega programmide t\u00f6\u00f6aegu. Backup-serverist k\u00e4ivitati tavaline tar, seega, kui v\u00f5rrelda sellega, siis taastamine t\u00f6\u00f6tab kolm korda aeglasemalt. V\u00f5ib-olla tasuks proovida t\u00f6\u00f6d mitme l\u00f5imega, kus l\u00f5imede arv on suurem kui kaks.<\/p>\n

BorgBackup<\/i> ilma kr\u00fcpteerimisre\u017eiimis toimis see veidi aeglasemalt kui tar, 2 minutit 45 sekundit, kuid erinevalt samast tar'ist, on tekkinud v\u00f5imalus repositoriumi dedupeerida. Koormus sel juhul osutus <\/p>\n

j\u00e4rgnevaks:<\/b>\"Varundamine,
\n
\nKui aktiveerida blake-p\u00f5hine kr\u00fcpteerimine, siis backup'i taastamise kiirus veidi aeglustub. Taastamis aeg on sel re\u017eiimil 3 minutit 19 sekundit ja koormus oli <\/p>\n

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

muutunud:<\/b>\"Varundamine,
\n
\nKuna Borg suudab t\u00f6\u00f6tada mitme l\u00f5ime re\u017eiimis, on protsessori koormus maksimaalne, samas kui t\u00e4iendavate funktsioonide aktiveerimisel kasvab lihtsalt t\u00f6\u00f6aeg. Tundub, et tasub uurida t\u00f6\u00f6 mitme l\u00f5ime kasutuse m\u00f5ju sarnaselt zbackup'iga.<\/p>\n

Restic<\/i> taastas andmed veidi aeglasemalt, t\u00f6\u00f6aeg oli 4 minutit ja 28 sekundit. Koormus n\u00e4is sel ajal olevat <\/p>\n

nii:<\/b>\"Varundamine,
\n
\nTundub, et taastamisprotsess t\u00f6\u00f6tab mitme l\u00f5imega, kuid efektiivsus ei ole nii k\u00f5rge kui BorgBackup'il, kuid ajaliselt on see v\u00f5rreldav tavalise rsync'iga.<\/p>\n

K\u00e4esoleva abil UrBackup<\/i> \u00f5nnestus andmed taastada 8 minutiga ja 19 sekundiga, samal ajal oli koormus <\/p>\n

selline:<\/b>\"Varundamine,
\n
\nK\u00f5ik n\u00e4itab endiselt mitte eriti k\u00f5rget koormust, isegi madalam kui tar. Kohati esinevad t\u00f5usud, kuid mitte rohkem kui \u00fche tuuma koormus.<\/p>\n

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

\nKuidas \u00f6eldi \u00fches varasemas artiklis, peab varunduss\u00fcsteem vastama j\u00e4rgmistele kriteeriumidele:<\/p>\n