Yandex Cloud потерял 2,84% данных клиентов после пожаров в ЦОДах: бэкапов не было

Каждый инженер хоть раз слышал фразу «у нас же облако, оно не пропадёт». Октябрь 2026 года показал, чего стоит такая уверенность. Яндекс сообщил, что после пожаров в ЦОДах не смог восстановить 2,84% клиентских данных на платформе Yandex Cloud.

Что известно на самом деле

По словам пресс-службы компании, вернуть эти данные невозможно по двум причинам: оборудование получило критические повреждения, а бэкапов этой информации на платформе не было. Важно именно сочетание. Пожар в дата-центре сам по себе — авария, которую индустрия умеет переживать. Данные пропадают тогда, когда единственная копия стояла в том же месте, где всё сгорело.

В ответ Яндекс планирует включать резервное копирование по умолчанию. Подробностей в сообщении мы не видим: неясно, сколько клиентов затронуто и какие именно сервисы потеряли данные. Цифра 2,84% звучит скромно, но для конкретной компании она может означать 100% её базы, если та попала в эту долю.

Почему слова «по умолчанию» здесь главное

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

Бэкап, который нужно включать вручную, часто остаётся выключенным. Кто-то экономит, кто-то забывает, а кто-то уверен, что провайдер делает это сам. Это классический разрыв ответственности: клиент считает, что за сохранность отвечает облако, а облако считает, что клиент сам настроит копии. Решение «по умолчанию» закрывает этот разрыв для тех, кто не вчитывался в документацию.

Что делать разработчику, продакту и основателю

Не ждите, пока провайдер изменит настройки. Проверьте свою инфраструктуру сегодня:

• Составьте список всех хранилищ: базы, объектные хранилища, диски виртуальных машин. Отметьте, у каких из них нет копий.
• Следуйте правилу 3-2-1: три копии данных, на двух типах носителей, одна из них в другом месте. Лучше всего в другой зоне доступности или у другого провайдера.
• Проверьте восстановление. Бэкап, который ни разу не разворачивали, остаётся гипотезой, а не защитой.
• Зафиксируйте допустимую потерю данных (RPO) и время восстановления (RTO). Без этих цифр разговор о бэкапах превращается в разговор о надеждах.
• Прочитайте раздел о разделении ответственности в документации и договоре. SLA на доступность сервиса не равен гарантии сохранности ваших данных.

Продактам стоит добавить потерю данных в реестр рисков и сравнить цену бэкапа с ценой потери. Основателям — задать технической команде один вопрос: «Сколько у нас данных, которые существуют в единственном экземпляре?». Если ответ звучит уверенно и сопровождается списком, всё в порядке. Если пауза, у вас есть работа.

Ограничения и оговорки

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

Итог простой. Облако избавляет от забот о железе, но не от ответственности за данные. Если у вас нет рабочей и проверенной копии в другом месте, считайте, что у вас её нет вообще.