Beget запустил 35% серверов виртуального хостинга после атаки на управляющий контур своей инфраструктуры. Для тысяч сайтов это означает постепенное возвращение в сеть, но не полноценное завершение инцидента: панель управления пока недоступна, а инфраструктуру резервного копирования ещё приводят в рабочее состояние. Восстановление Beget стало наглядным стресс-тестом для клиентов российского хостинга, которым приходится проверять не только доступность сайтов, но и собственные планы аварийного восстановления.
О текущем статусе 4 ноября сообщается Habr / Новости. Провайдер заявил, что каждый сервер виртуального хостинга проходит ручную проверку, поэтому сайты запускаются не одновременно. Такой подход замедляет процесс, зато снижает риск вернуть в эксплуатацию сервер с невыявленными последствиями атаки или повреждённой конфигурацией.
С выделенными машинами ситуация заметно неоднороднее. Серверы без администрирования со стороны Beget, по данным компании, уже запущены и доступны. Владельцам таких серверов, у которых сервисы всё ещё не работают, предложено обращаться в комментарии к сообщению провайдера. Выделенные серверы, которые администрирует сам Beget, восстановлены лишь на 15%. Это важная граница для бизнеса: клиент может владеть отдельной машиной, но фактическая скорость возврата сервиса зависит от того, кто отвечает за её системное администрирование.
Доменные сервисы и DNS уже работают. Владельцы доменов под управлением Beget, использующие DNS-серверы провайдера, могут менять записи через отдельный доменный интерфейс. Для части пострадавших проектов это позволяет хотя бы управлять маршрутизацией трафика: например, временно направить домен на резервную площадку. Но сам по себе рабочий DNS не возвращает приложение, базу данных или пользовательские файлы — он лишь даёт возможность переключить адрес назначения.
Инцидент начался в ночь с 1 на 2 ноября 2026 года. Beget ранее сообщил, что злоумышленники получили доступ к управляющему контуру всей архитектуры и запустили скрипты, удаляющие данные. Компания объявила форс-мажор и перевела сотрудников, включая DevOps-команду, на круглосуточный кризисный режим. Формулировка про управляющий контур особенно неприятна для клиентов: компрометация такой зоны затрагивает не отдельный сервер, а механизмы, через которые управляется значительная часть инфраструктуры.
Последствия различаются по продуктам. В облачной инфраструктуре — VPS, S3 и Kubernetes — данные были утрачены. Beget также сообщил об утрате настроек CDN и IP. При этом сохранились файловые резервные копии виртуальных машин и хостинга, а бинарные бэкапы VPS потеряны полностью. Компания рассчитывает восстанавливать данные из файловых копий и обещает отдельно описать порядок их получения после восстановления соответствующей инфраструктуры.
Это различие между файловым и бинарным бэкапом для разработчиков имеет вполне практический смысл. Наличие копии файлов не гарантирует моментального возврата сервиса в состояние «как было»: приложение может потребовать повторной настройки окружения, проверки зависимостей, восстановления баз данных и сверки конфигурации. Если часть инфраструктурных параметров — CDN, IP-адреса или настройки облачных ресурсов — исчезла, командам придётся заново собирать цепочку доставки приложения до пользователя.
Панель управления Beget остаётся в очереди после серверов, сайтов и бэкапов. Это логичный приоритет: клиенту важнее получить работающий сервис и данные, чем привычный интерфейс для рутинных операций. Но отсутствие панели усложняет самостоятельную диагностику и миграцию, особенно для небольших команд без отдельного системного администратора. Тем, у кого критичные проекты размещены у провайдера, уже имеет смысл проверить внешние резервные копии, сроки действия доменов, доступы к DNS и готовность резервной площадки.
Восстановление Beget пока измеряется не обещаниями, а долями запущенных серверов: 35% у виртуального хостинга и 15% у администрируемых выделенных машин. Следующий принципиальный вопрос — насколько быстро провайдер вернёт клиентам доступ к резервным копиям и сможет ли описать границы утраты данных по каждому облачному сервису. Для рынка это очередное напоминание: бэкап, находящийся в том же контуре управления, что и рабочая инфраструктура, не всегда является независимой страховкой.
