31 marca to World Backup Day, czyli dzień mający na celu przypomnienie o ochronie danych i konieczności przygotowania się na najgorsze scenariusze. Tegoroczny World Backup Day zapamiętam niestety na długo. Właśnie tego dnia miała miejsce najpoważniejsza w skutkach awaria bloga w historii.

W tym artykule podsumuję, co się wydarzyło, co zadziałało dobrze, a gdzie procesy zawiodły. To artykuł o nauce na błędach, jednak zdecydowanie lepiej, uczyć się na moich niż na swoich.

Historia incydentu

Pierwszy zwiastun incydentu przyszedł nieco wcześniej – 28 marca o godzinie 20:58 w postaci maila od zespołu administracyjnego Mikrusa:

W poniedziałek, 30 marca 2026 o godzinie 22:00 planujemy prace konserwacyjne na tej maszynie. Będziemy wymieniać w serwerze dyski SSD NVMe na nowe. Operacja ta wymaga wyłączenia maszyny i synchronizacji macierzy RAID.

Cyklicznie wymieniamy dyski na nowe, gdy poziom zużycia obecnych zbliża się do granicy bezpieczeństwa. Właśnie nadszedł czas na kolejną aktualizację sprzętu.

Szacujemy, że niedostępność serwerów VPS potrwa maksymalnie 3 godziny, więc około godziny 1:00 w nocy, 31 marca, Twój serwer powinien już działać normalnie.

Nie musisz niczego robić w związku z naszymi pracami.

Chcemy po prostu poinformować Cię o zaplanowanej przerwie technicznej, aby nocna niedostępność serwera nie była dla Ciebie zaskoczeniem.

Mówiąc szczerze, komunikat całkowicie zignorowałem. Nie był to pierwszy raz, gdy na maszynie miały miejsce prace konserwacyjne. Nigdy nie powodowało to większych komplikacji, więc uznałem, że nie trzeba nic z tym robić. To był błąd nr 1.

Całkowicie zapomniałem o temacie aż do wspomnianego 31 marca. Przy porannej kawie zacząłem rutynowo czytać maile i moją uwagę zwrócił ten o tytule „[MIKR.US] Ważna informacja o awarii srv** i utracie danych„. Początkowo uznałem, że komuś omsknął się palec i puścił żart Prima Aprilisowy dzień za wcześnie. Jednak po otwarciu wiadomości okazało się, że sprawa jest poważna.

piszemy do Ciebie z bardzo trudną informacją i z prośbą o przyjęcie przeprosin.

Podczas zaplanowanych na dziś w nocy prac serwisowych związanych z wymianą dysków w jednym z naszych serwerów doszło do awarii, której skutkiem była całkowita utrata danych znajdujących się na tym serwerze. Oznacza to, że dane zapisane na Twoim VPS-ie (***) zostały bezpowrotnie utracone.

Po dokładnym sprawdzeniu sytuacji ustaliliśmy, że w serwerze znajdowały się dyski SSD NVMe Samsung PM9A1 z wadliwej serii. Niestety uszkodzeniu uległy wszystkie nośniki jednocześnie, więc pomimo posiadania macierzy RAID, odzyskanie danych nie jest możliwe.

Bardzo nam przykro. Mamy świadomość, że za tymi danymi mogła stać Twoja praca, czas albo były tam po prostu rzeczy dla Ciebie ważne. Wiemy, że odtwarzanie usług po takiej awarii może być dla Ciebie trudne i czasochłonne. Jeśli masz własne kopie danych lub konfiguracji, mamy nadzieję, że ułatwią Ci one powrót do działania.

Jeśli korzystałeś u nas z usługi Cytrus, mamy pełną kopię danych znajdujących się w tej usłudze. W przypadku serwerów VPS ich zawartość nie była objęta backupem, dlatego nie mamy możliwości jej odtworzenia.

W uzupełnieniu otrzymałem również dodatkowe informacje dotyczące przyczyn awarii.

Wymiana dysków na nowe to operacja, którą wykonujemy standardowo i która zawsze się udaje. W przypadku tego serwera wiedzieliśmy, że mamy wadliwą partię dysków, jednak spięcie wszystkiego w RAID 5 teoretycznie gwarantowało nam możliwość przetrwania awarii jednego dysku.

Tymczasem technik serwerowni powiadomił nas, że z niewiadomych powodów cała macierz przestała działać, spalając jednocześnie wszystkie trzy podpięte dyski.

Szybki rekonesans pokazał, że sytuacja jest faktycznie poważna. Ani na VPS, ani do panelu administracyjnego Mikrusa nie szło się dostać. Uznałem, że na sam początek zrobię analizę tego, co jestem w stanie odzyskać, a co bezpowrotnie straciłem. O szczegółach analizy więcej piszę w dalszej części artykułu.

Mimo że incydent jest wynikiem błędu po stronie Mikrusa, nie mam zamiaru się obrażać ani obwiniać administracji. Mikrus ze swoją ofertą jasno celuje w serwery do nauki czy pobocznych projektów. Jeśli ktoś planuje stawiać poważne usługi na Mikrusie, to musi brać pod uwagę to, że jakość może odbiegać od konkurencji, wynagradzając to ceną.

W przypadku Mikrusa, ze względu na redukcję ceny, zawsze informujemy użytkowników, aby obsługiwali backupy swoich serwerów samodzielnie. Nie jesteśmy w stanie finansowo udźwignąć backupowania kilku tysięcy terabajtów danych w takiej cenie. Stąd ten zapis w regulaminie.

Wspomniane zapisy w regulaminie to w szczególności dwa punkty dotyczące odpowiedzialności za dane na serwerze.

4. Usługodawca korzysta z usług firm trzecich do świadczenia usług hostingowych (np. Datacenter Hetzner) i nie odpowiada za awarie, interwencje i przerwy techniczne dokonywane przez firmy trzecie z usług których korzysta Usługodawca

8. Usługodawca przerzuca na użytkownika odpowiedzialność za wykonywanie kopii bezpieczeństwa i zapewnienie integralności przetrzymywanych na serwerach Usługodawcy danych

Administracja faktycznie dość często przypomina o tym, by regularnie wykonywać kopie zapasowe. Wszelkie pretensje co do ewentualnych szkód mogę mieć wyłącznie do siebie.

Należy wspomnieć, że niemal od razu po nawiązaniu kontaktu z administracją otrzymałem nowy serwer, na którym mogłem rozpocząć przywracanie bloga. Doceniam też, że użytkownicy objęci awarią otrzymali rekompensaty, moim zdaniem adekwatne.

Od momentu rozpoczęcia prac nad przywróceniem bloga do działającej aplikacji minęły ok. 3 godziny. Kolejne 3 godziny zajęło przywrócenie usługi mailingu, dzięki czemu blog był już w pełni funkcjonalny. Ostatnie 2 godziny zajęło mi odtworzenie wewnętrznych workflowów dla n8n.

Co poszło dobrze

Dobrze poszło zaskakująco wiele rzeczy. Przede wszystkim awaria ominęła bazę danych bloga. Niestety było to dziełem przypadku, a nie przemyślanej strategii. Na potrzeby bloga korzystam z bazy danych połączonej z zewnętrznym serwerem nieobjętym awarią. Ostatni backup bazy danych miałem sprzed dwóch miesięcy. W razie jej awarii musiałbym ręcznie przywracać zawartość bloga z tego okresu. Byłoby to wykonalne, jednak dość czasochłonne.

Dość szybko udało się przywrócić samego bloga. Mimo że ostatni backup miałem sprzed dwóch miesięcy, od tego czasu w obszarze pluginów czy motywów nie zaszły praktycznie żadne zmiany. Zmuszony byłem jedynie do ponownego wrzucenia grafik dla kilku najnowszych artykułów. Konfigurację dla usług koniecznych do postawienia bloga przechowuję w dedykowanym repozytorium, co znacznie ułatwiło ponowne ich stawianie. Po mniej więcej dwóch godzinach blog wrócił do życia, a po kolejnej godzinie był w pełni funkcjonalny.

W przeszłości do tworzenia kopii zapasowych korzystałem z takich rozwiązań jak Duplicator czy BackWPup. Jednak wraz z rozrastaniem się bloga zaczęły pojawiać się problemy. Już na etapie tworzenia kopii narzędzia potrafiły rzucać błędami, zawieszać się i odmawiać współpracy. Uznałem, że wolę nie ryzykować i zdecydowałem się na samodzielne przygotowywanie kopii. Decyzja o ręcznym backupie WordPressa okazała się wystarczająca w tym przypadku. By przywrócić bloga, w moim przypadku wystarczyło zainstalować czystego WordPressa, przenieść zawartość wp-content z backupu, uzupełnić wp-config.php i tyle.

Szybko poszło również przywrócenie usługi do mailingu. Na szczęście całość konfiguracji miałem w kopiach zapasowych i wspomnianym już repozytorium. Wymagane było jedynie wprowadzenie kilku drobnych poprawek wynikających ze zmian portów i adresów w kilku miejscach.

Dobrą robotę zrobił też menedżer haseł, dzięki któremu miałem dostęp do wszystkich haseł, kluczy i innych sekretów potrzebnych do przywrócenia usług. Tu jednak należy wspomnieć, że było o krok od tragedii. Jeden z sekretów był zapisany wyłącznie w historii generowanych kluczy, a nie na liście haseł. Gdyby nie to, proces przywracania niektórych usług mocno by się skomplikował.

Co poszło źle

Największym błędem było moje zbyt frywolne podejście do backupów. Udało się uniknąć dużych szkód, głównie dlatego, że na blogu poza publikowaniem nowych artykułów nie działo się zbyt wiele. Ostatni backup pochodził z końca stycznia. Wynikało to z tego, że przypomnienie o konieczności zrobienia backupu dostaję raz miesięcznie i na moje nieszczęście kilka ostatnich przypomnień przegapiłem (lub raczej zignorowałem). Problemem były tu również konieczność manualnego przygotowywania kopii zapasowej i brak spisanej procedury i gotowych skryptów.

Drugim kardynalnym błędem backupów było miejsce ich przechowywania. Największą stratą wynikającą z awarii jest częściowa strata listy mailingowej. Straciłem informację o zapisanych na mailingu czytelnikach z ostatnich dwóch miesięcy.

Mailing korzysta z innej bazy niż blog. Baza danych w tym przypadku znajdowała się bezpośrednio na serwerze objętym awarią. Dla tej bazy danych kopia zapasowa była wykonywana automatycznie każdego dnia. Powodem jej utraty był fakt, że kopia była przechowywana… wyłącznie na serwerze.

Z tego samego powodu, przez który nie miałem aktualnej kopii zapasowej bloga, nie przenosiłem kopii bazy mailingu do dedykowanych miejsc. W tym przypadku skutki były jednak dużo poważniejsze.

Należy też pamiętać, że trzymanie kopii zapasowej i oryginalnych danych w tym samym miejscu to bardzo zły pomysł. Organizując backupy, warto pamiętać o zasadzie 3-2-1:

• 3 kopie danych – zawsze trzy egzemplarze danych: oryginał i co najmniej dwie kopie zapasowe. Dzięki temu, jeśli jedna kopia ulegnie uszkodzeniu, pozostają jeszcze dwie.
• 2 różne nośniki – kopie powinny być przechowywane na co najmniej dwóch różnych typach nośników, np. na dysku lokalnym i w chmurze. To chroni przed awarią jednego rodzaju nośnika.
• 1 kopia poza miejscem pracy – przynajmniej jedna kopia powinna znajdować się w innym fizycznym miejscu, np. w chmurze. Chroni to przed zdarzeniami lokalnymi, jak pożar, powódź czy kradzież.

Próbowałem również odzyskać brakujących czytelników przez analizę ruchu w AWS SES. Niestety okazało się, że wymaga to wcześniejszej konfiguracji CloudTrail, której nie zrobiłem. AWS domyślnie nie zapisuje adresów e-mail, na które wysyła wiadomości.

Źle poszło również przywracanie workflowów dla n8n. W tym przypadku nie miałem niestety żadnej kopii zapasowej na lokalnej maszynie. Skutkiem była konieczność przygotowania ich od zera. Na szczęście pamiętałem, co robiły i jak działały, dzięki czemu udało się je przygotować w nieco ponad dwie godziny. Warto wiedzieć, że przechowywanie workflowów n8n to nie jest rocket science. Aplikacja pozwala wyeksportować je w formie plików JSON, co zrobiłem zaraz po ich przywróceniu.

Wnioski

Mimo tak poważnej awarii ostatecznie jestem zadowolony, że jej skutki nie były tak poważne, jak początkowo myślałem. Awaria pozwoliła znaleźć mi luki i miejsca na usprawnienia w procesach, a ich załatanie sprawia, że będę gotowy na przyszłe takie sytuacje. Poczyniłem również pierwsze kroki w kierunku automatyzacji tego procesu.

Był to również kubeł zimnej wody, który przypomniał mi, dlaczego tak ważne jest odpowiedzialne podejście do robienia kopii zapasowych.

Taka awaria to świetna okazja, by przypomnieć sobie, że oprócz samego robienia backupów równie ważne są:

• częstotliwość ich wykonywania;
• miejsce przechowywania;
• możliwość ich użycia (dostęp do haseł czy kluczy szyfrujących itp.);
• umiejętność ich użycia;
• wygoda ich wykonania, a najlepiej automatyzacja.

Mam nadzieję, że z opisanej historii udało Ci się wyciągnąć coś dla siebie. Będzie mi miło, jeśli podzielisz się jakąś swoją historią awarii, z której udało Ci się wyciągnąć wartościowe wnioski.

Na sam koniec mam ogromną prośbę. Jeśli chcesz otrzymywać informacje o nowych artykułach i projektach związanych z blogiem, to możesz zapisać się na mailing. Zachęcam, by zrobić to, nawet jeśli już kiedyś się zapisałeś/aś. Istnieje ryzyko, że straciłem Twojego maila w trakcie awarii.

Zaobserwuj mnie w mediach społecznościowych!

LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.

📈 Szukasz księgowości dla swojej JDG? Skorzystaj z mojego polecenia i odbierz pierwszy miesiąc za 1zł netto!

Chcesz docenić moją pracę? Postaw mi kawę!