Studium przypadku odzyskiwania kopii zapasowej: 6 godzin wstecz
Opublikowano 10 lipca 2026
O 02:14 UTC witryna przestała zapisywać zamówienia do bazy danych. O 02:19 strona nadal serwowała strony z pamięci podręcznej, ale checkout był już fikcją. To studium przypadku odzyskiwania kopii zapasowej opisuje, co wydarzyło się później na produkcyjnym VPS małej firmy e-commerce, co przywróciliśmy, czego nie przywracaliśmy bezrefleksyjnie i dlaczego usługa znów działała stabilnie jeszcze przed świtem.
Klient korzystał z dość standardowego stosu dla rozwijającego się sklepu internetowego - Nginx, PHP-FPM, MariaDB, Redis oraz panel sterowania używany przez dwóch pracowników niebędących administratorami systemów. Ruch nie był ogromny, ale timing był bolesny. Kampania sprzedażowa zwiększyła liczbę zamówień, zapisy do bazy danych osiągały szczyt, a problem z pamięcią masową na warstwie filesystem zaczął uszkadzać aktywne tabele bazy danych. Nie było to dramatyczne jak w Hollywood, ale wystarczająco poważne, by każda minuta miała znaczenie.
Pierwszym zadaniem nie było przywracanie. Pierwszym zadaniem było powstrzymanie dalszego rozprzestrzeniania się szkód. Przełączyliśmy aplikację w tryb maintenance, zachowaliśmy bieżący stan dysku do przeglądu i sprawdziliśmy, czy replikacja, snapshoty czy logical dump dadzą nam najczystszy punkt odzyskiwania. To ma większe znaczenie, niż ludzie lubią przyznawać. Szybkie odzyskanie jest dobre. Szybkie odzyskanie do uszkodzonych danych to tylko szybkie rozczarowanie.
Co uległo awarii i skąd to wiedzieliśmy
Logi opowiadały już tę samą historię. MariaDB zaczęła zgłaszać błędy checksum stron InnoDB, po czym nastąpiły awarie tabel o intensywnych zapisach, obsługujących zamówienia i sesje. Sam hypervisor był sprawny. Zachowanie CPU, RAM i sieci pozostawało normalne. To zawęziło zdarzenie z szerokiej awarii platformy do integralności pamięci masowej na poziomie gościa.
Zweryfikowaliśmy trzy rzeczy, zanim dotknęliśmy kopii zapasowych. Po pierwsze, czy problem był ograniczony do niewielkiego zestawu tabel i czy można go było naprawić na miejscu. Po drugie, czy ostatnie kopie zapasowe były prawidłowe i możliwe do zamontowania. Po trzecie, czy jakiekolwiek transakcje zakończone po ostatniej znanej dobrej kopii zapasowej można było odtworzyć na podstawie logów aplikacji, potwierdzeń e-mail lub zapisów bramki płatniczej.
Ten trzeci krok często jest pomijany. Nie powinien. Przywrócenie kopii zapasowej nie jest całym procesem odzyskiwania. Firmy przejmują się brakującymi zamówieniami, rekordami klientów i stanem faktur, a nie tylko tym, czy MySQL znowu się uruchamia.
Wybrana przez nas ścieżka odzyskiwania
To studium przypadku odzyskiwania kopii zapasowej jest przydatne, ponieważ oczywista opcja nie była najlepszą opcją. Mieliśmy trzy możliwe ścieżki.
Pełny rollback snapshotu VM byłby najszybszy pod względem liczby kliknięć, ale odrzuciłby także kilka godzin prawidłowych zmian treści, aktualizacji wtyczek i edycji kont klientów. Naprawianie tabel na miejscu niosło zbyt duże ryzyko, ponieważ uszkodzenie objęło już kluczowe dane transakcyjne. Lepszą drogą było przywrócenie na poziomie plików i bazy danych do świeżej instancji, a następnie selektywne uzgadnianie danych.
Najpierw utworzyliśmy więc czyste środowisko odzyskiwania. Ten sam rozmiar VPS, ta sama rodzina systemu operacyjnego, ta sama wersja panelu, ta sama gałąź PHP. Odbudowa w równoległej instancji daje trochę oddechu. Chroni też oryginalny system do przeglądu forensic, co jest przydatne, jeśli klient musi zrozumieć przyczynę źródłową lub zweryfikować, że problem nie został spowodowany przez zachowanie aplikacji.
Pobraliśmy ostatnią udaną automatyczną kopię zapasową z 23:00 UTC. Następnie przetestowaliśmy ją przed przełączeniem. Brzmi to podstawowo, ale wiele zespołów odkrywa problemy z kopiami zapasowymi dopiero w najgorszej możliwej godzinie. Archiwum zamontowało się poprawnie, checksumy się zgadzały, import bazy danych zakończył się bez błędów, a aplikacja uruchomiła się w izolacji. Dobrze. Spokój zaczyna się właśnie tam.
Przywracanie usługi bez tworzenia nowych problemów
Odzyskiwanie miało cztery etapy. Po pierwsze, infrastruktura. Odbudowaliśmy stos webowy, zastosowaliśmy wcześniej zatwierdzone aktualizacje systemowe i dopasowaliśmy wersje runtime, aby aplikacja nie uległa awarii z powodu niespodziewanego niedopasowania zależności.
Po drugie, dane. Przywracanie bazy danych zakończyło się w 11 minut. Pliki webowe przywrócono w mniej niż 4 minuty. Zasoby multimedialne były nienaruszone, co oszczędziło klientowi uszkodzonych obrazów produktów i złoszczących pustych ramek w przeglądarce. Redis nie został przywrócony z kopii zapasowej, ponieważ dane cache są z założenia jednorazowe. Przeniesienie nieaktualnego cache z powrotem do świeżego środowiska to jeden z tych małych błędów, które później robią duży bałagan.
Po trzecie, walidacja. Sprawdziliśmy logowanie do aplikacji, przepływ checkout, zapisy w panelu administracyjnym, wykonanie cron, poprawność SSL, pocztę wychodzącą oraz zachowanie callbacków bramki płatniczej. Porównaliśmy też liczby rekordów w tabelach zamówień, klientów i katalogu z oczekiwanymi krzywymi wzrostu z poprzedniego tygodnia. Liczby nie muszą być idealną poezją, ale nie powinny wyglądać dziwnie.
Po czwarte, uzgadnianie. Między 23:00 UTC a 02:14 UTC przetworzono kilka udanych płatności. Te rekordy nie istniały w przywróconej bazie danych, ponieważ pojawiły się po punkcie wykonania kopii zapasowej. Odtworzyliśmy je na podstawie potwierdzeń dostawcy płatności, e-mailowych powiadomień o zamówieniach i logów dostępu do witryny. To właśnie tutaj doświadczony operator oszczędza firmie wielu problemów. Przywrócenie technicznie udane, ale tracące opłacone zamówienia, nie jest tak naprawdę sukcesem.
O 03:41 UTC aplikacja była dostępna do wewnętrznego przeglądu klienta. O 04:06 UTC DNS i routing brzegowy skierowały ruch produkcyjny z powrotem do odzyskanej instancji. Łączne zakłócenie checkout widoczne dla klientów trwało niecałe dwie godziny, podczas gdy dostęp odczytowy do większości witryny pozostawał dostępny przez znaczną część incydentu.
Co sprawiło, że odzyskiwanie było szybkie
To nie było szczęście ani jakiś magiczny przycisk kopii zapasowej. Szybkość wynikała z przygotowania i z ograniczenia liczby decyzji podejmowanych podczas incydentu.
Klient miał już automatyczne zaplanowane kopie zapasowe z retencją, monitorowane zachowanie serwera oraz ścieżkę wsparcia, która nie znikała w ciszy systemu zgłoszeń. To zmieniło przebieg tej nocy. Nie debatowaliśmy nad tym, czy kopia zapasowa istnieje. Wybieraliśmy najbezpieczniejszy punkt przywracania i go walidowaliśmy.
Spójność środowiska również miała znaczenie. Ponieważ stos hostingowy był standaryzowany, nie spędziliśmy 45 nerwowych minut na odkrywaniu, że przywrócona aplikacja wymaga starego rozszerzenia PHP albo brakującej biblioteki systemowej. Ludzie często nie doceniają, ile czasu odzyskiwania spala dryf konfiguracji.
Było też jedno mniej widoczne zwycięstwo - oddzielenie tego, co stanowe, od tego, co jednorazowe. Zawartość bazy danych, przesłane multimedia, konfiguracja i zasoby SSL były traktowane z należytą ostrożnością. Cache, pliki tymczasowe i wygenerowane sesje zostały odbudowane czysto. Dzięki temu odzyskiwanie pozostaje szczupłe i unika przenoszenia starego szumu do nowego uruchomienia.
Czego uczy to studium przypadku odzyskiwania kopii zapasowej
Główna lekcja nie brzmi po prostu: wykonuj kopie zapasowe serwera. Większość firm już zna to zdanie. Trudniejsza lekcja polega na projektowaniu odzyskiwania wokół funkcji biznesowej, a nie tylko wokół obiektów infrastruktury.
Snapshot VM jest przydatny, ale może być zbyt toporny. Dump bazy danych jest przydatny, ale niewystarczający, jeśli przesłane pliki są przechowywane osobno. Kopia zapasowa panelu sterowania jest wygodna, ale wygodę nadal trzeba testować. Właściwa strategia kopii zapasowych zależy od tego, jak zachowuje się aplikacja, jak często zmieniają się dane i jaka skala utraty jest rzeczywiście akceptowalna.
W przypadku witryny e-commerce obrazy produktów zwykle mogą tolerować nieco starsze punkty odzyskiwania niż rekordy zamówień. W przypadku aplikacji SaaS stan bazy danych klientów może mieć większe znaczenie niż zawartość lokalnego filesystem. W przypadku agencji cyfrowej hostującej wiele witryn klientów na jednym serwerze izolacja staje się krytyczna, ponieważ jedna hałaśliwa witryna nie powinna zamieniać odzyskiwania w problem obejmujący całą szafę.
Testowanie również zasługuje na większy szacunek. Kopie zapasowe są obietnicami, dopóki nie zostaną przywrócone. Po przywróceniu stają się dowodem. Ta różnica jest kosztowna.
Co zmieniło się po incydencie
Nie potraktowaliśmy odzyskiwania jako linii mety. Po ustabilizowaniu usługi przeanalizowaliśmy zachowanie pamięci masowej, kondycję filesystem, kontrole integralności bazy danych oraz harmonogram polityki kopii zapasowych. Bezpośrednia przyczyna techniczna wskazywała na niespójność dysku na poziomie gościa pod presją zapisu, ale szersze pytanie brzmiało, jak następnym razem ograniczyć promień rażenia.
Częstotliwość kopii zapasowych została dostosowana dla warstwy bazy danych, aby skrócić ekspozycję punktu odzyskiwania podczas kampanii. Zaostrzono progi alertów dla czasu oczekiwania I/O i wzorców błędów bazy danych. Klient przeszedł też od myślenia o pojedynczym przywróceniu do podejścia warstwowego - automatyczne kopie zapasowe, zweryfikowane procedury przywracania i jaśniejsze postępowanie przy uzgadnianiu transakcji.
To właśnie tutaj zarządzane wsparcie operacyjne pokazuje swoją wartość. Nie dlatego, że incydenty nigdy się nie zdarzają, ale dlatego, że kiedy już się zdarzą, ktoś już wie, gdzie spojrzeć najpierw i czego nie zepsuć podczas naprawy. Ta mała różnica bardzo często jest całą różnicą.
Jeśli utrzymujesz obciążenia generujące przychód, użyteczne pytanie nie brzmi, czy masz kopie zapasowe. Użyteczne pytanie brzmi, czy o 2 w nocy potrafisz przywrócić właściwe dane we właściwe miejsce, szybko je zweryfikować i rozliczyć to, co wydarzyło się po wykonaniu kopii zapasowej. Jeśli odpowiedź jest niepewna, system nadal domaga się uwagi. Lepiej odpowiedzieć na to w spokojne popołudnie niż podczas awarii checkout.
Andres Saar Inżynier ds. obsługi klienta