Kopia zapasowa, której nigdy nie przywrócono, jest założeniem. Jedynym dowodem jej istnienia jest udane odtworzenie.
Zakres
- baza danych,
- pliki wgrywane przez użytkowników,
- konfiguracja aplikacji i serwera,
- certyfikaty i klucze,
- harmonogramy zadań.
Sama baza nie wystarcza — odtworzenie usługi wymaga też reszty.
Przy bazie ważny jest sposób jej zabezpieczenia. Kopiowanie plików bazy w trakcie pracy serwera potrafi dać zbiór wewnętrznie niespójny, który wygląda poprawnie aż do próby odtworzenia. Kopia robiona narzędziem samej bazy takiego problemu nie ma.
Zasada trzech kopii
Trzy egzemplarze, dwa różne nośniki, jeden poza lokalizacją. To reguła stara, prosta i nadal skuteczna.
Sens jest taki, że każda z kopii ginie z innego powodu. Kopia lokalna nie przetrwa awarii serwera, kopia na tym samym dysku nie przetrwa awarii nośnika, a kopia w tej samej serwerowni nie przetrwa zalania czy kradzieży. Trzy egzemplarze w trzech katalogach jednego dysku to nadal jedna kopia.
Kopia poza serwerem
Kopia leżąca na tym samym dysku co dane chroni przed skasowaniem pliku, ale nie przed awarią i nie przed włamaniem. Musi wyjść na zewnątrz.
Warto sprawdzić jeszcze jedno: czy z serwera da się skasować kopie zdalne. Jeśli tak, to konto, które ktoś przejmie razem z serwerem, usunie także zabezpieczenie. Konto wysyłające kopie powinno mieć prawo zapisu, ale nie prawo usuwania. Kopie trzymane lokalnie zajmują przy okazji miejsce — to jedna z częstszych przyczyn zapełnienia dysku, opisana w tekście o monitorowaniu miejsca na dysku.
Okres przechowywania
Codzienne przez miesiąc, tygodniowe przez rok, miesięczne dłużej. Uszkodzenie danych bywa zauważone po tygodniach, więc sama wczorajsza kopia nie wystarcza.
Dotyczy to zwłaszcza błędów cichych: źle wykonanego importu, skryptu poprawiającego dane albo pomyłki w cenniku. Objaw pojawia się przy zamknięciu okresu, a przyczyna jest starsza niż wszystkie kopie dzienne.
Sprawdzenie odtworzenia
Regularne, na osobnym środowisku, z porównaniem liczby rekordów. To jedyna kontrola, która cokolwiek dowodzi.
Przy okazji mierzy się czas. Odtworzenie trwające dłużej niż dopuszczalna przerwa w pracy oznacza, że kopia istnieje, ale plan awaryjny nie działa. Warto też spisać kolejność kroków — kto ma dostęp, skąd pobiera plik, co uruchamia. Ta sama logika obowiązuje przy wdrażaniu zmian na produkcję, gdzie kopia jest pierwszym krokiem, a nie czynnością z pamięci.
Powiadomienie o niepowodzeniu
Skrypt musi zgłaszać błąd. Kopia, która przestała się wykonywać trzy miesiące temu i nikt tego nie zauważył, to najczęstszy scenariusz utraty danych.
Samo powiadomienie o błędzie nie wystarcza, bo skrypt może w ogóle się nie uruchomić i wtedy nic nie wyśle. Dlatego kontrola powinna sprawdzać obecność świeżego pliku kopii i jego rozmiar, a nie tylko przebieg zadania. Kopia zerowej długości powstaje bez żadnego komunikatu.
