Strategia backupu

Pierwszym krokiem w procesie tworzenia strategii backup jest określenie wymagań: co powinno być kopiowane, jak często i jak szybko należy przywrócić dane, gdy zajdzie taka potrzeba. Istotne jest pogrupowanie danych z punktu widzenia ich ważności dla funkcjonowania organizacji. Należy też zastanowić się, które dane wymagają backupu, a które archiwizacji (archiwizacja, w odróżnieniu od backupu, polega na zrobieniu kopii danych, a następnie skasowaniu oryginału).

Powszechnie używa się terminów RPO (Recovery Point Objective) i RTO (Recovery Time Objective). Pierwszy mówi, jak często należy kopiować dane czy, mówiąc inaczej, na jaką utratę danych organizacja może sobie pozwolić, gdy nastąpi awaria. Obok ilości danych objętych ochroną jest to główny czynniki decydujący o wielkości przestrzeni dyskowej wymaganej na backupy. Z kolei RTO mówi, ile czasu firma jest gotowa poświęcić na przywrócenie danych z kopii zapasowych.

Zobacz również:

• Ransomware zagraża ochronie zdrowia
• IBM Security QRadar SIEM pomoże zarządzić globalną strukturą odpowiedzialną za bezpieczeństwo
• Cyfrowa transformacja z AI - co nowego na Google Cloud Next 24

Po rozpoznaniu wymagań można przejść do wyboru systemu backupu dostosowanego do specyfiki danego środowiska. Oprócz rozważenia, czy będzie to rozwiązanie tylko programowe czy łączące również komponenty sprzętowe, należy też wziąć pod uwagę takie aspekty, jak łatwość obsługi, skalowalność, kompatybilność czy możliwość centralnego zarządzania. Bardzo ważne jest nie tylko opracowanie reguł backupu dostosowanych do różnych typów danych, ale również udokumentowanie tych reguł.

Specjaliści IT mają skłonność do przekonania, że zrobienie kopii zapasowej zamyka sprawę. Nie wynika to z lenistwa, ale działania według zasady, że jeśli coś nie jest zepsute, nie trzeba tego naprawiać. Jednak dobra strategia powinna uwzględniać następujące dobre praktyki:

• testowanie kopii zapasowych,
• testowanie procedur przywracania,
• nie budowanie strategii wokół jednej osoby.

Testowanie backupów

Wśród administratorów IT krąży anegdota o informatyku, który przekonał zarząd do wdrożenia systemu backupowego. System działał poprawnie i zgodnie ze starannie opracowanym harmonogramem tworzenia kopii zapasowych. Taśmy z backupem, jak należy, przechowywano w sejfie w innej lokalizacji. Gdy doszło do awarii, bohater tej opowieści ze spokojem sięgnął po kopie zapasowe, aby pokazać zarządowi, że warto było zainwestować w backup. Niestety z żadnej taśmy nie udało się odzyskać danych. Jak się ostatecznie okazało, winę ponosił zamek magnetyczny w sejfie, który skutecznie wyczyścił wszystkie informacje zapisane na taśmach. Oczywiście jest to tylko dykteryjka, ale chodzi o morał, który z niej płynie. Gdyby kopie zapasowe były od czasu do czasu testowane, problem zostałby wykryty wcześniej, a nie dopiero w momencie awarii.

Trzeba jednak pamiętać, że w rzeczywistości zdarzają się sytuacje mające podobne konsekwencje, np. kopie nie zostaną zapisane we wszystkich wymaganych folderach czy fragment taśmy ulegnie uszkodzeniu. Bez przeprowadzania testów ewentualny problem zostanie wykryty dopiero wtedy, gdy będzie za późno na działania naprawcze.

Symulacje przywracania

Testów nie powinno się ograniczać wyłącznie do sprawdzania poprawności zapisu danych w kopia. Warto przejść przez całą procedurę przywracania. Jeśli coś złego stanie się z danymi lub systemem, administratorzy IT będą pod wielką presją, aby szybko przywrócić wszystko do pierwotnego stanu. Wtedy lepiej nie znaleźć się w położeniu, w którym nie wiadomo, jaka jest procedura odzyskiwania. Co więcej, sama procedura może okazać się skomplikowana i czasochłonna, np. wymagać instalacji serwera SQL czy innych komponentów. A takie czynności można przecież wykonać wcześniej. Przygotowania na awaryjną sytuację należy rozpocząć od udokumentowania procedury odzyskiwania, a następnie sprawdzenia, czy opracowana metoda faktycznie działa. Przeprowadzanie regularnych testów da pewność działania, gdy dojdzie do awarii, a jednocześnie pozwala na weryfikowanie, czy same kopie zapasowe są w dobrym stanie.

Strategia wieloosobowa

Zgodnie z dobrymi praktykami jednej osobie należy przydzielić zadanie napisania procedur przywracania, a drugą obciążyć obowiązkiem ich przetestowania. Idealnym kandydatem do przeprowadzenia testów jest osoba, która ma odpowiednie umiejętności IT, ale nie jest bezpośrednio zaangażowana w obsługę systemu backupu. Jeśli testów nie jest w stanie przeprowadzić inna osoba, poza autorem dokumentacji, to sygnał, że opis procedur nie został wykonany należycie. Typowy przypadek to pominięcie w opisie czynności, które dla autora są oczywiste. Jeśli dokument przeczyta druga osoba i zechce wykonać opisane czynności, okaże się, że dojdzie do punktu, w którym nie będzie wiedziała, co zrobić. Co gorsze, z czasem autor może zmienić swoje nawyki i nie będzie w stanie zrealizować procedury, którą sam opisał. Poza tym, z pewnością żaden administrator nie lubi być ściąganym z urlopu, bo jest jedyną osobą, która wie, jak przywrócić backup. Z punktu widzenia biznesu również nie jest to komfortowa sytuacja, jeśli działanie firmy zależy od stałej dostępności jednej osoby.