GitLab przypadkowo usunął produkcyjną bazę, a dopiero wtedy odkrył, że kilka kopii zapasowych nie działało
31 stycznia 2017 r. podczas naprawiania problemów z replikacją GitLab administrator zamierzał wyczyścić katalog danych na serwerze wtórnym. Polecenie zostało jednak wykonane na serwerze głównym i usunęło produkcyjną bazę. Sytuację pogorszył fakt, że kilka oczekiwanych dróg recovery było niesprawnych: snapshoty nie były włączone, backup `pg_dump` od pewnego czasu cicho zawodził, a replika została wcześniej wyczyszczona. Ostatecznie GitLab utracił kilka godzin części danych. Awaria stała się testem kopii zapasowych, którego wcześniej realnie nie wykonano.
Wypadek wydarzył się podczas walki z wcześniejszą awarią
Replikacja bazy została zerwana po wzroście obciążenia. Zespół próbował odbudować secondary, co wymagało usunięcia jego katalogu danych. W warunkach presji i nocnej pracy administrator wykonał destrukcyjną komendę na niewłaściwym hoście.
Backup logiczny zawodził bez skutecznego alarmu
Regularny `pg_dump` nie działał poprawnie ze względu na niezgodność wersji PostgreSQL. System wysyłał powiadomienia e-mail, ale te były odrzucane z powodu konfiguracji DMARC. Mamy tu piękną kaskadę: backup failed, alarm failed, a organizacja nie zauważyła obu.
Replika nie była już kopią ratunkową
Secondary zostało wyczyszczone podczas próby naprawienia replikacji. W chwili usunięcia primary nie istniała więc gotowa kopia, na którą można było przełączyć ruch. Replikacja jest przydatna do wysokiej dostępności, ale nie zastępuje niezależnego backupu odpornego na błąd operatora.
Snapshoty były potencjalną drogą, ale nie były skonfigurowane
GitLab przyznał, że Azure disk snapshots nie były aktywne dla tych baz. Organizacja zakładała, że inne procedury backupowe są wystarczające. Dopiero awaria pokazała, że niezależne warstwy ochrony istnieją bardziej na diagramie niż w rzeczywistości.
Restore był bardzo wolny
Zespół musiał wykorzystać kopię stagingową hostowaną na wolniejszych maszynach w innym regionie. Recovery trwał kilkanaście godzin. To przypomina, że RTO zależy nie od samego istnienia backupu, lecz od szybkości realnego odtwarzania na produkcyjnej skali.
Backup, którego nie odtwarzasz, nie jest potwierdzonym backupem
GitLab po incydencie wyciągnął wnioski dotyczące ownershipu, automatyzacji i regularnego testowania restore. To jedna z najbardziej uniwersalnych lekcji administracji systemami. Monitorowanie procesu tworzenia kopii nie wystarcza; trzeba okresowo wykazać, że kopia faktycznie pozwala uruchomić usługę. Najlepszym testem jest regularny game day: zespół dostaje scenariusz utraty bazy i musi odtworzyć usługę z kopii w zadanym czasie. Taki test ujawnia brak haseł, niekompletne instrukcje i wolne transfery zanim realny incydent zrobi to za firmę.
Replikacja, backup i archiwum chronią przed różnymi rodzajami awarii
Replika jest świetna, gdy psuje się dysk lub serwer: można szybko przełączyć ruch na kopię o podobnym stanie. Jest jednak słabą ochroną przed błędnym `DELETE`, korupcją logiczną albo złośliwą zmianą, bo ten sam stan może natychmiast zostać zreplikowany. Backup point-in-time pozwala wrócić do wcześniejszego momentu, lecz jego odtworzenie trwa dłużej. Archiwum może być jeszcze bardziej izolowane i przechowywane przez miesiące, ale nie nadaje się do szybkiego failoveru. GitLab w jednym incydencie pokazał różnicę między tymi pojęciami. Prawdziwa strategia disaster recovery zwykle potrzebuje kilku warstw: szybkiej repliki, niezależnego backupu, testowanego restore oraz kopii poza tym samym failure domain. Samo zdanie „mamy kopię zapasową” jest zbyt ogólne, by ocenić odporność systemu. Ważny jest również cel recovery, wyrażony jako RPO i RTO. RPO mówi, ile danych organizacja akceptuje utracić, a RTO — jak długo usługa może być niedostępna. Dopiero test restore pokazuje, czy realny backup spełnia te liczby; sama obecność pliku w magazynie niczego jeszcze nie dowodzi. Kopia zapasowa powinna być też chroniona przed tym samym kontem i tym samym błędem, który może uszkodzić produkcję. Im bardziej niezależna jest administracyjnie i fizycznie, tym większa szansa, że przetrwa masową pomyłkę operatora.