«Яндекс» восстановил 97,16% данных Yandex Cloud, пострадавших после атак на его дата-центры в октябре. Оставшиеся 2,84% вернуть не удалось: оборудование получило критические повреждения, а у владельцев этих данных не было резервных копий. Для российских команд, которые строят сервисы на облаке, это не отвлечённая история об отказоустойчивости, а довольно наглядная цена настройки бэкапов.
Как сообщает vc.ru, инцидент не привёл к потерям у клиентов, использовавших штатные или собственные средства резервного копирования: компания заявляет о сохранении 100% их данных. После восстановления сервис изменил настройки по умолчанию: при создании виртуальной машины резервное копирование теперь включается автоматически. Его можно отключить, однако «Яндекс» называет такую защиту базовым способом снизить риск при внештатных событиях.
Серия проблем началась после атак беспилотников на дата-центры компании. В ночь на 8 октября 2026 года был атакован объект в Сасово, 9 октября — в Калуге, в ночь на 11 октября — во Владимире. Затем с перебоями работали как сервисы самого «Яндекса», так и продукты сторонних разработчиков. К концу октября компания постепенно вернула в строй большую часть сервисов, а теперь раскрыла итоговую оценку восстановления клиентской информации.
Цифра в 97,16% выглядит высокой, но для облачного провайдера важнее другая часть сообщения: потеря 2,84% не связана с ошибкой пользователя в приложении или случайно удалённой таблицей. Речь идёт о данных, которые не удалось извлечь из физически повреждённого оборудования. Облако действительно снимает с команды рутину по эксплуатации серверов, но не отменяет необходимость определить, что именно нужно копировать, как часто и куда можно восстановиться при потере целой площадки.
Автоматическое включение бэкапов меняет исходную позицию для новых виртуальных машин. Раньше резервирование нередко оставалось задачей, которую откладывают до «следующей итерации» — вместе с документацией и тестом аварийного восстановления. Теперь клиенту придётся совершить осознанное действие, чтобы остаться без такой защиты. Это полезная страховка от типовых ошибок конфигурации, хотя она не заменяет настройки срока хранения, расписания копий и проверки того, что восстановление действительно работает.
Для разработчиков и инфраструктурных команд этот случай стоит разобрать на более приземлённые вопросы. Попадают ли в резервные копии базы данных, объектное хранилище, конфигурации и секреты; есть ли отдельная копия критичных данных за пределами основной локации; известны ли допустимая потеря данных и время восстановления для каждого сервиса. Снимок диска сам по себе не является планом непрерывности бизнеса: при отказе площадки может понадобиться поднять сеть, права доступа, очереди и зависимости приложения в другом месте.
«Яндекс» также продолжает распределять вычислительные ресурсы по новым независимым локациям в разных регионах России и обещает увеличивать их число. Это снижает зависимость от одной точки размещения, но географическое распределение не стоит путать с резервной копией. Репликация помогает пережить часть отказов с минимальной паузой, а резервная копия остаётся последней линией защиты, когда повреждены данные, инфраструктура или обе вещи одновременно.
История с данными Yandex Cloud наверняка ускорит разговор о том, какие гарантии должны быть включены в облако по умолчанию, а какие остаются зоной ответственности клиента. Автоматический бэкап закрывает самый очевидный провал, но следующий экзамен для рынка — прозрачность: командам нужны понятные параметры размещения, восстановления и ограничений защиты, чтобы оценивать риски до инцидента, а не после сообщения о невосстановимых процентах.
