Экспертс
Сервисы

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

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

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

Артем Волков
Системный инженер

Что случилось с Beget 2 ноября 2026 года: хронология, версии и официальные формулировки

Как переехать с Beget: руководство по переносу сайта на другой хостинг
  • Около 03:00–03:50 МСК — первые жалобы на недоступность сайтов и проблемы с маршрутизацией. Пользователи видят 502 Bad Gateway, не открывается панель управления, лежат VPS, DNS и почтовые серверы.
  • 04:50 МСК — компания официально объявляет о «крупном инциденте»: «Задействованы все ресурсы, разбираемся в причинах».
  • К 06:00 МСК — Beget сообщает о восстановительных работах и начале детального расследования. Формулировка, которая войдет в мемы: проблема «носит комплексный характер и затрагивает все уровни архитектуры», инженеры вручную настраивают оборудование непосредственно в дата-центрах.
  • Днем — провайдер признает масштабную аварию и не называет сроков полного восстановления.
  • 15:43 МСК — в официальном канале впервые появляется слово «атака»: инфраструктура «подверглась массированной кибератаке».

По данным детектора сбоев Detector404, жалобы приходили из 33 городов России: 1,7 тысячи за час и 8,3 тысячи за сутки. Среди пострадавших оказались не только частные сайты: на некоторое время перестал открываться сайт государственной системы маркировки «Честный знак», проблемы фиксировались у каршеринга BelkaCar и ряда других платформ.

Что говорят о причинах

Причины официально не названы — компания продолжает расследование и обещает рассказывать о результатах по мере появления подтвержденных данных. В Telegram-канале Beget на момент публикации сформулировано аккуратно: идет разбор причин, работают все ресурсы, точные сроки полного восстановления не называются.

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

Что известно из косвенных признаков:

  1. Перед инцидентом в маршрутизации трафика фиксировалась аномальная активность. По данным RIPEstat, за один час было анонсировано почти миллион запросов на смену маршрутов — при том что за предыдущие 90 дней пиковое значение не превышало 20 тысяч.
  2. Источники «Ъ» на телеком-рынке предполагают, что атакующие могли получить высокие привилегии и сбросить конфигурации оборудования.
  3. Приоритетом восстановления выбраны NS-серверы, почтовая система и резервные копии. Компания заявила, что ей доступны файловые бэкапы «подавляющего большинства» ресурсов виртуального хостинга и облачной инфраструктуры, но объемы такие, что процесс займет длительное время.
  4. Клиентов официально уведомили о форс-мажоре со ссылкой на пункт 3 статьи 401 ГК РФ.

Почему сайты не просто упали, а исчезли

Самый неприятный слой инцидента — DNS. В первые часы браузер хотя бы находил сервер: сайты отдавали 502. Дальше картина сменилась на «Не удалось найти IP-адрес сервера». Технически это означает, что авторитативные NS-серверы Beget перестали отвечать по всем протоколам, а делегирование в зонах .ru и .com при этом осталось целым: записи в реестре есть, оборудование молчит. По мере истечения TTL кэш резолверов пустел, обновлять его было негде — и домены пропадали из интернета целиком.

Отсюда главный системный вывод, который дороже любых версий о причинах: хостинг, DNS, почта и панель управления оказались в одном домене отказа. Если сайт физически живёт у другого провайдера, но делегирование осталось на NS Beget, он тоже недоступен — хотя сервер работает.

И еще один момент, о котором стоит помнить: провайдер с лета 2026 года находится под санкциями ЕС, а предыдущий, куда менее масштабный сбой 2 июня 2026-го был связан с аварией у магистральных операторов связи. Два разных инцидента за пять месяцев — это уже не случайность, а повод задуматься об архитектуре.

Как перевезти сайт с Beget

Сразу оговорюсь: переезд — это не про героизм и не про «успеть за ночь». Это про последовательность. Хостинг — съемная квартира: вы меняете адрес, но вещи должны быть собраны заранее. Домен — это прописка, и ее трогают в последнюю очередь, а не в первую.

Ниже — пошаговая инструкция, рассчитанная на владельца сайта или админа, который делает перенос впервые.

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

Подготовка: зафиксировать факты и остановить утечку денег

Прежде чем что-то менять, узнавайте обстановку:

  1. Проверьте доступность из независимой сети — через check-host.net или мобильный интернет. Если сайт не отвечает отовсюду, а в Telegram-канале провайдера висит сообщение об инциденте, дело не в вашем роутере.
  2. Поставьте на паузу рекламные кампании в Яндекс Директе и VK Рекламе. Каждый клик сейчас ведет на мертвую страницу.
  3. Зафиксируйте хронологию: время падения, скриншоты ошибок, официальные сообщения. Это база для претензии по SLA и расчёта убытков.

Узнать, где живет домен и где лежат NS-записи

Это ключевая строка всей инструкции. Проверьте через whois и dig +trace:

  • если домен зарегистрирован у Beget и делегирован на его NS — быстро переключить трафик не получится, придётся ждать восстановления зоны либо переносить домен к независимому регистратору;
  • если NS внешние (Cloudflare, Яндекс Облако, отдельный DNS-хостинг) — у вас есть рычаг уже сейчас.

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

Собрать данные вне инфраструктуры Beget

Вам нужны копии, к которым есть доступ без панели управления:

  • файлы сайта (архив корня, включая скрытые файлы и конфиги);
  • дамп базы данных;
  • файл DNS-зоны или просто таблица всех записей: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), SRV;
  • действующие SSL-сертификаты и ключи, если они не выпускались автоматически;
  • список cron-задач, версии PHP, MySQL и расширений;
  • архив почтовых ящиков, если почта была на Beget.

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

Выбрать новый хостинг и проверить совместимость

Не хватайте первый попавшийся тариф. Сверьте:

  • версии PHP, MySQL/MariaDB и набор расширений;
  • наличие SSH, cron, поддержку нужных модулей (imagick, ionCube и т. д.);
  • лимиты по диску, inode и почте;
  • поддержку нужной CMS и возможность быстро получить помощь в чате.

Развернуть копию и проверить ее до переключения

Правильно сделанный перенос выглядит так: новый хостинг уже работает, а посетители еще идут на старый.

  1. Загрузите файлы и импортируйте базу.
  2. Поправьте конфиг подключения к БД — обычно это несколько строк в wp-config.php или .env.
  3. Проверьте сайт по временному адресу или через подмену hosts-файла на своей машине.
  4. Прогоните ключевые сценарии: оформление тестового заказа, отправка формы, письма, вход в админку.

Переключить DNS — и только потом трогать регистратора

  • Смените A-запись на IP нового сервера. Если нужно, перенесите MX и TXT.
  • TTL снижайте заранее, за сутки-двое: во время аварии менять его бессмысленно, новое значение просто не опубликуется.
  • Перенос домена к другому регистратору — отдельная процедура со своим сроком. Не совмещайте ее с переключением хостинга: если что-то сломается, вы не поймете, что именно.

Проверить результат и не спешить удалять старое

После переключения проверьте: код ответа 200, корректность редиректов, работу SSL, отправку почты, индексацию. Старый аккаунт не удаляйте минимум 2–4 недели — он ваша страховка. И не забудьте отправить главные страницы на переобход в Вебмастер и Search Console.

Куда переехать с Beget: 5 хостингов, работающих в России

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

  1. Timeweb — хостинг-провайдер с собственной панелью управления и линейкой от виртуального хостинга до выделенных серверов. Принимающая сторона при переезде сайта: файлы, базы данных и почта переносятся в привычную среду, а тариф можно подобрать под нагрузку проекта.
  2. Fornex — работает в основном с виртуальными серверами и держит несколько площадок в Европе, поэтому подходит проектам, которым важна география размещения. Отдельный акцент сделан на защите от сетевых атак и шифровании дисков.
  3. AdminVPS — специализируется на VPS и VDS и выдает сервер сразу после оплаты, что пригодится, когда перенос нужно закончить в сжатые сроки. Клиенту достается полный доступ к серверу и самостоятельная настройка окружения под задачи сайта.
  4. SmartApe — строит услуги вокруг виртуального хостинга и серверов на SSD, делая ставку на понятную панель управления. Проекты на популярных CMS разворачиваются здесь без ручной сборки окружения, что упрощает переезд с другой площадки.
  5. Рег.ру — регистратор доменов с собственной хостинговой инфраструктурой, поэтому переезд сайта можно совместить с управлением доменом и сертификатами в одном кабинете. Виртуальный хостинг и серверы рассчитаны на проекты разного масштаба.

Главный урок 2 ноября простой: план, как перевезти сайт с Бегета, надо держать в голове до аварии, а не после — ровно как огнетушитель покупают не во время пожара. Инцидент показал, что один подрядчик на хостинг, DNS, почту и панель управления — это не удобство, а единая точка отказа, и никакие заверения в надежности ее не отменяют. Правильная схема выглядит скучно: домен у независимого регистратора, DNS отдельно от хостинга, свежие копии данных вне провайдера и короткий TTL перед любыми изменениями. Скучно — зато сайт не превращается в тыкву в три часа ночи.

А как этот инцидент отразился на ваших проектах? Расскажите в комментариях, с какими сложностями при переносе столкнулись вы, и задайте вопросы, если что-то осталось непонятным.