Kopia zapasowa umożliwia odzyskanie danych, ale jej bezpośrednie odtworzenie w aktywnej bazie może usunąć uzasadnione zmiany wprowadzone po jej wykonaniu. Gdy problem dotyczy jednego rekordu lub ograniczonego zbioru danych, celem jest zwykle odzyskanie utraconych informacji przy zachowaniu pozostałej części bieżącego stanu. Wymaga to potraktowania odzyskiwania jako operacji porównania i uzgadniania, a nie prostego zastąpienia danych.
Właściwa strategia zależy od silnika bazy danych, schematu, dostępności logów audytowych i zakresu uszkodzeń. W aplikacji PHP warto oddzielić logikę odzyskiwania od aplikacji działającej na produkcji, udokumentować podjęte decyzje i przetestować walidacje przed zapisaniem danych. Jeśli nie można ustalić, które zmiany są bezpieczne, zatrzymanie się i przygotowanie ręcznego uzgodnienia jest zwykle mniej ryzykowne niż automatyczne nadpisanie danych.
Określ, co oznacza odzyskanie danych
Pełne odtworzenie zastępuje bazę, schemat lub szeroki zbiór danych zawartością z punktu odzyskiwania. Odzyskiwanie selektywne ma natomiast przywrócić konkretne wiersze lub określone wartości bez modyfikowania pozostałych aktywnych danych. Przed wyborem opisz dokładnie oczekiwany rezultat: której encji brakuje lub która została zmieniona, które pola należy odzyskać i jakie późniejsze zmiany trzeba zachować.
Określ zakres za pomocą stabilnych identyfikatorów, takich jak klucz główny, a nie tylko wartości, które mogły się zmienić, na przykład nazwa lub adres e-mail. Ustal także, czy incydent dotyczy powiązanych rekordów: zamówienie może na przykład zależeć od pozycji, płatności, adresów i zdarzeń dotyczących jego statusu. Przywrócenie tylko głównego wiersza może pozostawić niespójną encję; odzyskanie całej grupy może z kolei objąć prawidłowe zmiany, których nie należy cofać.
- Zapisz objawy, przybliżony przedział czasu oraz informację, kto zgłosił problem.
- Zidentyfikuj istotne tabele, klucze główne, klucze obce i ograniczenia.
- Określ, które pola mają wrócić do wcześniejszych wartości, a które mają pozostać bez zmian.
- Ustal, kto zatwierdzi operację i jakie kontrole pozwolą uznać ją za zakończoną.
Wybierz punkt odzyskiwania i odtwórz kontekst
Wybierz punkt odzyskiwania, który pozwoli odtworzyć wymagany stan — niekoniecznie kopię sprzed uszkodzenia. W zależności od incydentu może być konieczne porównanie kilku kopii, logów transakcyjnych i danych audytowych, aby ustalić, które informacje należy odzyskać, a jaki późniejszy kontekst warto zachować. Odtworzenie do określonego punktu w czasie może utworzyć tymczasową bazę przydatną do wyodrębnienia danych, ale nie oznacza to, że przeniesienie całej jej zawartości na produkcję jest bezpieczne.
Potwierdź datę i strefę czasową, zakres kopii, schemat, na podstawie którego ją utworzono, oraz wyniki dostępnych kontroli integralności. Niezweryfikowanej kopii nie należy domyślnie traktować jako wiarygodnego źródła. Sprawdź również, czy identyfikatory mogły zostać ponownie użyte oraz czy w trakcie analizy procesy zapisują dane w objętych problemem tabelach.
Odtwórz kopię w odizolowanej instancji z ograniczonym dostępem i bez połączeń umożliwiających zapis do środowiska produkcyjnego. Aplikacja nie powinna przypadkowo łączyć się z tą instancją ani uruchamiać na niej zaplanowanych zadań. Jeśli dane zawierają informacje osobowe lub wrażliwe, ogranicz dostęp i zastosuj przewidziane dla nich środki ochrony. Odizolowane środowisko pozwala porównać stany bez zwiększania ryzyka dla aktywnej bazy.
Porównuj dane, nie zakładając, że kopia odzwierciedla obecny stan
Porównaj potencjalne wiersze z kopii z aktualnymi wierszami, używając ich stabilnych kluczy. Dla każdego rozróżnij trzy sytuacje: rekordu już nie ma, rekord istnieje, ale jego pola uległy zmianie, albo nie ma istotnych różnic. Jeśli dostępne są znaczniki aktualizacji, historia zdarzeń lub dane audytowe, wykorzystaj je, aby ustalić, kiedy i dlaczego doszło do zmiany. Sam znacznik czasu nie dowodzi, który użytkownik wprowadził zmianę ani czy należy ją zachować.
Odzyskiwanie selektywne wymaga szczególnej ostrożności: nie kopiuj automatycznie całego starego wiersza, jeśli niektóre jego pola zmieniły się w uzasadniony sposób. Porównanie może na przykład wykazać, że rekord utracił pole opisowe, podczas gdy jego status, właściciel lub powiązanie z inną encją zmieniły się później. Przywrócenie tylko utraconego pola może być bezpieczniejsze niż zastąpienie całego wiersza, o ile pozwalają na to reguły biznesowe.
Sprawdź również konflikty unikalności, klucze obce, wymagane kolumny, wartości domyślne i reguły stosowane przez aplikację. W systemach z logicznym usuwaniem sprawdź, czy rekord jest oznaczony jako usunięty, zamiast zakładać, że go nie ma. Tabele uczestniczące w tej samej operacji biznesowej mogą wymagać wspólnego uzgodnienia, aby uniknąć niespójnych sald, statusów lub referencji.
Wykonaj ograniczoną i weryfikowalną operację
Przygotuj plan zawierający dokładny zestaw kluczy i kolumn, które mają zostać zmodyfikowane. Przed jego wykonaniem zachowaj kopię bieżącego stanu tych wierszy lub przygotuj równoważny mechanizm wycofania zmian. Przetestuj plan na aktualnej kopii aktywnej bazy i porównaj rezultat z oczekiwanym. Test musi obejmować rzeczywiste ograniczenia i zależności, a nie tylko import odizolowanych wierszy.
Jeśli pozwalają na to silnik i rodzaj operacji, wykonaj zmiany w transakcji. Transakcja nie zastępuje weryfikacji: niektóre działania związane z odtwarzaniem lub importem mogą mieć specyficzne dla silnika zachowanie, a procesy zewnętrzne mogą równolegle aktualizować dane. Użyj warunków wykrywających nieoczekiwane zmiany między porównaniem a zapisem. Jeśli wiersz nie odpowiada już sprawdzonemu stanowi, zatrzymaj operację i przeanalizuj go ponownie, zamiast po cichu go nadpisywać.
W aplikacji PHP kontrolowane zadanie lub polecenie konserwacyjne może weryfikować dane wejściowe, ograniczać zakres zmienianych kluczy i rejestrować wyniki. Unikaj budowania instrukcji SQL przez konkatenację wartości. Korzystaj z zapytań parametryzowanych i mechanizmu transakcyjnego używanego przez warstwę dostępu do danych aplikacji. Nie umieszczaj tej operacji na publicznie dostępnych ścieżkach i nie ujawniaj danych uwierzytelniających ani kopii zapasowych w logach tekstowych.
Przed zatwierdzeniem zmian sprawdź liczbę zmodyfikowanych wierszy, ograniczenia i istotne relacje. Następnie zweryfikuj odzyskane wartości oraz zachowanie aplikacji w powiązanych operacjach biznesowych. Jeśli walidacja nie powiedzie się przed zatwierdzeniem transakcji, wycofaj transakcję. Jeśli została już zatwierdzona lub wystąpiły nieodwracalne skutki, nie wykonuj kolejnego zapisu na własną rękę: przed dalszym działaniem uruchom zatwierdzony plan wycofania zmian lub odzyskiwania, postępując zgodnie z przetestowaną procedurą przywrócenia zaakceptowanego stanu i jego weryfikacji. Jeśli plan nie pozwala odzyskać spójnego stanu, wstrzymaj dalsze modyfikacje, zachowaj dowody i przekaż decyzję osobom odpowiedzialnym.
Udokumentuj decyzję i zdecyduj, kiedy nie automatyzować
Udokumentuj incydent, użyty punkt odzyskiwania, sprawdzone klucze, przywrócone pola i zachowane późniejsze zmiany. Zapisz, kto sprawdził i zatwierdził operację, kiedy ją wykonano, jakie walidacje przeprowadzono i jaki był wynik. Nie umieszczaj w dokumentacji zbędnych danych wrażliwych. Taki ślad audytowy pozwala wyjaśnić podjętą decyzję i ułatwia późniejsze dochodzenie.
Wybierz ręczne uzgodnienie, jeśli brakuje wiarygodnych kluczy, operacje biznesowe są ze sobą sprzeczne, nie można odróżnić przypadkowej zmiany od uzasadnionej albo odzyskiwanie dotyczy relacji, których znaczenie zależy od kontekstu. Pełne odtworzenie może być właściwe w przypadku rozległego uszkodzenia, wymaga jednak oceny jego skutków, przerwy w dostępności, utraty późniejszych zmian i procedury odzyskiwania. Nie należy go wybierać wyłącznie dlatego, że łatwiej je wykonać.
- Odzyskiwanie selektywne: zakres uszkodzeń jest jasno określony, klucze są wiarygodne, a różnice można zweryfikować.
- Ręczne uzgodnienie: występują równoległe zmiany lub reguły biznesowe wymagające oceny człowieka.
- Pełne odtworzenie: uszkodzenia są rozległe, a istnieje zatwierdzony plan postępowania z niedostępnością i utraconymi zmianami.
Lista kontrolna przed zakończeniem odzyskiwania
- Przygotowanie: Czy określono zakres, klucze, zależności i oczekiwany rezultat? Czy wybrano i zweryfikowano odpowiedni punkt odzyskiwania?
- Środowisko i zatwierdzenie: Czy kopię odtworzono w izolacji, ograniczono dostęp i przetestowano procedurę? Czy osoby odpowiedzialne zatwierdziły operację oraz plan wycofania zmian lub odzyskiwania?
- Wykonanie: Czy zachowano bieżący stan zmienianych wierszy, ograniczono zapis do planowanych kluczy i pól oraz wykrywane są zmiany równoległe?
- Weryfikacja: Czy sprawdzono zmienione wiersze, ograniczenia, referencje i zachowanie procesów biznesowych? Jeśli kontrola nie powiodła się, czy wstrzymano dalsze zapisy i uruchomiono zatwierdzoną procedurę?
- Możliwość prześledzenia: Czy udokumentowano decyzję, wykonanie, walidacje, zachowane zmiany i wynik bez ujawniania zbędnych danych wrażliwych?
Jeśli na istotne pytania nie możesz odpowiedzieć twierdząco, odłóż zapis w środowisku produkcyjnym. Decyzja między odzyskiwaniem selektywnym, ręcznym uzgodnieniem a pełnym odtworzeniem powinna uwzględniać zakres uszkodzeń, wiarygodność dowodów, wpływ operacyjny i rzeczywistą możliwość odzyskania spójnego stanu.
