Backup i Restore – dlaczego jedno nie może istnieć bez drugiego

Backup i Restore

Studium przypadku na przykładzie głośnego incydentu w GitLab.com.

Jak wiadomo pomyłki się zdarzają, w dodatku zdarzają się nawet doświadczonym w swojej branży ludziom. Historia, którą opisuję w tym artykule wyróżnia się tym, że inaczej niż w wypadku wielu firm tutaj nie próbowano zamiatać niczego pod dywan, wręcz przeciwnie: dokładny przebieg awarii, wraz z opisem błędów popełnionych przez pracowników został upubliczniony i opisany. Jest to szczególnie cenny materiał dla wszystkich zastanawiających się nad polityką backupu i odtwarzania postgresowej bazy danych.

Backup i Restore

Dziennik awarii

Godz. 18:00 Spamerzy zaatakowali system generując dużą liczbę snippetów.

Godz. 21:00 Po trzech godzinach problem nabrał na sile – zapisy do bazy stały się niemożliwe. Na szczęście udało się zablokować adresy IP spamerów oraz usunięto konto użytkownika.

Godz. 22:00 Replikacja została zatrzymana z powodu olbrzymiego skoku zapisów, które nie zdążyły zostać przetworzone przez replikę. Przystąpiono więc do synchronizacji repliki za pomocą narzędzia pg_basebackup.

Godz. 23:00 W związku z tym, że pg_basebackup wisi nie robiąc nic, pracownik GitLab-u opisywany na bloku jako team-member-1, postanawia usunąć katalog PGDATA. Mimo, że jest pusty, przypuszcza, że sama jego obecność przeszkadza odtwarzaniu. Po sekundzie lub dwóch team-member-1 zauważa, że zamiast wydać polecenie na db2.cluster.gitlab.com (replika) uruchomił je na db1.cluster.gitlab.com (produkcja).

Godz, 23:27 Jest już za późno. Team-member-1 przerywa wykonywanie usuwania, ale z około 300GB danych zostało już tylko 4.5GB.

No cóż, błędy się zdarzają, dobrze, że jest backup!

Na szczęście w GitLab-ie skonfigurowano aż pięć rodzajów backupów.

1. LVM snapshots – team-member-1 zrobił jeden z nich ręcznie na około 6h przed wystąpieniem awarii

2. Backupy logiczne – pg_dump – co 24h

3. Snapshoty dysków w Azure

4. Backup do Amazon S3

5. Replikacja na staging

ad 1). Jest ok, ale odtworzenie go oznacza utratę danych z sześciu godzin.
ad 2). Hmmm, ale gdzie są odkładane? Na szczęście team-member-2 odnalazł pliki. Okazało się jednak, że każdy z nich ma zaledwie kilka bajtów. Team-member-3 stwierdził, że binarka z wersji 9.2 była używana do robienie kopii zapasowej dla bazy, która jest w wersji 9.6 – w związku z tym żaden z backupów nie mógł się udać.
ad 3). Jednak były robione wyłącznie dla serwerów NFS, nie dla bazy…
ad 4). Tutaj też pusto…
ad 5). jest bardzo niestabilna, podatna na błędy, składa się z losowych skryptów bashowych i jest źle udokumentowana.

Finał

Zdecydowano się na odtworzenie danych ze snapshotu wykonanego na 6h przed awarią. Szacuje się, że w wyniku awarii utracono około: 5000 projektów, 5000 komentarzy i 700 użytkowników.

W artykule opublikowanym przez GitLab można znaleźć szczegółowy opis wydarzeń wraz z krokami, które nastąpiły już po odtworzeniu bazy. Bardzo ciekawym i pouczającym materiałem jest analiza przyczyn awarii oraz wprowadzonych usprawnień w procesie odtwarzania danych.

Zachęcamy również do śledzenia naszego bloga. Już niedługo pojawią się artykuły dotyczące najlepszych programów do wykonywania i odtwarzania backupu oraz opisujące szeroko rozumiane „Dobre praktyki” wykonywania i odtwarzania kopii zapasowych.

Tags

top