Nie pytaj, czy masz backup. Zapytaj, czy potrafisz go odtworzyć

Wtorek wieczorem. Próbuję uruchomić prywatny komputer. Nie startuje.

Kilka nieudanych prób reanimacji, podstawowe działania diagnostyczne. Wszystko wskazuje na awarię dysku.

Pierwsza myśl: przecież mam backup.

I rzeczywiście miałem. Tyle że kiedy zacząłem sprawdzać, okazało się, że ostatnia poprawna kopia części danych ma około dwóch lat.

To był dla mnie zimny prysznic. Po tym, jak skonfigurowałem backup, żyłem w przekonaniu, że sprawa jest załatwiona. Od dawna nie sprawdzałem jednak, czy wszystko nadal działa.

Na szczęście najważniejsze dane miałem zabezpieczone niezależnie. Zdjęcia przechowuję w trzech miejscach, podobnie najważniejsze dokumenty. Tu byłem spokojny. Część danych miała jednak trafiać do backupu, który jak się okazało od dawna nie działał poprawnie. I tych danych już nie odzyskałem.

Najbardziej uderzyło mnie nie to, że choć miałem backup, poczucie bezpieczeństwa jakie mi dawał, było zupełnie nieuzasadnione.

Gdybym dostał prosty alert, że zapasowa kopia danych przestała spełniać swoją funkcję, problem prawdopodobnie wyszedłby dużo wcześniej niż przy awarii dysku. Pewnie na tym skończyłaby się ta historia. Tyle że następnego dnia wydarzyło się coś bardzo podobnego.

Dzień później padł telefon

Środa. Syn bierze udział w turnieju piłkarskim. W pewnym momencie okazuje się, że zapomniał korków. Biegnę do samochodu, telefon wypada mi z ręki i uderza o ziemię.

Ekran rozbił się tak, że urządzenia praktycznie nie dało się używać.

I wtedy bardzo szybko zobaczyłem, jak wiele codziennych spraw koncentruje się wokół jednego urządzenia: bankowość, płatności, nawigacja, parking, aplikacje służbowe, uwierzytelnianie dwuskładnikowe, kontakty. Niby człowiek o tym wie, ale dopiero kiedy telefon nagle przestaje działać, naprawdę czuje skalę tej zależności.

Przez kilka godzin byłem odcięty od możliwości wykonania wielu zadań, które normalnie realizuję bez zastanowienia.

Wieczorem kupiłem nowy telefon. Zalogowałem się, uruchomiłem odtwarzanie z chmury i po krótkim czasie większość rzeczy wróciła na swoje miejsce. Mogłem normalnie działać i nie straciłem danych.

Dwa dni. Dwie awarie. Dwa zupełnie różne doświadczenia z powrotem do działania.

W pierwszym przypadku byłem przekonany, że mam działający backup. Dopiero awaria pokazała, że ostatnia dobra kopia części danych ma około dwóch lat, a ja od dawna tego nie kontrolowałem.

W drugim kopia była aktualna, odtworzenie się powiodło i po stosunkowo krótkim czasie wróciłem do normalnego działania.

I właśnie ta różnica wydaje mi się ważniejsza niż samo pytanie: czy mam backup.

Dla firmy liczy się powrót do działania

W systemie przemysłowym konsekwencje podobnej awarii mogą być znacznie poważniejsze. Uszkodzenie systemu sterowania, wizualizacji czy serwera danych może oznaczać przestój, utratę informacji procesowych albo długi powrót środowiska do działania.

Dlatego rozmowa o backupie nie powinna zaczynać się od dysku, serwera czy harmonogramu. Najpierw warto ustalić, co dla procesu jest akceptowalne:

Jaką ilość utraconych danych możemy zaakceptować?
Jak długo możemy czekać na powrót systemu do działania?

W technicznym języku są to RPO (Recovery Point Objective, czyli akceptowalny zakres utraty danych) i RTO (Recovery Time Objective, czyli akceptowalny czas odtworzenia systemu). RPO określa akceptowalną utratę danych, najczęściej wyrażoną czasem. RTO mówi, jak szybko po awarii system powinien wrócić do działania.

Nie ma jednej dobrej wartości dla wszystkich systemów. Dla jednego procesu utrata danych z kilku godzin może być do przyjęcia, dla innego kilkanaście minut będzie już problemem. Te liczby powinny wynikać z potrzeb procesu i uzgodnień organizacji, a nie wyłącznie z możliwości narzędzia do backupu.

W przypadku mojego komputera musiałem pogodzić się z tym, że nie będę już mieć dostępu do danych zapisywanych w ciągu ostatnich dwóch lat.  Zdecydowanie nie mógłbym świadomie zgodzić się na zaakceptowanie takiej straty.

„Backup się robi” to jeszcze za mało

Samo skonfigurowanie kopii zapasowej nie daje jeszcze pewności, że po awarii wszystko uda się odtworzyć.

Możemy mieć harmonogram robienia backupu, drugi dysk, serwer wyznaczony do przechowywania kopii albo zrobić backup całej maszyny wirtualnej i nadal nie wiedzieć, czy po awarii rzeczywiście uda się przywrócić potrzebne środowisko.

Warto też rozróżnić kilka pojęć. Synchronizacja danych nie jest tym samym co backup, bo może przenieść do drugiej lokalizacji również usunięcie albo zaszyfrowanie danych. Migawka maszyny wirtualnej jest przydatnym punktem powrotu np. przed zmianą, ale nie zastępuje długoterminowej kopii. Redundancja zwiększa dostępność, ale może powielić również błąd konfiguracji czy niepożądaną zmianę.

Dlatego sama informacja „mamy drugą kopię” mówi jeszcze niewiele.

Trzy kwestie, od których zacząłbym dziś

Z perspektywy osoby odpowiedzialnej za ciągłość działania zacząłbym od trzech prostych kwesti:

Monitorowanie. Jeśli backup przestaje się wykonywać, ktoś powinien się o tym dowiedzieć. Sam harmonogram nie oznacza, że kopia faktycznie powstaje. W moim przypadku właśnie tego zabrakło.

Ochrona kopii. Jeśli jedyna kopia znajduje się w tym samym środowisku co system produkcyjny, ten sam incydent może dotknąć obu. Dlatego warto mieć przynajmniej jedną kopię odpowiednio odseparowaną, offline albo zabezpieczoną przed modyfikacją.

Test odtworzenia. Dopiero wtedy, gdy próbujemy rzeczywiście wydobyć informacje z kopii, dowiadujemy się, czy backup naprawdę spełnia swoją rolę. Sam komunikat „zadanie zakończone pomyślnie” nie daje jeszcze tej pewności.

Pełny cykl warto traktować jako proces: inwentaryzacja > RPO/RTO > backup > weryfikacja > ochrona kopii > kolejne wersje > test odtworzenia > dokumentacja.

Odzyskaliśmy pliki. Czyli wszystko działa?

Niekoniecznie.

W systemie przemysłowym warto sprawdzić nie tylko, czy udało się odzyskać pliki. Trzeba zweryfikować, czy po odtworzeniu rzeczywiście działa komunikacja, historia danych, licencje, integracje i pozostałe elementy potrzebne do normalnej pracy systemu.

To szczególnie ważne po większych zmianach: aktualizacji, migracji serwera, zmianie wersji oprogramowania czy przebudowie architektury.

Dlatego zamiast pytać wyłącznie, czy mamy backub, lepiej zapytać, czy potrafimy odtworzyć system.

To nie jest tylko pytanie do działu IT

Osoba odpowiedzialna za produkcję czy ciągłość procesu nie musi znać technicznych szczegółów każdej kopii. Powinna jednak wiedzieć, jaki poziom utraty danych i jaki czas odtworzenia organizacja akceptuje, kto odpowiada za wykonanie i kontrolę kopii oraz czy procedura odtworzenia była kiedykolwiek sprawdzona.

To są ustalenia, które warto zrobić wspólnie między właścicielem procesu, automatyką i IT. Dzięki temu RPO i RTO nie pozostają tylko parametrami technicznymi, ale stają się częścią decyzji o ryzyku i ciągłości działania.

Sześć pytań, które warto sobie zadać

Po tych dwóch awariach sam zrobiłem szybki przegląd swoich danych. W środowisku przemysłowym zacząłbym od podobnego testu:

1. Czy wiem, kiedy powstała ostatnia poprawna kopia?
2. Czy dostanę informację, jeśli backup przestanie się wykonywać?
3. Czy wiem, ile danych możemy zaakceptować jako utracone?
4. Czy wiem, ile czasu może zająć odtworzenie systemu?
5. Czy przynajmniej jedna kopia jest odseparowana od środowiska produkcyjnego?
6. Czy kiedykolwiek naprawdę przeprowadziliśmy test odtworzenia?

Jeżeli przy którymś pytaniu odpowiedź brzmi „nie wiem”, nie oznacza to automatycznie, że system jest źle zabezpieczony.

To raczej sygnał, że warto sprawdzić temat, zanim zrobi to za nas awaria.

Po tych dwóch dniach mam do backupu trochę mniej zaufania „na słowo”. Wolę sprawdzić, kiedy powstała ostatnia dobra kopia i czy naprawdę da się z niej wrócić. W systemie przemysłowym stawką może być nie kilka prywatnych plików, ale ciągłość pracy całego procesu.