Сбой Beget 2 ноября 2026: как мы переехали за час и что делать вам

2 ноября 2026 года хостинг-провайдер Beget пережил кибератаку. По данным компании, злоумышленники получили доступ к управляющему контуру инфраструктуры и запустили скрипты, которые стирали данные. Одновременно перестали работать сайты, VPS, DNS, почта и панель управления, а данные облачных серверов были утрачены. Сбой на стороне хостера предотвратить нельзя, но можно сделать так, чтобы он стоил час работы, а не недели простоя: держать независимые копии кода, контента и базы, не держать домен, DNS и сайт у одного провайдера и уметь собрать сервер с нуля по скрипту.

Наш сайт itelmen.ru тоже работал на инфраструктуре Beget. Ниже рассказываем, что произошло, как мы переехали и что стоит сделать заранее. Статья обновляется по мере появления новых подтверждённых данных.

Что произошло с Beget

Сбой начался в ночь на 2 ноября, около трёх часов утра по Москве. Официальные сообщения Beget и публикации в отраслевых СМИ сходятся в следующем:

• Причина. Beget сообщил о кибератаке «с получением доступа к управляющему контуру всей архитектуры и последующим запуском обнуляющих скриптов». Подробности компания не раскрывает, ссылаясь на интересы расследования.
• Масштаб. По собственным данным Beget, у компании около 200 тысяч клиентов. Не работали виртуальный хостинг, облачные серверы, DNS, почта и панель управления. Для восстановления нужно вручную проверить больше 1000 серверов на скрытые уязвимости и вредоносные скрипты.
• Облако. Данные облачной инфраструктуры (VPS, S3, Kubernetes) утрачены, полные образы VPS потеряны, как и настройки CDN и IP-адреса. Файловые бэкапы VPS сохранились, но доступа к ним пока нет.
• Виртуальный хостинг. По предварительной оценке Beget, восстановлению подлежат почти 100% сайтов, но каждый сервер перед запуском проверяют вручную, и это занимает много времени.
• Утечка. Beget пишет, что не видит попыток скачать или изменить данные на серверах с данными пользователей, и при этом рекомендует сменить все пароли, ключи и учётные данные, которые хранились на серверах.
• Форс-мажор. Компания официально уведомила клиентов об обстоятельствах непреодолимой силы по п. 3 ст. 401 ГК РФ. Это освобождает хостера от ответственности за простой, поэтому на компенсации по SLA рассчитывать не стоит.

Хронология

• 2 ноября, ночь. Перестают отвечать сайты, VPS, DNS-серверы и панель Beget.
• 2 ноября, около 14:00. Beget возвращает в работу выделенные серверы, которые клиенты администрируют сами. В течение дня компания объявляет о кибератаке и форс-мажоре.
• 2 ноября, поздний вечер. DNS-серверы Beget снова начинают отвечать, домены клиентов открываются по старым адресам.
• 3 ноября. Beget публикует разбор атаки. Клиентам снова доступна смена DNS-записей A, MX и TXT в зонах .ru, .рф и .su. С Координационным центром доменов достигнута договорённость: домены с истекающим сроком регистрации не будут разделегированы.

Как мы переехали за час

Сайт itelmen.ru построен на headless WordPress: CMS только хранит контент, а страницы отдаёт отдельное приложение на Nuxt. Приложение работало на облачном VPS Beget, CMS на виртуальном хостинге там же. Облачный сервер был стёрт вместе со всем облаком. Мы на нём ничего не потеряли: на сервере не было ничего, чего нет в наших собственных копиях.

• Код хранится в Git-репозитории, вне хостинга.
• Контент. Мы регулярно делаем резервную копию всего контента CMS: услуги, кейсы, статьи, страницы, меню и настройки на двух языках. Сайт умеет собираться прямо из этой копии, не обращаясь к CMS.
• Медиафайлы. Оригиналы всех изображений хранятся вместе с кодом.
• Сервер описан скриптами. Установка пакетов, firewall, nginx, SSL-сертификат и деплой выполняются командами, а не вручную по памяти.

От чистой Ubuntu до работающего сайта на HTTPS прошло меньше часа. Дамп базы данных для этого не понадобился. Даже если бы база CMS пропала безвозвратно, мы развернули бы новый WordPress и загрузили в него контент из той же копии штатным импортом. Это тоже около часа работы.

Сервер — только половина дела. Чтобы посетители попали на новый сервер, нужно переключить домен, а для этого должен работать DNS. Если DNS-зону обслуживает тот же хостер, что и сайт, переключение ждёт, пока хостер восстановит DNS, как бы ни был готов новый сервер. Поэтому домен и DNS стоит держать отдельно от хостинга.

Почему всё упало сразу

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

Похожие истории случались и с крупными игроками:

• Dyn, октябрь 2016 года. DDoS-атака ботнета Mirai на DNS-провайдера на несколько часов сделала недоступными Twitter, GitHub, Netflix и Reddit. Сами сайты работали, но браузеры не могли найти их адреса.
• OVH, март 2021 года. Пожар в дата-центре в Страсбурге. Часть клиентов потеряла данные безвозвратно, потому что резервные копии хранились в том же месте.
• Rackspace, декабрь 2022 года. Атака вымогателя на сервис размещённой почты Exchange. Сервис так и не восстановили, а у части клиентов пропала переписка.

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

Схемы размещения и последствия полного отказа хостера

Как снизить риски: чек-лист

• Домен у отдельного регистратора. Если регистратор и хостер одна компания, при её падении вы теряете возможность сменить DNS-серверы домена.
• NS-серверы у независимого DNS-провайдера. Это главная защита от сбоя вроде того, что случился у Beget. Если DNS-зону обслуживает не хостер, домен продолжает работать, когда хостер лежит, и A-запись на новый сервер меняется за минуты. Ещё надёжнее указать у домена NS-серверы двух разных провайдеров (вторичный DNS): тогда отказ одного из них посетители не заметят вовсе.
• NS настраивают заранее. Сменить NS-серверы у регистратора можно и во время сбоя, если его панель работает, но новые NS расходятся по сети от нескольких часов до суток: резолверы держат старые записи в кэше. Во время аварии быстро меняется только A-запись с коротким TTL.
• Почта не у хостера сайта. Корпоративная почта у отдельного сервиса продолжит работать, даже если сайт лежит.
• Резервные копии вне хостера, включая базу данных. Бэкапы самого хостера хранятся в его инфраструктуре и бывают недоступны вместе с ней. Файлов сайта без базы данных для восстановления CMS обычно недостаточно.
• Копия контента в репозитории. Регулярная выгрузка контента CMS позволяет развернуть сайт где угодно, даже без базы.
• Сервер как код. Скрипт установки и деплоя превращает переезд из многодневного проекта в рутинную операцию.
• Репетиция восстановления. Раз в квартал разверните сайт из копий на тестовом сервере. Бэкап, из которого ни разу не восстанавливались, нельзя считать бэкапом.
• Смена паролей после взлома хостера. Пароли админки и базы, ключи API, токены ботов, секреты в переменных окружения. Скомпрометированный сервер не стоит включать как есть, его лучше пересобрать с нуля.
• Короткий TTL у важных записей. Если TTL A-записи несколько часов, переключение на новый сервер тоже расходится несколько часов.

Что мы рекомендуем

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

Если сайт работает на WordPress и для бизнеса критичен, присмотритесь к сайтам на headless WordPress: при такой архитектуре сайт не зависит от доступности CMS и может работать из копии контента. Настроить бэкапы, мониторинг и план восстановления можно в рамках технической поддержки сайта, а переехать от проблемного хостера поможет перенос сайта.