«id =» main «> Поделиться Практический пример на примере громкого инцидента на & nbsp; GitLab.com.
Как вы знаете, случаются ошибки, и случаются даже опытные люди в своей отрасли. Тот факт, что , в отличие от многих компаний, здесь не было попытки что-то скрыть под ковром, наоборот: был обнародован и описан точный ход поломки вместе с описанием ошибок, допущенных сотрудниками Восстановление базы данных postgres.
Журнал сбоев резервного копирования и восстановления
18:00 & nbsp; Спамеры атаковали систему, создав большое количество & nbsp;; фрагменты.
21:00 Через три часа проблема обострилась — регистрация на базу стала невозможной. К счастью, IP-адреса спамера были заблокированы, а учетная запись пользователя была удалена.
22: 00 Репликация остановлена из-за огромного скачка в записях, которые не удалось обработать репликой. Поэтому реплика была синхронизирована с помощью инструмента & nbsp; pg_basebackup.
23:00 & nbsp; Из-за того, что & nbsp; pg_basebackup & nbsp; ничего не делает, сотрудник GitLab, описанный в блоке как & nbsp; team-member-1, решает удалить каталог PGDATA. Несмотря на то, что он пуст, предполагается, что его присутствие мешает воспроизведению. Через секунду или две член команды-1 замечает, что вместо выполнения команды на db2.cluster.gitlab.com (реплика) он запустил ее на db1.cluster.gitlab.com (производственная).
< p>, 23:27 Слишком поздно. Член команды 1 прерывает удаление, но из примерно 300 ГБ данных осталось только 4,5 ГБ.
Что ж, случаются ошибки, хорошо, что есть резервная копия!
К счастью, в GitLab настроено целых пять типов резервных копий.
Снимки LVM — & nbsp; team-member-1 & nbsp; один из них был создан вручную примерно за 6 часов до сбоя Логические резервные копии — & nbsp; pg_dump & nbsp; — каждые 24 часа Снимки состояния диска в Azure Backup to Amazon S3 Replication on & nbsp ; staging Просто потеряйте шесть данных, восстановите их часами. Хммм, а где они хранятся? К счастью, член команды-2 нашел файлы. Однако оказалось, что каждая из них имеет длину всего несколько байт. Team-member-3 заявил, что двоичный файл 9.2 использовался для резервного копирования базы данных версии 9.6 — поэтому ни одна из резервных копий не могла работать, однако они были сделаны только для серверов NFS, а не для базы данных … Здесь тоже пусто … он очень нестабилен, подвержен ошибкам, состоит из случайных сценариев bash и плохо документирован. Final
Было решено восстановить данные из моментального снимка, сделанного за 6 часов до сбоя. По оценкам, около 5000 проектов, 5000 комментариев и 700 пользователей были потеряны в результате сбоя.
В статье, опубликованной GitLab, вы можете найти подробное описание событий, включая шаги, которые были предприняты место после восстановления базы данных. Очень интересным и информативным материалом является анализ причин сбоев и улучшений, внесенных в процесс восстановления данных.
Мы также рекомендуем вам следить за нашим блогом. Вскоре появятся статьи о лучших программах для создания и восстановления резервных копий и с описанием широко понятных «лучших практик» создания и восстановления резервных копий.