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

Backup i Restore gitLab.com

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 gitLab.com

Jest to prawdziwe wyzwanie dla organizacji, które chcą lepiej rozumieć procesy zachodzące we własnej firmie, chcą przewidywać najbliższe wydarzenia, reagować w obliczu ryzyka oraz wykorzystywać nadarzające się szanse. Jeżeli Twoja firma nie posiada odpowiedniego oprogramowania – czas najwyższy, aby to zmienić.

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.

  • LVM snapshots – team-member-1 zrobił jeden z nich ręcznie na około 6h przed wystąpieniem awarii
    • Jest ok, ale odtworzenie go oznacza utratę danych z sześciu godzin.
  • Backupy logiczne – pg_dump – co 24h
    • 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ć.
  • Snapshoty dysków w Azure
    • Jednak były robione wyłącznie dla serwerów NFS, nie dla bazy…
  • Backup do Amazon S3
    • Tutaj też pusto…
  • Replikacja na staging
    • 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