Hlavní navigace

GitLab měl pět zálohovacích mechanismů, nefungoval ani jeden

Petr Krčmář

Že je potřeba zálohovat, ví každý admin a snad to tuší i každý uživatel. Případ velkého výpadku služby GitLab ale ukazuje, že je potřeba zálohy řešit pořádně, koncepčně a hlavně je průběžně hlídat.

GitLab má velký výpadek, služba nefunguje a správci se snaží zachránit situaci. Výpadky se občas stávají, dokonce se i někdy stává, že si spletete server a smažete si data někde jinde. V tomto případě správce v Nizozemí omylem smazal databázi na produkčním serveru, ze kterého měla proběhnout replikace. Jedním příkazem tak služba přišla o 300 GB uživatelských dat.

Nepříjemné je to hlavně pro velké množství uživatelů, ale Git je z principu decentralizovaný, takže není problém chvíli počkat a commitovat lokálně nebo repozitář dočasně přesunout jinam.

Známý mi nedávno vyprávěl, jak se snažil dokola restartovat server, ale nedařilo se mu to. Pak k němu i dojel a skutečně to pořád nedělalo, co chtěl. Až po nějaké chvíli zjistil, že má v telefonu hromadu nepřijatých hovorů od šéfa a zákazníků. Restartoval totiž omylem produkční stroj a divil se, že ten jeho stále žije svým životem. Kdo to nezažil, není admin.

Na případu GitLab je pozoruhodný jiný fakt: totiž že měli pět různých zálohovacích mechanismů a pět z nich selhalo. Ani jeden nefungoval správně. Výsledkem je smazaná produkční databáze, ke které neexistuje snadno dostupná a dostatečně čerstvá záloha. Databáze obsahovala například hlášení chyb (issues) a merge requests. Samotné gitovské repozitáře a soubory s wiki poškozeny nebyly.

  1. LVM snapshoty se automaticky dělaly jen jednou za 24 hodin. Šest hodin před výpadkem byl jeden udělán manuálně.
  2. Klasické zálohy probíhaly také jednou za 24 hodin, ale není jasné, kam byly ukládány. Zálohy na S3 jsou prázdné.
  3. Snapshoty v Azure byly zapnuté pro NFS disky, ale už ne pro databázové úložiště.
  4. Záloha pomocí pg_dump také selhávala, protože se omylem pouštěl PostgreSQL verze 9.2 místo správné 9.6. Proces tak potichu selhával a nikdo si toho nevšiml.
  5. Replikační procedura byla prováděna nahodile napsanými shellovými skripty bez dokumentace.

Zároveň se objevily další problémy, jako že byly špatně zpracovány webhooky, takže pravděpodobně jsou součástí záloh a budou ztraceny a podobně. Postupně se daří staré zálohy obnovovat, ale není jasné, jak dlouho to bude trvat ani kolik toho bude nakonec ztraceno. V každém případě budou data minimálně šest hodin stará.

GitLab se rozhodl pro radikální změnu, v budoucnu poběží na Ceph clusteru a to by jej mělo činit odolnějším proti podobným problémům. Uvidíme. V každém případě to opět ukazuje na fakt, že zálohy je potřeba nejen dělat (třeba pětkrát), ale hlavně kontrolovat jejich funkčnost.

Našli jste v článku chybu?
1. 2. 2017 12:34

Je trapne to opakovat, ale asi je to potreba: je vic nez vhodne si dat periodicky ukol zkontrolovat zalohy. A v ramci kontrol se hodi jednou za cas udelat i cvicnou obnovu (coz je trebas v domacich podminkach dost opruz, ale na druhou stranu v cloudu by to mela byt trivialita).