GitLab.com przypadkowo usunął jedną z baz danych. Zawiodły kopie zapasowe

Administracja GitLab.com na długo zapamięta dzisiejszą datę. Popularny serwis umożliwiający zarządzanie repozytoriami napotkał serię problemów, które poskutkowały niestety nie tylko przerwą w dostępności, ale także utratą danych. Oczywiście serwis posiadał odpowiedni harmonogram kopii zapasowych. Problem w tym, że i on zawiódł.

We accidentally deleted production data and might have to restore from backup. Google Doc with live notes https://t.co/EVRbHzYlk8

— GitLab.com Status (@gitlabstatus) 1 lutego 2017Podczas replikacji jednej z baz danych, administrator użył komendy rm -rf na folderze, który zawierał 300 GB danych. Zanim wstrzymał proces pozostało z nich ledwie 4,5 GB. Wśród usuniętych plików nie znalazły się repozytoria. Nie oznacza to jednak, że problem należy bagatelizować – administracja serwisu czym prędzej przystąpiła do przywracania kopii zapasowych, zachowując przy tym pełną transparentność, relację można było nawet śledzić na YouTube. Jak można się spodziewać, informacje o utraconych danych wywoływały sporo emocji.

Obok relacji wideo, administracja GitLab.com na bieżąco informuje o postępach w pracach w osobnym dokumencie. Podsumowuje go stwierdzenie, że ze wszystkich pięciu metod dokonywania kopii zapasowych poprawnie nie zadziałała ani jedna. W jednym przypadku nieznane jest miejsce zapisu kopii, migawki zapisywane w chmurze Azure są jedynie kopią serwerów NFS, a nie baz danych, zaś na serwerach Amazon S3, kopii nie ma w ogóle.

Wszystko, czym w tej chwili dysponuje GitLab to migawka LVM, zapisana ręcznie przez administrację 6 godzin przed usunięciem danych. Można tutaj mówić o szczęściu, gdyż konfiguracja przewidywała tworzenie kopii w dobowych interwałach. Aktualnie trwają prace nad jej przywróceniem, jednak sam winny stwierdził, że lepiej, aby niczego już dziś nie uruchamiał z sudo.

Oczywiście takich zaniedbań w kwestii sprawności tworzenia kopii zapasowych nie sposób uzasadnić. Zwłaszcza że w zeszłym roku Pablo Carranza deklarował całkowite porzucenie dotychczasowej chmurowej infrastruktury dostarczanej przez firmy trzecie na rzecz własnego systemu kopii zapasowych. Z całą pewnością od dziś prace nad nim będą przebiegały znacznie sprawniej.