W poniedziałek 7 kwietnia 2025 roku o 8:59 padł nasz VPS w OVH. Razem z nim strony, poczta, API i panele administracyjne. SSH odpowiadał timeoutem. Przez następne siedem dni nie działało nic.
Piszę to półtora roku później, bo ta historia wciąż wraca, kiedy ktoś mówi mi „przecież jest backup”. I dlatego, że dostawca, któremu płaciliśmy za infrastrukturę i kopie zapasowe, zawalił na całej linii, a sprzątać musiałem ja.
Dzień pierwszy: incydent, którego nie ma
Zgłoszenie przez panel wysłałem przed jedenastą. Na stronie statusu OVH wisiał incydent, ale nic nie wskazywało, że dotyczy naszego serwera. Po południu support przysłał link do innego incydentu i przyznał, że poprzedni był błędny. Wieczorem zgłoszenia zaczęły się zamykać automatycznie. Bez rozwiązania.
Do tego drobiazg, który w takich chwilach przestaje być drobiazgiem: nasz adres kontaktowy obsługiwał ten sam serwer, który leżał. Hasło do trybu ratunkowego dało się odebrać tylko przez panel.
W trybie Rescue dostałem się do dysku. Komunikat był jednoznaczny:
EXT4-fs (sda1): bad geometry: block count 83885819 exceeds size of device (63292816 blocks)Przekładam na ludzki. System plików był zbudowany na dysku o pojemności około 320 GiB. Urządzenie, które OVH podawało do maszyny, miało około 241 GiB. Z dysku zniknęło prawie 79 GiB, jedna czwarta. Nie skasowaliśmy plików. Nie pomyliliśmy konfiguracji. Warstwa, na której stał nasz serwer, nagle zaczęła udawać mniejszy dysk. Ta warstwa należy do dostawcy.
Dzień drugi i trzeci: „trwa większa awaria”
We wtorek support przez telefon: trwa większa awaria, trwa naprawa. Po południu strona statusu ogłosiła, że serwery w centrum DE2 wracają. Nasz nie wrócił.
W środę poproszono mnie o testy sieci. Zrobiłem, wysłałem. Sieć nie była problemem. Problemem był dysk, o czym mówiłem od poniedziałku.
Wieczorem fsck. Kilka pełnych przebiegów do pierwszej w nocy i nadal błędy. Systemu plików nie da się naprawić na urządzeniu o jedną czwartą za małym. To próba zmieszczenia czegoś w miejscu, którego już nie ma.
Backup, który miał być ostatnią linią obrony
W czwartek zostały kopie zapasowe. Płaciliśmy za automatyczne backupy OVH. Zacząłem je przeglądać po kolei, każdą montowaną przez panel, każda montowała się mniej więcej dwie godziny.
- Kopia z 6 kwietnia: w trybie Rescue widziałem tylko system i biblioteki. Ani stron, ani baz.
- Kopia z 5 kwietnia: ten sam błąd geometrii co na głównym dysku.
- Kopie z 4 i 2 kwietnia: struktura systemowa, bez danych użytkowników.
- Kopia z 3 kwietnia: znowu bad geometry.
- Kopie z 1 kwietnia i 31 marca: to samo, puste albo uszkodzone.
Dopóki serwer nie działa, można zakładać, że dane gdzieś są. Kiedy kolejne kopie też nie dają się odczytać, pytanie się zmienia. Już nie: kiedy wrócimy. Tylko: czy w ogóle będzie co przywracać.
W sobotę nad ranem miałem przed sobą dwie opcje. Ryzykowne przywrócenie kopii z 6 kwietnia albo snapshot z 10 lutego, czyli dwa miesiące danych w plecy. Do tego sprawy, za które odpowiadamy wobec ludzi korzystających z naszych aplikacji.
W niedzielę zrobiłem to, czego nikt za mnie nie zrobił: ściągnąłem cały dysk. Przez SSH, poleceniem dd, skompresowany w locie, na zewnętrzny dysk podpięty do mojego komputera. 259 GB surowego obrazu, 119 GB po kompresji, sprawdzona integralność. Od tej chwili przynajmniej to, co zostało, było u mnie.
Poniedziałek, 14 kwietnia
W nocy z niedzieli na poniedziałek podjąłem ostatnią próbę: przywrócenie kopii z 6 kwietnia przez panel OVH. Ta sama kopia, która w trybie Rescue wyglądała na pustą. Po pierwszej w nocy system wstał. Dane były. Bazy były. O czwartej skończyłem weryfikację i usługi zaczęły wracać.
Ten szczegół mówi o OVH więcej niż cała reszta. Kopia była dobra. Narzędzia dostawcy przez kilka dni pokazywały mi ją jako pustą. Klient, który w kryzysie ufa temu, co widzi w panelu, mógł ją skreślić i przywrócić dane sprzed dwóch miesięcy.
Rachunek
Siedem dni bez usług. Ponad 90 godzin mojej pracy technicznej według zestawienia, które prowadziłem na bieżąco, godzina po godzinie. Telefony, maile po polsku i po angielsku, zgłoszenia zamykane automatycznie, prośby o testy sieci przy uszkodzonym dysku. Formalną reklamację złożyłem.
OVH potwierdziło w korespondencji, że incydent infrastrukturalny objął nasz serwer, a informacja o awarii przez ponad dobę widniała w ich systemie komunikatów o awariach. Nie znam wewnętrznej przyczyny i nie będę jej zgadywać. Znam skutki: dysk o jedną czwartą mniejszy niż system plików, kopie, których nie dało się odczytać ich własnymi narzędziami, i support, który przez kilka dni nie wiedział, który incydent nas dotyczy.
Co z tego zostało
Płacimy za serwer, ale odpowiedzialność za skutki awarii nie przechodzi na dostawcę razem z fakturą. Kiedy pada infrastruktura, to nie OVH tłumaczy naszym użytkownikom, dlaczego nie mogą pracować. Robimy to my.
Trzy zasady, które od tamtego tygodnia traktuję jak prawo:
- Backup u tego samego dostawcy, na tej samej infrastrukturze, to nie backup. To nadzieja.
- Kopia, której nie odtworzyłeś w próbie, jest obietnicą, nie zabezpieczeniem.
- Poczta, którą kontaktujesz się z supportem, nie może stać na serwerze, który właśnie padł.
I jeszcze jedno. Kiedy jesienią 2026 spędziłem dwa tygodnie na porządkowaniu serwerów, chodziło o wydajność. Ale chyba jeszcze bardziej o to, żeby nigdy więcej nie przeżyć tamtego tygodnia. Piszę o tym w tekście „Filozofia na tle szumiących serwerów”, który ukaże się 22 października.
Dodaj komentarz