Из-за ошибки оказалась стёрта база, в которой содержались запросы на изменение документации и кода проектов пользователей, при этом их репозитории (хранилища) остались нетронутыми. Вскоре после инцидента представители GitLab стали публиковать всю информацию о восстановлении базы.
Сисадмин из Нидерландов, из-за которого возникла проблема, занимался копированием базы с одного сервера на другой и по ошибке запустил удаление данных с основного сервера. Когда этот процесс был остановлен, нетронутыми осталось только 4,5 ГБ данных.
В GitLab отметили, что в этом случае не помогла ни одна из пяти существующих в компании систем для хранения бэкапов: например, в одном из случаев процедура сохранения данных срабатывала с ошибкой, из-за чего бэкап не создавался. Представители сервиса заметили, что у них не было системы оповещения об ошибках при создании бэкапов.
В распоряжении GitLab оказался один из бэкапов, созданный вручную примерно за шесть часов до инцидента, и теперь компания восстанавливает данные с его помощью.
GitLab создана в 2014 году украинским предпринимателем Дмитрием Запорожцем, штаб-квартира компании расположена в Сан-Франциско. По данным CrunchBase, за всё время существования она привлекла около $25,6 млн.
GitLab конкурирует с другими платформами, такими как GitHub и Atlassian, однако у неё есть дополнительное преимущество — она бесплатно распространяет свои инструменты для хранения кода, что позволяет другим организациям построить собственные репозитории на основе систем GitLab, добавив необходимые для себя функции, отмечает TechCrunch.
По-любому просто бутылку текилы случайно поставил на кнопку Delete, если вы понимаете о чём я...
и случайно сел на нее
Такая же мысль возникла )))
Дудочник же :)
Комментарий удален модератором
Представляю лицо этого сисадмина, когда удаление закончилось )
Сисадмина кастрировали?
Начать надо с CIO. Потому что: "у них не было системы оповещения об ошибках при создании бэкапов".
Данные просрал не сисадмин (которого у GitLab просто нету), а разработчик ПО, который понятия не имеет о таких вещах как "отказоустойчивость", "кластеризация" и другие страшные, но очень полезные слова.
Оригинал: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
VC в своем репертуаре. Слышу звон, не знаю где он.
А у них разве не DevOps?
Именно он. И в данном, конкретном случае, он показал себя во всей красе. DevOps, в отличии от ITIL\SM отличается как раз тем, что в первую очередь он направлен на "удобное" взаимодействие внутри команды и стремится сделать работу быстро (не значит качественно).
Проблема DevOps как раз в том, что каждый Java-программист считает себя сервисменеджером, таковым не являясь.
upd:
Например "Java-программист". Ничего не имею против них :)
CIO виноват :-)
Не был правильно построен процесс тестирования софта.
Не проверяли такие кейсы.
Не было стресс тестов :-)
Ну и классика
Комментарий удален модератором
Ответственный за бэкапы в GitLab
Сколько раз уже говорилось, что все эти ваши бекапы бесполезны без проверенного механизма их восстановления.
Бесполезны люди которые не умеют с ними работать. Бэкапы нормально работают.
После прочтения перепроверил все у себя.
Ни одна из пяти, Карол
Реально сижу и жду
Комментарий недоступен
GitHub(пока не запрещённая в России организация )взяла на себя ответственность за данный инцидент
Удалил не сисадмин, а разработчик ПО. Откуда разрабу известны такие вещи как "отказоустойчивость", "кластеризация", "эвенталерты" и другие страшные, но полезные слова.
Оригинал: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
люди делятся на 3 типа:
кто еще не делает бэкапы
кто их уже делает
и те, кто их действительно уже делает.
Комментарий удален модератором
Комментарий удален модератором
Комментарий удален модератором
Комментарий удален модератором
Комментарий удален модератором
Комментарий удален модератором
Комментарий удален модератором
Кому интересен Live - https://www.youtube.com/watch?v=nc0hPGerSd4
Пока можно помедитировать на то, как его поднимают.
ошибка была совершена на фоне усталости, это всем кто выше пишет что инцидент произошел только потому что работу работал DevOps/разработчик, якобы ничего не знающий о "кластеризации" (при чем тут кластеризация, вообще непонятно)
спонсор ошибки админа github
И отличия Российского и Европейского менталитета во всей красе.
Ну либо второе сарказм)))
Дешёвый пиар никому не нужного сервиса, когда есть битбакет и гитхаб.
Небось ничего и не роняли, а тянули пивко - твитя и стримя на ютубе.
5 систем бэкапов не сработало, а что не 10.
Слабое понимание отличий между тремя перечисленными сервисами.
GitLab хорош для организации качественного сервера корпоративных репов на своем сервере. В легкости интеграции ему пока равных нет. Хорошая поддержка и регулярные обновления.
Из минусов, слишком тормознутая "вебморда", напрягает работа с большим количеством репов и их веток. А админ, "засланный казачок" от конкурентов )))
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...
=))))
Упс, удалил с мастера а не со слейва.
Прочитал как GitHub :)