Kopie zapasowe aplikacji — plan odtwarzania, który faktycznie działa

Kopia zapasowa, której nikt nigdy nie próbował odtworzyć, jest hipotezą, a nie zabezpieczeniem. Firmy regularnie odkrywają to w najgorszym możliwym momencie: kopie istnieją, ale są niekompletne, uszkodzone, zaszyfrowane kluczem, którego nikt nie pamięta, albo odtworzenie trwa trzy dni zamiast trzech godzin. Dobry plan zaczyna się więc nie od wyboru narzędzia, lecz od odpowiedzi na dwa pytania: ile danych firma może stracić i jak długo może nie działać.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Dwa parametry, od których wszystko zależy

Akceptowalna utrata danych określa, jak dużo pracy firma może stracić. Jeśli kopia robiona jest raz na dobę o północy, awaria o osiemnastej oznacza utratę osiemnastu godzin zamówień, zgłoszeń i zmian. Dla bloga to akceptowalne, dla sklepu internetowego zwykle nie.

Akceptowalny czas przestoju określa, jak długo system może nie działać. Odtworzenie z kopii przechowywanej w archiwum wymagającym kilku godzin na udostępnienie danych nie spełni wymogu przywrócenia w godzinę.

Te wartości trzeba ustalić z osobami odpowiedzialnymi za biznes, a nie przyjąć arbitralnie po stronie technicznej. Odpowiedź „nie możemy stracić nic i nie możemy stać ani minuty" jest możliwa do zrealizowania, ale kosztuje wielokrotnie więcej niż rozsądny kompromis — i warto, żeby decydent to wiedział.

Co trzeba kopiować

Najczęstszy błąd to kopia samej bazy danych w przekonaniu, że to „wszystkie dane". Odtworzenie działającego systemu wymaga znacznie więcej.

• Baza danych — oczywista, ale z dziennikiem transakcji, jeśli akceptowalna utrata jest krótsza niż odstęp między pełnymi kopiami.
• Pliki przesłane przez użytkowników — załączniki, zdjęcia produktów, dokumenty. Często leżą poza bazą i poza kopią.
• Konfiguracja aplikacji — zmienne środowiskowe, ustawienia usług zewnętrznych, adresy integracji.
• Sekrety i klucze — przechowywane osobno i bezpiecznie, ale z pewnością, że da się je odzyskać.
• Konfiguracja serwera — reguły przekierowań, certyfikaty, zadania cykliczne.
• Kod w wersji wdrożonej — zwykle w repozytorium, ale warto wiedzieć, która dokładnie wersja działała.
• Dokumentacja odtwarzania — w miejscu dostępnym, gdy system nie działa.

Zasada trzech kopii

Sprawdzoną regułą jest utrzymywanie co najmniej trzech kopii danych, na dwóch różnych rodzajach nośników, z czego jedna znajduje się poza główną lokalizacją. Jej sens jest prosty: żadne pojedyncze zdarzenie — awaria dysku, pożar serwerowni, zablokowanie konta u dostawcy — nie powinno zniszczyć wszystkich kopii jednocześnie.

Współcześnie warto dodać do tego czwarty element: jedna kopia powinna być niezmienialna albo odłączona od systemu produkcyjnego. Oprogramowanie szyfrujące dane dla okupu celowo szuka i niszczy dostępne kopie zapasowe, zanim ujawni atak. Kopia, do której ma dostęp to samo konto co produkcja, nie chroni przed takim scenariuszem.

Gdzie przechowywać

Rozsądny układ dla typowej firmy: szybkie kopie u dostawcy hostingu do codziennych drobnych przywróceń oraz niezależna, niezmienialna kopia u innego dostawcy na wypadek scenariuszy poważnych.

Jak długo trzymać kopie

Awarie nie zawsze wychodzą na jaw od razu. Błąd w kodzie, który przez dwa tygodnie po cichu nadpisywał dane, sprawia, że kopie z ostatnich czternastu dni zawierają już uszkodzone informacje. Retencja siedmiodniowa nie pozwoli wtedy na odzyskanie.

• Kopie dzienne przez kilka tygodni.
• Kopie tygodniowe przez kilka miesięcy.
• Kopie miesięczne przez rok lub dłużej, jeśli wymagają tego przepisy albo charakter danych.

Przy danych osobowych retencja ma też drugą stronę: kopie przechowywane latami zawierają dane osób, które zażądały ich usunięcia. Plan powinien uwzględniać, jak takie żądania realizuje się wobec kopii.

Testowanie odtworzenia

To element, który odróżnia plan działający od deklarowanego. Test polega na odtworzeniu systemu z kopii na osobnym środowisku i sprawdzeniu, że działa.

• Odtwórz na czystym środowisku, nie na serwerze, na którym kopia powstała — tylko wtedy sprawdzisz, że niczego nie brakuje.
• Zmierz czas całego procesu i porównaj z akceptowalnym przestojem.
• Sprawdź działanie aplikacji, nie tylko to, że baza się wczytała. Logowanie, złożenie zamówienia, podgląd załącznika.
• Sprawdź najnowsze dane — czy odtworzony stan odpowiada założonej akceptowalnej utracie.
• Niech odtwarza ktoś inny niż autor procedury. Jeśli bez niego się nie da, dokumentacja jest niekompletna.
• Zapisz wynik i poprawki — każdy test ujawnia coś, co trzeba uzupełnić.

Częstotliwość zależy od znaczenia systemu. Dla kluczowych aplikacji — raz na kwartał, dla pozostałych — raz na pół roku, a zawsze po istotnej zmianie architektury.

Monitorowanie kopii

Kopie przestają się wykonywać po cichu. Wypełniony dysk, wygasłe dane dostępowe, zmiana nazwy bazy — i od tygodni nic nie trafia do magazynu, a nikt o tym nie wie.

• Alert przy braku nowej kopii w oczekiwanym czasie — sprawdzany niezależnie od samego procesu kopiowania.
• Kontrola rozmiaru — nagły spadek wielkości kopii bywa sygnałem, że czegoś w niej brakuje.
• Weryfikacja integralności — sprawdzenie, że plik kopii da się otworzyć, a nie tylko że istnieje.

O budowie alertów, które nie męczą zespołu, piszemy w materiale o monitoringu aplikacji produkcyjnej.

Procedura odtworzenia na papierze

W sytuacji awaryjnej nikt nie powinien improwizować. Procedura spisana krok po kroku, przechowywana poza systemem, którego dotyczy, oszczędza godzin i błędów wynikających ze stresu.

• Kto decyduje o rozpoczęciu odtwarzania i kto je wykonuje.
• Gdzie leżą kopie i jak uzyskać do nich dostęp.
• Gdzie są klucze szyfrujące i dane dostępowe.
• Kolejność odtwarzania komponentów.
• Jak zweryfikować, że system działa poprawnie.
• Jak poinformować klientów o przerwie i jej zakończeniu.
• Kontakty do dostawców hostingu i usług zewnętrznych.

Scenariusze, na które warto się przygotować

Plan kopii zapasowych ocenia się po tym, czy pokrywa realne zdarzenia, a nie tylko awarię dysku. Warto przejść kilka scenariuszy i dla każdego odpowiedzieć, jak wygląda odtworzenie.

Ostatni scenariusz jest w małych firmach jednym z najbardziej prawdopodobnych, a najrzadziej uwzględnianym. Kopie, których odtworzenie wymaga wiedzy jednej osoby, są zabezpieczeniem tylko tak długo, jak ta osoba jest dostępna.

Kto odpowiada za kopie

W wielu firmach kopie zapasowe są „sprawą informatyka" albo „sprawą dostawcy hostingu", co w praktyce oznacza, że nikt nie sprawdza ich regularnie. Warto wskazać jedną osobę odpowiedzialną za cały proces: konfigurację, przegląd raportów, cykliczne testy odtworzenia i aktualizację procedury po zmianach w systemie.

Równie ważne jest ustalenie, kto podejmuje decyzję o odtworzeniu. Przywrócenie danych sprzed kilku godzin oznacza utratę zmian wprowadzonych w międzyczasie, więc to decyzja biznesowa, nie techniczna. Osoba techniczna przedstawia opcje i ich skutki, a właściciel procesu wybiera. Ustalenie tego przed awarią oszczędza nerwowych dyskusji w jej trakcie.

Dobrą praktyką jest też krótki raport po każdym teście odtworzenia: ile trwało, co nie zadziałało, co poprawiono w procedurze. Po kilku takich raportach widać, czy plan staje się coraz pewniejszy, czy tylko istnieje na papierze.

Podsumowanie

Plan kopii zapasowych to nie wybór narzędzia, lecz odpowiedź na dwa pytania biznesowe: ile danych można stracić i jak długo system może nie działać. Z nich wynika częstotliwość, miejsce i retencja. Bez regularnego testu odtworzenia nawet najstaranniej zaprojektowany plan pozostaje hipotezą.

Jeśli masz dziś kopie, ale nigdy z nich nie odtwarzałeś systemu, zaplanuj test w tym miesiącu — na osobnym środowisku, przeprowadzony przez kogoś innego niż autor konfiguracji. To jedno ćwiczenie powie Ci więcej o bezpieczeństwie danych niż jakikolwiek przegląd dokumentacji. Szerzej o budowie niezawodnych systemów piszemy na stronie aplikacje webowe.