Beget не работает: что делать, если сайт недоступен

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

Если сайт на Beget не работает, сначала проверьте официальный статус, домен, DNS и ответ сервера, затем сохраните доступные данные и обратитесь в поддержку. Восстановление копии выполняйте отдельно от рабочей версии. При отсутствии бэкапа 404ai может оценить веб-архив и пересобрать сохранённую публичную часть; база и серверные функции требуют других источников.

Сбой Beget в ноябре 2026: что подтверждено

В официальном сообщении Beget говорится об атаке на инфраструктуру в ночь с 1 на 2 ноября 2026 года. В обновлении канала провайдера от 7 ноября восстановительные работы продолжались. Этот материал подготовлен 8 ноября: он помогает принять решения владельцу сайта, но не является поминутным мониторингом. Доступность конкретного аккаунта, сервера и его копий нужно уточнять отдельно.

Здесь важна разница между двумя вопросами. «У провайдера произошёл инцидент?» — да, есть его публичное подтверждение. «Мой сайт сейчас не открывается именно по этой причине, и данные потеряны?» — для такого вывода нужны проверки. Неправильная DNS-запись после поспешного переезда способна продлить аварию уже вашими собственными силами. Причём сервер к этому моменту может прекрасно работать.

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

У нас в 404ai можно обсудить восстановление сайта и его пересборку: сначала проверим доступы, копии и сохранённые страницы, затем определим, что можно вернуть и что потребуется разработать заново. Если бэкапов нет, отдельно оценим веб-архив; полное восстановление заранее не обещаем.

Нужна помощь с вашим сайтом? Оставить заявку на восстановление можно прямо на этой странице. Укажите домен и способ связи — сначала оценим доступные материалы и согласуем следующий шаг.

Первые действия: сохранить данные и управление

Назначьте одного человека, который ведёт технические изменения, и одного — коммуникацию с клиентами. Совмещение возможно в небольшой компании, но решения всё равно записывают. В журнале нужны время с часовым поясом, наблюдение, действие, исполнитель и результат. «Сайт не работал утром» непригодно для сопоставления с логами. «В 09:20 МСК главная вернула 502 из офисной сети и мобильного интернета» уже можно проверять.

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

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

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

Как понять, где именно перестало работать

Проверяйте цепочку снаружи внутрь: доменное имя, DNS, соединение, HTTPS, веб-сервер, приложение, база, внешняя интеграция. Один симптом не доказывает причину. Ошибка 502 часто означает проблему между прокси и приложением, но сама по себе не говорит об уничтоженной базе. Отсутствие DNS-ответа не доказывает, что сервер с файлами пропал. А просроченный сертификат не исправляется переустановкой CMS.

Для первичной проверки инженер может использовать nslookup example.com и curl -I https://example.com/. В примерах example.com — заменитель вашего домена. Ответ на HEAD полезен для заголовков, но не доказывает работоспособность страницы: некоторые приложения обрабатывают HEAD и GET по-разному. Поэтому затем открывают реальную страницу обычным запросом, проверяют содержимое и ключевое действие. Команды не меняют сервер, но их результаты всё равно интерпретируют в контексте.

Сравните офисную сеть и мобильный интернет. Откройте известный внутренний URL, а не только корень. Если недавно меняли записи, запишите, какой DNS-сервер отвечает и какое значение он возвращает. Разные ответы могут объясняться кешированием, однако привычное «подождите DNS» не должно заменять проверку авторитетных серверов. Ждать распространения неверного IP — отдельный, очень терпеливый способ ничего не восстановить.

Проверку по IP выполняют с учётом виртуального хостинга и имени сайта. Пустая страница при прямом открытии адреса сервера не обязательно означает неисправность: серверу может требоваться правильный Host и имя для TLS. Не отключайте проверку HTTPS у настоящих клиентов, чтобы замаскировать проблему. Для диагностики используется контролируемый технический маршрут, а для запуска — корректный сертификат на нужный домен.

Поддержка: какое обращение экономит время

В разделе помощи Beget описана работа с тикетами. Если панель недоступна, актуальный внешний способ связи берите с официальной страницы контактов, открытой самостоятельно. Не переходите к «аварийному менеджеру» из случайного комментария. Во время массового инцидента сообщение «мы сохранили вашу базу, оплатите восстановление по ссылке» заслуживает проверки отправителя, а не немедленной оплаты.

Содержательный запрос выглядит так: «Аккаунт такой-то, услуга такая-то, домен такой-то. С указанного времени получаем такой ответ. Панель доступна или недоступна. Просим подтвердить состояние сервера, наличие копий, их даты и способ безопасного получения. Данные не перезаписывать без согласования». Приложите короткие результаты проверок без секретов. Номер тикета сохраните рядом с журналом инцидента.

Разделите просьбу восстановить сервис и просьбу предоставить данные. Провайдер может ещё не запустить ваш сайт, но уже иметь возможность передать архив. Или вернуть панель без готовой базы. Для бизнеса эти варианты дают разные пути продолжения. Вопрос «когда всё заработает?» понятен эмоционально, но для собственного плана полезнее уточнить доступный сейчас результат: выгрузка, файловая копия, дамп, состояние домена или работающий сервер.

Не превращайте отсутствие индивидуального срока в придуманное обещание своим покупателям. Лучше сообщить время следующего обновления статуса: «Проверяем доступность и резервную площадку, следующая информация в 15:00». Это обязательство, которое компания контролирует. Формулировка «через час точно восстановим» превращает неопределённость инфраструктуры в вашу собственную просрочку перед клиентом.

Ждать восстановления или поднимать резервную площадку

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

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

Для условного каталога без онлайн-оплаты допустим ранний запуск подтверждённых страниц и рабочего контакта. Для магазина с личными кабинетами и оплатой этого недостаточно: нужны состояние заказов, сверка платежей и корректные уведомления. Решение о частичном запуске должно описывать, что доступно посетителю. Не рисуйте работающую кнопку «Оплатить», если за ней пока только надежда на следующую итерацию.

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

Если есть бэкап: проверьте его до переключения

Слово «бэкап» должно сопровождаться датой, составом и результатом проверки. Архив файлов без базы может вернуть дизайн и картинки, но не содержимое каталога. Дамп без загружаемых файлов оставит карточки без фотографий и документов. Копия без ключей шифрования может оказаться недоступной. Запишите, какие части подтверждены, а какие только ожидаются от поддержки.

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

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

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

Если бэкапа нет: что можно вернуть через веб-архив

Проверьте рабочие компьютеры разработчиков, репозиторий, экспорт CMS, материалы редакции, сохранённые изображения и предыдущие сборки. Затем смотрите публичные снимки в Wayback Machine. В справке Internet Archive объясняется, почему части сайта могут отсутствовать. Наличие главной в календаре ещё не означает, что сохранены все страницы и зависимости.

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

В 404ai можем оценить сохранность материалов и пересобрать доступную публичную часть на новом размещении. Отдельно согласуем недостающие блоки, новые формы, структуру адресов и проверки. Для оценки достаточно начать с домена и описания, что перестало работать; пароль в публичной заявке не нужен. Объём и сроки определяются после просмотра источников, а не по факту появления сайта в архивном календаре.

Полный порядок — в разборе восстановления сайта из веб-архива. Приоритет аварийной версии — вернуть важные страницы и подтверждённый канал связи. Полный редизайн лучше вынести в отдельную задачу. Иначе срочное восстановление внезапно превращается в обсуждение оттенка кнопки, пока покупатели продолжают видеть ошибку.

DNS, HTTPS и поиск: возвращаем прежний адрес

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

Перед изменением DNS сохраните существующую зону. В ней могут находиться почтовые MX, проверки владения, TXT для защиты почты и другие записи, которые не относятся к веб-серверу. Замена всей зоны шаблоном ради одной A-записи способна остановить то, что пережило исходную аварию. Меняйте только необходимое, записывайте прежнее значение и проверяйте результат снаружи.

Если вместо сайта временно показывается сообщение о технических работах, корректно настройте HTTP-статус. Для короткой недоступности Google рекомендует 503, а не индексируемую заглушку с 200. Длительный простой всё равно несёт поисковые риски. Нельзя обещать сохранение позиций только потому, что выставлен правильный код. После восстановления проверяют доступность важных URL и отчёты поисковых систем.

Не закрывайте основной домен через robots.txt ради борьбы с аварией. Роботу тогда труднее увидеть восстановленные ответы. Защита тестового стенда и доступность публичного сайта решаются отдельно. Для удалённых страниц выбирают корректный ответ или содержательно подходящий редирект; отправлять все потерянные адреса на главную — плохая замена карте восстановления.

Как принять восстановление, а не просто увидеть главную

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

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

После переключения наблюдайте ошибки, доставку обращений, новые записи и нагрузку. Ограничьте изменения на период приёмки, чтобы новый дефект можно было связать с конкретной причиной. Запишите фактический простой и обнаруженный разрыв данных. Эти величины полезнее впечатления «вроде быстро подняли». Они показывают, что требуется улучшить в следующем резервном контуре.

Что изменить после инцидента

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

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

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