Backupy i odzyskiwanie danych

Powody bywają różne. Zadanie przestało się wykonywać cztery miesiące temu, bo wygasły poświadczenia, a mail o błędzie szedł do osoby, która już nie pracuje. Nowy serwer wstawiono rok temu i nikt nie dopisał go do harmonogramu. Bazę skopiowano jako zwykły plik w trakcie transakcji, więc plik jest, ale się nie wczytuje. Kopie leżały na udziale sieciowym, który ransomware zaszyfrował razem z resztą, bo przejęty serwer miał do niego prawo zapisu.

Każdy z tych przypadków da się wykryć wcześniej. I na tym w gruncie rzeczy polega ta usługa: na skróceniu dystansu między przekonaniem, że masz backupy, a wiedzą, że je masz.

Ile danych możesz stracić? Jeśli backup robi się w nocy, a awaria zdarza się o szesnastej, tracisz dzień pracy. W części systemów to niedogodność. W obsłudze zamówień to poważny problem, a odpowiedź musi brzmieć „minuty”, co oznacza inne i droższe rozwiązanie.

Jak długo możesz nie działać? Odtworzenie kilku terabajtów przez łącze internetowe trwa tyle, ile trwa. Jeśli firma wytrzyma dwa dni, w porządku. Jeśli nie wytrzyma, kopie muszą leżeć bliżej, a ścieżka odtwarzania musi być przygotowana wcześniej.

To decyzje biznesowe z doczepioną ceną techniczną, a nie decyzje techniczne. Pokazujemy warianty razem z kosztami i zostawiamy wybór Tobie. Backup wszystkiego w trybie ciągłym i trzymanie go bez końca są wykonalne i rzadko proporcjonalne do potrzeb.

Sensowny układ oddziela kopie od tego, co chronią. Oddzielenie lokalizacji, żeby pożar, zalanie albo kradzież serwera nie zabrały obu naraz. Oddzielenie dostępów, żeby konto przejęte na produkcji nie sięgało zasobu z backupami. I oddzielenie w czasie, żeby wczorajsza kopia nadal istniała, gdy dzisiejsza zdążyła już wciągnąć zaszyfrowane pliki.

Ten ostatni punkt umyka najczęściej. Jeśli jedyną kopią jest lustrzane odbicie stanu bieżącego, ransomware przenosi się do niej natychmiast. Dopiero przechowywanie kilku starszych wersji daje punkt, do którego można wrócić.

Kopie oczywiście szyfrujemy, co jest proste, a następnie upewniamy się, że w trakcie incydentu ktoś potrafi znaleźć klucz. To właśnie w tym miejscu robi się krępująco.

Dlatego odtwarzamy. Cyklicznie, do odizolowanego środowiska, a potem sprawdzamy wynik, a nie kod wyjścia: czy baza się otwiera, czy dane są kompletne, czy aplikacja startuje na tych danych. Pierwszy test na zastanej konfiguracji znajduje coś mniej więcej w połowie przypadków. Brakująca tabela, bo ktoś wykluczył katalog przy braku miejsca na dysku. Aplikacja, która odtwarza się poprawnie, ale nie rusza, bo jej konfiguracja nigdy nie była objęta backupem.

Test daje też zmierzony czas odtwarzania zamiast szacunku. Ta liczba powinna trafić do planu odzyskiwania, bo w trakcie prawdziwej awarii pytanie, które pada w pierwszych dziesięciu minutach, brzmi „ile to potrwa”, a zgadywanie nie jest dobrą odpowiedzią.

Dlatego procedura odtwarzania zostaje spisana: co odtwarzamy najpierw i w jakiej kolejności, kto to robi, kto ma dostępy, kto informuje klientów i co zespół robi w czasie oczekiwania. Trzymana tam, gdzie da się do niej dotrzeć, gdy Twoje własne systemy nie działają. Brzmi oczywiście, a nie jest, biorąc pod uwagę, ile planów awaryjnych leży na serwerze plików, który miały chronić.

Potem przechodzimy ją co najmniej raz. Niekoniecznie jako pełną symulację, ale na tyle, żeby pierwsze czytanie tego dokumentu nie odbywało się w trakcie awarii.