Назад в блог
Техподдержка

Один хостинг — одна точка отказа: чему атака на Beget научила бизнес

В ночь на 2 ноября 2026 года злоумышленники добрались до управляющих серверов Beget — одного из крупнейших хостингов Рунета. Через десять дней примерно половина сайтов виртуального хостинга всё ещё ждала восстановления, а данные облака пропали совсем. Разбираем, что произошло, и как устроить сайт, почту и CRM так, чтобы падение одного провайдера не останавливало бизнес.

Большинство компаний держит всё у одного провайдера: сайт, почту на домене, DNS, а иногда и сам домен. Это удобно — один счёт, одна панель, одна поддержка. Пока провайдер работает, о том, что всё лежит в одной корзине, никто не вспоминает.

Атака на Beget показала, во что обходится такое удобство. Ниже — что известно об инциденте на 12 ноября 2026 года, что из этого следует для любого сайта (на 1С‑Битрикс, Laravel, WordPress или самописного) и какие шаги можно сделать уже на этой неделе.

Что случилось с Beget: хронология сбоя

Хронология собрана по официальной странице восстановительных работ Beget и сообщениям компании в Telegram. Время московское.

  1. Злоумышленники попадают в управляющий контур

    Это серверы, через которые администрируется вся инфраструктура хостинга, а не отдельный клиентский сервер.

  2. Запущена программа, которая стирает данные

    Через десять минут взлом замечают, в 02:55 все серверы отключают от сети. Удаление шло примерно 25 минут.

  3. Снова работают NS-серверы

    Домены опять отвечают в сети, но сайты за ними пока недоступны. Днём поднялись выделенные серверы, которые клиенты администрируют сами.

  4. Возвращается почта

    К полудню работает больше 80% почтовой инфраструктуры, к 13:30 — веб-интерфейс почты. Начинается проверка резервных копий. Компания подтверждает: данные облака (VPS, S3, Kubernetes) уничтожены.

  5. Первые сайты на восстановленных серверах

    В ночь на 4 ноября запускаются первые сайты, к вечеру 5 ноября — 60% виртуального хостинга.

  6. Панель и копии VPS

    Выясняется, что файловые копии VPS сохранились только у половины клиентов. 7 ноября открывают панель управления с урезанными функциями, 9 ноября в ней появляется скачивание копий VPS.

  7. Массовое восстановление из бэкапов

    Остальные сайты поднимают из резервных копий: 33 000 уже работают.

  8. Больше 55 000 сайтов, половина работ

    Основную часть Beget рассчитывает закончить примерно за три дня, но называет срок ориентировочным. Скачивание копий VPS из панели временно убрали.

Для части клиентов простой к моменту публикации длится больше десяти дней. Если ваш сайт ещё не вернулся — переходите к разделу «Что делать, если сайт был на Beget».

Сбой Beget в цифрах

540 000

доменов в зоне .ru

Около 14,7% всей зоны по данным StatOnline. Это домены вместе с припаркованными, а не работающие сайты.

334 562

активных сайта

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

9 000

жалоб за первые сутки

Такой поток обращений зафиксировал сервис Detector404.

1 000+

серверов на ручную проверку

Каждый перед запуском проверяли на вредоносный код, поэтому восстановление растянулось.

В новостях встречались и другие оценки — от 400 000 до 700 000 сайтов. Мы опираемся на цифры выше: они посчитаны по понятной методике.

Среди пострадавших оказались не только небольшие сайты. Перебои были у портала системы маркировки «Честный знак», у каршеринга BelkaCar (пользователи не могли завершить аренду), у «РЖД Тура», сайта Омского аэропорта, рекламного портала ADPASS, туроператоров, региональных СМИ и театров.

Что потеряли компании, кроме сайта

Слово «сайт не открывается» сильно преуменьшает масштаб. Для бизнеса, который всё держал у одного провайдера, остановились сразу несколько процессов.

Почта на домене

Больше суток письма на адреса компании не доходили. Это заявки, счета, ответы клиентов и уведомления от банков и маркетплейсов.

Облачные серверы

Данные VPS, S3 и Kubernetes уничтожены. Бинарные копии VPS тоже. Файловые копии сохранились только у половины клиентов.

Управление доменом

В первый день не работала и панель. Отдельный сервис управления доменами появился только 3 ноября — до этого быстро увезти сайт к другому провайдеру было нельзя.

Связи с другими системами

Остановился обмен заказами с 1С, передача заявок в CRM, уведомления платёжных сервисов и служб доставки. Часть данных за эти дни придётся собирать вручную.

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

Деньги за простой вернуть почти не получится. Beget сослался на непреодолимую силу, а компенсации в договорах хостинга обычно ограничены стоимостью самой услуги. Эксперты по безопасности оценивают возможную выплату бизнесу в лучшем случае в несколько тысяч рублей — несопоставимо с потерянными заказами.

Почему не спасли копии хостинга

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

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

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

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

Это не первый такой случай

  • 8 ноября 2026 года, через неделю после Beget, о серьёзном сбое сообщил хостинг-провайдер ESTT, который обслуживает бизнес. Виртуальные серверы поднимали несколько дней, личный кабинет клиентов долго оставался недоступен.
  • В марте 2021 года пожар в дата-центре OVHcloud в Страсбурге вывел из строя миллионы сайтов. Часть клиентов, у которых копии хранились там же, потеряла данные навсегда.
  • Летом 2022 года массовая атака через уязвимость в одном из модулей 1С‑Битрикс уничтожила содержимое многих сайтов. Мы разбирали её в отдельной статье.

Причины разные: взлом, пожар, уязвимость. Вывод одинаковый — инфраструктуру, от которой зависит выручка, нельзя держать в одном месте.

Резервное копирование сайта: что бизнес может сделать сам

Ниже — шаги, которые не требуют переезда на дорогую инфраструктуру. Большую часть можно сделать за неделю, и они подходят для сайта на любой CMS. Если не хочется разбираться самим, настроим резервное копирование под ключ.

Правило 3‑2‑1 без терминов

Три копии данных: рабочая версия и ещё две. Два разных места хранения, а не две папки на одном сервере. Одна копия — у другого провайдера или вообще вне сети. Как это выглядит на практике:

1С‑Битрикс

Штатное резервное копирование по расписанию. Копии отправляются в облако 1С‑Битрикс (объём зависит от лицензии) и дополнительно в хранилище у другого провайдера. Копия должна включать и файлы, и базу данных.

WordPress

Плагин резервного копирования с отправкой архива во внешнее облачное хранилище. Плюс полная выгрузка базы перед каждым обновлением тем и плагинов.

Laravel

Код хранится в репозитории (Git) вне хостинга. База данных и папка с загруженными файлами по расписанию уходят во внешнее хранилище, файл настроек окружения с ключами — отдельно и в зашифрованном виде.

Самописный сайт

Код хранится в репозитории (Git) вне хостинга. Дамп базы и загруженные файлы по расписанию уходят в стороннее хранилище. Настройки сервера описаны так, чтобы его можно было собрать заново.

Копии вне хостинга: где хранить

  • Объектное хранилище у другого провайдера. Это недорогое S3-совместимое хранилище, куда сайт сам отправляет архивы. Ключ доступа выдаётся только на запись, без права удаления. Тогда даже взломанный сайт не сможет стереть свои копии.
  • Версионирование и защита от удаления. Многие хранилища умеют держать несколько версий файла и запрещать удаление на заданный срок, например на 30 дней. Именно такая копия выживает при атаке, похожей на атаку на Beget.
  • Холодная копия. Раз в неделю, в выходной, полный архив сайта отправляется в отдельное S3-хранилище, ключи от которого не хранятся на сайте. Так мы делаем у клиентов на поддержке: даже если взломщик доберётся до сайта и его облачных копий, недельный архив останется нетронутым.

Копия на том же сервере или в той же учётной записи хостинга защищает только от собственной ошибки — например, от неудачного обновления. От сбоя или взлома провайдера она не спасает.

Почту и DNS — отдельно от хостинга сайта

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

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

План восстановления сайта на одну страницу

Задать нужно два вопроса. Сколько часов бизнес может обходиться без сайта? И за какой период данные можно потерять без последствий: за час, за день, за неделю? От ответов зависит, как часто делать копии и нужен ли заранее подготовленный запасной хостинг. Сам план умещается на одну страницу:

  • список всех сервисов: сайт, почта, DNS, CRM, обмен с 1С, формы заявок, аналитика, платежи;
  • где лежит последняя копия каждого из них и как её достать без участия текущего провайдера;
  • кто принимает решение о переезде и кто его выполняет — со своей стороны и со стороны подрядчика, с телефонами;
  • куда переносить: заранее выбранный запасной хостинг с подходящим тарифом;
  • что сделать сразу: поставить рекламу на паузу, предупредить клиентов в соцсетях и мессенджерах, переключить приём заявок на телефон.

Проверка копий и пробное восстановление

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

  • настройте уведомление, если копия не создалась или оказалась подозрительно маленькой;
  • раз в квартал разворачивайте копию на тестовом сервере и проверяйте, что сайт открывается, заказы и формы работают;
  • засекайте, сколько заняло восстановление, — это и есть реальный срок вашего простоя.

Пароли и ключи: сменить и хранить по-новому

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

  • доступ к панели хостинга, FTP и SSH, пароли баз данных;
  • администраторы CMS;
  • ключи API: платёжные системы, CRM, службы доставки, сервисы рассылок, обмен с 1С;
  • пароли почтовых ящиков и SMTP, через которые сайт отправляет письма.

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

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

Что делать, если сайт был на Beget

Если сайт всё ещё недоступен или вернулся частично, идите по шагам.

  1. 1

    Проверьте, что с сайтом в панели

    Зайдите в панель Beget, раздел «Сайты», и в файловый менеджер. Посмотрите, восстановлены ли файлы и база данных и от какого числа копия.

  2. 2

    Заглушка «домен не привязан» — ещё не потеря данных

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

  3. 3

    Привяжите домен заново

    В разделе «Сайты» привяжите домен к восстановленному сайту. Не забудьте вариант с www и поддомены. Откройте сайт в режиме инкогнито, чтобы не смотреть на старую страницу из кэша. Если браузер предупреждает о небезопасном соединении — перевыпустите SSL-сертификат.

  4. 4

    Пройдите сайт как клиент

    Отправьте заявку через форму, оформите тестовый заказ, проверьте оплату, письма с сайта и обмен с 1С и CRM. Восстановление из копии не всегда возвращает задачи по расписанию и настройки почтовой отправки.

  5. 5

    Соберите потерянные заявки и заказы

    Всё, что пришло после даты копии, в ней нет. Сверьтесь с CRM, почтой, личными кабинетами платёжной системы и службы доставки и внесите недостающее.

  6. 6

    Смените доступы и сохраните копию у себя

    Обновите пароли и ключи по списку выше. Как только сайт заработал, сразу скачайте его полную копию и положите вне хостинга.

  7. 7

    Решите, оставаться или переезжать

    Если сайт критичен для продаж, а очередь восстановления ещё не дошла, его можно поднять у другого провайдера из своей копии и переключить DNS. Пока сайт лежит, поставьте рекламу на паузу и следите за ошибками в Яндекс Вебмастере.

Чек-лист: что делать, если упал хостинг, и как подготовиться заранее

10 пунктов на одну страницу

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

Поможем, даже если хостинг уже упал

Подключимся к сайту на 1С‑Битрикс, WordPress или самописному, разберёмся с тем, что осталось, и наладим резервное копирование, которое не зависит от одного провайдера.

Есть своя копия

Перенесём сайт на новый хостинг

Развернём копию у другого провайдера, переключим DNS, проверим формы, оплаты и обмен с 1С. Отдельно настроим почту.

Перенести сайт
Копии нет, сайт на Beget

Вернём сайт в строй

Привяжем домен, перевыпустим SSL, проверим, что работает после восстановления, сменим доступы и включим резервное копирование.

Вернуть сайт
Хотим заранее

Аудит и настройка резервного копирования

Проверим, где лежат копии, почта, DNS и доступы. Настроим копии вне хостинга, проведём пробное восстановление и оставим план на одну страницу.

Заказать аудит

Как мы настраиваем копии вне хостинга и проверяем их — на странице услуги «Резервное копирование сайтов». О сопровождении сайтов — на странице технической поддержки. Сайт на шаблоне Аспро? Резервное копирование для таких сайтов — на нашем сайте об Аспро.

Понравилась статья? Больше разборов — в наших каналах

Давайте обсудим ваш проект

Расскажите о задаче — ответим и предложим, с чего начать.

+7 (4872) 44-05-17mail@imagemark.ruг. Тула, ул. Некрасова, д. 7, офис 311
Скачать презентацию

Заявка на проект