Varundamine, osa 1: Eesmärk, meetodite ja tehnoloogiate ülevaade

Miks on varukoopiate tegemine vajalik? Varustus on küllaltki usaldusväärne, lisaks on olemas 'pilved', mis on usaldusväärsemad kui füüsilised serverid: korralikult seadistatud 'pilveserver' talub tõrkeid infrastruktuuri füüsilise serveri tasemel kergelt ning teenuste kasutajatele on teenindusaeg vaid veidi, peaaegu märkamatult pikenenud. Samuti nõuab teabe dubleerimine tihti 'liigse' protsessoriteabe, ketta koormuse ja võrgu liikluse eest tasumist.

Ideaalne programm töötab kiiresti, ei voola üle operatiivmälu, ei oma vigu ja ei eksisteeri.

—Tundmatu

Kuna programme kirjutavad ikka veel inimesed, puudub testimisprotsess sageli ja programmide tarnimine toimub harva, järgides 'best practices' (mis on iseenesest samuti programmid ja seega mitte ideaalsed), peavad süsteemihaldurid enamasti lahendama lühikesi, kuid mahukaid ülesandeid: 'tagasi nagu oli', 'tuua andmebaas normaalsesse tööse', 'töötab aeglaselt — taastame' ja mu lemmik 'ei tea, mis, aga korda'.

Lisaks loogilistele vigadele, mis tulenevad arendajate hooletusest, juhuslikest olukordadest ning osalistest teadmistest või arusaamatusest programmide loomise väikestest nüanssidest — sealhulgas ühenduste ja süsteemide, sealhulgas operatsioonisüsteemide, draiverite ja püsivara osas — on veel mitmeid teisi vigu. Näiteks tuginevad enamik arendajatest runtime'ile, unustades täielikult füüsikaseadused, mille ületamine programmide abil on endiselt võimatu. See hõlmab pidevat usaldusväärsust kõvakettade süsteemides ja igasugustes andmete salvestamise alustes (sealhulgas töömälu ja protsessori vahemälu!), protsessorite töötlemise nullaega, puuduvat viga andmete edastamisel võrgus ja protsessoris töötlemisel ning võrgu viivitusi, mis on võrdsed 0-ga. Samuti ei tohiks alahinnata ühtki kuulsa tähtaega, sest kui sellele ei jõuta — tekivad probleemid, mis võivad olla sama keerulised kui võrgu ja ketta töö nüansid.

Kuidas peaksime käituma probleemide korral, mis tõusevad meie väärtuslike andmete kohale? Inimeste arendajaid ei saa asendada, ja ei ole kindel, et suudame neid lähitulevikus leida. Teisest küljest on täiesti tõestada, et programm töötab nii nagu planeeritud, suutnud ainult mõned projektid, ning tõendeid ei ole kindlasti võimalik lihtsalt võtta ja rakendada teiste, sarnaste projektide puhul. Samuti nõuavad sellised tõendid palju aega ning spetsiifilisi oskusi ja teadmisi, mis praktiliselt vähendab võimalust nende rakendamiseks deadlineste tõttu. Lisaks ei ole me veel suutnud arendada ülikiiret, odavat ja äärmiselt usaldusväärset tehnoloogiat andmete säilitamiseks, töötlemiseks ja edastamiseks. Sellised tehnoloogiad, kui need üldse eksisteerivad, on enamasti ainult kontseptsioonide kujul või — sagedamini — vaid ulme raamatutes ja filmides.

Head kunstnikud kopeerivad, suured kunstnikud varastavad.

—Pablo Picasso.

Parimad lahendused ja imeliselt lihtsad asjad sünnivad tavaliselt seal, kus kohtuvad esmapilgul täiesti ühilduvad mõisted, tehnoloogiad, teadmised ja teadusvaldkonnad.

Näiteks, lindudel ja lennukitel on tiivad, kuid vaatamata funktsionaalsele sarnasele — tegevuspõhimõte mõnedes režiimides ühtib ning tehnilised probleemid lahendatakse sarnaselt: õõnsad luud, tugevate ja kergete materjalide kasutamine jne. — tulemused on täiesti erinevad, kuigi väga sarnased. Parimad näited, mida jälgime meie tehnoloogia valdkonnas, on ka põhiliselt inspireeritud loodusest: suletud sektsioonid laevadel ja allveelaevadel — otseanalogia rõngaskurgidega; raid-massiivide koostamine ja andmete terviklikkuse kontrollimine — DNA ahela dubleerimine; samuti paarisorganid, erinevate organite töö sõltumatus kesknervesüsteemist (südametöö automaatika) ja refleksid — autonoomsed süsteemid Internetis. Loomulikult võivad valmis lahenduste „otsemüük“ kasutamine tuua probleeme, aga kes teab, võib-olla polegi teisi lahendusi olemas.

Kui ainult teaks, kus kukun — paneks heina alla!

— Valgevene rahvapärane ütlus

See tähendab, et varukoopiad on eluliselt vajalikud neile, kes soovivad:

• Omada võimalust taastada oma süsteemide töö minimaalsete seiskamisaegadega, isegi ilma nendeta.
• Otsustage julgelt, sest vigade korral on alati võimalik taastada.
• Minimeerida andmete tahtliku rikutud tulemusi.

Siin on natuke teooriat.

Iga klassifikatsioon on meelevaldne. Loodus ei klassifitseeri. Me klassifitseerime, sest see on meile mugavam. Ja klassifitseerime andmete põhjal, mida me samuti meelevaldsetena võtame.

— Jean Bruyler

S sõltumata füüsilisest andmete salvestamise viisist saab loogilise andmete salvestamise jagada tinglikult kaheks juurdepääsuviisiks: plokkide ja failide. Viimasel ajal on see jagunemine üha rohkem hägustunud, sest täiesti puhtaid plokkimise ega failide loogilisi salvestusi ei eksisteeri. Siiski, lihtsuse huvides eeldame, et need on olemas.

Plokisüsteemide andmesalvestamine tähendab, et on füüsiline seade, kuhu andmed kirjutatakse teatud fikseeritud portsjonitena, plokkidena. Juurdepääs plokkidele toimub teatud aadressi kaudu, kus igal plokil on oma aadress seadme piires.

Varukoopia tehakse tavaliselt andmeplokkide kopeerimise teel. Andmete terviklikkuse tagamiseks kopimise ajal peatatakse uute plokkide kirjutamine ning olemasolevate muutmine. Kui tuua paralleel tavalisest maailmast, siis sarnaneb see kõige enam kapiga, millel on ühesugused numbritega tähistatud sektsioonid.

Andmete salvestamine failide järgi on loogikapõhine ja sarnaneb sageli plokkstruktuuriga. Oluline erinevus on salvestamise hierarhii olemasolu ja inimkeele mõistetele tuginevad nimed. Eraldatakse abstraktsioonina fail — nimeline andmevaldkond, samuti kataloog — spetsiifiline fail, kus hoitakse kirjeldusi ja ligipääse teistele failidele. Faile võib varustada täiendavate metainfodega: loomise aeg, ligipääsu lipud jms. Tüüpiliselt reserveeritakse nii: otsitakse muudetud faile, seejärel kopeeritakse need teise, struktuurilt sarnasesse failihoidlasse. Andmete terviklikkust tagatakse tavaliselt failide puudumise kaudu, kuhu salvestamine toimub. Failide metainfot reserveeritakse sarnaselt. Kõige lähedasem analoog on raamatukogu, kus on erinevad jaotised erinevate raamatute jaoks ning olemas on kataloog, kus on inimkeele mõistetele tuginevad raamatute nimed.

Viimasel ajal on mõnikord kirjeldatud veel ühte varianti, mille järgi, põhimõtteliselt, algas failide andmete salvestamine ja millel on samad arhailised jooned: objekti andmete salvestamine.

Objektite salvestamine erineb failisalvestamisest selle poolest, et sellel ei ole rohkem kui ühe taseme (tasane skeem) sügavust ning failide nimetused, kuigi inimsõbralikud, on siiski rohkem kohandatud masinatel töötlemiseks. Varundamise ajal töödeldakse objektide salvestusi kõige sagedamini nagu failisüsteeme, kuid harva on ka teisi variante.

— On kahte tüüpi süsteemiadministraatoreid: need, kes ei tee varukoopiaid, ja need, kes JUBA teevad.
— Tegelikult on kolme tüüpi: on ka selliseid, kes kontrollivad, kas varukoopiaid saab taastada.

—Tundmatu

On oluline mõista, et andmete varundamise protsess toimub programmide abil, seega kaasnevad sellega kõik need samad puudused nagu teiste programmidega. Inimfaktorist sõltumise vähendamiseks, samuti eripärade, mis eraldi ei mõjuta, kuid koos võivad avaldada märkimisväärset mõju, kasutatakse nn 3-2-1 reeglit. On palju variante, kuidas seda tõlgendada, kuid mulle meeldib järgmine tõlgendus: hoida tuleb 3 komplekti samu andmeid, 2 komplekti erinevates formaatides ja 1 komplekt peab olema geograafiliselt kaugemal asuvas salvestusasendis.

Salvestusvormi all tuleb mõista järgmist:

• Kui sõltume füüsilisest salvestusviisist, siis muudame füüsilist viisi.
• Kui sõltume loogilisest salvestusviisist, siis muudame loogilist viisi.

Maximaalse efekti saavutamiseks 3-2-1 reegli järgi soovitatakse salvestusvormi muuta mõlemal viisil.

Varukoopia valmiduse seisukohalt, selle otstarbekuse — töövõime taastamise — osas eristatakse "kuumi" ja "külmi" varukoopiaid. Kuumad erinevad külmadest vaid ühe aspekti poolest: need on kohe kasutusvalmis, samas kui külmad vajavad taastamiseks teatud täiendavaid toiminguid, nagu dekrüpteerimine, arhiivist väljavõtmine jne.

Ärge segage kuumi ja külmi koopiaid online ja offline kopeerimisega, mis tähendavad andmete füüsilist isoleerimist ja on põhimõtteliselt teise klassifikatsiooni tunnus varundamisviiside osas. Niisiis, offline koopia — mis ei ole otse süsteemiga ühendatud, kuhu seda tuleb taastada — võib olla nii kuum kui külm (valmiduse osas taastamiseks). Online koopia võib olla otse seal, kus seda tuleb taastada, ja on enamasti kuum, kuid esinevad ka külmad.

Lisaks ei tohi unustada, et varukoopia loomise protsess ei lõppe tavaliselt ühe varukoopia loomisega ning varukoopiaid võib olla piisavalt palju. Seetõttu tuleb eristada täisvarukoopiaid, st neid, mida saab taastada iseseisvalt, ja samuti erinevaid (inkrementaalseid, diferentsiaalseid, dekrementaalseid jne) varukoopiaid — neid, mida ei saa iseseisvalt taastada ja mis vajavad eelnevat taastamist ühe või mitme teise varukoopia alusel.

Diferentsiaalsed inkrementaalsed varukoopiad — katse säästa varukoopiate salvestusruumi suurust. Seega salvestatakse varukoopiasse ainult muutunud andmed, alates viimasest varukoopiast.

Diferentsiaalsed dekrementaalsed varukoopiad luuakse sama eesmärgi saavutamiseks, kuid veidi teistsugusel viisil: tehakse täisvarukoopia, kuid tegelikult hoitakse ainult erinevust uue koopia ja eelneva vahel.

Oluline on käsitleda varundamisprotsessi, mis toetab dubleerimise puudumist salvestuses. Sellisel juhul, kui kirjutada täielikke varukoopiaid, salvestatakse tegelikult ainult erinevused varukoopiate vahel, kuid varukoopiate taastamisprotsess toimub nagu täieliku koopia taastamisel, olles täiesti läbipaistev.

Quis custodiet ipsos custodes?

(Kes kaitseb valvureid? — ladina keeles.)

On äärmiselt ebameeldiv, kui varukoopiaid pole, kuid veel hullem on, kui varukoopia on näiliselt tehtud, kuid taastamisel selgub, et seda ei saa taastada, sest:

• Algandmete terviklikkus on rikutud.
• Varukoopia salvestus on kahjustatud.
• Taastamine toimub väga aeglaselt, andmeid, mis on osaliselt taastatud, ei saa kasutada.

Korrektselt üles ehitatud varundamisprotsess peab arvesse võtma selliseid märkusi, eriti kahte esimest.

Algandmete terviklikkuse tagamine on võimalik mitmel viisil. Kõige sagedamini kasutatakse järgmist: a) failisüsteemi tasemel kloonide loomine, b) failisüsteemi oleku „külmutamine”, c) eriline versioonihoidla plokkseade, d) failide või plokkide järjestikune kirjutamine. Samuti kasutatakse kontrollsummasid, et tagada andmete kontroll taastamise käigus.

Salvestusvigade avastamiseks on võimalik kasutada ka kontrollsummasid. Täiendava meetodina kasutatakse spetsialiseeritud seadmeid või failisüsteeme, kus ei saa juba kirjutatud andmeid muuta, aga uusi andmeid saab lisada.

Andmete taastamiseks kasutatakse mitme protsessiga taastamist, eeldusel, et ei esine aeglast võrku ega aeglast kõvakettasüsteemi, mis võiksid taastamise protsessi aeglustada. Probleemsete andmete osalise taastamise vältimiseks on soovitatav jagada varundamisprotsess väiksemateks alatehtudeks, millest igaüht viiakse ellu eraldi. Nii on võimalik järjestikku taastada süsteemi töövõime, prognoosides taastamise aega. See probleem tuleneb sageli organizatsioonilistest piirangutest (SLA), seega ei jääme selle juures pikemalt peatuma.

Tõeliselt oskab maitsesegusid hinnata see, kes lisab neid vaid õiges koguses, mitte see, kes paneb neid igasse rooga.

—V. Sinjavski

Süsteemiadministraatorite praktikas kasutatavate tarkvarade osas võivad erisused esineda, kuid üldised põhimõtted jäävad siiski samaks, sealhulgas:

• Soovitatakse kasutada valmis lahendusi.
• Programmid peavad töötama ettearvamatult, st ei tohi olla dokumenteerimata omadusi ega kitsaskohti.
• Iga programmi seadistamine peaks olema piisavalt lihtne, et ei peaks iga kord lugema kasutusjuhendit või märkmeid.
• Lahendus peaks olema võimaluse korral universaalne, kuna serverite riistvaralised omadused võivad oluliselt erineda.

Plokkseadmetelt varukoopiate tegemiseks on mitmeid levinud programme:

• dd, tuntud süsteemiadministraatorite seas, samuti kuuluvad siia sarnased programmid (nt dd_rescue).
• Mõnesse failisüsteemi sisseehitatud hooldusprogrammid (utiliidid), mis loovad failisüsteemi koopia (dump).
• Universaalsed utiliidid; näiteks partclone.
• Omandipõhised lahendused; näiteks NortonGhost ja hilisemad.

Failisüsteemide varundamise ülesanne lahendatakse osaliselt plokkseadmete jaoks rakendatavate meetoditega, kuid selle saab lahendada ka tõhusamalt, kasutades näiteks:

• Rsync, universaalne programm ja protokoll failisüsteemide oleku sünkroonimiseks.
• Sisseehitatud arhiveerimise tööriistad (ZFS).
• Kolmandad osapooled arhiveerimise tööriistad; kõige populaarsem esindaja on tar. On ka teisi, näiteks dar — tar'i asendus, mis on suunatud kaasaegsetele süsteemidele.

Eraldi tasub mainida andmete järjepidevuse tagamise tarkvaralahendusi varukoopiate loomisel. Kõige sagedamini kasutatakse järgmisi variante:

• Failisüsteemi mountimine ainult lugemisrežiimi (ReadOnly) või failisüsteemi külmutamine (freeze) — meetod on piiratud kasutuses.
• Failisüsteemi või plokiseadmestike (LVM, ZFS) oleku koopia loomine.
• Kolmandate osapoolte tööriistade kasutamine koopia korraldamiseks, isegi juhul, kui eelnevaid punkte ei ole mingil põhjusel võimalik tagada (programmid, nagu hotcopy).
• Muudatuste korral kopeerimise tehnika (CopyOnWrite), kuid see on enamasti seotud kasutatava failisüsteemiga (BTRFS, ZFS).

Seega peab väike server tagama varukoopia koostamise skeemi, mis vastab järgmistele nõudmistele:

• Lihtne kasutada — ei vaja erilisi täiendavaid toiminguid, minimaalne tegevus koopiate loomiseks ja taastamiseks.
• Universaalne – töötab nii suurte kui ka väikeste serveritega; see on oluline arvu suurenemise või skaleerimise korral. serverite Installitakse paketihalduri abil või ühe-kahe käsklusega, nagu "lae alla ja korralda".
• Stabiilne – kasutab standardset või juba ammu tuntud salvestusformaati.
• Kiire töökorraldus.
• Kandidaadid, kes vastavad rohkem-vähem nõuetele:

Kandidaadid, kes vastavad nõuetele enam-vähem:

• rdiff-backup
• rsnapshot
• burp
• duplicati
• duplicity
• deja dup
• dar
• zbackup
• restic
• borgbackup

Katsestendi jaoks kasutatakse virtuaalmasinat (XenServeri baasil) järgmiste omadustega:

• 4 tuuma 2,5 GHz,
• 16 GB RAM-i,
• 50 GB hybrid storage (SSD vahemälu 20% virtuaaldiskist) eraldi virtuaaldiskina ilma jaotamata,
• 200 Mbit/s kanal Internetti.

Varukoopiate vastuvõtmiseks kasutatakse praktiliselt sama masinat, vaid 500 GB kõvakettaga.

Käitusüsteem – CentOS 7 x64: tavapärane partitsioneerimine, lisajaotust kasutatakse andmeallikana.

Algandmetena kasutame WordPressi veebisaiti, mille meediafailide maht on 40 GB, ja MySQL andmebaasi. Kuna virtuaalsed serverid erinevad omaduste poolest, samuti parema reprodutseeritavuse saavutamiseks, siin on

serveri testimise tulemused, kasutades sysbench'i.sysbench —threads=4 —time=30 —cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (kasutades sisseehitatud LuaJIT 2.1.0-beta3)
Katsed järgnevate valikutega:
Keenid: 4
Algatatakse juhuslike numbrite generaator praegusest ajast

Prime numbrite piir: 20000

Töötajate teemasid algatatakse…

Teemad on käivitatud!

CPU kiirus:
sündmused sekundis: 836.69

Läbilaskevõime:
sündmused/s (eps): 836.6908
möödunud aeg: 30.0039s
kokku sündmuste arv: 25104

Latentsus (ms):
min: 2.38
avg: 4.78
max: 22.39
95. protsentil: 10.46
summa: 119923.64

Teemade õiglus:
sündmused (avg/stddev): 6276.0000/13.91
täitmise aeg (avg/stddev): 29.9809/0.01

sysbench —threads=4 —time=30 —memory-block-size=1K —memory-scope=global —memory-total-size=100G —memory-oper=read memory run
sysbench 1.1.0-18a9f86 (kasutades sisseehitatud LuaJIT 2.1.0-beta3)
Katsed järgnevate valikutega:
Keenid: 4
Algatatakse juhuslike numbrite generaator praegusest ajast

Mälu kiiruskatse järgmiste valikutega:
ploki suurus: 1KiB
kogusumma: 102400MiB
tegevus: lugemine
ulatus: globaalne

Töötajate teemasid algatatakse…

Teemad on käivitatud!

Kokku operatsioone: 50900446 (1696677.10 sekundis)

49707.47 MiB edastatud (1656.91 MiB/sec)

Läbilaskevõime:
sündmused/s (eps): 1696677.1017
möödunud aeg: 30.0001s
kokku sündmuste arv: 50900446

Latentsus (ms):
min: 0.00
avg: 0.00
max: 24.01
95. protsentil: 0.00
summa: 39106.74

Teemade õiglus:
sündmused (avg/stddev): 12725111.5000/137775.15
täitmise aeg (avg/stddev): 9.7767/0.10

sysbench —threads=4 —time=30 —memory-block-size=1K —memory-scope=global —memory-total-size=100G —memory-oper=write memory run
sysbench 1.1.0-18a9f86 (kasutades sisseehitatud LuaJIT 2.1.0-beta3)
Katsed järgnevate valikutega:
Keenid: 4
Algatatakse juhuslike numbrite generaator praegusest ajast

Mälu kiiruskatse järgmiste valikutega:
ploki suurus: 1KiB
kogusumma: 102400MiB
tegevus: kirjutamine
ulatus: globaalne

Töötajate teemasid algatatakse…

Teemad on käivitatud!

Kokku operatsioone: 35910413 (1197008.62 sekundis)

35068.76 MiB edastatud (1168.95 MiB/sec)

Läbilaskevõime:
sündmused/s (eps): 1197008.6179
möödunud aeg: 30.0001s
kokku sündmuste arv: 35910413

Latentsus (ms):
min: 0.00
avg: 0.00
max: 16.90
95. protsentil: 0.00
summa: 43604.83

Teemade õiglus:
sündmused (avg/stddev): 8977603.2500/233905.84
täitmise aeg (avg/stddev): 10.9012/0.41

sysbench —threads=4 —file-test-mode=rndrw —time=60 —file-block-size=4K —file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (kasutades sisseehitatud LuaJIT 2.1.0-beta3)
Katsed järgnevate valikutega:
Keenid: 4
Algatatakse juhuslike numbrite generaator praegusest ajast

Lisafaili avamise lipud: (pole)
128 faili, igaühe maht 8MiB
Kokkufaili suurus 1GiB
Ploki suurus 4KiB
I/O päringute arv: 0
Lugemise/Kirjutamise suhe juhusliku I/O testi jaoks: 1.50
Perioodilised FSYNC on lubatud, fsync() kutsub iga 100 päringu järel.
Kutsun fsync() testi lõpus, lubatud.
Kasutatakse süncroniseeritud I/O režiimi
Tehakse juhuslikku r/w testi
Töötajate teemasid algatatakse…

Teemad on käivitatud!

Läbilaskevõime:
lugemine: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
kirjutamine: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98

Latentsus (ms):
min: 0.00
keskmine: 0.27
max: 18.01
95. percenti: 1.08
summa: 238469.45

Selle märkusega algab suur

artiklite tsükkel varundamisest

1. Varundamine, osa 1: Miks on varundamine vajalik, meetodite, tehnoloogiate ülevaade
2. Varundamine, osa 2: rsync-põhiste varunduslahenduste ülevaade ja testimine
3. Varundamine, osa 3: Duplicity, duplicaty, deja dup ülevaade ja testimine
4. Varundamine, osa 4: Zbackup, restic, borgbackup ülevaade ja testimine
5. Varundamine, osa 5: Bacula ja Veeam Backup for Linux testimine
6. Varundamine, osa 6: Varundamisvahendite võrdlus
7. Varundamine, osa 7: Järeldused

Allikas: habr.com