Varundamine ei ole just moes olev tehnoloogia, millest räägitakse igas ajakirjas. See peaks lihtsalt olema igas tõsises ettevõttes – ja kõigest nii. Meie pangas varundatakse mitu tuhat serverit – see on keeruline ja huvitav töö, mille mõningatest nüanssidest ja ka tüüpilistest eksiarvamustest varundamise kohta tahaksingi rääkida.
Olen sellega tegelema hakanud juba pea 20 aastat, millest viimased 2 aastat – Promsvyazbankis. Alguses tegin varundamist peaaegu käsitsi, skriptidega, mis lihtsalt kopeerisid faile. Siis tulid Windowsis mugavad tööriistad: utiliit Robocopy failide ettevalmistamiseks ja NT Backup kopeerimiseks. Ja siis tuli aeg spetsialiseeritud tarkvarale, eelkõige Veritas Backup Exec, mis nüüd kannab nime Symantec Backup Exec. Nii et varundamisega olen tuttav juba pikka aega.
Lihtsalt öeldes, varundamine tähendab andmete koopia säilitamist (virtuaalmasinad, rakenduste, andmebaaside ja failide) regulaarselt. Juhtumid ilmnevad tavaliselt seadme või loogilise tõrke näol ja toovad kaasa andmete kadumise. Varundussüsteemi ülesanne on vähendada teabe kaotamisega seotud kahjusid. Seadmestiku tõrge on näiteks serveri või salvestusseadmestiku rike, kus andmebaas asub. Loogilised tõrked on seotud andmete kadumise või muutmisega, sealhulgas inimese mõju tõttu: tabeli või faili eksitamine, vale skripti käivitamine. On ka regulatiivsed nõuded teatud tüüpi teabe säilitamiseks pikaks ajaks, näiteks kuni mitmeks aastaks.
Kõige tüüpilisem varundamise eesmärk on taastada talletatud andmekoopiaid andmebaasidest erinevate testimise süsteemide, arendajatele mõeldud kloonide loomiseks.
Küsimused varundamise kohta on tekitanud mitmeid levinud müüte, mida on juba ammu aeg ümber lükata. Siin on kõige tuntumad neist.
Müüt 1. Varundamine on juba ammu vaid väikene funktsioon turvasüsteemide või andmete salvestamise osana.
Varunduslahendused on endiselt üsna iseseisev lahenduste klass, millele on pandud väga oluline ülesanne. Nad on tegelikult viimane kaitseliin, millest sõltub andmete säilitamine. Seega töötab varundamine oma rütmis ja oma ajakava järgi. Serverite kohta koostatakse igapäevane aruanne ning esinevad sündmused, mis käivitavad jälgimissüsteemi.
Lisaks võimaldab rollimudel juurdepääsuks varundussüsteemi volituste osalist delegeerimist sihtsüsteemide administraatoritele, kes haldavad varukoopiaid.
Müüt 2. Kui on RAID, ei ole varundamine enam vajalik.
Ilmselgelt on RAID-massiivid ja andmete replikatsioon head viisid, kuidas kaitsta teabe süsteeme tehniliste riketega, ning standby-serveri olemasolul on kiire ülemineku korraldamine peamise masina rikke korral lihtne.
Kasutajate süsteemis tehtud loogilised vead ei päästa liigse kopeerimise ja dubleerimise eest. Siin aitab standby-server, millel on edasilükatud salvestamine – jah, see võib päästa, kui viga avastatakse enne, kui see on sünkroniseeritud. Aga mis juhtub, kui õige hetk on möödas? Ainult õigel ajal tehtud varukoopia aitab. Kui on teada, et andmed muutusid eile, saab süsteemi taastada eelmise päeva seisuga ja vajalikud andmed sealt välja tõmmata. Arvestades, et loogilised vead on kõige sagedasemad, jääb vana hea varukoopia usaldusväärseks ja vajalikuks abivahendiks.
Müüt 3. Varukoopia on midagi, mida tehakse kord kuus.
Varundamise sagedus on kohandatav parameeter, mis sõltub eelkõige varundussüsteemi nõuetest. On täiesti realistlik leida andmeid, mis praktiliselt kunagi ei muutu ja ei ole eriti olulised, nende kadumine ei ole ettevõttele kriitiline.
Neid tõepoolest saab varundada kord kuus ja isegi harvem. Kuid kriitilisemaid andmeid säilitakse sagedamini, sõltuvalt RPO (Recovery Point Objective) näitajast, mis määrab lubatud andmekao. See võib olla kord nädalas, kord päevas või isegi mitu korda tunnis. Meil on need andmebaasi tehingute logid.
Süsteemide tööstusliku kasutuselevõtu käigus tuleb tingimata kinnitada varundamise dokumentatsioon, milles on kajastatud peamised punktid, uuendamise regulatsioon, süsteemi taastamise kord, varukoopiate säilitamise kord ja muu.
Müüt 4. Koopiate maht kasvab pidevalt ja täidab täielikult igasugust eraldatud ruumi.
Varukoopiate säilitamise tähtaeg on piiratud. Pole mõtet näiteks aastaringselt koguda kõiki 365 igapäevast varukoopiat. Üldiselt on lubatud säilitada igapäevased koopiad 2 nädalat, pärast mida asendatakse need uute koopiatega, ja pikaajalises säilitamises jääb alles see versioon, mis tehti kuu esimesel päeval. See omakorda säilib teatud aja – igal koopia on oma eluiga.
On olemas kaitse andmete kadumise eest. Kehtib reegel: enne, kui varukoopia kustutatakse, peab järgmine olema loodud. Seetõttu ei kustutata andmeid, kui varukoopia ei õnnestunud, näiteks serveri kättesaamatuse tõttu. Jälgitakse mitte ainult ajaraame, vaid kontrollitakse ka koopiate arvu komplektis. Kui süsteemis on seadistatud, et peab olema kaks täielikku varukoopiat, siis neid on alati kaks, ja vana kustutatakse alles siis, kui uus kolmas on edukalt salvestatud. Seega on varukoopia arhiveerimise suuruse kasv seotud ainult kaitstud andmete arvu kasvuga ja ei sõltu ajast.
Müüt 5. Alguses bäkape - kõik hangus
Parem on öelda nii: kui kõik hangus, siis on administraatori käed vale koha peal. Üldiselt sõltub varukoopia jõudlus paljusid teguritest. Näiteks varukoopiate süsteemi jõudlusest: kui kiiresti töötab sealne kettaruum ja lintide raamatukogud. Jõudlusest serverite varukoopiate süsteem: kas nad suudavad andmeid töödelda, tihendada ja deduplicate. Samuti lähevad arvesse klientide ja serveri vahelise suhtlusliini kiirus.
Backup võib toimuda ühes või mitmes voos, olenevalt sellest, kas varundatav süsteem toetab mitmevoo töötlemist. Näiteks andmebaasisüsteem Oracle lubab kasutada mitmeid vooge, mis vastavad saadavalolevate protsessorite arvule, kuni edastuskiirus ei jõua võrgu ribalaiuse piiranguni.
Kui proovida varundada liiga suures hulgas voogudes, on oht koormata töötavat süsteemi, mis tõesti võib hakata aeglustuma. Seetõttu valitakse optimaalne voogude arv, et tagada piisav jõudlus. Kui aga ka kõige väiksem jõudluse vähenemine on kriitilise tähtsusega, on suurepärane lahendus varundada mitte tootmiserverilt, vaid selle koopia pealt – standby andmebaasi terminoloogias. See protsess ei koorma põhitegevust. Andmeid saab koguda suurema hulga voogude kaudu, kuna serverit ei kasutata teenindamiseks.
Suuremates organisatsioonides luuakse varundussüsteemile eraldi võrk, et varundamine ei mõjutaks tootmisprotsesse. Lisaks võib liiklus edastada mitte läbi võrgu, vaid läbi SAN.
Me püüame koormust jaotada ka ajaliselt. Varukoopiad tehakse enamasti mitte tööajal: öösel, nädalavahetustel. Lisaks ei käivitu need kõik korraga. Virtuaalmasinate varukoopiad on eriline juhtum. Protsess ei mõjuta peaaegu üldse masina jõudlust, seega saab varukoopiaid hajutada ka päevasel ajal, mitte lükata kõike öösse. Kui kõik nüansid arvesse võtta, ei mõjuta varundamine süsteemide jõudlust.
Müüt 6. Käivitasin varundussüsteemi – ja nüüd on siin talitluspüsivus.
Ärge kunagi unustage, et varundussüsteem on viimane kaitseliin, seega peab enne seda olema veel mitu süsteemi, mis tagavad IT-infrastruktuuri ja ettevõtte infotehnoloogiliste süsteemide pidevuse, kõrge kättesaadavuse ja katastroofikindluse.
Lootes on, et varundamine taastab kõik andmed ja tõstab kiiresti üles kukkunud teenuse. Andmete kaotus varundamise hetkest kuni rikete hetkeni on garanteeritud, ja uue serveri andmete üleslaadimine võib võtta mitu tundi (või päeva, kuidas läheb). Seetõttu on mõistlik luua täielikult talitluspidevaid süsteeme, mitte kõik varundamise peale loota.
Müüt 7. Hästi seadistatud varundamine, kontrollisin, et see töötab. Jääb ainult logisid vaadata.
See on üks kahjulikemaid müüte, mille valeusust teadvustatakse alles intsidendi ajal. Logid eduka varundamise kohta ei tähenda, et kõik tõeliselt läks nii nagu vaja. Salvestatud koopiat on oluline eelnevalt testida, et kontrollida selle taastatavust. Teisisõnu, käivitage taastamisprotsess testkeskkonnas ja vaadake tulemust.
Ja veidi süsteemiadministraatori tööst.
Käsi järgi enam andmeid ei kopeerita. Kaasaegsed SRK-d oskavad varundada praktiliselt kõike, piisab vaid selle korralikust seadistamisest. Kui on lisandunud uus server, tuleb poliitikad määrata: valida sisu, mida varundada, määrata säilitamise parameetrid ja rakendada ajakava.
Samas on tegemist siiski ulatusliku serveripargiga, kuhu kuuluvad andmebaasid, meilisüsteemid, virtuaalmasinate klastrid ja failiresursid nii Windowsis kui ka Linuxi/Unixis. Backup-süsteemi töövõimet toetavad töötajad ei istu kunagi käed rüpes.
Püha puhul soovin kõigile administraatoritele tugevate närvide, selgete liigutuste ja lõputu ruumi bekkapite hoidmiseks!
Allikas: habr.com
