W dzisiejszym „cyfrowym” świecie nie da się przecenić znaczenia kopii zapasowej danych (lub jak ktoś woli – backupu). Zabezpieczenie danych przed ich utratą jest kluczowe dla ciągłości działania przedsiębiorstwa.
Tworzenie polityk backupu i zarządzanie nimi wymaga stałej współpracy pomiędzy Biznesem (innymi jednostkami w organizacji) a działem IT. Zdarza się, że Biznes oraz IT nie wymieniają się najważniejszymi informacjami na temat procesów biznesowych, brakuje podstawowej komunikacji i współpracy nad wspólnym celem. Dopiero realny incydent i konieczność przywrócenia danych lub systemów do działania staje się przyczyną bardziej „systemowego” podejścia do zarządzania ciągłością organizacji.
W niniejszym artykule odpowiemy na pytanie, dlaczego wyżej wspomniana współpraca jest niezbędna oraz jakie kroki można podjąć, aby rozpocząć proces budowania strategii i rozwiązań backupu.
1. Podejście do projektowania systemów kopii bezpieczeństwa
Na wstępie warto przywołać przykład z życia wzięty. Rzecz miała miejsce podczas audytu ISO w firmie produkcyjnej.
Jakie wnioski płyną z powyższego dialogu?
- Dział IT nie jest w stanie wdrożyć skutecznego rozwiązania bez znajomości podstawowych procesów i wiedzy na temat innych obszarów działalności firmy. Nie będzie w stanie odpowiedzieć na niewypowiedziane potrzeby Biznesu w przypadku awarii.
- Potrzebny jest wspólny, merytoryczny dialog pomiędzy Biznesem a IT oraz zniesienie barier komunikacyjnych.
- Jeśli w danym momencie, system backupu (z różnych przyczyn) nie spełnia określonych, zmieniających się wymagań Biznesu, dział IT powinien o tym informować wszystkich zainteresowanych.
2. Inwentaryzacja i Hierarchizacja systemów zbiorów danych.
Należy określić zasady komunikacji i zasady parametryzacji wymagań oraz metodę zapisu uzgodnionych celów. Idealnym rozwiązaniem tymczasowym będzie najprostsza tabelka, do której dział IT wspólnie z Biznesem zinwentaryzują wszystkie systemy oraz zbiory danych które są wykorzystywane produkcyjnie i mają zostać zabezpieczone podczas backupu. Udostępniamy poniżej, gotowy do pobrania i sparametryzowany inwentarz systemów, który ułatwi komunikację i spis ustaleń Biznesu oraz IT. Dodatkowo wyposażyliśmy go w praktyczny kalkulator zapotrzebowania na pojemność systemu backupu.
Pobierz inwentarz usług z kalkulatorem pojemności systemu kopii zapasowych!
W następnym etapie dla każdego systemu należy dopisać stopień „ważności” i wolumen (ilość) danych źródłowych, a także określić zdolność organizacji do funkcjonowania w sytuacji niedostępności danego systemu. Ważne będzie określenie czasu (godziny/dni), w jakim niedostępność nie wywoła negatywnych konsekwencji i nie zakłuci funkcjonowania procesów biznesowych. Te informacje zdeterminują maksymalny czas wymagany do przywrócenia określonego systemu do działania, od momentu wystąpienia awarii lub utraty danych. Nazywamy to parametrem RTO (Recovery Time Objective).
Kolejnym istotnym krokiem jest określenie akceptowalnej ilości nieodwracalnie utraconych danych po odtworzeniu ostatniej kopii bezpieczeństwa. Te dane będzie trzeba wyprodukować (lub wprowadzić) na nowo, dlatego ten próg musi być określony dla każdego z systemów w porozumieniu z Biznesem. Znajomość tego progu jest niezbędna do zaprojektowania harmonogramu wykonywania kopii bezpieczeństwa. Nazywamy to parametrem RPO (Recovery Point Objective).
W ostatnim kroku należy określić jak długo powinniśmy trzymać kopie poszczególnych systemów oraz jaka powinna być ich granulacja (charakterystyka i typy kopii zapasowych w czasie). Dla niektórych systemów okres tygodnia może być wystarczający, dla innych konieczne będzie utrzymanie kopii przez znacznie dłuższy czas. W przypadku archiwizacji, która, jak wiadomo, różni się tym od backupu, że zabezpiecza dane, których nie utrzymujemy już w systemach produkcyjnych, okres ten może wynosić długie lata. Nazywamy ten parametr RETENCJĄ.
Wymagania bywają oczywiście znacznie bardziej złożone, np. niektóre systemy mogą stać się krytycznymi w pewnych konkretnych okresach czy dniach każdego miesiąca, a w pozostałe dni „poziom” ich krytyczności maleje (naliczenie poborów, podatków, premii dla przedstawicieli handlowych, itd.). Tę zmienność wyrazi zróżnicowanie parametrów RTO i należy uwzględnić ją w projekcie polityk backupu.
Ten przykład dobrze ilustruje ogólne podejście do tworzenia wstępnych założeń dla systemu kopii zapasowych.
Warto zauważyć, że te założenia pozwalają wyskalować system backupu, a co za tym idzie pozwala wycenić i zabudżetować rozwiązania. Jeśli pojawia się problem z budżetowaniem rozwiązania odpowiadającego na potrzeby Biznesu, należy wrócić do inwentarza systemów oraz wymagań dotyczących ich zabezpieczenia i zrewidować oczekiwania. IT i Biznes muszą tutaj wspólnie wypracować kompromis – bez tego żadna z jednostek organizacyjnych nie może być pewna tego, na czym stoi (lub stanie w obliczu awarii).
3. Jak rozpocząć dialog w „trudnym środowisku”.
Jeśli polityka zachowania ciągłości dopiero powstaje i system kopii bezpieczeństwa będzie projektowany w przyszłości, to wystarczy już na początku zastosować opisane podejście.
Jeśli jednak już coś mamy, ale perspektywa awarii i duża ilość znaków zapytania oraz zmiennych nie daje pewności co do efektu odtwarzania systemów, najlepszym rozwiązaniem może być przygotowanie tabelki samodzielnie przez Dział IT i przedstawienie jej Biznesowi.
W tym momencie, realnie skonfrontujemy założenia biznesowe z faktycznymi możliwościami systemu kopii bezpieczeństwa i infrastruktury IT.
4. Proponowane zalecenia na przyszłość
- Regularne wykonywanie testów odtworzeniowych – rutynowe testowanie scenariuszy usuwania skutków awarii pozwala zdemaskować możliwe problemy i błędne założenia. Dodatkowo wyrabia nawykowe działanie, co w sytuacji faktycznego problemu będzie nieocenione i z pewnością skróci czas obsługi incydentu.
- Regularnie rozmowy z Biznesem – przeglądy i weryfikacja aktualności wymagań ustalonych parametrów RTO i RPO.
- Stosowanie reguły 3-2-1 – wszystkie kopie powinny być przechowywane w trzech egzemplarzach, na dwóch różnych nośnikach, a jedna kopia powinna znajdować się w innej lokalizacji lub offline (niedostępna z sieci produkcyjnej).
Co robić, jeśli jednak system bądź infrastruktura nie spełniają postawionych wymagań?
- IT powinno ustalić przyczyny (nie zawsze są stricte techniczne!).
- IT może samodzielnie przygotować inwentarz systemów i możliwe parametry RPO i RTO (z uwzględnieniem możliwości systemu kopii bezpieczeństwa, poziomów obsługi serwisowej infrastruktury, itp.).
- Biznes musi wiedzieć, czyli IT powinno zaraportować powyższe ustalenia.
- IT powinno sformułować propozycję planu naprawczego.
- Jeśli nie da się zagwarantować wymaganego RTO, warto zastanowić się nad redundancją (nadmiarowością) danego systemu lub rozważyć rozwiązanie w chmurze.
- W przypadku wysokich kosztów systemu backupu, Biznes może być zmuszony do zmiany pierwotnych założeń i wymagań. Takie zmiany wymuszają uwzględnienie ryzyka strat finansowych, związanego z dłuższą niedostępnością systemów IT lub utratą większej ilości danych po ich odtworzeniu. Biznes jednak nie weźmie tego pod uwagę, jeśli nie dostanie konkretnych informacji od IT.
- Najważniejszy jest dialog i chęć współpracy pomiędzy wszystkimi zainteresowanymi, a aspekty techniczne często będą kwestią wtórną.
Podsumowując, należy zaznaczyć, że perspektywa może być zróżnicowana w zależności od konkretnej firmy. Niemniej jednak, ważne jest dążenie do wprowadzenia skutecznych praktyk i budowania efektywnego dialogu, aby osiągniąć wspólny cel.
