Strategjia e kopjeve rezervë: nga rregulli 3-2-1 te rikthimi i testuar

Vetëm një kopje nuk e rikthen një proces biznesi

Të hënën mungon një dosje projekti, por sinkronizimi e ka përhapur tashmë kudo fshirjen e fundjavës. Një kompani tjetër i ruan të dhënat, por nuk mund ta rinisë menaxhimin e inventarit pas një dështimi serveri sepse mungojnë skedari i licencës, konfigurimi i bazës së të dhënave dhe qasja e administratorit. Të dy shembujt tregojnë pse një strategji duhet të shpjegojë më shumë sesa vendin ku ruhet një kopje.

Rezultati është që një proces i caktuar funksionon përsëri, me një gjendje të pranueshme të të dhënave dhe brenda një kohe të dakordësuar. Një biznes i vogël zejtar mund të ketë nevojë për qasje tjetër nga një sistem porosish që punon pa ndërprerje. Planifikimi ekonomik nis me këtë dallim.

Zgjidhni humbjen e pranueshme para orarit të kopjeve rezervë

Objektivi i pikës së rikuperimit (RPO) kufizon humbjen e pranueshme të të dhënave në kohë. Një RPO prej katër orësh kërkon një pikë të rikuperueshme jo më të vjetër se katër orë në momentin e dështimit. Objektivi i kohës së rikuperimit (RTO) përshkruan kohën e synuar deri në rifillimin e shërbimit. Vetëm kopjet e natës nuk plotësojnë një RPO katërorësh dhe një shkarkim i shpejtë nuk e provon RTO-në.

Ekipi i biznesit duhet t'i miratojë këto objektiva. Rifutja e porosive nga emailet mund të kompensojë disa të dhëna të humbura, por sërish kushton kohë personeli. Pritja për harduerin, disponueshmëria e furnizuesit dhe validimi përfundimtar i biznesit llogariten të gjitha në ndërprerjen reale. Shembujt vijues janë ilustrime planifikimi, jo rekomandime universale.

• Dokumente projekti: RPO katër orë, RTO një ditë pune; disa pika ditore dhe rikthim i synuar dosjesh.
• Porosi aktuale: RPO një orë, RTO katër orë; mbrojtje e bazës së të dhënave dhe një mjedis rikuperimi menjëherë i disponueshëm.
• Faqe publike uebi: RPO 24 orë, RTO tetë orë; mbroni së bashku përmbajtjen, aplikacionin, konfigurimin dhe administrimin e domenit.

3-2-1 kërkon kopje vërtet të pavarura

Rregulli klasik nënkupton tri kopje duke përfshirë prodhimin, dy lloje mediumesh dhe një kopje jashtë vendndodhjes. Shqyrtoni gjithashtu shkaqet e përbashkëta të dështimit. Dy direktori në një NAS nuk janë mbrojtje e pavarur. Një llogari e dytë cloud ndihmon vetëm nëse administratori kryesor nuk mund t'ia ndryshojë edhe asaj afatin e ruajtjes dhe të dhënat.

Një kombinim praktik është të dhënat e prodhimit, një kopje lokale për rikthime të shpejta dhe një kopje e jashtme e veçantë për humbjen e vendndodhjes. Një kopje jashtë linje ose përkohësisht e pandryshueshme i kufizon më tej ndryshimet e padëshiruara. RAID mund të përballojë disa dështime disqesh, por nuk ofron versione historike të pavarura.

Pandryshueshmëria ka kufij specifikë sipas produktit. S3 Object Lock mbron versione të veçanta objektesh për një periudhë të përcaktuar, ndërsa versionet e reja mund të krijohen sërish. Testoni afatin e ruajtjes dhe përshtateni me buxhetin e hapësirës dhe procedurën e rikuperimit.

Skedarët, bazat e të dhënave dhe shërbimet cloud kërkojnë metoda të ndryshme

Dokumentet shpesh kërkojnë një version të caktuar të mëparshëm. Një bazë të dhënash ka nevojë që ndryshimet e lidhura të jenë konsistente; kopjimi i skedarëve të hapur në një çast arbitrar mund të mos e sigurojë këtë. Kopjet rezervë që njohin aplikacionin koordinojnë një pikë rikuperimi me një aplikacion të mbështetur. Kontrolloni mbështetjen për bazën përkatëse të të dhënave në vend që të supozoni se konsistenca e aplikacionit është universale.

Për shërbimet cloud, inventarizoni llogaritë, lejet, afatet e ruajtjes dhe eksportet. Koshat e riciklimit dhe historiku i versioneve mund të ndihmojnë, por nuk janë automatikisht kopje rezervë të pavarura. Përcaktoni nëse të dhënat e kërkuara mbeten të disponueshme pas humbjes së llogarisë ose skadimit të historikut. Një eksport është i dobishëm vetëm nëse destinacioni mund ta importojë.

Llogaritni koston e gjithë rrugës së rikuperimit

Përfshini licencat, rritjen, kopjet e jashtme, kapacitetin e rikuperimit, monitorimin dhe kohën e ushtrimeve. Ofruesit mund të tarifojnë marrjen e të dhënave, ruajtjen minimale ose transferimin. Afati i gjatë i ruajtjes nuk e ul koston kur çdo ditë mbërrijnë sasi të mëdha të dhënash të reja. Matni dedublikimin dhe kompresimin me të dhëna reale, në vend që të supozoni një zbritje standarde.

Kjo llogaritje e gjerësisë së brezit është ilustruese: transferimi i 1 TB përmes një lidhjeje 100 Mbit/s plotësisht të përdorshme në vazhdimësi zgjat rreth 22.2 orë, duke përdorur njësi dhjetore dhe duke shpërfillur ngarkesën shtesë të protokollit. Çpaketimi, nisja e bazës së të dhënave dhe validimi kërkojnë kohë shtesë. Një rikuperim katërorësh ka nevojë për rrugë më të shpejtë ose kopje që ndodhen tashmë pranë mjedisit të rikuperimit.

Një propozim duhet të emërtojë sistemet e mbrojtura dhe përjashtimet, kopjet, afatet e ruajtjes, objektivat, një kontakt të disponueshëm, qasjen e dokumentuar dhe rikthimin e parë të suksesshëm me matje kohe. Pranoni veçmas rikthimin e elementeve individuale dhe rinisjen e të gjithë shërbimit.

Kryeni një ushtrim me rezultat të verifikueshëm

Zgjidhni një proces të plotë, por të menaxhueshëm, si administrimi i porosive. Riktheni një pikë të zgjedhur në një mjedis testimi të izoluar dhe verifikoni hyrjen, kërkimin e porosive, marrjen e dokumenteve dhe një transaksion prove të padëmshëm. Pengoni që njoftime ose porosi reale të arrijnë te sistemet e jashtme. Regjistroni pikën e nisjes, varësitë dhe rezultatin e pritshëm përpara fillimit.

Matni më shumë sesa kopjimin: regjistroni fillimin e incidentit të simuluar, disponueshmërinë e të dhënave të hyrjes, nisjen e aplikacionit, përfundimin e kontrolleve të biznesit dhe vulën kohore të të dhënave të rikthyera. Krahasoni kohën reale të rikuperimit dhe humbjen me RTO dhe RPO. Caktoni një përgjegjës dhe afat për çdo devijim, në vend që ta përshtatni raportin që të duket i suksesshëm. Ritestoni pas ndryshimeve të rëndësishme në bazën e të dhënave, enkriptim ose hostim.

Një paralajmërim duhet të çojë në veprim

Proceset e dështuara janë vetëm një sinjal. Kanë rëndësi edhe kopjet që mungojnë, grupet jashtëzakonisht të vogla të të dhënave, rritja e vazhdueshme dhe pikat e rikuperimit më të vjetra se afati i dakordësuar. Klasifikoni çdo paralajmërim dhe dërgojeni te dikush që mund të veprojë gjatë orarit të kontraktuar të mbështetjes.

Një sistem kritik mund të paralajmërojë kur pika e fundit e konfirmuar e rikuperimit arrin një vjetërsi paralajmëruese të brendshme, duke lënë kohë për hetim dhe kontroll të kopjeve alternative përpara shkeljes së RPO-së. Testoni rrugën e raportimit dhe konfirmoni që një zëvendësues merr të njëjtin informacion.

Dorëzimi është pjesë e pranimit

Plani i rikuperimit duhet të mbetet i arritshëm pa serverin e dështuar ose njohuritë e një personi të vetëm. Emërtoni kontaktet, produktet dhe versionet, rendin e varësive dhe qasjen e sigurt te çelësat dhe kredencialet. Ruajini fjalëkalimet në një menaxher të përshtatshëm me qasje emergjente të kontrolluar, jo të ekspozuara në një manual të përgjithshëm.

Një person i dytë duhet të kryejë një rikthim të kufizuar duke përdorur vetëm dokumentacionin. Regjistroni çdo boshllëk njohurish. Shpeshtësia e ushtrimeve ndjek ritmin e ndryshimit dhe kriticitetin: një shqyrtim vjetor i dokumentuar mund të jetë pikënisje, ndërsa sistemet bazë që ndryshojnë shpesh ose objektivat e paplotësuar kërkojnë kontrolle më të afërta.