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).
- Mały dron, duże zamieszanie, czyli seria DJI Mini i zabawa w klasy (unijne klasy dla dronów) z EASA i użytkownikami - 1970-01-01
- Opcja “restore_from_flash”, czyli sposób na zapamiętywanie ustawień w ESPHome na układach ESP8266 - 1970-01-01
- Blokowe szablony powiadomień (block notice) w WooCommerce, nawet w klasycznych motywach - 1970-01-01