Yandex Cloud вернул 97,16% данных после атак на ЦОДы, а бэкапы теперь включены по умолчанию

Есть вещи, которые все знают и всё равно откладывают на потом. Бэкапы — главная из них. Новая история с Yandex Cloud хорошо показывает цену этого «потом»: после атак на дата-центры компания рассказала, сколько данных клиентов удалось спасти, а сколько нет.

Что произошло и какие цифры

По данным, опубликованным со ссылкой на Интерфакс, Yandex Cloud восстановил доступ к 97,16% клиентских данных. Это случилось при критических повреждениях оборудования, то есть речь не о коротком сбое, а о физическом уроне инфраструктуре.

Остальные 2,84% вернуть не удалось. Причины две, и они сработали вместе: железо, на котором лежали данные, критически повреждено, а у владельцев этих данных не было собственных бэкапов на платформе.

Если у клиента было включено резервное копирование, сохранилось 100% данных. Это главная цифра всей истории. Из неё видно, что техника отказывает у всех, а спасают данные настройки, которые клиент сделал заранее.

Для контекста: недавно AWS после ударов по инфраструктуре в Бахрейне и ОАЭ признала, что часть данных и ресурсов на пострадавших площадках восстановить не получится. Так что у крупных облаков физические риски вполне реальны, и это не экзотика.

Что меняется в продукте

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

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

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

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

Урок здесь приземлённый, без громких выводов.

• Проверьте, включены ли бэкапы. Особенно на виртуальных машинах, созданных до изменения. Новый дефолт на них не распространяется, а про старые машины в публикации ничего не сказано.
• Не путайте отказоустойчивость облака с резервной копией. Облако может обещать доступность, но физическое уничтожение площадки показывает разницу: без отдельной копии данные остаются на том же железе.
• Подумайте, где лежит копия. В публикации не уточняется, где именно хранятся бэкапы клиентов, но логика проста: копия рядом с оригиналом при серьёзной аварии рискует пострадать вместе с ним. Стоит прочитать документацию провайдера и выяснить, в другой ли локации хранится копия.
• Проверяйте восстановление. Бэкап, из которого ни разу не пробовали поднять систему, остаётся гипотезой.
• Заложите это в продукт. Если вы строите сервис поверх облака, в SLA и в архитектуре должны быть явные цели: сколько данных вы готовы потерять и как быстро должны вернуться.

Ограничения

Все цифры исходят от самой компании и пересказаны в публикации. Независимого аудита нет, неизвестно, какая часть клиентов и каких типов данных попала в 2,84%. Нет и подробностей об атаках и масштабе повреждений. Поэтому не стоит делать вывод, что один провайдер надёжнее другого. Сравнение с AWS в посте скорее эмоциональное, чем строгое: инциденты разные, данных для прямого сопоставления нет.

Тем не менее главный вывод от этого не слабеет. Даже при тяжёлых физических повреждениях 97,16% данных вернули, а среди тех, кто делал бэкапы, потерь не было вовсе. Резервная копия стоит недорого по сравнению с потерей данных, а теперь её ещё и не нужно включать вручную, если вы создаёте новые машины.