Атаки на ЦОД Яндекса: как защитить данные и сервисы бизнеса

С 8 по 11 октября 2026 года «Яндекс» сообщил о повреждениях инфраструктуры трех дата-центров. После пожара в Сасове Рязанской области работа площадки остановилась, в Калуге часть инфраструктуры вышла из строя, а 11 октября компания подтвердила остановку дата-центра во Владимире. Об этом говорится в официальном сообщении «Яндекса», обновленном 11 октября.

Последствия затронули не только отдельные пользовательские сервисы. Согласно журналу инцидентов Yandex Cloud, при недоступности одной зоны возникали ограничения на создание новых виртуальных машин, кластеров Kubernetes и баз данных в других зонах. Позднее провайдер сообщил о ручном распределении квот на вычислительные ресурсы и диски, а 11 октября рекомендовал клиентам использовать внешние площадки для аварийного восстановления. По состоянию на 12 октября облачная платформа продолжала работать в ограниченном режиме.

События поставили перед компаниями вопрос, который обычно возникает уже после аварии: если основной дата-центр перестанет работать, где окажутся критичные данные, на каких мощностях запустятся приложения и сколько времени потребуется, чтобы вернуть клиентам доступ к сервисам?

Да, наличие резервных копий важно, но само по себе оно не дает гарантии непрерывной работы бизнеса в случае аварий.

Репликация (резервная копия) поддерживает дополнительные экземпляры данных и помогает пережить отказ диска или узла. Резервная копия позволяет вернуться к прежнему состоянию после удаления, повреждения либо некорректного изменения информации. Аварийное восстановление включает не только данные, но и серверы, сети, доступы, конфигурации и порядок запуска приложений. Если построен лишь один из этих уровней защиты, другие риски остаются.

Данные сохранились, а приложение не работает

Представим интернет-магазин, у которого каталог товаров размещен в объектном хранилище, база заказов работает в облачной СУБД, а фронтенд запускается в контейнерном кластере. Даже если файлы каталога доступны, сервис не примет заказ, пока не восстановлены база данных, обработка платежей, авторизация и маршрутизация запросов. Поэтому план непрерывности нужно составлять для бизнес-процесса целиком, а не для одного бакета или виртуальной машины.

Резервная копия зависит от той же инфраструктуры

Копии в другом бакете или в отдельном аккаунте могут защитить от некоторых ошибок и случайных удалений, но не обязательно от масштабного отказа самого провайдера. Для независимого восстановления важно проверить физическое расположение копий, доступность управления ими и возможность выгрузить данные без работающей основной площадки. Отдельно следует предусмотреть независимые учетные данные и безопасное хранение ключей шифрования.

Свободные мощности нужны именно во время аварии

Как правило, компании хранят одну резервную копию, рассчитывая в случае сбоя быстро создать новые серверы. Но когда одновременно восстанавливаются десятки клиентов, у доступных зон и альтернативных провайдеров могут возникнуть ограничения по ресурсам. В этом случае решающую роль играют заранее согласованная емкость, готовые конфигурации, проверенные сетевые подключения и время, необходимое для передачи данных.

Начать стоит с перечня систем, остановка которых приведет к потере выручки, невозможности обслуживать клиентов или нарушению обязательств. Для каждой системы необходимо зафиксировать:

• владельца,
• место размещения приложения и данных,
• зависимость от внешних сервисов,
• порядок восстановления.

Для составления плана вам понадобятся два параметра:

1. RTO – сколько времени бизнес готов ждать возобновления работы системы;
2. RPO – за какой предшествующий период допустима потеря изменений в данных.

Затем нужно проверить доступность последней пригодной копии: можно ли ее прочитать из независимого контура, хватает ли полномочий на восстановление, имеются ли ключи, схемы баз, настройки приложения и инструкции для команды.

Если резервной копии за пределами основного провайдера нет, создание защищенной независимой копии критичных данных становится первоочередной задачей. Передача должна быть зашифрована, права ограничены, а удаление или перезапись копий контролироваться отдельной политикой хранения.

Проведите тест – запустите критичный сервис в изолированном окружении, не использующем основные вычислительные мощности. Команда должна получить данные, восстановить СУБД, запустить приложение, настроить сетевой доступ и убедиться, что бизнес-функция работает (например, заказ проходит от корзины до сохранения в базе и отправки подтверждения).

В ходе теста нужно измерить фактические RTO и RPO, а также оценить скорость чтения данных из хранилища, время переноса больших массивов, права доступа, зависимость от DNS, сертификатов, секретов и внешних API. Если восстановление потребовало ручных действий, которые знает только один специалист, их следует документировать и передать резервной команде.

Важно проверить, что после возобновления работы основной площадки потребуется синхронизировать изменения и исключить расхождение данных. Аварийное переключение без продуманного возвращения способно создать новую проблему уже после устранения инцидента.

Стоит сопоставить реальную стоимость простоя с ценой резервирования, трудозатратами на эксплуатацию и допустимым временем восстановления, поэтому универсального решения нет. Разберем самые распространенные сценарии:

Для большинства компаний рациональнее начинать с разграничения критичных и некритичных систем, а не переносить все в собственный ЦОД. Иногда достаточно независимого резервного хранилища и подготовленного сценария запуска, тогда как наиболее важным приложениям действительно требуется постоянно доступная вторая площадка.

Один из способов снизить зависимость от крупных облачных провайдеров – разместить резервное хранилище на собственных мощностях. В этом случае даже при атаке на дата-центры внешнего провайдера компания сможет сохранить доступ к независимой копии данных и использовать ее для восстановления сервисов.

Собственная инфраструктура дает бизнесу возможность самостоятельно определять, где размещаются данные и как устроен контур хранения. Такой подход особенно востребован, если у компании уже есть серверные мощности, строгие внутренние требования к доступу или необходимость держать резервные копии отдельно от основного облачного провайдера.

Но даже одна копия на собственных мощностях не дает гарантии защиты данных, ведь единственная серверная компании тоже может пострадать от пожара, отключения электропитания или отказа сети.

Для подобных сценариев PlatformCraft разработала PC-Depot – программное обеспечение объектного хранения, которое разворачивается на инфраструктуре заказчика и предоставляет доступ к данным через S3-интерфейс. Решение поддерживает:

• настройку фактора репликации,
• управление доступом через IAM,
• распределенное размещение узлов.

При этом создание собственного контура хранения не обязательно требует дорогостоящего оборудования. Наше программное обеспечение нетребовательно к аппаратным ресурсам и позволяет эффективно использовать доступное дисковое пространство, сокращая затраты на хранение данных и расширение инфраструктуры.

Команда PlatformCraft поможет подобрать конфигурацию под вашу нагрузку и требования к доступности, надежности и производительности.

Подробнее: PC-DEPOT — объектное хранилище на инфраструктуре заказчика.

После крупной аварии нагрузка на уцелевшие мощности может вырасти, а перенос данных и выделение новых вычислительных ресурсов занять больше времени, чем планировалось. Одновременно возрастает зависимость от службы авторизации, DNS, мониторинга, хранилища и каналов поддержки. Эти риски не означают, что новый сбой неизбежен, но их стоит учитывать при планировании аварийного восстановления.

Не менее важен контроль над данными. Компания должна понимать не только где физически находятся резервные копии, но и сможет ли она получить их самостоятельно, что произойдет при потере доступа к основному аккаунту и кто вправе изменять политики хранения? Компаниям нужно снизить риски случайного удаления и вредоносных действий помогают разграничение прав, версионирование и неизменяемые резервные копии, если соответствующие механизмы поддерживаются системой хранения и правильно настроены.

Отдельного внимания требует доставка контента. Если корпоративные порталы, видеосервисы или файловые ресурсы используют внешнюю CDN, ее недоступность может нарушить работу даже при сохранности самих данных. Для компаний с распределенной инфраструктурой альтернативой становится собственная внутренняя CDN, развернутая на собственных мощностях. Она позволяет организовать доставку файлов и медиаконтента между филиалами, снизить нагрузку на центральное хранилище и уменьшить зависимость от внешних сервисов. При этом важно предусмотреть резервирование источников контента, ведь кэширование само по себе не гарантирует доступность всех файлов при отказе основного хранилища. С этим так же поможет команда PlatformCraft.

Подробнее: кейс с распределенной сетью доставки контента для «Росатома».

Если провайдер обещает SLA 99,9% или выше, нужен ли резервный ЦОД?

SLA определяет согласованные показатели услуги и возможные последствия их нарушения, но не подменяет план аварийного восстановления. Для критичной системы важно заранее выяснить, чем бизнес сможет пользоваться во время простоя, какие исключения есть в договоре, и кто обеспечивает доступ к резервной площадке.

Достаточно ли хранить резервные копии в другом бакете S3?

Не всегда. Другой бакет снижает отдельные операционные риски, однако может зависеть от тех же зон, учетных записей и сервисов управления. Для защиты от масштабного отказа нужна копия в независимом контуре и тест доступа к ней без основной инфраструктуры.

Нужно ли полностью уходить из публичного облака?

Нет. Облачные сервисы сохраняют преимущества по масштабированию и скорости запуска. Задача – убрать критические единые точки отказа, имея независимую копию данных, подготовленную альтернативную среду для важных приложений и проверенный порядок переключения.

Можно ли восстановить всю систему только из S3-хранилища?

Объектное хранилище может содержать резервные копии, файлы, конфигурации и другие данные, но само не восстанавливает базы, приложения, сетевые настройки и внешние интеграции. Для запуска сервиса требуются совместимые вычислительные мощности, инструменты восстановления и актуальная документация.