Cloud není záloha: lekce z útoků na datová centra Yandexu v Rusku

Mezi 8. a 11. říjnem 2026 zasáhly drony tři datová centra Yandexu v Rusku. Výpadek odstavil přes 80 služeb, od bankovních aplikací po cloudové databáze firem. Z toho plyne lekce i pro české firmy: když máte data jen u jednoho poskytovatele, nemáte zálohu. Máte jen jedno místo, kde o data můžete přijít.

Cloud jsme si zvykli brát jako něco nezničitelného. Ve skutečnosti jsou to budovy plné serverů. Mají konkrétní adresu, přívod elektřiny a chlazení. A jako každou budovu je lze poškodit požárem, povodní, výpadkem proudu nebo útokem.

Co se stalo

Během čtyř dní zasáhly drony tři datová centra Yandexu. Útoky se připisují Ukrajině, ta se k nim ale oficiálně nepřihlásila.

DatumLokalitaDopad
11. 10. 2026VladimirProvoz datového centra (40–50 MW) zastaven; vypadly Yandex Cloud (Compute, Object Storage, Kubernetes, PostgreSQL) a přes 80 služeb (Kyiv Post)
9. 10. 2026Kaluga„Několik modulů datového centra je zcela vyřazeno“ (The Moscow Times)
8. 10. 2026Sasovo (Rjazaňská oblast)Požár, centrum zcela mimo provoz; Yandex nepotvrdil, zda vybavení půjde obnovit (CNBC)

Výpadek nezasáhl jen služby Yandexu. Nefungovaly bankovní aplikace, rozvoz jídla, taxi služby i obchodní řetězce Magnit a Fix Price, které na infrastruktuře Yandexu stavěly. Ještě 29. října, tedy po třech týdnech, Yandex uváděl, že obnovil jen „klíčové funkce“. Kvůli tomu také stáhl finanční výhled na rok 2026 (The Moscow Times).

Proč cloud sám o sobě není záloha

Poskytovatel cloudu se stará o to, aby služba běžela. Za to, že vaše data přežijí, ručíte vy. Tomuto rozdělení se říká model sdílené odpovědnosti a používají ho AWS, Azure, Google Cloud i menší hráči.

Cloud u jednoho dodavatele vás nechrání před těmito riziky:

  • Fyzické zničení lokality. Požár, povodeň, výpadek energie nebo útok. Replikace v rámci jednoho regionu nepomůže, když region vypadne celý.
  • Výpadek celého poskytovatele. Chyba v konfiguraci, kybernetický útok nebo bankrot dodavatele může zasáhnout všechny jeho regiony najednou.
  • Ransomware a smazání. Útočník, který získá přístup k vašemu účtu, smaže data i jejich zálohy ve stejném účtu.
  • Zablokování účtu. Spor o platbu, chybné vyhodnocení porušení podmínek nebo sankce vás mohou od dat odříznout ze dne na den.
  • Jurisdikce. Data v jedné zemi podléhají jejím zákonům a geopolitickým rizikům.

Případ Yandexu spojuje hned dvě z nich: fyzické zničení a geopolitiku. Firmy, které měly všechno jen v Yandex Cloudu, čekaly týdny, než se jim služby vrátily.

Pravidlo 3-2-1-1-0: zálohy na různých místech a u různých dodavatelů

Osvědčeným základem je pravidlo 3-2-1, dnes rozšířené na 3-2-1-1-0:

ČísloPravidloProti čemu chrání
3Tři kopie dat (produkční + dvě zálohy)Selhání jedné kopie
2Dva různé typy úložiště nebo dodavateléChyba nebo výpadek jedné technologie či firmy
1Jedna kopie v jiné lokalitě (offsite)Požár, povodeň, zničení datového centra
1Jedna kopie offline nebo neměnná (immutable)Ransomware, smazání útočníkem či omylem
0Nula chyb při ověření obnovyZáloha, která v krizi nejde obnovit

V praxi to znamená rozložit zálohy na třech úrovních:

  • Různí dodavatelé. Produkce běží třeba v Azure, záloha jde do AWS S3, Backblaze B2, k českému poskytovateli nebo do specializované zálohovací služby, jako je SnapBackuper. Ta přes šifrované SSH spojení zálohuje počítače, NAS i servery, uchovává historii změn a chrání zálohy před přepsáním ransomwarem. Výpadek ani zablokování jednoho účtu pak nezasáhne všechny kopie.
  • Různé lokality. Kopie leží v jiném regionu, ideálně stovky kilometrů daleko a mimo dosah stejné přírodní nebo politické hrozby.
  • Oddělené přístupy. Zálohy jsou v jiném účtu s jinými přihlašovacími údaji. Kdo ovládne produkci, nesmí umět smazat zálohy.

U kritických systémů se vyplatí navíc architektura multi-cloud nebo hybridní cloud. Aplikaci pak jde v případě nouze spustit u jiného poskytovatele, ne jen obnovit data.

Plán obnovy: záloha bez otestované obnovy nemá cenu

Záloha je jen polovina práce. Druhou polovinou je umět data rychle obnovit, když hlavní služba vypadne. Bez toho se záloha může v krizi ukázat jako neúplná, stará nebo nečitelná.

Každý systém potřebuje dvě čísla:

  • RTO (Recovery Time Objective): jak dlouho může systém stát. U e-shopu třeba 4 hodiny, u interní wiki klidně 3 dny.
  • RPO (Recovery Point Objective): kolik dat můžete ztratit. RPO 1 hodina znamená, že zálohujete aspoň jednou za hodinu.

Plán obnovy (disaster recovery) by měl počítat i se scénářem, kdy vypadne celý poskytovatel, ne jen jeden server. Měl by říct:

  1. Kdo rozhoduje o spuštění obnovy a jak se tito lidé spojí, když nejede firemní e-mail ani chat.
  2. Kde leží zálohy a přístupové údaje k nim. Tyto údaje nesmí být uložené jen v systému, který právě vypadl.
  3. V jakém pořadí se systémy obnovují, od kritických po vedlejší.
  4. Kam se obnovuje: do jiného regionu, k jinému poskytovateli, nebo na vlastní hardware.

Plán se musí pravidelně zkoušet. Aspoň jednou za čtvrtletí obnovte vybraný systém naostro do náhradního prostředí a změřte, jestli jste se vlezli do RTO. Teprve test ukáže, zda záloha opravdu funguje.

Checklist pro firmy

  • Máme seznam všech systémů a dat a u každého stanovené RTO a RPO.
  • Každá kritická data mají aspoň tři kopie.
  • Aspoň jedna záloha je u jiného poskytovatele než produkce.
  • Aspoň jedna záloha je v jiné geografické lokalitě.
  • Aspoň jedna záloha je neměnná (immutable) nebo offline.
  • Zálohy jsou v odděleném účtu s vlastními přístupy a vícefaktorovým ověřením.
  • Zálohujeme i konfiguraci: infrastrukturu jako kód, DNS, certifikáty a hesla.
  • Máme sepsaný plán obnovy dostupný i mimo firemní systémy.
  • Obnovu zkoušíme aspoň jednou za čtvrtletí a výsledky zapisujeme.
  • Víme, na jaké infrastruktuře běží naši klíčoví dodavatelé SaaS služeb.

Závěr

Výpadek Yandexu není jen ruský problém. Datové centrum může vyřadit i povodeň, požár, výpadek sítě nebo chyba poskytovatele, a to kdekoli v Evropě. Cloud je skvělý nástroj, ale odpovědnost za bezpečnost dat za vás neřeší.

Firma, která má zálohy u různých dodavatelů, na různých místech a s otestovaným postupem obnovy, přečká i výpadek celého poskytovatele. Ostatní mohou čekat týdny, jako zákazníci Yandexu v říjnu 2026.

Zdroje