„Mamy backup” kontra „umiemy odtworzyć”

Pytanie „czy macie kopie zapasowe” prawie zawsze dostaje odpowiedź twierdzącą. Pytanie „kiedy ostatnio ktoś coś z nich odtworzył” prawie zawsze dostaje ciszę.

To nie jest złośliwość. Kopie się konfiguruje raz, po czym działają w tle latami i nie dają żadnego powodu, żeby do nich wracać. Problem w tym, że jedyny moment, w którym się o nich przypomina, jest jednocześnie jedynym momentem, w którym nie ma czasu na odkrywanie, że nie działają.

Cztery pytania, które rozdzielają jedno od drugiego

1. Ile trwa odtworzenie?

Nie „czy się da” — ile godzin. To jest liczba, którą trzeba znać przed awarią, bo od niej zależy wszystko inne: czy firma może pracować w tym czasie, czy trzeba odsyłać ludzi do domu, co powiedzieć klientom.

Odtworzenie serwera plików z kopii przez internet potrafi zająć dobę i więcej. Jeżeli kopia leży w chmurze, a łącze ma 100 Mb/s, to dwa terabajty danych ściągają się przez wiele godzin niezależnie od tego, jak dobre jest oprogramowanie.

Nikt tego nie liczy, dopóki nie musi.

2. Ile danych stracimy?

Kopia raz na dobę o drugiej w nocy oznacza, że awaria o siedemnastej kosztuje piętnaście godzin pracy całej firmy. Czasem to do przyjęcia. Czasem nie i nikt tego nie ustalił.

To pytanie warto zadać osobom z działów, nie technikom: ile pracy jesteście w stanie odtworzyć z głowy i z papierów. Odpowiedź bywa bardzo różna dla księgowości i dla działu handlowego.

3. Czy kopia przeżyje to samo zdarzenie co dane?

Kopia na tym samym serwerze nie chroni przed awarią serwera. Kopia na stale podłączonym dysku sieciowym nie chroni przed oprogramowaniem szyfrującym, bo ono też ten dysk widzi. Kopia w tej samej serwerowni nie chroni przed pożarem i zalaniem.

Sprawdzenie w jednym zdaniu: czy istnieje kopia, do której nie da się dostać z zaatakowanej maszyny. Jeżeli nie — masz zabezpieczenie przed skasowaniem pliku przez pomyłkę, a nie przed tym, o czym myślisz.

4. Czy ktokolwiek to sprawdził?

Nie chodzi o test odtworzenia całego środowiska — to projekt sam w sobie i w małej firmie zwykle nie ma na niego miejsca. Chodzi o coś znacznie skromniejszego, co da się zrobić w kwadrans:

odtworzyć jeden plik z zeszłego tygodnia i sprawdzić, że się otwiera,
odtworzyć jedną skrzynkę pocztową do folderu tymczasowego,
odtworzyć jedną bazę na maszynie testowej.

To nie dowodzi, że wszystko zadziała. Dowodzi, że kopia zawiera dane, a nie puste pliki o właściwych nazwach — a to jest najczęstsza cicha awaria.

Cicha awaria kopii zapasowych

Najgorszy scenariusz nie polega na tym, że kopii nie ma. Polega na tym, że kopia jest, wykonuje się co noc i od ośmiu miesięcy zapisuje pusty katalog, bo ktoś zmienił ścieżkę udziału sieciowego.

Objawy, których nikt nie zauważa:

rozmiar kopii przestał rosnąć albo nagle spadł,
zadanie kończy się „z ostrzeżeniami” od miesięcy,
powiadomienia o błędach idą na skrzynkę osoby, która odeszła,
kopia obejmuje serwer sprzed migracji, a nie ten, który działa dziś.

Stąd najprostsza rzecz, jaką warto włączyć: alert na to, że kopia się nie wykonała albo że jej rozmiar odbiega od poprzednich. Alert na sukces nikomu nie jest potrzebny — po tygodniu przestaje się go czytać.

Czego nie obiecuję i czego nie warto obiecywać

Nie prowadzę cyklicznych testów odtworzeniowych całego środowiska i nie znam małej firmy, w której miałoby to ekonomiczny sens. To praktyka z organizacji z osobnym zespołem i osobnym budżetem.

Realny zakres, który ma sens i mieści się w rozsądnych kosztach:

kopia zaprojektowana według wartości danych, a nie najtańszej opcji w panelu,
co najmniej jedna kopia poza maszyną i poza siecią, w której stoją dane,
znany czas odtworzenia — policzony raz, zapisany,
alert na brak wykonania,
odtworzenie próbki przy okazji każdej większej zmiany w środowisku.

To wystarcza, żeby awaria była kosztem jednego dnia, a nie końcem firmy.

Jedno zdanie na koniec

Kopia zapasowa nie jest produktem, tylko procedurą, której wynik ktoś kiedyś sprawdził. Bez tego ostatniego elementu to jest wydatek, a nie zabezpieczenie — i dowiadujesz się o tym w najgorszym możliwym momencie.