Backup is not one of those trendy technologies that everyone is shouting about. It simply needs to be present in any serious company, and that's it. In our bank, we back up several thousand servers – this is a complex and interesting task, and I would like to talk about some of its nuances, as well as about typical misconceptions regarding backups.
I've been dealing with this topic for almost 20 years, with the last 2 years at Promsvyazbank. At the very beginning of my practice, I did backups almost manually, using scripts that simply copied files. Then convenient tools appeared in Windows: the Robocopy utility for preparing files and NT Backup for copying. Eventually, it was time for specialized software, primarily Veritas Backup Exec, which is now called Symantec Backup Exec. So I’ve been familiar with backups for a long time.
Simply put, backup is the process of saving a copy of data (makinat virtuale, applications, databases, and files) regularly just in case. A 'just in case' typically manifests as a hardware or logical failure, resulting in data loss. The aim of the backup system is to minimize the losses from information loss. A hardware failure could be, for example, the server or storage failure where the database resides. A logical failure is the loss or alteration of part of the data, including due to human error: accidentally deleting a table, file, or running a flawed script. There are also regulatory requirements to store specific types of information for extended periods, sometimes for several years.
The most common use of backups is to restore saved copies of databases for deploying various testing environments or clones for developers.
There are several typical myths surrounding backups that need to be dispelled. Here are the most well-known ones.
Myth 1. Backup has long been just a minor function within security or storage systems.
Sistemet e kopjimit të të dhënave vazhdojnë të jenë një klasë e veçantë zgjidhjesh, dhe mjaft të pavarura. Çështja që u është besuar është tepër e rëndësishme. Në thelb, ato përfaqësojnë linjën e fundit mbrojtëse kur flitet për sigurinë e të dhënave. Pra, kopjimi funksionon në ritmin e tij, sipas orarit të tij të veçantë. Raporti ditor përbëhet për serverët, ka ngjarje që veprojnë si nxitës për sistemin e monitorimit.
Plus, modeli i rolit të aksesit në sistemin e kopjimit të të dhënave lejon delegimin e disa përgjegjësive administratorëve të sistemeve të caktuara për menaxhimin e kopjeve rezervë.
Miti 2. Kur ekziston RAID, backup-i nuk është më i nevojshëm.
Pa dyshim, RAID array-t dhe replikimi i të dhënave janë një mënyrë e mirë për të mbrojtur sistemet informative nga defektet hardware, dhe nëse ka një server të gatshëm, mund të organizohet shpejt kalimi tek ai në rast se makineria kryesore dështon.
Nga gabimet logjike që bëhen nga përdoruesit e sistemit, teprica dhe replikimi nuk mbrojnë. Ja, serveri i gatshëm me shkrim të vonuar – po, mund të ndihmojë, nëse gabimi zbulohet para se të jetë sinkronizuar. Por nëse momenti është humbur? Atëherë vetëm një backup i bërë në kohë ndihmon. Nëse dihet se të dhënat janë ndryshuar dje, mund të rikthehet sistemi në gjendjen e pardjeshme dhe të nxirren të dhënat e nevojshme. Duke marrë parasysh se gabimet logjike janë më të shpeshta, backup-i i vjetër dhe i besueshëm mbetet një mjet i nevojshëm.
Miti 3. Backup-i është diçka që bëhet një herë në muaj.
Frekuenca e kopjimit të të dhënave është një parameter që mund të konfigurohet, kryesisht i varur nga kërkesat për sistemin e kopjimit. Në të vërtetë, është e mundur të gjejmë të dhëna që praktikisht nuk ndryshojnë kurrë dhe nuk janë veçanërisht të rëndësishme, humbja e tyre nuk do të jetë kritike për kompaninë.
Ata me të vërtetë mund të kopjohen një herë në muaj dhe madje edhe më rrallë. Ndërsa të dhënat më kritike ruhen më shpesh, në varësi të treguesit RPO (Recovery Point Objective), që përcakton humbjen e pranueshme të të dhënave. Kjo mund të jetë një herë në javë, një herë në ditë ose madje disa herë në orë. Kjo është për ne regjistrat e transaksioneve nga DBMS.
Kur miratohen sistemet në prodhim, është e domosdoshme të miratohet dokumentacioni për kopjimin e rezervës, që përfshin pikat kryesore, rregullin e përditësimit, procedurën për rikuperimin e sistemit, rregullin e ruajtjes së kopjeve rezervë dhe gjëra të ngjashme.
Miti 4. Vëllimi i kopjeve rritet njëherë e përgjithmonë dhe zë çdo hapësirë të dedikuar plotësisht.
Kopjet rezervë kanë një afat të kufizuar ruajtjeje. Nuk ka kuptim, për shembull, të ruash të gjitha 365 kopjet ditore për një vit. Në përgjithësi është e pranueshme të ruash kopje ditore për 2 javë, pas së cilës zëvendësohen me të reja, ndërsa për ruajtjen afatgjatë mbetet ajo versioni që është bërë e para në muaj. Ky version gjithashtu ruhet për një periudhë të caktuar – çdo kopje ka një jetëgjatësi.
Ekziston mbrojtje nga humbja e të dhënave. Përmbledhja e rregullit është: para se të fshihen kopjet rezervë, duhet të krijohet kopja e ardhshme. Prandaj, të dhënat nuk do të fshihen nëse kopjimi nuk është realizuar, për shembull, për shkak të mungesës së qasjes në server. Respektohen jo vetëm afatet kohore, por gjithashtu kontrollohet numri i kopjeve në grup. Nëse sistemi parashikon që të ketë dy kopje të plota, gjithmonë do të ketë dy, dhe e vjetra do të fshihet vetëm kur regjistrohet me sukses një e re e treta. Pra, rritja e vëllimit të arkivave të 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ë themi kështu: nëse gjithçka është ngrirë, kjo do të thotë se administratorët nuk dinë çfarë bëjnë. Në të vërtetë, shpejtësia e kopjimit varet nga shumë faktorë. Për shembull, nga shpejtësia e sistemit të kopjimit të rezervës: sa të shpejtë janë atje sistemet e ruajtjes në disqe, bibliotekat e kasetave. Nga shpejtësia e sistemit të kopjimit të rezervës: a arrijnë ata të përpunojnë të dhënat, të kryejnë kompresimin dhe deduplikimin. Gjithashtu, nga shpejtësia e linjave të komunikimit midis klientit dhe serverit. serverësh Kopjimi mund të shkojë në një ose disa rrjedha, në varësi të suportit që ofron sistemi i rezervuar për shumëprocese. Për shembull, SGBD Oracle lejon dërgimin e disa rrjedhave, në përputhje me numrin e procesorëve të disponueshëm, derisa shpejtësia e transmetimit të mos përballet me kufizimin e kapacitetit të rrjetit.
Kopjimi rezervë mund të shkojë në një ose disa rrjedha, në varësi të mbështetjes që ofron sistemi rezervuar për shumëprocese. Për shembull, SGBD Oracle lejon dërgimin e disa rrjedhave, në përputhje me numrin e procesorëve të disponueshëm, derisa shpejtësia e transmetimit të mos përballet me kufizimin e kapacitetit të rrjetit.
Nëse përpiqeni të bëni backup me shumë kanale, ka mundësi që të ngarkoni sistemin që punon, dhe ai me të vërtetë do të fillojë të ngadalësohet. Prandaj, zgjidhet numri optimal i kanaleve për të siguruar performancë të mjaftueshme. Nëse edhe një rënie e vogël e performancës është kritike, ekziston një opsion i shkëlqyer kur backup bëhet jo nga serveri kryesor, por nga kloni i tij – standby në terminologjinë e bazave të të dhënave. Ky proces nuk ngarkon sistemin kryesor të punës. Të dhënat mund të përfshihen përmes një numri më të madh kanalesh, pasi serveri nuk përdoret për shërbim.
Në organizatat e mëdha, për sistemin e rezervës krijohet një rrjet i veçantë, për të siguruar që backup të mos ndikojë në prodhim. Për më tepër, trafiku mund të kalojë jo përmes rrjetit, por përmes SAN.
Ne mundohemi të shpërndajmë ngarkesën edhe sipas kohës. Backup-i kryesisht bëhet në orë jopunesimi: gjatë natës, në fundjavë. Për më tepër, ato nuk fillojnë të gjitha menjëherë. Backup-et e makinave virtuale janë një rast i veçantë. Procesi praktikisht nuk ka ndikim në performancën e vetë makines, kështu që backup-i mund të shtrihet në kohën e ditës, në vend që të presë të gjitha për natën. Ka shumë detaje, dhe nëse gjithçka merret parasysh, rezervimi nuk do të ndikojë në performancën e sistemeve.
Miti 6. E aktivizova sistemin e backup-it – ja, ja ule është qëndrueshmëri.
Kurrë mos harroni se sistemi i backup-it është lënda e fundit mbrojtëse, dhe do të thotë që përpara tij duhet të ketë edhe pesë sisteme që sigurojnë vazhdimësinë, disponueshmërinë e lartë dhe qëndrueshmërinë e katastrofave të infrastrukturës IT dhe sistemeve të informacionit të ndërmarrjes.
Të shpresosh se backup-i do të rikthejë të gjitha të dhënat dhe shpejt do të ngrijë shërbimin e rënies nuk ka kuptim. Humbja e të dhënave nga momenti i backup-it deri në momentin e defektit është e garantuar, dhe të dhënat në serverin e ri mund të ngarkohet për disa orë (ose ditë, siç mund të ndodhë). Prandaj, ka kuptim të krijohet sisteme të plota të qëndrueshmërisë, pa e lënë gjithçka te backup-i.
Miti 7. E konfigurova një herë backup-in, kontrollova që funksionon. Tani mbetet vetëm të shikoj regjistrat.
Ky është një nga mitet më të dëmshme, e cila kuptohet vetëm gjatë një incidenti. Logët e realizimit të suksesshëm të backup-it nuk janë një garanci që gjithçka ka shkuar siç duhet. Është e rëndësishme të kontrolloni paraprakisht kopjen e ruajtur për shkallëzueshmëri. Kjo do të thotë të filloni procesin e rikuperimit në një mjedis testimi dhe të shihni rezultatin.
Dhe pak për punën e administratorit të sistemit
Në modin manual askush nuk kopjon më të dhëna prej kohësh. Sistemet moderne të rezervimi dinë t'i bëjnë backup pothuajse të gjitha, mjafton të jenë të konfiguruara si duhet. Nëse është shtuar një server i ri – të përcaktohen politikat: të zgjidhet përmbajtja që do të merret në backup, të specifikohen parametrat e ruajtjes dhe të vendoset një kalendar.
Megjithatë, punë ka akoma për shkak të morisë së serverëve, mes të cilave bazohet mbi të dhëna, sisteme postare, klastere makinash virtuale dhe burime skedare si në Windows ashtu edhe në Linux/Unix. Punonjësit që mbështesin operativitetin e sistemit të rezervimit nuk qëndrojnë të papunë.
Në nder të festës dëshiroj të uroj të gjithë administratorët nerva të forta, qartësi në lëvizje dhe hapësirë të pafund për ruajtjen e backup-eve!
Burimi: habr.com
