Kopia zapasowa, która naprawdę działa

Dzień, w którym kopia jest naprawdę potrzebna

Wyobraź sobie poniedziałek, w którym to wszystko przestaje być teorią. Komuś z zespołu ukradli laptopa z jedynym kompletem umów. Dysk w komputerze padł po pięciu latach pracy bez ostrzeżenia. Albo gorzej: rano nikt w firmie nie może otworzyć plików, bo w nocy zaszyfrował je ransomware, a na ekranie wisi żądanie okupu.

Pierwsza myśl przynosi ulgę: „Spokojnie, przecież mamy kopię zapasową”.

A potem przychodzi druga chwila, ta, w której kopia okazuje się bezużyteczna. Archiwum nie chce się otworzyć. Ostatnia kopia ma osiem miesięcy, bo coś się kiedyś rozłączyło i nikt tego nie zauważył. Hasło do zaszyfrowanej kopii znała tylko jedna osoba, która odeszła z firmy rok temu. Albo klasyka gatunku: kopia leżała na tym samym dysku, który właśnie padł.

W żadnym z tych przypadków nie chodzi o pecha: to najzwyklejszy scenariusz awarii i da się go uniknąć.

Kopie zawodzą po cichu

Kopia zapasowa ma jedną podstępną cechę: psuje się bezgłośnie. Strona internetowa, która nie działa, krzyczy o tym od razu. Kopia, która nie działa, wygląda dokładnie tak samo jak ta, która działa, aż do dnia, w którym jest potrzebna.

Najczęstsze ciche awarie wyglądają tak:

Uszkodzone archiwum. Plik istnieje, ma sensowny rozmiar, a przy próbie odtworzenia okazuje się, że jest nie do otwarcia.
Niekompletne pliki. Kopia robi się co noc, ale od pół roku pomija katalog, w którym siedzi to, co najważniejsze, bo ktoś go kiedyś przeniósł.
Hasło, którego nikt nie pamięta. Zaszyfrowana kopia bez hasła jest warta dokładnie tyle, co brak kopii.
Kopia na tym samym dysku. Jeśli kopia leży na maszynie, którą ma chronić, to pożar, kradzież albo awaria dysku zabiera oryginał i kopię za jednym zamachem.

AWS w swojej dobrej praktyce REL09-BP04, „Perform periodic recovery of the data to verify backup integrity and processes” (okresowe odtwarzanie danych w celu sprawdzenia integralności kopii i procesów) wymienia listę antywzorców, która czyta się jak opis poniedziałku z pierwszego akapitu:

„Odtworzenie kopii bez sprawdzenia lub pobrania jakichkolwiek danych, by zweryfikować, że odtworzenie da się użyć.”
„Zakładanie, że kopia zapasowa istnieje.”
„Zakładanie, że kopia zapasowa systemu jest w pełni sprawna i dane da się z niej odzyskać.”
„Zakładanie, że czas potrzebny na przywrócenie lub odzyskanie danych z kopii mieści się w RTO dla danego obciążenia.”
„Zakładanie, że dane zawarte w kopii mieszczą się w RPO dla danego obciążenia.”
„Odtwarzanie w razie potrzeby bez korzystania z gotowej procedury (runbooka) albo poza ustaloną, zautomatyzowaną procedurą.”

W tej liście powtarzają się dwa pojęcia: RTO (recovery time objective, czyli dopuszczalny czas trwania odtworzenia) i RPO (recovery point objective, czyli dopuszczalna utrata danych, mierzona w czasie). Datto opisuje automatyczną weryfikację kopii jako funkcję wbudowaną w swoje produkty, a NinjaOne publikuje poradnik testowania kopii i dowodzenia, że odtworzenie działa. Rozumowanie jest wszędzie takie samo: kopia jest środkiem, celem jest odzyskanie danych, a tego nie da się sprawdzić inaczej niż próbując.

Test na kwadrans

Nie musisz być informatykiem i nie potrzebujesz żadnej usługi, żeby sprawdzić podstawy. Wystarczy kwadrans i te cztery kroki:

Odtwórz jeden plik. Wybierz dowolny dokument z kopii i otwórz go na innym urządzeniu niż to, z którego pochodzi. Jeśli się otwiera i wygląda jak trzeba, pierwszy test zaliczony.
Sprawdź datę ostatniej kopii. Z kiedy jest najnowsza? Z wczoraj, czy z lutego? Jeśli nie wiesz, gdzie to sprawdzić, to już jest odpowiedź.
Sprawdź, gdzie kopia fizycznie leży. Inny dysk, inna maszyna, najlepiej inne miejsce niż oryginał. Kopia na tym samym komputerze chroni przed skasowaniem pliku, ale nie przed awarią, kradzieżą ani ransomware.
Zapisz, gdzie jest hasło do kopii. Jeśli kopia jest zaszyfrowana, dobrze. Upewnij się tylko, że hasło jest zapisane w bezpiecznym miejscu i że w razie czego znajdzie je ktoś więcej niż jedna osoba.

Jeśli wszystkie cztery punkty przechodzą, podstawy masz w porządku. Wystarczy powtarzać to co jakiś czas, na przykład pierwszego dnia każdego miesiąca.

Jeśli któryś nie przechodzi, dowiedziałeś się tego w spokojny dzień, a nie w ten poniedziałek z pierwszego akapitu. To lepszy z dwóch wariantów.

Prawdziwa próba odtworzenia

Test na kwadrans sprawdza, czy kopia w ogóle się otwiera. Nie mówi, czy pełne odtworzenie zmieści się w założonym czasie ani czy odzyskane dane są na tyle aktualne, by się przydać. Do tego służy dłuższa procedura z REL09-BP04 — poniższa wersja to jej skrócona forma, bez narzędzi specyficznych dla AWS (CloudTrail, Resilience Hub, AWS Backup), których nie ma w samodzielnie hostowanym środowisku:

Najpierw ustal RTO i RPO. RTO to czas, przez jaki możesz tolerować przestój, zanim odtworzenie się zakończy. RPO to ilość najnowszych danych, jaką możesz stracić, mierzona w czasie (np. „najwyżej 24 godziny nowych faktur”). Bez tych liczb „odtworzyło się” i „odtworzyło się na czas” znaczą to samo, a nie powinny.
Odtwarzaj w nowe miejsce, nie z powrotem na oryginał. Zalecenie AWS wprost mówi o „okresowym odtwarzaniu kopii w nowej lokalizacji i uruchamianiu testów sprawdzających integralność danych” — odtwarzanie na żywym systemie grozi zamaskowaniem wadliwej kopii danymi, które nigdy nie zniknęły.
Sprawdź same dane, nie tylko ich obecność. Kryteria walidacji z AWS to gotowa lista kontrolna: „typ danych, format, suma kontrolna, rozmiar lub kombinacja tych elementów z własną logiką walidacji”. Zweryfikuj, że odtworzone pliki są kompletne i nieuszkodzone, a najnowszy rekord w nich mieści się w Twoim RPO. Odtworzony folder, który się otwiera, ale brakuje w nim faktur z zeszłego tygodnia, oblał próbę, mimo że nic nie zgłosiło błędu.
Zmierz cały czas. Zanotuj, kiedy zaczęło się odtwarzanie i kiedy skończyła się weryfikacja. Porównaj to z Twoim RTO. Kopia, której odtworzenie zajmuje sześć godzin, to liczba, którą warto znać przed dniem, w którym będzie potrzebna, a nie w jego trakcie.
Zapisz wyniki i powtarzaj próbę według harmonogramu. Test zrobiony raz, dwa lata temu, mówi tylko o tym, jak Twoje kopie działały dwa lata temu.

Kopie w Trybie samodzielnym wykonują się według harmonogramu na przestrzeń, którą kontrolujesz, od pierwszego dnia, bez opłat, ale nikt jeszcze nie pilnuje tych zadań ani nie robi tej próby za Ciebie — to dziś należy do Ciebie, a zweryfikowana, zautomatyzowana próba odtworzenia z raportem jest w planach, jeszcze niedostępna.

To jest różnica między „kopia się wykonała” a „kopia działa”. Pierwsze to obietnica; drugie trzeba pokazać odtworzeniem.

principale.dev instaluje takie narzędzia open source na serwerze, który należy do Ciebie. Każda instalacja jest darmowa. Zobacz, jak to działa.