-15% na nową książkę sekuraka: Wprowadzenie do bezpieczeństwa IT. Przy zamówieniu podaj kod: 10000

GitLab skasował przypadkiem produkcyjną bazę… a backup nie działa

01 lutego 2017, 08:57 | W biegu | komentarzy 14

Roztargniony admin w GitLab przerwał rm -rf na produkcyjnej bazie w momencie gdy z 300GB zostało już tylko 4,5GB.

Niby zdarza się, tylko… backup nie do końca działa. Status walki z incydentem możemy obserwować „na żywo” – GitLab bowiem nie stara się całej sprawy zatuszować tylko w pełni informuje o statusie i postępach:


Sid: try to undelete files?
CW: Not possible! `rm -Rvf` Sid: OK
JEJ: Probably too late, but isn’t it sometimes possible if you make the disk read-only quickly enough? Also might still have file descriptor if the file was in use by a running process according to http://unix.stackexchange.com/a/101247/213510

Proponuję włączyć zatem w swoje procedury testowanie odtworzenia backupu, a sama analiza przypadku może być ciekawym doświadczeniem w tematyce incident response.

Update: 1.02.2017r. 20:24. Incydent wygląda na zażegnany, ale nie bez strat (przy okazji trochę przypadkowo udało się zrealizować backup LVM „tylko” 6h przed incydentem):

±6 hours of data loss
4613 regular projects, 74 forks, and 350 imports are lost (roughly); 5037 projects in total. Since Git repositories are NOT lost, we can recreate all of the projects whose user/group existed before the data loss, but we cannot restore any of these projects issues, etc.
±4979 (so ±5000) comments lost
707 users lost potentially, hard to tell for certain from the Kibana logs
Unconfirmed: loss of all webhooks (there’s a potential snapshot that might allow us to restore them)

Za GitLab trzymamy kciuki tak żeby sytuację jednak udało się w pełni opanować, choć na razie wygląda to ciężko (1.02.2017, 9:23):

GitLab napisał też dodatkowo, że incydent dotyczy bazy danych, nie samych repozytoriów.

–ms

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Radek

    Tak czy inaczej mają jaja żeby nie ściemniać.
    Niestety jest to kolejny przykład żeby nie ufać do końca żadnemu hostingo- czy usługodawcy i trzymać kopie wszystkich rzeczy gdzie indziej.

    Odpowiedz
  2. Michal

    Wypadadałoby mocniej zaznaczyć, że usunięto tylko dane w bazie, a nie repozytoria. Pliki w repozytoriach są bezpieczne.

    Odpowiedz
    • Prawdopodobnie tak jest – wrzuciłem info z linkiem do ich wpisu na Twitterze o tym.

      Odpowiedz
  3. Interfejs GitLaba to taki – za przeproszeniem – pie**olnik, że się nie dziwię takiej pomyłce. Ktoś, kto tworzy tak zakręcony frontend, w backendzie musi mieć analogiczny chaos.

    Odpowiedz
  4. BOfH
    Odpowiedz
  5. BOfH
    Odpowiedz
    • Wit

      Już odbudowali. 2min temu tweetnęli info

      Odpowiedz
      • w dużej mierze tak, ale są jednak a) straty (info w updacie newsa) b) jeszcze Twittują że nie do końca wszystko się posynchronizowało jeszcze

        Odpowiedz
        • Michał

          Wczoraj stworzyłem repo.
          Dzisiaj zniknęło.
          Po próbie push błąd, że remote does not exist.
          Stworzyłem identyczne repo
          Push się udał.

          Ciekawe co zepsuje przywrócenie backupu :D
          Historia commitów (kwadraciki też zniknęły)

          Wydaje mi się, że próbą naprawienia mogą pogorszyć sprawę.

          Odpowiedz
          • Michał

            Ha po stworzeniu identycznego repo, pojawiło się z historią z 31 stycznia.

            Wciąż jednak nie ma tego w historii aktywności i kwadracikach. :D

  6. Tomek

    Czemu tylko 480p? :p dziwnie się ogląda nie w HD. :)

    Odpowiedz
  7. sdfgth

    rtyui

    Odpowiedz
  8. Michał

    Wczoraj stworzyłem repozytorium i wykonałem dwa commity. Dzisiaj nie istnieje. Więc chyba jednak dotyczy repo.

    Odpowiedz

Odpowiedz na Monter