Test kopii zapasowej: skonfigurowana kopia to nie kopia działająca

Kopia zapasowa ustawiona w panelu nie znaczy jeszcze, że w razie awarii odzyskasz dane. Jedyny dowód, że kopia działa, to test kopii zapasowej: odtworzenie danych w osobnym miejscu i sprawdzenie, że system z nich wstaje. Jeśli w firmie ktoś mówi „kopie się robią”, ale nikt nie pamięta, kiedy ostatnio coś z nich odzyskano, ten tekst jest dla Ciebie. Pokazuję, jak sprawdzić, czy kopia istnieje, jak przeprowadzić test odtworzenia i jak zapisać, kto za to odpowiada.

Dlaczego skonfigurowana kopia to za mało

Zadanie kopii w panelu to tylko obietnica, że kopia powstanie. Między tą obietnicą a odzyskanymi danymi jest wiele miejsc, w których coś może pójść nie tak.

Przy przeglądach infrastruktury trafiam na te same sytuacje: zadanie kopii od dawna kończy się błędem i nikt nie dostaje powiadomienia, kopia obejmuje pliki strony, ale nie bazę danych, kopie leżą na tym samym serwerze co dane albo zostały zaszyfrowane hasłem, którego nikt już nie zna. Pisałem o tym przy okazji tekstu o tym, jak prowadzę audyt odziedziczonej infrastruktury IT. W każdym z tych przypadków panel pokazuje, że kopie są włączone.

Jak sprawdzić, czy kopia w ogóle istnieje

Zacznij od pytań, na które odpowiedź da się sprawdzić w kilka minut, bez technicznej wiedzy. Poproś osobę lub firmę, która odpowiada za serwery, o pokazanie tych rzeczy, a nie o zapewnienie.

• Data ostatniej udanej kopii każdego ważnego systemu: strony, sklepu, bazy, poczty, dysku z dokumentami.
• Zakres: czy kopia obejmuje pliki i bazę danych, a przy poczcie wszystkie skrzynki.
• Miejsce: gdzie fizycznie leży kopia i czy jest poza serwerem, z którego pochodzi.
• Okres przechowywania: ile wersji wstecz da się odzyskać. To ważne, gdy błąd albo zaszyfrowanie danych zauważysz po czasie.
• Dostęp: kto może kopię odtworzyć, a kto ją skasować. Kopia, którą może usunąć to samo konto co dane, nie chroni przed włamaniem.

Zasada 3-2-1 prostym językiem

Zasada 3-2-1 mówi: trzymaj trzy kopie danych, na dwóch różnych nośnikach, z czego jedną poza siedzibą firmy. Tak opisuje ją amerykańska agencja CISA w poradniku o wyborze sposobu tworzenia kopii zapasowych.

W małej firmie przekłada się to na prosty układ: dane produkcyjne na serwerze, kopia u dostawcy hostingu albo w drugim centrum danych i jeszcze jedna kopia w osobnej usłudze, do której nie loguje się to samo konto co do serwera. Celem jest to, żeby jedna awaria, jeden błąd człowieka albo jedno włamanie nie zabrały wszystkich kopii naraz.

Test kopii zapasowej krok po kroku

Test odtworzenia polega na tym, żeby z kopii postawić system w osobnym miejscu i sprawdzić, że działa, bez dotykania wersji produkcyjnej. Tak wygląda procedura, którą proponuję klientom:

1. Wybierz system do testu, zaczynając od najważniejszego dla firmy, na przykład sklepu albo systemu z zamówieniami.
2. Przygotuj miejsce testowe: osobny serwer albo środowisko, które nie wysyła maili do klientów i nie łączy się z produkcyjnymi integracjami.
3. Odtwórz dane z kopii, tak jak robiłbyś to po awarii, korzystając tylko z dokumentacji, a nie z pamięci jednej osoby.
4. Sprawdź działanie: logowanie, ostatnie zamówienia lub dokumenty, wyszukiwanie, kilka typowych operacji.
5. Zmierz czas od decyzji o odtworzeniu do działającego systemu. To realny czas przestoju, jaki firma poniesie po awarii.
6. Zapisz wynik: datę, system, czas, problemy i poprawki do procedury.

Pierwszy test prawie zawsze ujawnia coś, czego brakuje: hasło do szyfrowania kopii, plik konfiguracyjny, którego nie było w zakresie, albo krok znany tylko jednej osobie. Właśnie po to się go robi.

Nieudany test kopii zapasowej to nie porażka, tylko lista zadań. Każdy brak poprawiasz, dopisujesz do procedury i powtarzasz test, aż odtworzenie przejdzie od początku do końca bez improwizacji. Dopiero wtedy wiesz, ile naprawdę trwa powrót po awarii i czy ten czas jest do przyjęcia dla firmy.

Alerty o nieudanej kopii

Kopia, która przestała się robić, jest groźniejsza od jej braku, bo daje fałszywe poczucie bezpieczeństwa. Dlatego każde zadanie kopii powinno wysyłać powiadomienie o błędzie do konkretnej osoby, a nie na wspólną skrzynkę, której nikt nie czyta.

Dobrze działa też alert odwrotny: powiadomienie, gdy przez określony czas nie powstała żadna nowa kopia. Łapie sytuację, w której zadanie w ogóle się nie uruchomiło i nie miało czego zgłosić. To ten sam monitoring, który powinien obejmować dostępność serwera, miejsce na dysku i certyfikaty.

Kto w firmie odpowiada za kopie i jak to zapisać

Odpowiedzialność za kopie trzeba zapisać z imienia funkcji, a nie zakładać, że „IT to ogarnia”. Gdy serwerami zajmuje się firma zewnętrzna, zakres kopii, częstotliwość testów i czas odtworzenia powinny być w umowie. Szerzej o takich zapisach pisałem w tekście o umowie SLA na utrzymanie systemu.

Wystarczy krótki dokument, który odpowiada na kilka pytań:

• które systemy mają kopie, gdzie one leżą i jak długo są trzymane,
• kto dostaje alerty o błędach kopii i kto na nie reaguje,
• jak często robimy test odtworzenia i kto go wykonuje,
• gdzie jest procedura odtworzenia i hasła potrzebne do kopii,
• kto po stronie firmy podejmuje decyzję o odtworzeniu po awarii.

Ten dokument przydaje się też przy zmianie dostawcy. Przy przeprowadzce hostingu małej firmy kopie są jedną z pierwszych rzeczy, które trzeba przenieść i sprawdzić na nowo.

Jeśli nie pamiętasz, kiedy ostatnio ktoś odtworzył dane z kopii, zaplanuj test kopii zapasowej najważniejszego systemu w najbliższych tygodniach i zapisz wynik. Gdy chcesz, żeby ktoś przeprowadził go razem z Tobą i spisał procedurę, napisz do mnie w sprawie kopii.