Įmonė kasdien gauna pranešimą, kad atsarginė duomenų kopija sukurta sėkmingai. Vadovas ramus: jeigu serveris sugestų, informaciją būtų galima susigrąžinti. Tačiau įvykus gedimui paaiškėja, kad paskutinėje kopijoje nėra naujausių užsakymų, dalis duomenų bazės neatsidaro, o programai paleisti trūksta konfigūracijos failų. Kopijos buvo kuriamos, bet veikiančios sistemos iš jų atkurti nepavyksta.
Tai hipotetinis, tačiau techniškai įmanomas scenarijus, atskleidžiantis esminį skirtumą tarp duomenų kopijavimo ir verslo veiklos atkūrimo. Atsarginės kopijos nauda paaiškėja ne tada, kai sistema praneša apie sėkmingai baigtą užduotį, o tada, kai iš kopijos pavyksta atkurti reikalingus duomenis ir vėl pradėti darbą.
Elektroninėms parduotuvėms, apskaitos, klientų valdymo ar gamybos sistemas naudojančioms įmonėms tai tiesiogiai susiję su veiklos tęstinumu. Todėl atsarginių kopijų strategiją verta vertinti ne pagal turimų failų skaičių, o pagal tai, ką įmonė iš tiesų galėtų padaryti praradusi pagrindinį serverį.
Sėkmingas kopijavimas dar nereiškia sėkmingo atkūrimo
Automatinė kopijavimo sistema gali patvirtinti, kad užduotis atlikta, tačiau tai savaime neįrodo, jog išsaugota visa reikalinga informacija. Kartais kopijuojami svetainės failai, bet ne duomenų bazė; kartais duomenų bazė išsaugoma netinkamu momentu, kai vyksta operacijos. Atkuriant programą gali pritrūkti licencijų, šifravimo raktų, nustatymų ar kitų komponentų, kurie į kopijavimo planą nebuvo įtraukti.
Sudėtingesnėse sistemose svarbus ir duomenų tarpusavio suderinamumas. Elektroninės parduotuvės užsakymas gali būti susijęs su sandėlio likučiais, apskaitos įrašais bei pristatymo sistema. Jei kiekviena sistema atkuriama iš skirtingo momento, informacija gali nebesutapti. Vadinasi, kopijuoti reikia ne atsitiktinai pasirinktus katalogus, o iš anksto nustatytą visumą, leidžiančią atkurti svarbiausias verslo funkcijas.
Duomenų bazėms ne visada pakanka paprastai nukopijuoti failus, kol programa aktyviai apdoroja užsakymus ar mokėjimus. Tokiu atveju būtina pasirinkti su naudojama sistema suderinamą kopijavimo būdą, kuris užtikrintų duomenų nuoseklumą. Kitu atveju iš pirmo žvilgsnio tvarkinga kopija gali būti netinkama paleisti. Dar prieš užsakant paslaugą verta išvardyti ne tik serverius, bet ir visas svarbias duomenų bazes, integracijas, sertifikatus bei konfigūracijos failus, be kurių programa neveiktų.
Kaip dažnai reikia saugoti duomenis?
Jeigu elektroninė parduotuvė atsarginę kopiją sukuria tik naktį, o serveris sugenda vakare, per dieną atsiradę užsakymai ir kiti pakeitimai gali nepatekti į paskutinę kopiją. Reprezentacinei svetainei, kurios turinys keičiamas retai, toks kopijavimo dažnumas galėtų būti pakankamas. Aktyviai prekybos ar apskaitos sistemai jis gali būti nepriimtinas.
Šį poreikį apibrėžia RPO (angl. Recovery Point Objective) – didžiausias duomenų praradimo laikotarpis, kurį įmonė gali toleruoti. Jeigu verslas negali prarasti daugiau nei valandos operacijų, kopijavimo tvarka turi būti pritaikyta šiam tikslui. Kai kuriais atvejais prireiks ne tik dažnesnių kopijų, bet ir duomenų bazių operacijų žurnalų ar kitų specializuotų sprendimų.
Taip pat svarbu numatyti, kiek laiko galima laukti sistemos sugrąžinimo. RTO (angl. Recovery Time Objective) nusako tikslinę atkūrimo trukmę. Šie du rodikliai nėra automatinės tiekėjo garantijos: juos turi nustatyti verslas, o pasirinkta infrastruktūra ir atkūrimo procedūros – pagrįsti, kad tikslai įgyvendinami.
Kopijos tame pačiame serveryje gali dingti kartu su duomenimis
Atsargines kopijas laikant tik tame pačiame serveryje kaip ir pagrindinius duomenis, vienas rimtas gedimas gali sunaikinti abu jų egzempliorius. Dar pavojingiau, jei pagrindinės sistemos ir kopijų saugyklos administravimui naudojami tie patys prisijungimai: juos perėmęs užpuolikas gali bandyti ištrinti ir atkūrimui skirtus failus.
Todėl dažnai taikomas 3-2-1 principas: turėti tris duomenų egzempliorius, juos saugoti naudojant dvi skirtingas laikmenas ar saugojimo priemones ir bent vieną kopiją laikyti atskiroje vietoje. Atsižvelgiant į riziką, papildomai gali reikėti izoliuotų ar nuo pakeitimo apsaugotų kopijų. Svarbu ne vien geografinis atskyrimas, bet ir tai, ar incidentas pagrindinėje sistemoje negalėtų paveikti atsarginių duomenų.
Kopijų atskyrimas turi būti apgalvotas ir prieigos valdymo požiūriu. Jei pagrindinio serverio administratorius be papildomų ribojimų gali ištrinti visas atsargines kopijas, organizacija išlieka pažeidžiama net tada, kai duomenys fiziškai laikomi kitoje vietoje. Verta aptarti atskirus prisijungimus, kopijų išlaikymo terminus ir galimybę apsaugoti bent dalį jų nuo pakeitimo. Svarbu ir tai, kas gauna perspėjimus apie nesėkmingą kopijavimą: pranešimas, kurio niekas neskaito, problemos neišsprendžia.
„Bacloud“ sprendimai: kopijavimas, infrastruktūra ir administravimas
Serverių infrastruktūros paslaugas teikianti „Bacloud“ siūlo rezervinių duomenų kopijų sprendimus, kuriuose galima planuoti kopijavimo laiką ir dažnumą bei pasirinkti atkūrimo tašką. Tokios galimybės leidžia pritaikyti duomenų saugojimą prie skirtingų sistemų: retai atnaujinamos svetainės ir kasdien daugybę užsakymų apdorojančios parduotuvės poreikiai nėra vienodi.
Bendrovė taip pat teikia serverių administravimo paslaugą, apimančią atsarginių kopijų konfigūravimo, priežiūros ir atkūrimo darbus pagal pasirinktos paslaugos sąlygas. Įmonei tai suteikia galimybę serverio priežiūrą ir duomenų apsaugos užduotis derinti su vienu infrastruktūros partneriu, užuot palikus jas be aiškiai paskirto atsakingo specialisto.
Tačiau paslaugos pavadinimas neturėtų pakeisti konkretaus susitarimo. Prieš ją užsakant reikia išsiaiškinti, kurie duomenys kopijuojami, kiek laiko saugomos kopijos, kur jos laikomos, kaip kontroliuojama prieiga ir kokia atkūrimo pagalba įtraukta į pasirinktą planą. Jeigu verslui būtinas konkretus atkūrimo laikas ar papildoma kopijų izoliacija, šiuos reikalavimus būtina aptarti atskirai, o ne laikyti savaime įtrauktomis funkcijomis.
Atkūrimo bandymas parodo daugiau nei bet kuri ataskaita
Patikimiausias būdas sužinoti, ar kopijos naudingos, – atlikti atkūrimo bandymą. Jį galima suplanuoti atskiroje aplinkoje, nepertraukiant pagrindinės sistemos darbo. Patikrinama, ar duomenys atsiveria, ar programa paleidžiama, ar veikia jos ryšiai su kitomis sistemomis ir kiek laiko iš tiesų trunka visas procesas.
Pavyzdžiui, elektroninei parduotuvei neužtenka vien atkurti prekių nuotraukas ir duomenų bazės lenteles. Reikia įsitikinti, kad galima prisijungti, peržiūrėti užsakymus, atlikti bandomąjį pirkimą ir tinkamai perduoti duomenis kitoms sistemoms. Atkūrimo bandymas taip pat gali atskleisti, kad trūksta slaptažodžių, instrukcijų ar žmogaus, kuris incidento metu turėtų teisę priimti sprendimus.
Tokie bandymai neturi vykti tik po gedimo. Juos verta kartoti pasikeitus programinei įrangai, infrastruktūrai ar kritiniams verslo procesams. Kiekvienas sėkmingas bandymas suteikia gerokai daugiau pagrindo pasitikėti apsauga nei automatinis pranešimas apie sukurtą kopiją.
Atkūrimo bandymą naudinga dokumentuoti: užrašyti, kuri kopija naudota, kiek truko procesas, kokios kliūtys iškilo ir kokias verslo funkcijas pavyko patikrinti. Kitą kartą tokie įrašai padeda išvengti improvizacijos. Be to, jie atskleidžia, ar organizacija pernelyg priklauso nuo vieno darbuotojo žinių. Jei atkūrimo instrukcija egzistuoja tik specialisto atmintyje, jo atostogos ar liga gali tapti papildoma kliūtimi net ir turint techniškai tinkamas kopijas.
Atsarginė kopija nepakeičia atsparios infrastruktūros
Duomenų kopijavimas ir nepertraukiamas sistemos veikimas sprendžia skirtingas problemas. Atsarginė kopija padeda atkurti informaciją po jos praradimo ar sugadinimo. Tačiau ji pati neperjungia lankytojų į kitą serverį, jeigu pagrindinis staiga nustoja veikti. Įmonėms, kurioms net trumpa prastova nepriimtina, gali prireikti rezervinių serverių, replikavimo ar kitų aukšto pasiekiamumo sprendimų.
Ir atvirkščiai: rezervinė infrastruktūra nepakeičia kopijų. Klaidingai ištrinti duomenys ar sugadinti įrašai gali būti perduoti ir į antrąją sistemą. Todėl patikima architektūra derina veiklos tęstinumą su galimybe grįžti prie ankstesnės, tinkamos duomenų būsenos.
Penki klausimai, kuriuos verta užduoti šiandien
Įmonės vadovui nebūtina pačiam administruoti serverio. Tačiau jis turėtų žinoti, kokie duomenys saugomi, kaip dažnai kuriamos kopijos, kur jos laikomos, kas atsakingas už atkūrimą ir kada paskutinį kartą buvo atliktas tikras atkūrimo bandymas. Jei į šiuos klausimus nėra aiškių atsakymų, pirmasis žingsnis turėtų būti esamos sistemos peržiūra.
„Bacloud“ siūlomos infrastruktūros, rezervinių kopijų ir administravimo paslaugos gali padėti sukurti nuoseklesnę duomenų apsaugos sistemą. Tačiau jos vertė priklausys nuo teisingai įvardytų verslo poreikių, aiškiai paskirstytų atsakomybių ir išbandyto atkūrimo plano. Tikrasis atsarginių kopijų kokybės kriterijus paprastas: ne ar vakar pavyko nukopijuoti duomenis, o ar rytoj prireikus pavyks atkurti darbą.
SEO pavadinimas: Atsarginės duomenų kopijos: kodėl svarbu išbandyti atkūrimą
META aprašymas: Atsarginės kopijos negarantuoja sėkmingo duomenų atkūrimo. Sužinokite, ką tikrinti, kaip planuoti kopijavimą ir kokius sprendimus siūlo „Bacloud“.
Siūlomas URL adresas: atsargines-duomenu-kopijos-atkurimas-bacloud
