Сервис для хранения кода GitLab случайно удалил почти 300 ГБ данных из-за ошибки сисадмина Статьи редакции

Сервис для хранения кода GitLab оказался недоступен для пользователей с вечера 31 января после того, как системный администратор компании случайно стёр около 300 ГБ из базы данных компании. Об этом пишет The Register.

Из-за ошибки оказалась стёрта база, в которой содержались запросы на изменение документации и кода проектов пользователей, при этом их репозитории (хранилища) остались нетронутыми. Вскоре после инцидента представители GitLab стали публиковать всю информацию о восстановлении базы.

Сисадмин из Нидерландов, из-за которого возникла проблема, занимался копированием базы с одного сервера на другой и по ошибке запустил удаление данных с основного сервера. Когда этот процесс был остановлен, нетронутыми осталось только 4,5 ГБ данных.

В GitLab отметили, что в этом случае не помогла ни одна из пяти существующих в компании систем для хранения бэкапов: например, в одном из случаев процедура сохранения данных срабатывала с ошибкой, из-за чего бэкап не создавался. Представители сервиса заметили, что у них не было системы оповещения об ошибках при создании бэкапов.

В распоряжении GitLab оказался один из бэкапов, созданный вручную примерно за шесть часов до инцидента, и теперь компания восстанавливает данные с его помощью.

GitLab создана в 2014 году украинским предпринимателем Дмитрием Запорожцем, штаб-квартира компании расположена в Сан-Франциско. По данным CrunchBase, за всё время существования она привлекла около $25,6 млн.

GitLab конкурирует с другими платформами, такими как GitHub и Atlassian, однако у неё есть дополнительное преимущество — она бесплатно распространяет свои инструменты для хранения кода, что позволяет другим организациям построить собственные репозитории на основе систем GitLab, добавив необходимые для себя функции, отмечает TechCrunch.

0
35 комментариев
Написать комментарий...
Валерий Алексеев

По-любому просто бутылку текилы случайно поставил на кнопку Delete, если вы понимаете о чём я...

Ответить
Развернуть ветку
Питух Хохлятско Габонский

и случайно сел на нее

Ответить
Развернуть ветку
Pablo Artemov

Такая же мысль возникла )))

Ответить
Развернуть ветку
Максим Федоров

Дудочник же :)

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Kondin Dmitriy

Представляю лицо этого сисадмина, когда удаление закончилось )

Ответить
Развернуть ветку
Юрий Ковалёв
Ответить
Развернуть ветку
Игнат Смирнов

Сисадмина кастрировали?

Ответить
Развернуть ветку
Злой Полушубок

Начать надо с CIO. Потому что: "у них не было системы оповещения об ошибках при создании бэкапов".

Ответить
Развернуть ветку
Alexander Pavlovskiy

Данные просрал не сисадмин (которого у GitLab просто нету), а разработчик ПО, который понятия не имеет о таких вещах как "отказоустойчивость", "кластеризация" и другие страшные, но очень полезные слова.
Оригинал: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

VC в своем репертуаре. Слышу звон, не знаю где он.

Ответить
Развернуть ветку
Злой Полушубок

А у них разве не DevOps?

Ответить
Развернуть ветку
Alexander Pavlovskiy

Именно он. И в данном, конкретном случае, он показал себя во всей красе. DevOps, в отличии от ITIL\SM отличается как раз тем, что в первую очередь он направлен на "удобное" взаимодействие внутри команды и стремится сделать работу быстро (не значит качественно).
Проблема DevOps как раз в том, что каждый Java-программист считает себя сервисменеджером, таковым не являясь.

Ответить
Развернуть ветку
Alexander Pavlovskiy

upd:
Например "Java-программист". Ничего не имею против них :)

Ответить
Развернуть ветку
Max Bourinov

CIO виноват :-)
Не был правильно построен процесс тестирования софта.
Не проверяли такие кейсы.
Не было стресс тестов :-)

Ответить
Развернуть ветку
Егор Шарапов

Ну и классика

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Птиц

Ответственный за бэкапы в GitLab

Ответить
Развернуть ветку
Alex Markelov

Сколько раз уже говорилось, что все эти ваши бекапы бесполезны без проверенного механизма их восстановления.

Ответить
Развернуть ветку
Alexander Pavlovskiy

Бесполезны люди которые не умеют с ними работать. Бэкапы нормально работают.

Ответить
Развернуть ветку
Антон Соколов

После прочтения перепроверил все у себя.

Ответить
Развернуть ветку
Vitaly

Ни одна из пяти, Карол

Ответить
Развернуть ветку
Ivan Prishvin

Реально сижу и жду

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Марат Закарьяев

GitHub(пока не запрещённая в России организация )взяла на себя ответственность за данный инцидент

Ответить
Развернуть ветку
Alexander Pavlovskiy

Удалил не сисадмин, а разработчик ПО. Откуда разрабу известны такие вещи как "отказоустойчивость", "кластеризация", "эвенталерты" и другие страшные, но полезные слова.

Оригинал: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

Ответить
Развернуть ветку
Dima Dyakonov

люди делятся на 3 типа:
кто еще не делает бэкапы
кто их уже делает
и те, кто их действительно уже делает.

Ответить
Развернуть ветку
Ilya Gusev
Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Andrey Petrov

Кому интересен Live - https://www.youtube.com/watch?v=nc0hPGerSd4

Ответить
Развернуть ветку
Valentin Dombrovsky

Пока можно помедитировать на то, как его поднимают.

Ответить
Развернуть ветку
Alexander Orlovsky

ошибка была совершена на фоне усталости, это всем кто выше пишет что инцидент произошел только потому что работу работал DevOps/разработчик, якобы ничего не знающий о "кластеризации" (при чем тут кластеризация, вообще непонятно)

Ответить
Развернуть ветку
Roman Maximov

спонсор ошибки админа github

Ответить
Развернуть ветку
Anton Barhan

И отличия Российского и Европейского менталитета во всей красе.
Ну либо второе сарказм)))

Ответить
Развернуть ветку
Знаменитый меч

Дешёвый пиар никому не нужного сервиса, когда есть битбакет и гитхаб.

Небось ничего и не роняли, а тянули пивко - твитя и стримя на ютубе.

5 систем бэкапов не сработало, а что не 10.

Ответить
Развернуть ветку
Arseny Yankovsky

Слабое понимание отличий между тремя перечисленными сервисами.

Ответить
Развернуть ветку
Виталий Подольский

GitLab хорош для организации качественного сервера корпоративных репов на своем сервере. В легкости интеграции ему пока равных нет. Хорошая поддержка и регулярные обновления.

Из минусов, слишком тормознутая "вебморда", напрягает работа с большим количеством репов и их веток. А админ, "засланный казачок" от конкурентов )))

Ответить
Развернуть ветку
Dmitry Makashov

Sid: try to undelete files?
CW: Not possible! `rm -Rvf` Sid: OK
=)))))
YP thinks that perhaps pg_basebackup is being super pedantic about there being an empty data directory, decides to remove the directory. After a second or two he notices he ran it on db1.cluster.gitlab.com, instead of db2.cluster.gitlab.com
2017/01/31 23:27 YP - terminates the removal, but it’s too late. Of around 310 GB only about 4.5 GB is left...

=))))
Упс, удалил с мастера а не со слейва.

Ответить
Развернуть ветку
Denis Denis

Прочитал как GitHub :)

Ответить
Развернуть ветку
Читать все 35 комментариев
null