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.
