Из-за ошибки оказалась стёрта база, в которой содержались запросы на изменение документации и кода проектов пользователей, при этом их репозитории (хранилища) остались нетронутыми. Вскоре после инцидента представители GitLab стали публиковать всю информацию о восстановлении базы.
Сисадмин из Нидерландов, из-за которого возникла проблема, занимался копированием базы с одного сервера на другой и по ошибке запустил удаление данных с основного сервера. Когда этот процесс был остановлен, нетронутыми осталось только 4,5 ГБ данных.
В GitLab отметили, что в этом случае не помогла ни одна из пяти существующих в компании систем для хранения бэкапов: например, в одном из случаев процедура сохранения данных срабатывала с ошибкой, из-за чего бэкап не создавался. Представители сервиса заметили, что у них не было системы оповещения об ошибках при создании бэкапов.
В распоряжении GitLab оказался один из бэкапов, созданный вручную примерно за шесть часов до инцидента, и теперь компания восстанавливает данные с его помощью.
GitLab создана в 2014 году украинским предпринимателем Дмитрием Запорожцем, штаб-квартира компании расположена в Сан-Франциско. По данным CrunchBase, за всё время существования она привлекла около $25,6 млн.
GitLab конкурирует с другими платформами, такими как GitHub и Atlassian, однако у неё есть дополнительное преимущество — она бесплатно распространяет свои инструменты для хранения кода, что позволяет другим организациям построить собственные репозитории на основе систем GitLab, добавив необходимые для себя функции, отмечает TechCrunch.
Валерий Алексеев
По-любому просто бутылку текилы случайно поставил на кнопку Delete, если вы понимаете о чём я...
Питух Хохлятско Габонский
Валерийи случайно сел на нее
Pablo Artemov
ВалерийТакая же мысль возникла )))
Максим Федоров
ВалерийДудочник же :)
Комментарий удален
Kondin Dmitriy
Представляю лицо этого сисадмина, когда удаление закончилось )
Юрий Ковалёв
KondinИгнат Смирнов
Сисадмина кастрировали?
Злой Полушубок
ИгнатНачать надо с CIO. Потому что: "у них не было системы оповещения об ошибках при создании бэкапов".
Alexander Pavlovskiy
Данные просрал не сисадмин (которого у GitLab просто нету), а разработчик ПО, который понятия не имеет о таких вещах как "отказоустойчивость", "кластеризация" и другие страшные, но очень полезные слова.
Оригинал: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
VC в своем репертуаре. Слышу звон, не знаю где он.
Злой Полушубок
AlexanderА у них разве не DevOps?
Alexander Pavlovskiy
ЗлойИменно он. И в данном, конкретном случае, он показал себя во всей красе. DevOps, в отличии от ITIL\SM отличается как раз тем, что в первую очередь он направлен на "удобное" взаимодействие внутри команды и стремится сделать работу быстро (не значит качественно).
Проблема DevOps как раз в том, что каждый Java-программист считает себя сервисменеджером, таковым не являясь.
Alexander Pavlovskiy
Alexanderupd:
Например "Java-программист". Ничего не имею против них :)
Max Bourinov
AlexanderCIO виноват :-)
Не был правильно построен процесс тестирования софта.
Не проверяли такие кейсы.
Не было стресс тестов :-)
Егор Шарапов
Ну и классика
Комментарий удален
Птиц
Ответственный за бэкапы в GitLab
Alex Markelov
Сколько раз уже говорилось, что все эти ваши бекапы бесполезны без проверенного механизма их восстановления.
Alexander Pavlovskiy
AlexБесполезны люди которые не умеют с ними работать. Бэкапы нормально работают.
Антон Соколов
После прочтения перепроверил все у себя.
Vitaly
Ни одна из пяти, Карол
Ivan Prishvin
Реально сижу и жду
BearStrikesBack
Пусть напишут Дропбоксам, они восстановят.
Марат Закарьяев
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
И отличия Российского и Европейского менталитета во всей красе.
Ну либо второе сарказм)))
Ruslan Rugoals
Дешёвый пиар никому не нужного сервиса, когда есть битбакет и гитхаб.
Небось ничего и не роняли, а тянули пивко - твитя и стримя на ютубе.
5 систем бэкапов не сработало, а что не 10.
Arseny Yankovsky
RuslanСлабое понимание отличий между тремя перечисленными сервисами.
Виталий Роко
RuslanGitLab хорош для организации качественного сервера корпоративных репов на своем сервере. В легкости интеграции ему пока равных нет. Хорошая поддержка и регулярные обновления.
Из минусов, слишком тормознутая "вебморда", напрягает работа с большим количеством репов и их веток. А админ, "засланный казачок" от конкурентов )))
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 :)