Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
GitLab skasował przypadkiem produkcyjną bazę… a backup nie działa
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)
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
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.
dla ciekawskich: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
Wypadadałoby mocniej zaznaczyć, że usunięto tylko dane w bazie, a nie repozytoria. Pliki w repozytoriach są bezpieczne.
Prawdopodobnie tak jest – wrzuciłem info z linkiem do ich wpisu na Twitterze o tym.
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.
Śmiech przez łzy: http://howfuckedismydatabase.com/
Team Gitlaba jest na żywo https://twitter.com/gitlabstatus
+ stream i livechat na żywo na yt
Tylko popcornu brakuje, taka akcja – jest co i gdzie oglądać ;)
GitLab Live Stream
https://youtu.be/nc0hPGerSd4
Już odbudowali. 2min temu tweetnęli info
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
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ę.
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
Czemu tylko 480p? :p dziwnie się ogląda nie w HD. :)
rtyui
Wczoraj stworzyłem repozytorium i wykonałem dwa commity. Dzisiaj nie istnieje. Więc chyba jednak dotyczy repo.