Šiame straipsnyje bus palyginami atsarginių kopijų kūrimo įrankiai, tačiau pirmiausia turėtumėte išsiaiškinti, kaip greitai ir gerai jie susidoroja su duomenų atkūrimu iš atsarginių kopijų.
Kad būtų lengviau palyginti, apsvarstysime galimybę atkurti iš visos atsarginės kopijos, ypač todėl, kad visi kandidatai palaiko šį veikimo režimą. Paprastumo dėlei skaičiai jau yra suvidurkinami (kelių važiavimų aritmetinis vidurkis). Rezultatai bus apibendrinti lentelėje, kurioje taip pat bus informacija apie galimybes: žiniatinklio sąsajos buvimas, sąrankos ir veikimo paprastumas, galimybė automatizuoti, įvairių papildomų funkcijų buvimas (pavyzdžiui, duomenų vientisumo tikrinimas) ir kt. Grafikai parodys serverio, kuriame bus naudojami duomenys, apkrovą (ne serverio atsarginėms kopijoms saugoti).
Duomenų atkūrimas
rsync ir tar bus naudojami kaip atskaitos taškas, nes paprasti scenarijai atsarginėms kopijoms kurti.
"Rsync" su testo duomenų rinkiniu susidorojo per 4 minutes ir 28 sekundes, parodydamas
toks krūvis
Atkūrimo procesas susidūrė su atsarginės kopijos saugojimo serverio disko posistemio apribojimu (sawtooth grafikai). Taip pat aiškiai matosi vieno branduolio įkėlimas be jokių problemų (low iowait ir softirq – jokių problemų atitinkamai su disku ir tinklu). Kadangi kitos dvi programos, būtent rdiff-backup ir rsnapshot, yra pagrįstos rsync ir taip pat siūlo įprastą rsync kaip atkūrimo įrankį, jų įkėlimo profilis ir atsarginės kopijos atkūrimo laikas bus maždaug toks pat.
Derva pavyko šiek tiek greičiau
2 minutės ir 43 sekundės:
Bendra sistemos apkrova buvo didesnė vidutiniškai 20% dėl padidėjusio softirq - padidėjo pridėtinės išlaidos tinklo posistemio eksploatavimo metu.
Jei archyvas dar labiau suglaudinamas, atkūrimo laikas pailgėja iki 3 minučių 19 sekundžių.
esant tokiai apkrovai pagrindiniame serveryje (išpakavimas pagrindinio serverio pusėje):
Dekompresijos procesas užima abu procesoriaus branduolius, nes vyksta du procesai. Apskritai tai yra laukiamas rezultatas. Be to, palyginamas rezultatas (3 minutės ir 20 sekundžių) buvo gautas paleidus gzip serverio pusėje su atsarginėmis kopijomis; pagrindinio serverio apkrovos profilis buvo labai panašus į paleidimą tar be gzip kompresoriaus (žr. ankstesnę diagramą).
В rdiff-atsarginė kopija galite sinchronizuoti paskutinę atsarginę kopiją, kurią padarėte naudodami įprastą rsync (rezultatai bus panašūs), tačiau senesnes atsargines kopijas vis tiek reikia atkurti naudojant rdiff-backup programą, kuri atkūrimą užbaigė per 17 minučių ir 17 sekundžių,
ši apkrova:
Galbūt taip buvo siekiama, bent jau apriboti autorių greitį . Atsarginės kopijos atkūrimo procesas užima šiek tiek mažiau nei pusę branduolio, o našumas yra proporcingas (t. y. 2–5 kartus lėtesnis) diske ir tinkle naudojant rsync.
Snapshot Atkūrimui siūloma naudoti įprastą rsync, todėl jo rezultatai bus panašūs. Apskritai viskas pasirodė taip.
burbėti Atsarginės kopijos atkūrimo užduotį atlikau per 7 minutes ir 2 sekundes
su šia apkrova:
Jis veikė gana greitai ir bent jau yra daug patogesnis nei grynas rsync: nereikia atsiminti jokių vėliavėlių, paprasta ir intuityvi Cli sąsaja, integruotas kelių kopijų palaikymas – nors du kartus lėtesnis. Jei reikia atkurti duomenis iš paskutinės atsarginės kopijos, galite naudoti rsync su keliais įspėjimais.
Programa rodė maždaug tokį patį greitį ir apkrovą Atsarginė PC įgalinus rsync perdavimo režimą, diegiant atsarginę kopiją
7 minutės ir 42 sekundės:
Tačiau duomenų perdavimo režimu „BackupPC“ su taru susidorojo lėčiau: per 12 minučių ir 15 sekundžių procesoriaus apkrova paprastai buvo mažesnė.
pusantro karto:
Dviveidiškumas be šifravimo parodė šiek tiek geresnius rezultatus, atsarginę kopiją atkūrė per 10 minučių ir 58 sekundes. Jei suaktyvinsite šifravimą naudodami gpg, atkūrimo laikas pailgėja iki 15 minučių ir 3 sekundžių. Taip pat, kurdami saugyklą kopijoms saugoti, galite nurodyti archyvo dydį, kuris bus naudojamas skaidant gaunamų duomenų srautą. Apskritai, įprastuose kietuosiuose diskuose, taip pat dėl vieno sriegio veikimo režimo, nėra daug skirtumų. Kai naudojama hibridinė saugykla, jis gali būti rodomas skirtingų dydžių blokais. Pagrindinio serverio apkrova atkūrimo metu buvo tokia:
jokio šifravimo
su šifravimu
Dublikatas parodė panašų atsigavimo greitį, užbaigdamas jį per 13 minučių ir 45 sekundes. Atkurtų duomenų teisingumo patikrinimas užtruko dar apie 5 minutes (iš viso apie 19 minučių). Krovinys buvo
gana aukštas:
Kai AES šifravimas buvo įjungtas viduje, atkūrimo laikas buvo 21 minutė 40 sekundžių, o CPU panaudojimas buvo maksimalus (abiejų branduolių!) atkūrimo metu; Tikrinant duomenis buvo aktyvi tik viena gija, užimanti vieną procesoriaus branduolį. Duomenų patikrinimas po atkūrimo užtruko tas pačias 5 minutes (iš viso beveik 27 minutes).
Rezultatas
duplicati buvo šiek tiek greitesnis atkūrimas naudojant išorinę gpg programą šifravimui, tačiau apskritai skirtumai nuo ankstesnio režimo yra minimalūs. Veikimo laikas buvo 16 minučių 30 sekundžių, o duomenų patikrinimas per 6 minutes. Krovinys buvo
tokie:
AMANDA, naudojant degutą, jį užbaigė per 2 minutes 49 sekundes, o tai iš principo yra labai artima įprastai dervai. Sistemos apkrova iš esmės
tas pats:
Atkuriant atsarginę kopiją naudojant zbackup buvo gauti šie rezultatai:
šifravimas, lzma suspaudimas
Veikimo laikas 11 minučių ir 8 sekundės
AES šifravimas, lzma suspaudimas
Veikimo laikas 14 minučių
AES šifravimas, lzo suspaudimas
Veikimo laikas 6 minutės 19 sekundžių
Apskritai, neblogai. Viskas priklauso nuo atsarginiame serveryje esančio procesoriaus greičio, kuris aiškiai matyti iš programos veikimo laiko su skirtingais kompresoriais. Atsarginio serverio pusėje buvo paleista įprasta tara, todėl palyginus su ja, atkūrimas yra 3 kartus lėtesnis. Galbūt verta patikrinti veikimą kelių gijų režimu, kai yra daugiau nei dvi gijos.
„BorgBackup“ nešifruotu režimu buvo šiek tiek lėtesnis nei tar, per 2 minutes 45 sekundes, tačiau, skirtingai nei tar, atsirado galimybė dedublikuoti saugyklą. Krovinys pasirodė esąs
Sekantis:
Jei įjungsite blake pagrįstą šifravimą, atsarginės kopijos atkūrimo greitis bus šiek tiek lėtesnis. Atkūrimo laikas šiuo režimu yra 3 minutės 19 sekundžių, o apkrova nebėra
kaip šitas:
AES šifravimas yra šiek tiek lėtesnis, atkūrimo laikas yra 3 minutės 23 sekundės, apkrova ypač didelė
nepasikeitė:
Kadangi Borg gali dirbti kelių sriegių režimu, procesoriaus apkrova yra maksimali, o suaktyvinus papildomas funkcijas, veikimo laikas tiesiog pailgėja. Matyt, verta ištirti kelių gijų kūrimą panašiai kaip zbackup.
Pailsėti su atsigavimu susitvarkė kiek lėčiau, veikimo laikas buvo 4 minutės 28 sekundės. Krovinys atrodė taip
taip:
Matyt, atkūrimo procesas veikia keliose gijose, tačiau efektyvumas nėra toks didelis kaip BorgBackup, tačiau laiko atžvilgiu panašus į įprastą rsync.
naudojant „UrBackup“ Duomenis pavyko atkurti per 8 minutes ir 19 sekundžių, apkrova buvo
tokie:
Apkrova vis dar nėra labai didelė, net mažesnė nei dervos. Kai kuriose vietose yra sprogimų, bet ne daugiau kaip vienos šerdies apkrova.
Palyginimo kriterijų parinkimas ir pagrindimas
Kaip nurodyta viename iš ankstesnių straipsnių, atsarginė sistema turi atitikti šiuos kriterijus:
- Naudojimo paprastumas
- universalumas
- Stabilumas
- Greitis
Verta išsamiau apsvarstyti kiekvieną tašką atskirai.
Eksploatacijos paprastumas
Geriausia, kai yra vienas mygtukas „Daryk viską gerai“, bet jei grįšite į tikras programas, patogiausia bus koks nors pažįstamas ir standartinis veikimo principas.
Daugumai vartotojų greičiausiai bus geriau, jei jiems nereikės prisiminti daugybės cli klavišų, konfigūruoti įvairių, dažnai neaiškių parinkčių žiniatinklyje arba tui, arba nustatyti pranešimų apie nesėkmingą veikimą. Tai taip pat apima galimybę lengvai „pritaikyti“ atsarginį sprendimą į esamą infrastruktūrą, taip pat atsarginio kopijavimo proceso automatizavimą. Taip pat yra galimybė įdiegti naudojant paketų tvarkyklę arba vieną ar dvi komandas, pvz., „atsisiųsti ir išpakuoti“. curl ссылка | sudo bash - sudėtingas metodas, nes reikia patikrinti, kas ateina per nuorodą.
Pavyzdžiui, iš svarstomų kandidatų paprastas sprendimas yra burp, rdiff-backup ir restic, kurie turi mnemoninius klavišus skirtingiems darbo režimams. Šiek tiek sudėtingesni yra borg ir dviveidiškumas. Sunkiausia buvo AMANDA. Likusi dalis naudojimo patogumo požiūriu yra kažkur per vidurį. Bet kokiu atveju, jei jums reikia daugiau nei 30 sekundžių perskaityti vartotojo vadovą, arba jums reikia eiti į „Google“ ar kitą paieškos sistemą, o taip pat slinkti ilgą pagalbos lapą, sprendimas vienaip ar kitaip yra sunkus.
Kai kurie iš svarstomų kandidatų gali automatiškai siųsti žinutę per el. pašto jabber, o kiti pasikliauja sukonfigūruotais perspėjimais sistemoje. Be to, dažniausiai sudėtingi sprendimai neturi visiškai akivaizdžių įspėjimų nustatymų. Bet kokiu atveju, jei atsarginė programa sukuria ne nulinį grąžinimo kodą, kurį teisingai supras sistemos tarnyba atliekant periodines užduotis (bus išsiųstas pranešimas sistemos administratoriui arba tiesiai į stebėjimą) – situacija paprasta. Bet jei atsarginės kopijos sistemos, kuri neveikia atsarginiame serveryje, sukonfigūruoti nepavyksta, akivaizdu, kad apie problemą galima pasakyti, kad sudėtingumas jau per didelis. Bet kokiu atveju įspėjimų ir kitų pranešimų siuntimas tik žiniatinklio sąsajai arba žurnalui yra bloga praktika, nes dažniausiai jie bus ignoruojami.
Kalbant apie automatizavimą, paprasta programa gali nuskaityti aplinkos kintamuosius, kurie nustato jos veikimo režimą, arba turi sukurtą klipą, kuris gali visiškai dubliuoti elgesį, pavyzdžiui, dirbant per žiniatinklio sąsają. Tai taip pat apima nuolatinio veikimo galimybę, plėtros galimybių prieinamumą ir kt.
universalumas
Iš dalies pakartodamas ankstesnį poskyrį apie automatizavimą, neturėtų būti didelių problemų „pritaikyti“ atsarginį procesą į esamą infrastruktūrą.
Verta paminėti, kad nestandartinių prievadų (na, išskyrus žiniatinklio sąsają) naudojimas darbui, šifravimo įgyvendinimas nestandartiniu būdu, keitimasis duomenimis naudojant nestandartinį protokolą yra nestandartinio protokolo požymiai. - universalus sprendimas. Dažniausiai visi kandidatai jas vienaip ar kitaip turi dėl akivaizdžios priežasties: paprastumas ir universalumas dažniausiai nedera. Išimtis – burp, yra ir kitų.
Kaip ženklas - galimybė dirbti naudojant įprastą ssh.
Darbo greitis
Labiausiai ginčytinas ir ginčytinas punktas. Viena vertus, mes pradėjome procesą, jis veikė kuo greičiau ir netrukdė atlikti pagrindines užduotis. Kita vertus, atsarginės kopijos kūrimo laikotarpiu didėja srautas ir procesoriaus apkrova. Taip pat verta paminėti, kad greičiausios kopijų darymo programos dažniausiai yra prasčiausios vartotojams svarbių funkcijų atžvilgiu. Vėlgi: jei norint gauti vieną nelemtą kelių dešimčių baitų tekstinį failą su slaptažodžiu ir dėl to kainuoja visa paslauga (taip, taip, suprantu, kad čia dažniausiai nėra kaltas atsarginės kopijos kūrimo procesas), ir reikia iš naujo iš eilės perskaityti visus saugykloje esančius failus arba išplėsti visą archyvą – atsarginių kopijų kūrimo sistema niekada nėra greita. Kitas dalykas, kuris dažnai tampa kliūtimi, yra atsarginės kopijos iš archyvo diegimo greitis. Čia yra aiškus pranašumas tiems, kurie gali tiesiog kopijuoti ar perkelti failus į norimą vietą be didelių manipuliacijų (pvz., rsync), tačiau dažniausiai problema turi būti sprendžiama organizaciniu būdu, empiriškai: matuojant atsarginės kopijos atkūrimo laiką. ir atvirai apie tai informuoti vartotojus.
Stabilumas
Tai reikia suprasti taip: viena vertus, atsarginę kopiją turi būti įmanoma bet kokiu būdu grąžinti atgal, kita vertus, ji turi būti atspari įvairioms problemoms: tinklo nutrūkimui, disko gedimui, dalies ištrynimui. saugykla.
Atsarginių įrankių palyginimas
Kopijos sukūrimo laikas
Kopijuoti atkūrimo laiką
Lengvas montavimas
Lengvas nustatymas
Paprastas naudojimas
Paprasta automatika
Ar jums reikia kliento serverio?
Saugyklos vientisumo tikrinimas
Diferencinės kopijos
Darbas per vamzdį
universalumas
Nepriklausomybė
Saugyklos skaidrumas
Šifravimas
Suspaudimas
Deduplikacija
Interneto sąsaja
Užpildymas iki debesies
Windows palaikymas
Rezultatas
"Rsync"
4m15s
4m28s
taip
ne
ne
ne
taip
ne
ne
taip
ne
taip
taip
ne
ne
ne
ne
ne
taip
6
Derva
grynas
3m12s
2m43s
taip
ne
ne
ne
ne
ne
taip
taip
ne
taip
ne
ne
ne
ne
ne
ne
taip
8,5
gzip
9m37s
3m19s
taip
Rdiff atsarginė kopija
16m26s
17m17s
taip
taip
taip
taip
taip
ne
taip
ne
taip
ne
taip
ne
taip
taip
taip
ne
taip
11
Snapshot
4m19s
4m28s
taip
taip
taip
taip
ne
ne
taip
ne
taip
ne
taip
ne
ne
taip
taip
ne
taip
12,5
burbėti
11m9s
7m2s
taip
ne
taip
taip
taip
taip
taip
ne
taip
taip
ne
ne
taip
ne
taip
ne
taip
10,5
Dviveidiškumas
jokio šifravimo
16m48s
10m58s
taip
taip
ne
taip
ne
taip
taip
ne
ne
taip
ne
taip
taip
ne
taip
ne
taip
11
gpg
17m27s
15m3s
Dublikatas
jokio šifravimo
20m28s
13m45s
ne
taip
ne
ne
ne
taip
taip
ne
ne
taip
ne
taip
taip
taip
taip
taip
taip
11
AES
29m41s
21m40s
gpg
26m19s
16m30s
„Zbackup“
jokio šifravimo
40m3s
11m8s
taip
taip
ne
ne
ne
taip
taip
taip
ne
taip
ne
taip
taip
taip
ne
ne
ne
10
AES
42m0s
14m1s
aes+lzo
18m9s
6m19s
„BorgBackup“
jokio šifravimo
4m7s
2m45s
taip
taip
taip
taip
taip
taip
taip
taip
taip
taip
ne
taip
taip
taip
taip
ne
taip
16
AES
4m58s
3m23s
blake2
4m39s
3m19s
Pailsėti
5m38s
4m28s
taip
taip
taip
taip
ne
taip
taip
taip
taip
taip
ne
taip
ne
taip
ne
taip
taip
15,5
„UrBackup“
8m21s
8m19s
taip
taip
taip
ne
taip
ne
taip
ne
taip
taip
ne
taip
taip
taip
taip
ne
taip
12
amanda
9m3s
2m49s
taip
ne
ne
taip
taip
taip
taip
ne
taip
taip
taip
taip
taip
ne
taip
taip
taip
13
Atsarginė PC
rsync
12m22s
7m42s
taip
ne
taip
taip
taip
taip
taip
ne
taip
ne
ne
taip
taip
ne
taip
ne
taip
10,5
degutas
12m34s
12m15s
Lentelės legenda:
- Žalia, veikimo laikas trumpesnis nei penkios minutės arba atsakymas „Taip“ (išskyrus stulpelį „Reikia kliento serverio?“), 1 balas
- Geltona, veikimo laikas nuo penkių iki dešimties minučių, 0.5 balo
- Raudona, darbo laikas daugiau nei dešimt minučių arba atsakymas yra „Ne“ (išskyrus stulpelį „Ar jums reikia kliento serverio?“), 0 taškų
Remiantis aukščiau esančia lentele, paprasčiausias, greičiausias ir tuo pačiu patogiausias bei galingas atsarginių kopijų kūrimo įrankis yra BorgBackup. Restic užėmė antrąją vietą, likusieji svarstyti kandidatai buvo išdėstyti maždaug po lygiai, pabaigoje pasiskirstę vienu ar dviem balais.
Dėkoju visiems, kurie perskaitė serialą iki galo, kviečiu aptarti variantus ir pasiūlyti savo, jei tokių yra. Diskusijai įsibėgėjus, lentelė gali būti plečiama.
Serialo rezultatas bus paskutinis straipsnis, kuriame bus bandoma sukurti idealų, greitą ir valdomą atsarginių kopijų kūrimo įrankį, leidžiantį per trumpiausią įmanomą laiką įdiegti kopiją atgal ir tuo pačiu būti patogiai bei lengvai. konfigūruoti ir prižiūrėti.
Skelbimas
Atsarginė kopija 6 dalis: Atsarginės kopijos įrankių palyginimas
Atsarginė kopija 7 dalis: Išvados
Šaltinis: www.habr.com