**Три ЦОД за четыре дня: Яндекс.Облако признало инфраструктуру неустойчивой. Что делать...
**Три ЦОД за четыре дня: Яндекс.Облако признало инфраструктуру неустойчивой. Что делать, если у вас Яндекс.Диск** Атаки БПЛА вывели из строя дата-центры в Сасово, Калуге и Владимире. Yandex Cloud перешёл в аварийный режим и советует клиентам искать альтернативы. Разбираем, что осталось от резервирования — и как вытащить свои данные с Яндекс. Диска, пока он ещё дышит. За четыре дня, с 8 по 11 октября, Яндекс потерял три крупных дата-центра. Сначала — Сасово (Рязанская область), зона ru-central1-b: пожар после атаки беспилотников, площадка полностью остановлена, десятки тысяч серверов. На следующий день — Калуга: несколько серверных модулей вышли из строя, ЦОД на 3800 стоек и 63 МВт частично потерян. И вот 11 октября — Владимир, зона ru-central1-a: удар по площадке, полная остановка, нарушение электропитания в 04:12 мск. Самое тревожное — не сами аварии, а официальная реакция. Yandex Cloud признал оставшуюся конфигурацию ресурсов **неустойчивой** и рекомендовал клиентам задействовать любые альтернативные планы аварийного восстановления, не ограничиваясь переключением между своими зонами. Фактически это сигнал: внутреннее резервирование облака больше не гарантирует выживание сервисов. Владимирские площадки — это ru-central1-a и ru-central1-e. Первый комплекс с 2017 года рассчитан на 2880 стоек, второй, запущенный в марте 2026-го, — ещё на 2800 стоек и 40 МВт. Между зонами высокоскоростное соединение до 25,6 Тбит/с с задержкой менее миллисекунды. Но близкое географическое расположение и независимые инженерные системы не спасли от одновременного удара. До этого Yandex Cloud уже работал на пределе: после первых аварий квоты на вычислительные ресурсы и диски перевели в ручной режим, расширение ограничили, приоритет отдали критически важным приложениям. Теперь же поддержка может работать нестабильно, а клиентам предлагают переносить управляющие компоненты Kubernetes и узлы управляемых БД из недоступных зон. Договорённости с Selectel, К2Cloud и VK Cloud об ускоренном размещении — это уже не план Б, а план выживания. Проблема в том, что перенос работающей системы к другому провайдеру — это не кнопка «мигрировать». Нужно восстановить базы данных, настроить сеть, права, балансировку, а если бэкапы лежали внутри пострадавшего облака — доступ к ним тоже может быть потерян. Физическое восстановление ЦОДов, по экспертным оценкам, займёт до года и обойдётся в 12–15 млрд рублей без серверов. При локальных повреждениях — 1–2 месяца, но это в лучшем случае. 🛠 Мнение DevGeek.IT: Три удара по трём ЦОД за четыре дня — это не чёрный лебедь, а суровая реальность. Если ваш DR-план заканчивался на «переключимся на другую зону внутри того же облака», считайте, у вас его нет. Но если вы просто пользователь Яндекс. Диска и думаете, что вас это не касается, — зря. Диск живёт на той же инфраструктуре, и «неустойчивая конфигурация» означает, что в один момент файлы могут стать недоступны. Вот что делать прямо сейчас, не откладывая: **1. Не полагайтесь на веб-интерфейс.** Скачать терабайты через браузер — это боль и риск. Используйте API. Для публичных папок есть `ydiskarc`: `pip install ydiskarc`, затем `ydiskarc sync https://disk.yandex.ru/d/ВАША_ССЫЛКА -o ./backup --parallel 8`. Для приватных папок — `ydisk-downloader` с OAuth-токеном: получаете токен через официальное приложение, ставите `export YANDEX_DISK_TOKEN=...` и качаете с `--concurrent 10`. Оба инструмента поддерживают докачку и проверку целостности. **2. Если у вас организация — не мучайтесь вручную.** Есть готовый скрипт от Yandex 360 Solutions Library: создаёте сервисное приложение с правами `cloud_api:disk.read`, прописываете CLIENT_ID и CLIENT_SECRET в `.env`, запускаете `python downloader.py ` — файлы складываются в папку по домену. Или используйте специализированные решения вроде «Бэкап Яндекс 360», которые умеют выгружать Диск, Почту, Календарь и Контакты в S3-совместимое хранилище. **3. Для миграции на другой облако — rclone.** Он умеет Яндекс. Диск как rem