K vývoji dnes samozřejmě používám AI. Kdo ji v roce 2026 ještě nepoužívá, ten je podle mě úplný blázen. Manuálně už dnes prakticky nekóduji, protože mi AI vývoj zrychlila odhadem o 80 % — a to je číslo, které se prostě nedá ignorovat. Takže používání AI jednoznačně doporučuji.
Co mě ale poslední dobou opravdu pobavilo, je něco jiného. Už dlouho jsem na Redditu narážel na ty nechvalně známé nightmare stories — příběhy, kdy někomu AI během pár vteřin smazala celou produkční databázi. Vždycky jsem to bral jako varování, ale zároveň jsem si říkal, že mně se to stát nemůže. Používám totiž výhradně vlajkové modely a všechno mám dobře oddělené. A ono nic. Měsíce, rok+ nic.
Až teď.
Vážná zpráva pro tebe — zastavuji testy
Nedávno jsem přeprogramovával můj blog codedtrip.com — chystám členskou sekci, komentáře, pár novinek a trochu lepší zázemí pro čtenáře. AI si v klidu něco dělala na pozadí, když z ničeho nic — a opravdu z ničeho nic — přiletěla zpráva, nad kterou jsem chvíli jen “čuměl” s otevřenou pusou. Pobavila mě a zároveň trochu vyděsila:
„Vážná zpráva pro tebe — zastavuji testy. Dev DB se během testů vyprázdnila.“
Co se vlastně stalo? Při prvních pokusech o spuštění testů došlo k nešťastné kombinaci špatně nastavené konfigurace a automatického mechanismu, který před testy resetuje databázi. Místo aby se reset provedl proti testovací databázi, spustil se proti dev databázi — a během jediné vteřiny byla celá prázdná.
Všechna aplikační data zmizela. Zůstaly jenom systémové tabulky, ze kterých se dá těžko něco smysluplného poskládat.
Naštěstí se jednalo jen o dev databázi, takže mě to popravdě moc netrápilo. Obnovil jsem ji, spustil znovu migrace, naseedoval data a jelo se dál. Žádný problém, žádná panika. Zajímavá zkušenost do sbírky.
Začernil jsem názby tabulek DB atd. kvůli bezpečnosti.
Ale u těch produkčních databází to legrace není
Dokáži si ale velmi živě představit vývojáře, kteří to takzvaně vibe-kódují, nemají žádný backup, jsou připojení přímo na produkční databázi a takový průšvih je potká naostro. Pokud nemají zálohy, je to prostě v čudu.
A že se to děje? O tom není pochyb. Asi nejznámější případ z poslední doby se odehrál v GitLabu v lednu 2017. Pro ty, kdo tenhle incident neznají: jeden z inženýrů se snažil vyřešit zpoždění replikace mezi primární a replikovanou databází a v rámci opravy chtěl vyčistit datový adresář na replice. Jenže byl přihlášený na primáru. Než to stihl přerušit, z 300 GB živých dat zbylo něco kolem 4,5 GB. GitLab tehdy přišel o šest hodin dat — issues, merge requesty, komentáře, uživatele. A co bylo ještě horší: z pěti nasazených záložních systémů nefungoval pořádně ani jeden. Jediná použitelná záloha byla ta, kterou si ten samý inženýr čirou náhodou udělal ručně šest hodin předtím, když ladil něco jiného. Ironicky tak jeho vlastní chybu zachránila jeho vlastní paranoia. Obnova trvala přes osmnáct hodin a GitLab ji živě streamoval na YouTube — je to dodnes jeden z nejpoučnějších postmortem příběhů v oboru.
A mně se to, bohužel, taky už stalo
U mě samotného se něco podobného, i když naštěstí mimo AI, přihodilo zhruba před dvěma lety.
Dělal jsem v databázovém klientovi nějaký rychlý zásah u projektu Editee. Pod sebou mám vždycky otevřené tři databáze — produkční, stagingovou a dev. Tenkrát to bylo jednodušší rozdělení než dnes, teď máme databáze různě rozštěpené podle služeb. Potřeboval jsem kvůli nějakému problému s platební integrací rychle vyčistit jednu tabulku a dal jsem příkaz na její smazání.
Jenže v rychlosti jsem si nevšiml, že jsem se v klientovi proklikl o jednu záložku vedle — na produkční databázi.
Takže jsem smazal tabulku v produkci.
Naštěstí máme velmi silné zálohování, takže jsme o žádná data nepřišli, ale musel jsem produkční databázi obnovit — a protože máme opravdu velký objem dat, výpadek trval skoro hodinu. Není to otázka jednoho kliknutí. Byla to ale velmi zajímavá a potřebná zkušenost, která mi ještě víc utvrdila jedno pravidlo: zálohujte, zálohujte, zálohujte. A pak ještě jednou zálohujte.
Voda v datovém centru, aneb proč mám na zálohy paranoiu
Moje backup paranoia ale nevznikla kvůli tomuhle. Začala mnohem dřív — a mnohem bolestivěji.
Myslím, že to bylo v roce 2012, tedy je to dnes už skoro 14+ let zpátky. Tehdy jsme měli servery v jednom pražském datacentru Casablanca a v jejich cloud hostingu Big Blue One, které se neustále chvástalo tím, jak mají plně zrcadlenou redundanci — jedna ku jedné replikované do druhého datacentra v Ostravě, takže když jedno datacentrum vypadne, druhé okamžitě přebere provoz. Znělo to nádherně.
Jenže nad datovým centrem byla tělocvična (ano, tělocvična). A v té tělocvičně praskla voda. Voda prosákla stropem do prostor datacentra, zaplavila servery — a ty prostě přestaly fungovat. Obnova jim trvala skoro 14 dní a data nám nakonec neobnovili vůbec. Přišli jsme o všechno, co na těch serverech bylo.
Naštěstí jsem tehdy dva dny před incidentem dělal velkou ruční zálohu (kterou jsem si tehdy dělal pravidelně spíš z intuice než z procesu nebo nějak pravidelně). Strávil jsem celou noc tím, že jsem to obnovoval a migroval jinam — myslím, že jsme tehdy přešli na DigitalOcean, kde se od té doby nikdy nic podobného nestalo a funguje skvěle.
Byla to pro mě silná lekce. Slibu o replikované redundanci od poskytovatele nikdy úplně nevěřte, dokud si ji sami nezkontrolujete.
Když shoří celé datacentrum — kauza OVH 2021
Pokud si myslíte, že voda v datacentru je extrém, asi největší varování posledních let přišlo 10. března 2021. Tehdy ve Štrasburku kompletně shořelo datacentrum SBG2 francouzské společnosti OVHcloud, jednoho z největších evropských cloudových poskytovatelů. Budova SBG2 o rozloze 500 m² byla kompletně zničena a sousední SBG1 vážně poškozena. Jako pravděpodobná příčina byly identifikovány dvě nedávno opravované záložní UPS jednotky, které se přehřály.
Co je ale na tom příběhu ještě zajímavější: celá řada zákazníků ztratila data napořád — včetně těch, kteří si připlatili za zálohy. Francouzský soud později v několika případech rozhodl, že OVHcloud ukládal zákaznické zálohy ve stejném datacentru jako ostrá data, takže když shořela produkce, shořela s ní i „záloha“. U jednoho ze zákazníků to dopadlo ještě absurdněji — OVH tvrdil, že data z jeho záložního serveru obnovil, ale server prý zapnuli bez varování a automatický skript zákaznická data smazal jako „stará“. Zákazník pak obdržel zpět prázdný server.
Populární hra Rust tehdy přišla o kompletní evropské herní servery bez možnosti obnovy. Úhrnem mělo být požárem zasaženo přes 130 firem, které se následně spojily do hromadné žaloby.
Ponaučení? Záloha uložená ve stejném datacentru jako produkce není záloha. Je to kopie.
Jak zálohuji já
Kvůli všem těmhle zkušenostem jsem si vypěstoval zálohovací paranoiu, která hraničí s obsesí. U Editee máme:
-
Hodinové zálohy na šest různých míst napříč kontinenty.
-
Jednou týdně velké full backupy s dlouhou retencí.
-
U produkčních databází sekundové point-in-time zálohy s retencí až jeden týden.
-
Zálohuji i GitHub — ano, i ten.
-
A ruční checkpointy před každým větším zásahem.
Takže naše backupy jsou objemově opravdu velké a stojí to nějaké peníze, ale ve chvíli, kdy se něco pokazí (a ono se to dřív nebo později pokazí vždycky), je to investice, která se vrátí během jedné jediné obnovy.
Co říci závěrem
AI je neskutečný nástroj a vývoj mi zrychlila tak, že si bez ní už ani neumím představit práci. Ale zároveň je to další hráč u klávesnice, který může udělat chybu. Stejně jako ji můžete udělat vy sami přes databázového klienta, stejně jako ji může udělat poskytovatel cloudu, stejně jako ji může způsobit prasklá voda nad datacentrem nebo přehřátá UPS jednotka.
Mně osobně to jenom potvrdilo pravidlo, kterým se řídím už víc než deset let:
Zálohujte všechno. A potom to zálohujte ještě jednou. A kopii záloh mějte někde úplně jinde.
Mně se naštěstí vyprázdnila jen dev databáze. Mohlo to ale dopadnout mnohem hůř — a přesně proto mám zálohování 20× překryté na všech možných místech. Protože nikdy nevíte, kdy to budete potřebovat. A věřte mi, že ten den přijde, není otázka jestli, ale jen kdy.
