Главное
- Осенью 2026 года рынок пережил серию тяжёлых аварий: атаки на дата-центры Яндекса и остановка двух зон Yandex Cloud, взлом панели управления у FirstVDS и кибератака на Beget.
- Критические инциденты на российских площадках за 2025–2026 годы были также у Timeweb Cloud (22-часовой сбой хранилища в Москве), Selectel (14-часовой сбой сети в пуле ru-7) и RUVDS (изъятие оборудования в Казани).
- Самые опасные сценарии — не отказ диска или сети, а компрометация управляющего контура: панели виртуализации, через которую злоумышленник получает доступ ко всем серверам сразу.
- Больше записей в истории не значит, что провайдер хуже. Selectel и Timeweb Cloud ведут подробные статус-страницы с десятками записей, а у многих других история аварий вообще не публикуется. Рейтинг самых надёжных аналогов Beget учитывает это и выносит провайдеров без истории в отдельный блок.
- Дешёвый и надёжный провайдер не выбирается по таблице характеристик: важны независимые бэкапы, отдельный DNS и проверка конкретного дата-центра.
Критические инциденты
Yandex Cloud: остановка двух зон доступности, октябрь 2026
8 октября в 01:31 МСК Yandex Cloud сообщил о перебоях питания в зоне ru-central1-b: после атаки беспилотников на дата-центр в Сасове (Рязанская область) начался пожар, ЦОД полностью остановили. 9 октября Яндекс сообщил об атаке на дата-центр в Калуге, где из строя вышли несколько модулей, а в ночь на 11 октября остановился ЦОД во Владимире, обслуживавший зону ru-central1-a. Две зоны оказались недоступны одновременно, облако перешло в аварийный режим: выдачу квот приостановили, плату за октябрь не взимали.
23 октября открылась новая зона в другой локации, ресурсы в ней запускают вручную при ограниченных квотах; доступ к данным платформы восстановлен не полностью, работы продолжаются. Хронология — на статус-странице Yandex Cloud и в блоге Yandex Cloud.
Что это значит для клиента: даже три зоны доступности у одного провайдера не защищают от одновременной потери нескольких дата-центров. Резервные копии и запасной сервер стоит держать у другой компании.
FirstVDS: взлом VMmanager 6, 17 октября 2026
Злоумышленник получил административный доступ к панели виртуализации VMmanager 6 через уязвимость HTTP Request Smuggling и запускал на гипервизорах сборщик, который читал диски клиентских виртуальных серверов — без запуска вредоносного кода внутри самих ВМ. Архивы сборщика нашли на 457 физических узлах, общий объём — 117,24 ГиБ. Это не число пострадавших клиентов и не подтверждённый объём похищенных данных: логи подтверждают соединения с сервером атакующего, но точный объём передачи установить нельзя.
Панель изолировали, часть операций и выдача новых серверов ограничивались. 3 ноября компания опубликовала FAQ и программу компенсаций. Подробности — в постмортеме FirstVDS и первом оповещении.
Что это значит для клиента: если ваш сервер работал у FirstVDS в октябре 2026 года, смените все пароли, ключи и токены, которые хранились на сервере, и проверьте журналы доступа. Хранить единственную копию секретов и важных данных у одного провайдера рискованно у любого хостера.
Beget: кибератака, 2–4 ноября 2026
По официальной хронологии Beget, атака на управляющую инфраструктуру началась 2 ноября в 02:00, в 02:30 было запущено вредоносное ПО, рассчитанное на удаление данных, а в 02:55 все серверы отключили от сети. К 14:00 восстановили неадминистрируемые выделенные серверы, к 17:00 — NS-серверы. 3 ноября вернули почту и начали поэтапно запускать виртуальный хостинг, 4 ноября в 01:00 заработали первые сайты. Восстановление продолжается — актуальный статус смотрите на сайте Beget.
Что делать владельцам сайтов, пока восстановление не завершено, — в статье «Что делать при сбое Beget».
RUVDS: изъятие оборудования в Казани, 11–15 июня 2026
В ходе оперативных мероприятий оборудование в казанском дата-центре изъяли, и затронутые серверы были недоступны несколько дней. Это не массовое падение всех локаций RUVDS, а физическая и юридическая точка отказа у конкретного ЦОД. Разбор — в статье RUVDS на Хабре.
Timeweb Cloud: сбой хранилища в Москве, 9–10 апреля 2026
Из-за программной ошибки в системе хранения узлы кластера в локации MSK-1 перезагружались по кругу: виртуальные машины зависали на операциях ввода-вывода, управление серверами блокировалось. Полностью управление восстановили 10 апреля в 17:30 МСК — около 22 часов спустя; по данным компании, целостность данных не нарушена. Запись есть на статус-странице Timeweb Cloud.
Selectel: сбой сети в пуле ru-7, 2–3 ноября 2026
Сбой компонентов, управляющих виртуальными сетями, нарушил связность облачных серверов, балансировщиков и смежных сервисов в московском пуле ru-7. Основная фаза длилась около 14 часов, до 21:51 МСК 3 ноября; другие пулы не пострадали. Подробности — на статус-странице Selectel.
Другие инциденты на российских площадках
Selectel, 2025–2026. Статус-страница фиксирует за период около 25 крупных сбоев в отдельных пулах и регионах и несколько сотен мелких событий в отдельных сервисах. Это следствие очень подробной публичной истории, а не признак, что Selectel падает чаще других.
Timeweb Cloud, 2025–2026. Кроме апрельского сбоя, на статус-странице — около 20 крупных инцидентов, больше половины из них в зарубежных локациях, и несколько десятков мелких. Последний заметный сбой в Москве — 23 октября 2026 года, частичная недоступность VDS в MSK-1 с 15:30 до 18:15.
REG.RU, июль и август 2026. 16 июля пользователи сообщали о перебоях DNS и недоступности сайтов на хостинге (Хабр), 18 августа авария на подстанции обесточила часть оборудования на узле ММТС-9: не открывались сайт, личный кабинет и сайты клиентов (РБК).
VK Cloud, 2025. На статус-странице — несколько крупных сбоев: ошибки объектного хранилища 30 мая (около 2 часов) и недоступность виртуальных машин в регионе GZ1 13 августа (1 ч 48 мин).
HOSTKEY, 26 октября 2026. Компания отвечала клиентам о проблемах электропитания в дата-центре DataPro в Москве; сколько российских VPS затронуто и как долго, публично не раскрыто.
McHost, 19 августа 2026. Сообщалось о сбое электропитания на узле ММТС-9 в Москве; влияние на конкретные серверы не раскрыто.
SpaceWeb, 5 июня 2026. Провайдер сообщал о проблемах доступа и связывал их с внешними ограничениями маршрутизации.
Аварии за пределами России
Их не стоит переносить на российские локации тех же брендов, но они важны, если вы держите серверы в Европе:
- FirstVDS, Амстердам (Qupra DC2), май — июль 2026 — серия аварий охлаждения, по данным постмортема суммарно около 58 часов недоступности; компания начала переезд.
- HOSTKEY, Нидерланды, лето 2026 — длительный отказ инфраструктуры.
- Majordomo, McHost и VDSina, июнь 2026 — отключение питания в нидерландском дата-центре nLighten; европейские серверы были недоступны около шести дней, Majordomo перенёс оборудование в Сербию.
- Timeweb Cloud, Амстердам, май — июль 2026 — серия отказов охлаждения в ЦОД Qupra, самый долгий эпизод — около 47 часов в конце июня; компания ввела нулевой биллинг и начала переезд.
- В июне 2026 года европейские площадки сразу нескольких провайдеров пострадали из-за отключения у общего оператора инфраструктуры. Разные бренды могут стоять в одном ЦОД — для резервирования этого недостаточно.
У кого нет публичной истории
У Спринтбокса, Masterhost, Джино, i7.ru, Hostland, SmartApe, FirstByte, NetAngels, Cloud.ru и ряда других провайдеров публичной датированной хронологии крупных аварий за 2025–2026 годы нет. Это не значит, что они стабильнее: просто провайдер не ведёт открытую статус-страницу или не публикует постмортемы. У AEZA отдельно стоит учитывать санкционные риски части компаний группы с 2025 года.
Как выбирать провайдера с учётом рисков
- Узнайте конкретный дата-центр: название, город, оператора, где находятся панель управления и резервные копии.
- Спросите о защите панели: какая система виртуализации, установлены ли патчи, проводилась ли ротация служебных секретов, есть ли двухфакторная авторизация.
- Запросите историю инцидентов конкретного кластера за 2025–2026 годы и ссылку на статус-страницу.
- Держите бэкапы у другого провайдера — в S3-хранилище другой компании или на втором сервере, и проверьте, что восстановление действительно работает.
- Вынесите DNS отдельно — к регистратору или в DNS-хостинг, чтобы при аварии быстро переключить сайт.
- Протестируйте финалистов: steal time процессора, скорость дисков (fio), сетевые задержки, восстановление из снапшота.
- Мониторьте доступность не меньше 14 дней из нескольких сетей, считая аптайм своих сервисов, а не сайта хостера.
Для критичных данных используйте два независимых дата-центра у разных провайдеров. Подобрать сервер по ресурсам и цене поможет калькулятор VPS, а перенести проект — наша услуга переноса.