W skrócie
Ten artykuł opisuje organizacyjną stronę backupu — jak doprowadzić do tego, żeby IT i Biznes ustaliły wspólne wymagania i zapisały je w jednym miejscu.
Jeśli szukasz szczegółowego omówienia projektowania backupu, znajdziesz je w tekście „Jak zaprojektować niezawodny backup? RPO, RTO i retencja kopii bezpieczeństwa”
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.
Wprowadzenie do backupu danych
Backup danych to proces tworzenia kopii zapasowych danych w celu ich zabezpieczenia przed utratą lub uszkodzeniem. Jest to niezwykle ważne dla firm, które przechowują duże ilości danych, takich jak dokumenty, pliki, e-maile i inne informacje. Dzięki regularnemu przechowywaniu kopii zapasowych, przedsiębiorstwa mogą chronić się przed różnymi zagrożeniami, które mogą wpłynąć na ich działalność.
Dlaczego warto wykonywać kopię zapasową danych?
Wykonanie kopii zapasowej danych jest niezwykle ważne, ponieważ pozwala ono na odtworzenie danych w przypadku ich utraty lub uszkodzenia. Może to nastąpić w wyniku awarii systemu, ataku hakerskiego, kradzieży lub zagubienia sprzętu. Bez kopii zapasowej danych, firma może stracić cenne informacje, co może mieć poważne konsekwencje dla jej działalności. W przypadku incydentu, posiadanie aktualnej kopii zapasowej może być kluczowe dla szybkiego przywrócenia normalnego funkcjonowania firmy.
Rodzaje kopii zapasowych
Istnieją różne rodzaje kopii zapasowych, które można dostosować do specyficznych potrzeb firmy:
- Kopia zapasowa lokalna: Przechowywana na dyskach służbowych komputerów lub serwerach w siedzibie firmy. Jest łatwo dostępna, ale narażona na te same zagrożenia co oryginalne dane.
- Kopia zapasowa offsite: Przechowywana na serwerach zewnętrznych, poza siedzibą firmy. Zapewnia dodatkową warstwę ochrony w przypadku fizycznych zagrożeń w siedzibie firmy.
- Kopia zapasowa w chmurze: Przechowywana na serwerach chmurowych, dostępnych przez Internet. Umożliwia łatwy dostęp do danych z dowolnego miejsca, ale wymaga stabilnego połączenia internetowego.
- Kopia zapasowa fizyczna: Przechowywana na nośnikach danych, takich jak dyski twarde lub taśmy. Jest to tradycyjna metoda, która może być użyteczna jako dodatkowa warstwa zabezpieczeń.
W praktyce te rodzaje się uzupełniają. Dobrze zaprojektowany backup łączy co najmniej dwa z nich — i właśnie o tym mówi reguła 3-2-1, do której wracamy w dalszej części artykułu.
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.
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.
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 zinwentaryzuje 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.
Na tym etapie warto od razu przypisać każdemu systemowi poziom krytyczności — krytyczny, ważny albo pomocniczy. To ta klasyfikacja decyduje później o tym, ile realnie kosztuje ochrona danego zasobu. Rozpisujemy ją szczegółowo w artykule o projektowaniu backupu (link po publikacji).
RTO, RPO i retencja — co trzeba ustalić z Biznesem
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.
Z tych ustaleń wynikają trzy parametry, które trzeba zapisać osobno dla każdego systemu:
- RTO (Recovery Time Objective) — maksymalny akceptowalny czas przywrócenia systemu do działania, liczony od momentu awarii.
- RPO (Recovery Point Objective) — maksymalna akceptowalna ilość danych (wyrażona w czasie), którą organizacja może bezpowrotnie stracić.
- Retencja — jak długo przechowujemy poszczególne kopie i z jaką granulacją.
Kluczowe jest to, że żadnej z tych wartości nie ustala samodzielnie dział IT. To decyzje biznesowe — IT jedynie przekłada je na harmonogram, technologię i budżet. Konkretne progi, ich koszty oraz przykładową macierz wymagań dla firmy kilkudziesięcioosobowej omawiamy w artykule
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). W przypadku archiwizacji, która, 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.
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).
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.
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). Coraz częściej mówi się o jej rozszerzeniu do reguły 3-2-1-1-0: jedna kopia niezmienialna (immutable) lub offline oraz zero błędów w testach odtworzeniowych. To bezpośrednia odpowiedź na ransomware, który celuje dziś także w same repozytoria backupu.
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ągnąć wspólny cel.
Skuteczny backup w firmie nie zaczyna się od wyboru narzędzia, tylko od rozmowy. Najpierw inwentarz systemów i danych, potem ustalenie z Biznesem, ile organizacja może stracić i jak długo może być offline, a dopiero na końcu technologia i budżet. Odwrócenie tej kolejności to najczęstsza przyczyna sytuacji, w której backup formalnie istnieje, ale w dniu awarii okazuje się bezużyteczny.
W ESVS pomagamy organizacjom MŚP przejść przez ten proces — od inwentaryzacji zasobów, przez politykę ciągłości działania i konfigurację polityk backupu, po regularne testy odtworzeniowe i odtwarzanie systemów po awarii.
