GitLab.com leży, i na razie ciężko powiedzieć kiedy uda się ponownie uruchomić stronę/serwis, bo administratorzy cały czas walczą by przywrócić dane z kopii zapasowej…
GitLab.com Database Incident
Postanowiłem, że nie będę się silił na jakiś „podtytuł” w naszym języku, bo wersja oryginalna (po angielsku) chyba idealnie oddaje problem.
I tak można napisać, że była sobie baza danych na serwerze produkcyjnym, i jej nie ma – prawdopodobnie w trakcie walki z niespotykanie dużym obciążeniem serwisu ktoś nieopatrznie skasował pliki bazy danych (PostrgeSQL) za pomocą komendy:
rm -Rvf
Komenda jest na tyle skuteczna, że raczej od odzyskiwaniu danych można zapomnieć:
Sid: try to undelete files?
CW: Not possible! `rm -Rvf`
Sid: OK
Oczywiście ratunkiem w takim przypadku są kopie zapasowe, ale o ile w przypadku „zwykłych stron” sama kopia zajmuje relatywnie niewiele, a tym samym jej odtworzenie nawet z serwera umieszczonego na drugim krańcu świata nie powinno długo trać, to w przypadku takich „molochów” jest to już operacja zdecydowanie bardziej złożona i czasochłonna.
Przy okazji warto pochwalić ekipę za otwartość w tym temacie – w udostępnionym dokumencie cały czas, na bieżąco możemy śledzić przebieg prac nad przywróceniem serwisu (przy okazji może z tego powstać fajny materiał do analizy).
Trzymam kciuki by ekipie GitLab.com udało się jak najszybciej uruchomić stronę, zwłaszcza że zapewne jest to w interesie nie tylko ich, ale i użytkowników serwisu (na szczęście problem dotyczy samej bazy danych i repozytoria są nienaruszone).
- Zero Trust od Cloudflare, czyli prosty i bezpieczny sposób na dostęp do lokalnych zasobów z zewnątrz, bez publicznego adresu IP i otwierania portów na routerze - 1970-01-01
- Home Assistant i integracja z IMGW-PIB, czyli tworzymy automatyzację z powiadomieniami bazując na sensorach zagrożenie i alarm powodziowy - 1970-01-01
- Home Assistant 2024.9 i kolejne przydatne nowości w widoku „sekcje”, dzięki którym jeszcze lepiej można dopasować wygląd - 1970-01-01