Backup-i nuk Ă«shtĂ« njĂ« teknologji moderne qĂ« shpallet nga çdo kĂ«nd. Thjesht duhet tĂ« ekzistojĂ« nĂ« çdo kompani serioze, kjo Ă«shtĂ« e gjitha. Ne nĂ« bankĂ« bĂ«jmĂ« backup pĂ«r disa mijĂ«ra servera â kjo Ă«shtĂ« njĂ« punĂ« e ndĂ«rlikuar dhe interesante, pĂ«r disa nga nuancat e saj, si dhe pĂ«r keqkuptimet tipike rreth backup-eve, dĂ«shiroj tĂ« flas.
Kjo temĂ« kam marrĂ« pĂ«rsipĂ«r pĂ«r gati 20 vjet, prej tĂ« cilave dy vitet e fundit â nĂ« Promsvyazbank. NĂ« fillim tĂ« praktikĂ«s merrja backup pothuajse manualisht, me skripte qĂ« thjesht kopjonin skedarĂ«. Pastaj nĂ« Windows dolĂ«n mjete tĂ« pĂ«rshtatshme: utilita si Robocopy pĂ«r pĂ«rgatitjen e skedarĂ«ve dhe NT Backup pĂ«r kopjimin. MĂ« vonĂ« erdhi koha pĂ«r software tĂ« specializuar, kryesisht Veritas Backup Exec, qĂ« tani quhet Symantec Backup Exec. Pra, kam njohuri tĂ« thella rreth backup-eve.
Nëse e thjeshtojmë, backup-i është ruajtja e një kopje të të dhënave (makinave virtuale, aplikacioneve, bazave të të dhënave dhe skedarëve) për çdo rast me një rregullshmëri të caktuar. Rasti i çdo gjëje zakonisht shfaqet si një dështim harduerik ose logjik dhe çon në humbje të të dhënave. Detyra e sistemit të backup-it është të zvogëlojë humbjet nga humbja e informacionit. Një dështim harduerik ndodhi, për shembull, kur ndalon serveri ose ruajtja, ku ndodhet baza e të dhënave. Një dështim logjik do të thotë humbje ose ndryshim i një pjese të të dhënave, përfshirë edhe për shkak të faktorëve njerëzorë: fshirja aksidentale e tabelave, skedarëve, ose ekzekutimi i një skripti të gabuar. Ka gjithashtu kërkesa nga rregullatorët për ruajtjen e një lloji të caktuar informacioni për një periudhë të gjatë, për shembull, deri në disa vjet.
Kërkesa më tipike për backup është rikthimi i një kopje të ruajtur të bazave të të dhënave për të ndërtuar sisteme të ndryshme testimi ose klone për zhvilluesit.
Rreth backup-it ekzistojnë disa mite tipike që është koha t'i shpërbëjmë. Këtu janë disa nga më të njohurat.
Miti 1. Backup-i është thjesht një funksion dytësor brenda sistemeve të sigurisë ose ruajtjes
Sistemet e backup-it vazhdojnë të mbeten një klasë e veçantë zgjidhjesh, shumë të pavarura. Ato kanë një detyrë shumë të rëndësishme. Në thelb, ato janë linja e fundit e mbrojtjes kur bëhet fjalë për ruajtjen e të dhënave. Pra, backup-i funksionon në ritmin e tij, sipas orarit të tij. Një raport ditor formohet për serverat, ka ngjarje që veprojnë si një shkak për sistemin e monitorimit.
Për më tepër, modeli i qasjeve të rolit në sistemin e backup-it lejon delegimin e disa autoriteteve administratave të sistemeve të caktuara për menaxhimin e backup-eve.
Miti 2. Kur ka RAID, backup-i nuk është më i nevojshëm
Sigurisht, RAID-ët dhe replikimi i të dhënave janë një mënyrë e mirë për t'i mbrojtur sistemet informative nga dështimet harduerike, dhe nëse ka një server rezervë, është e lehtë të kalosh aty në rast dështimi të makinës kryesore.
PĂ«r dĂ«shtimet logjike qĂ« ndodhin pĂ«r shkak tĂ« vetĂ« pĂ«rdoruesve, shterimi dhe replikimi nuk ofrojnĂ« mbrojtje. NjĂ« server rezervĂ« me shkruarje tĂ« vonuar â po, mund tĂ« ndihmojĂ«, nĂ«se gabimi zbulohet para se tĂ« sinkronizohet. Por nĂ«se momenti humbet? AtĂ«herĂ« vetĂ«m njĂ« backup i kryer nĂ« kohĂ« mund tĂ« ndihmojĂ«. NĂ«se dihet se tĂ« dhĂ«nat ndryshuan dje, mund tĂ« rikthehet sistemi nĂ« gjendjen e para dy ditĂ«ve dhe tĂ« nxirren tĂ« dhĂ«nat e nevojshme. Duke marrĂ« parasysh faktin qĂ« gabimet logjike janĂ« mĂ« tĂ« zakonshmet, backup-i i mirĂ« i lashtĂ« mbetet njĂ« mjet i provuar dhe i nevojshĂ«m.
Miti 3. Backup-i është diçka që bëhet një herë në muaj.
Frekuenca e backup-it është një parametër i konfigurueshëm, kryesisht në varësi të kërkesave për sistemin e backup-it. Mjafton të gjejmë të dhëna që pothuajse nuk ndryshojnë kurrë dhe nuk janë shumë të rëndësishme; humbja e tyre nuk do të jetë fatale për kompaninë.
Ato vërtet mund të bëhen backup një herë në muaj e madje edhe më rrallë. Ndërsa të dhënat më kritike ruhen më shpesh, varësisht nga treguesi RPO (Objektivi i pikës së rikuperimit), i cili përcakton humbjen e lejuar të të dhënave. Kjo mund të jetë një herë në javë, një herë në ditë ose madje disa herë në orë. Këtu ne kemi regjistrat e transaksioneve nga DBMS.
Me futjen e sistemeve në përdorim industrial, dokumentacioni për backup-in duhet të miratohet, ku pasqyrohen çështjet kryesore, rregulli i azhurnimit, procedura e rikthimit të sistemit, rendi i ruajtjes së backup-eve dhe kështu me radhë.
Miti 4. Vëllimi i kopjeve rritet vazhdimisht dhe zë përkufizimin e çdo hapësire të dedikuar plotësisht
Kopjet rezervĂ« kanĂ« njĂ« afat tĂ« kufizuar ruajtjeje. Nuk ka kuptim, pĂ«r shembull, tĂ« grumbullohen 365 kopje ditore pĂ«r njĂ« vit. NjĂ« praktikĂ« normale Ă«shtĂ« ruajtja e kopjeve ditore pĂ«r 2 javĂ«, pas sĂ« cilĂ«s ato zĂ«vendĂ«sohen me kopje tĂ« freskĂ«ta, ndĂ«rsa nĂ« ruajtje afatgjatĂ« mbetet versioni qĂ« Ă«shtĂ« krijuar i pari nĂ« muaj. Ky version gjithashtu ruhet pĂ«r njĂ« periudhĂ« tĂ« caktuar â çdo kopje ka njĂ« kohĂ« jetĂ«.
Ekziston mbrojtje nga humbja e të dhënave. Para se të fshihet një kopje rezervë, duhet të krijohet një tjetër. Prandaj, të dhënat nuk do të fshihen, nëse kopja nuk përfundoi, për shembull, për shkak të papërshtatshmërisë së serverit. Respektohen jo vetëm afatet kohore, por kontrollohet edhe numri i kopjeve në grup. Nëse sistemi parashikon që duhet të ketë dy kopje të plota rezervë, gjithmonë do të ketë dy, dhe e vjetra do të fshihet vetëm kur të regjistrohet me sukses një e re që është e treta. Kështu që rritja e hapësirës së zënë nga arkivi i kopjeve rezervë është e lidhur vetëm me rritjen e sasisë së të dhënave që mbrohen dhe nuk varet nga koha.
Miti 5. Ka filluar kopjimi â gjithçka Ă«shtĂ« ngrirĂ«.
Më mirë të thuhet kështu: nëse gjithçka është ngrirë, atëherë duar të administratorit nuk janë aty ku duhet. Në përgjithësi, shpejtësia e kopjimit varet nga shumë faktorë. Për shembull, nga shpejtësia e sistemit të vetë kopjimit: sa të shpejta janë storage disk, bibliotekat e kasetave. Nga shpejtësia e servera sistemës së kopjimit: a arrijnë ata të përpunojnë të dhënat, të kryejnë kompresim dhe deduplikim. Po ashtu nga shpejtësia e linjave të komunikimit mes klientit dhe serverit.
Kopjimi mund të ndodhi në një ose disa rrjedha, në varësi të mbështetjes për multithreading e sistemit që po rezervohen. Për shembull, DBMS Oracle lejon të dorëzojë disa rrjedha, sipas numrit të procesorëve të disponueshëm, derisa shpejtësia e transferimit të mos shpërthejë në kufizimin e kapacitetit të rrjetit.
NĂ«se pĂ«rpiqeni tĂ« bĂ«ni kopje me njĂ« numĂ«r tĂ« madh rrjedhash, ekziston mundĂ«sia pĂ«r ta tepruar sistemin operativ, dhe ai do tĂ« fillojĂ« tĂ« ngadalĂ«sohet. Prandaj, zgjidhet numri optimal i rrjedhave pĂ«r tĂ« siguruar njĂ« shpejtĂ«si tĂ« mjaftueshme. NĂ«se, ndonĂ«se ka ndonjĂ« ngadalĂ«sim tĂ« vogĂ«l nĂ« performancĂ«, ekziston njĂ« mundĂ«si e shkĂ«lqyer, kur kopjimi kryhet nga njĂ« server kloni, jo nga serveri kryesor â standby nĂ« terminologjinĂ« e databazave. Ky proces nuk ngarkon sistemin e punĂ«s. TĂ« dhĂ«nat mund tĂ« merren pĂ«rmes njĂ« numri mĂ« tĂ« madh rrjedhash, pasi serveri nuk pĂ«rdoret pĂ«r shĂ«rbim.
Në organizatat e mëdha krijohet një rrjet i veçantë për sistemin e kopjimit, në mënyrë që të mos ndikojë në prodhim. Për më tepër, trafiku mund të transferohet jo përmes rrjetit, por përmes SAN.
Ne përpiqemi të shpërndajmë ngarkesën edhe në kohë. Kopjimet kryesisht bëhen në kohë jo-punë: natën, në fundjavë. Për më tepër, ato nuk nisen të gjitha njëkohësisht. Kopjimet e makinave virtuale janë një rast i veçantë. Procesi praktikisht nuk ndikon në performancën e makinës vetë, kështu që kopjimi mund të shpërndahet në kohë ditore dhe jo të prishet për natën. Ka shumë hollësi, nëse merret parasysh gjithçka, kopjimi nuk do të ndikojë në performancën e sistemeve.
Miti 6. Kam nisur sistemin e kopjimit â ja ku e ke qĂ«ndrueshmĂ«rinĂ«.
Kurrë mos e harroni se sistemi i kopjimit është linja e fundit e mbrojtjes, dhe për këtë arsye duhet të ketë edhe pesë sisteme të tjera që sigurojnë vazhdimësinë, disponueshmërinë e lartë dhe qëndrueshmërinë e IT-infrastrukturës dhe sistemeve informacionit të kompanisë.
Nuk duhet të shpresoni se kopjimi do të rikthejë të gjitha të dhënat dhe do të ngrisë shërbimin e rënies shpejt. Humbja e të dhënave nga momenti i kopjimit deri në momentin e prishjes është e garantuar, dhe të dhënat në serverin e ri mund të ngarkohen për disa orë (apo ditë, siç ndodh). Prandaj, ka kuptim të krijoni sisteme të plota qëndrore, duke mos e kaluar gjithçka te kopjimi.
Miti 7. E kam vendosur një herë kopjimin, kontrollova se funksionon. Mbetet vetëm të shikoj log-ët.
Ky Ă«shtĂ« njĂ« nga mitet mĂ« tĂ« dĂ«mshme, pasojat e tĂ« cilit e kupton vetĂ«m gjatĂ« njĂ« incidenti. Log-Ă«t pĂ«r pĂ«rfundimin e suksesshĂ«m tĂ« kopjimit nuk janĂ« njĂ« garanci qĂ« gjithçka ka shkuar siç duhet. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« verifikohet paraprakisht kopja e ruajtur pĂ«r shkak tĂ« rikthimit. DomethĂ«nĂ«, tĂ« fillohet procesi i rikthimit nĂ« njĂ« mjedis testues dhe tĂ« shihet rezultati.
Dhe pak për punën e administratorit të sistemeve.
NĂ« modin manual, askush nuk kopjon tĂ« dhĂ«nat qĂ« nga kohĂ«t e vjetra. Sistemet moderne tĂ« rezervave mund tĂ« bĂ«jnĂ« backup pĂ«r pothuajse gjithçka, mjafton t'i konfigurosh siç duhet. NĂ«se shtohet njĂ« server i ri â duhet tĂ« shkruhen politikat: tĂ« zgjidhni pĂ«rmbajtjen qĂ« do tĂ« bĂ«het backup, tĂ« pĂ«rcaktoni parametrat e ruajtjes dhe tĂ« aplikoni njĂ« orar.
Megjithatë, punë ka ende për shkak të numrit të madh të serverëve, përfshirë bazat e të dhënave, sistemet e postës, klasterët e makinave virtuale dhe burimet e skedarëve si në Windows ashtu edhe në Linux/Unix. Punonjësit që mbajnë në funksion sistemin e rezervimit nuk qëndrojnë pa punë.
Në nder të festës, dëshiroj të gjithë administratorëve nerva të forta, lëvizje të qarta dhe hapësirë të pafund për ruajtjen e backup-eve!
Burimi: habr.com
