Rezervimi nuk është një nga teknologjitë e modës për të cilat brohorasin nga çdo hekur. Thjesht duhet të jetë në ndonjë kompani serioze, kjo është e gjitha. Ne bëjmë kopje rezervë të disa mijëra serverëve në bankën tonë - kjo është një punë komplekse, interesante, disa nga hollësitë e së cilës, si dhe keqkuptimet tipike rreth kopjeve rezervë, thjesht duan të tregohen.
Unë kam punuar në këtë temë për gati 20 vjet, nga të cilat 2 vitet e fundit kanë qenë në Promsvyazbank. Në fillim të praktikës, bëra kopje rezervë pothuajse manualisht, me skriptet që thjesht kopjonin skedarët. Pastaj u shfaqën mjete të përshtatshme në Windows: mjeti Robocopy për përgatitjen e skedarëve dhe NT Backup për kopjim. Dhe vetëm atëherë erdhi koha për softuer të specializuar, kryesisht Veritas Backup Exec, i cili tani quhet Symantec Backup Exec. Kështu që unë jam njohur me kopjet rezervë për një kohë të gjatë.
Me fjalë të thjeshta, rezervimi është mbajtja e një kopjeje të të dhënave (makinat virtuale, aplikacionet, bazat e të dhënave dhe skedarët) vetëm në rast me një rregullsi të caktuar. Çdo rast zakonisht manifestohet si një dështim hardware ose logjik dhe rezulton në humbje të të dhënave. Qëllimi i një sistemi rezervë është të zvogëlojë humbjen e informacionit. Një dështim i harduerit është, për shembull, një dështim i serverit ose ruajtjes ku ndodhet baza e të dhënave. Logjike - kjo është humbja ose ndryshimi i një pjese të të dhënave, duke përfshirë edhe për shkak të faktorit njerëzor: ata fshinë aksidentalisht një tabelë, skedar, nisën një skenar të shtrembër për ekzekutim. Ekzistojnë gjithashtu kërkesa të rregullatorit për ruajtjen e një lloji të caktuar informacioni për një periudhë të gjatë, për shembull, deri në disa vjet.
Përdorimi më tipik i kopjeve rezervë është rivendosja e një kopjeje të ruajtur të bazave të të dhënave për vendosjen e sistemeve të ndryshme të testimit, klone për zhvilluesit.
Ka disa mite tipike rreth kopjeve rezervë që duhet të shpërndahen shumë kohë më parë. Këtu janë më të famshmit prej tyre.
Miti 1. Rezervimi ka qenë prej kohësh vetëm një funksion i vogël brenda sistemeve të sigurisë ose ruajtjes
Sistemet rezervë mbeten ende një klasë e veçantë zgjidhjesh dhe shumë të pavarura. Ata kanë shumë punë për të bërë. Në fakt, ato janë linja e fundit e mbrojtjes kur bëhet fjalë për integritetin e të dhënave. Pra, rezervimi funksionon me ritmin e vet, sipas orarit të vet. Një raport ditor gjenerohet për serverët, ka ngjarje që veprojnë si nxitës për sistemin e monitorimit.
Plus, modeli i rolit të aksesit në sistemin rezervë ju lejon të delegoni një pjesë të autoritetit tek administratorët e sistemeve të synuara për të menaxhuar kopjet rezervë.
Miti 2. Kur ka një RAID, një kopje rezervë nuk është më e nevojshme.
Pa dyshim, grupet RAID dhe riprodhimi i të dhënave janë një mënyrë e mirë për të mbrojtur sistemet e informacionit nga dështimet e harduerit, dhe nëse keni një server gatishmërie, mund të organizoni shpejt kalimin në të në rast se makina kryesore dështon.
Nga gabimet logjike që janë bërë nga përdoruesit e sistemit, teprica dhe përsëritja nuk kursen. Këtu është një server gatishmërie me shkrim mbrapa - po, mund të ndihmojë nëse zbulohet një gabim përpara se të sinkronizohej. Dhe nëse momenti humbet? Vetëm një kopje rezervë në kohë do të ndihmojë këtu. Nëse e dini që të dhënat ndryshuan dje, mund ta rivendosni sistemin në pardje dhe të nxirrni të dhënat e nevojshme prej tij. Duke pasur parasysh faktin se gabimet logjike janë më të zakonshmet, rezervimi i vjetër i mirë mbetet një mjet i provuar dhe i nevojshëm.
Miti 3. Një kopje rezervë është diçka që bëhet një herë në muaj.
Frekuenca e rezervimit është një cilësim i konfigurueshëm që varet kryesisht nga kërkesat e sistemit tuaj rezervë. Është mjaft e mundur të gjesh të dhëna që pothuajse kurrë nuk ndryshojnë dhe nuk janë veçanërisht të rëndësishme, humbja e tyre nuk do të jetë kritike për kompaninë.
Ato, në të vërtetë, mund të rezervohen një herë në muaj dhe madje edhe më rrallë. Por të dhënat më kritike ruhen më shpesh, në varësi të treguesit RPO (Recovery point Objrective), i cili përcakton humbjen e lejuar të të dhënave. Kjo mund të jetë një herë në javë, një herë në ditë ose edhe disa herë në orë. Ne i kemi këto regjistra të transaksioneve nga DBMS.
Kur sistemet vihen në funksionim komercial, duhet të miratohet dokumentacioni rezervë, i cili pasqyron pikat kryesore, procedurën e përditësimit, procedurën e rikthimit të sistemit, procedurën e ruajtjes së kopjeve rezervë dhe të ngjashme.
Miti 4. Vëllimi i kopjeve po rritet vazhdimisht dhe zë plotësisht çdo hapësirë të caktuar.
Rezervimet kanë një periudhë të kufizuar ruajtjeje. Nuk ka kuptim, për shembull, të ruash të gjitha 365 kopjet rezervë ditore gjatë vitit. Si rregull, lejohet të mbahen kopje ditore për 2 javë, pas së cilës ato zëvendësohen me të freskëta, dhe versioni që është bërë i pari në muaj mbetet në ruajtje afatgjatë. Ai, nga ana tjetër, ruhet gjithashtu për një kohë të caktuar - çdo kopje ka një jetë.
Ekziston një mbrojtje nga humbja e të dhënave. Rregulli zbatohet: para se të fshihet një kopje rezervë, duhet të formohet tjetra. Prandaj, të dhënat nuk do të fshihen nëse rezervimi nuk është përfunduar, për shembull, për shkak të mosdisponueshmërisë së serverit. Jo vetëm që respektohen kornizat kohore, por kontrollohet edhe numri i kopjeve në set. Nëse sistemi është projektuar që të ketë dy kopje rezervë të plotë, do të ketë gjithmonë dy prej tyre dhe e vjetra do të fshihet vetëm kur të shkruhet me sukses një i tretë i ri. Pra, rritja e vëllimit të zënë nga arkivi rezervë shoqërohet vetëm me rritjen e sasisë së të dhënave të mbrojtura dhe nuk varet nga koha.
Miti 5. Filloi kopjimi - gjithçka varej
Është më mirë të thuash këtë: nëse gjithçka është e varur, atëherë duart e administratorit nuk rriten prej andej. Në përgjithësi, performanca e një kopje rezervë varet nga shumë faktorë. Për shembull, në shpejtësinë e vetë sistemit rezervë: sa të shpejta janë ruajtjet e diskut, bibliotekat e kasetave. Nga shpejtësia e serverëve të sistemit rezervë: nëse kanë kohë për të përpunuar të dhënat, për të kryer kompresim dhe dedublikim. Dhe gjithashtu në shpejtësinë e linjave të komunikimit midis klientit dhe serverit.
Rezervimi mund të shkojë në një ose më shumë transmetime, në varësi të faktit nëse sistemi që rezervohet mbështet multithreading. Për shembull, Oracle DBMS ju lejon të jepni fije të shumta, sipas numrit të procesorëve të disponueshëm, derisa shpejtësia e transferimit të arrijë kufirin e gjerësisë së brezit të rrjetit.
Nëse përpiqeni të rezervoni një numër të madh temash, atëherë ekziston një shans për të mbingarkuar një sistem që funksionon, ai me të vërtetë do të fillojë të ngadalësohet. Prandaj, numri optimal i fijeve zgjidhet për të siguruar performancë të mjaftueshme. Nëse edhe rënia më e vogël e performancës është kritike, atëherë ekziston një mundësi e shkëlqyer kur kopjimi nuk kryhet nga një server luftarak, por nga kloni i tij - gatishmëria në terminologjinë e bazës së të dhënave. Ky proces nuk nis sistemin kryesor të punës. Të dhënat mund të merren përmes më shumë transmetimeve, pasi serveri nuk përdoret për mirëmbajtje.
Në organizatat e mëdha, krijohet një rrjet i veçantë për sistemin rezervë në mënyrë që rezervimi të mos ndikojë në prodhimin. Për më tepër, trafiku mund të mos transmetohet përmes rrjetit, por përmes SAN.
Ne përpiqemi të shpërndajmë ngarkesën edhe me kalimin e kohës. Rezervimet kryhen kryesisht gjatë orëve jo pune: gjatë natës, gjatë fundjavave. Gjithashtu, ata nuk vrapojnë të gjithë në të njëjtën kohë. Rezervimet e makinave virtuale janë një rast i veçantë. Procesi praktikisht nuk ka asnjë efekt në performancën e vetë makinës, kështu që rezervimi mund të shpërndahet gjatë ditës dhe të mos shtyjë gjithçka gjatë natës. Ka shumë hollësi, nëse merrni parasysh gjithçka, rezervimi nuk do të ndikojë në performancën e sistemeve.
Miti 6. Nis një sistem rezervë - kjo është toleranca e gabimeve për ju
Mos harroni kurrë se një sistem rezervë është linja e fundit e mbrojtjes, që do të thotë se duhet të ketë pesë sisteme të tjera përpara tij që sigurojnë vazhdimësinë, disponueshmërinë e lartë dhe tolerancën ndaj fatkeqësive të infrastrukturës së IT dhe sistemeve të informacionit të ndërmarrjeve.
Të shpresosh që kopja rezervë do të rivendosë të gjitha të dhënat dhe do të rrisë shpejt shërbimin e rënë nuk ia vlen. Humbja e të dhënave nga momenti i kopjimit deri në momentin e dështimit është i garantuar dhe të dhënat mund të ngarkohen në një server të ri për disa orë (ose ditë, siç jeni me fat). Prandaj, ka kuptim të krijohen sisteme të plota tolerante ndaj gabimeve pa zhvendosur gjithçka në një kopje rezervë.
Miti 7. Kam krijuar një kopje rezervë një herë, kontrollova nëse funksiononte. Mbetet vetëm për të parë regjistrat
Ky është një nga mitet më të dëmshme, falsifikimin e të cilit e kupton vetëm gjatë incidentit. Regjistrimet e suksesshme të rezervimit nuk janë një garanci që gjithçka shkoi vërtet ashtu siç duhej. Është e rëndësishme të kontrolloni paraprakisht kopjen e ruajtur për vendosje. Kjo do të thotë, filloni procesin e rikuperimit në një mjedis testimi dhe shikoni rezultatin.
Dhe pak për punën e administratorit të sistemit
Në modalitetin manual, askush nuk ka kopjuar të dhëna për një kohë të gjatë. SRK-të moderne mund të rezervojnë pothuajse gjithçka, thjesht duhet ta konfiguroni siç duhet. Nëse është shtuar një server i ri, vendosni politika: zgjidhni përmbajtjen që do të rezervohet, specifikoni opsionet e ruajtjes dhe zbatoni orarin.
Në të njëjtën kohë, ka ende shumë punë për shkak të flotës së gjerë të serverëve, duke përfshirë bazat e të dhënave, sistemet e postës, grupimet e makinave virtuale dhe ndarjet e skedarëve si në Windows ashtu edhe në Linux / Unix. Punonjësit që mbajnë në funksion sistemin rezervë nuk rrinë pa punë.
Për nder të festës, dëshiroj t'u uroj të gjithë administratorëve nerva të fortë, qartësi lëvizjesh dhe hapësirë të pafund për ruajtjen e kopjeve rezervë!
Burimi: www.habr.com