Gitlab «лежить», база знищена (відновлюється)

imageВчора, 31 січня, сервіс Gitlab випадково знищив свою продакшн базу даних (самі гіт-репозиторії не постраждали).

Справа була приблизно так.

З якоїсь причини стала відставати hot-standby репліка бази (PostgreSQL) (репліка була єдина). Співробітник gitlab якийсь час намагався вплинути на ситуацію різними налаштуваннями і т. д, потім вирішив все стерти і налити репліку заново. Намагався стерти папку з даними на репліці, але переплутав сервера і стер на майстра (зробив rm -rf на db1.cluster.gitlab.com замість db2.cluster.gitlab.com).

Цікаво, що в системі було 5 різних видів бекапів/реплік, і нічого з цього не спрацювало. Був лише LVM snapshot, зроблений випадково за 6 годин до падіння.

Ось наводжу скорочену цитату з їх документа. Виявлені проблеми:

1) LVM snapshots are only by default taken once every 24 hours.
2) Regular backups seem to also only be taken once per 24 hours, though YP has not yet been able to figure out where they are stored.
3) Disk snapshots in Azure are enabled for the NFS server, but not for the DB servers.
4) The synchronisation process removes webhooks once it has synchronised data to staging. Unless we can pull these from a regular backup from the past 24 hours they will be lost
5) The replication procedure is super fragile, prone to error, relies on a handful of random shell scripts, and is badly documented
6) Our backups to S3 apparently don't work either the bucket is empty
7) We don't have solid alerting/paging for when backups fails, we are seeing in this the dev host too now.
Таким чином, роблять висновок gitlab, з 5 бекапів/технік реплікації нічого не спрацювало надійно і як треба => тому йде відновлення із випадково зробленої 6-годинного бекапу

Ось повний текст документа
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.