Сайт снова открывается — но это ещё не означает, что в нём на месте все файлы, записи и настройки. После восстановления из копии могли вернуться данные на конкретный момент времени. Поэтому сначала выясните, какую именно копию развернули, за какой период и какие части проекта ещё восстанавливались. Beget в статусе от 10 ноября сообщал о поэтапном восстановлении сайтов и данных из резервных копий; актуальный статус смотрите в официальном канале провайдера.
Сначала выясните границы копии
Запишите дату и время резервной копии, из которой подняли сайт, и попросите поддержку подтвердить, завершены ли все этапы восстановления именно для вашего аккаунта. Сохраните номер обращения и кратко зафиксируйте ответы. Важны не только файлы сайта: отдельно уточните базу данных, почтовые ящики, привязку домена, DNS и SSL. Эти компоненты могли возвращаться поэтапно, а их состояния могут различаться.
Если вы не уверены, что копирование закончено, не делайте повторное восстановление поверх работающего сайта. Сначала скачайте текущие файлы и экспортируйте актуальную базу, если доступ уже открыт. Иначе можно затереть более новые записи, которые появились после предыдущего восстановления. Отдельная копия текущего состояния даёт точку возврата для аккуратной сверки.
Рейтинг хостингов для сайта после сбоя
� �� ����⠭������� �� ��� ᬥ���� ���頤��, �ࠢ������ ���� �� ᮢ���⨬��� � ������, ������ � 䠩��� � ����, ��楤�� ��७�� � �����প�. ���砫� ����� ������� ����⠭�������� ������: ���� ��⨭� �� ����� �����, ������ ��� � ��娢�.
- Timeweb — сопоставьте тариф с CMS, почтой, объёмом базы и нагрузкой.
- МакХост — уточните варианты переноса, доступ к копиям и технические ограничения.
- SpaceWeb — проверьте состав резервирования и возможность тестового запуска.
- Hostland — отдельно сверьте версии PHP, базы, SSL и расписание копий.
- SprintHost — узнайте, какие работы по переезду входят в услугу.
- AdminVPS — подходит для сравнения управляемых вариантов; заранее уточните границы администрирования.
Сверьте файлы, базу и загрузки
Проверьте размер архива и дату его создания, затем сопоставьте основные каталоги проекта со своей последней независимой копией. Для WordPress в первую очередь важны каталог загрузок, тема и плагины, а также база с публикациями, настройками и заказами. Не ограничивайтесь тем, что главная страница открылась: отдельные изображения, вложения и документы могут отсутствовать.
Сравнивайте не только количество файлов, но и выборочные контрольные суммы для важных материалов. Для базы данных проверьте последние записи до и после даты копии, количество заказов, пользователей и заявок. Если у сайта есть внешняя CRM или платёжный кабинет, они могут содержать более свежую историю, чем восстановленная база. Не пытайтесь вручную склеивать таблицы без копии и плана отката.
Проверьте WordPress, домен и адреса
Откройте главную, несколько внутренних страниц, каталог и страницу контактов. Проверьте, что домен привязан к нужной папке, ссылки ведут на правильный адрес, сертификат HTTPS действителен, а редирект с HTTP работает ожидаемо. В WordPress посмотрите постоянные ссылки, меню, язык сайта, виджеты и медиафайлы. Если после аварии изменялись DNS-записи, сверяйте их с сохранённой зоной, а не с памятью.
Проверьте индексационные настройки: случайно включённый запрет индексации может закрыть сайт поисковикам после восстановления. Убедитесь, что robots.txt, canonical, карта сайта и страницы ошибок ведут на правильный домен. Если проект использует кеш или CDN, очистите кеш после подтверждённой сверки, иначе посетители могут видеть старую версию даже при исправных файлах.
Испытайте формы, почту и заказы
Проведите безопасный тест каждой важной формы. Убедитесь, что заявка появляется в админке или CRM, а уведомление доставляется на нужный адрес. Для магазина используйте тестовый режим платёжного провайдера либо согласованный внутренний сценарий — не создавайте случайный реальный платёж. Проверьте карточку заказа, остатки, статусы оплаты и письма покупателю.
При восстановлении из точки до сбоя часть событий могла не попасть в сайт. Перед открытием магазина сравните заказы с кабинетом эквайринга, CRM и журналами доставки. Важна не только сумма: найдите операции, которые прошли по карте, но отсутствуют в магазине, и заказы, которые сайт записал, но не передал в оплату. Ручное исправление фиксируйте по одному идентификатору, чтобы не создать дубль.
Обновите доступы и проверьте события
Недоступность площадки сама по себе не доказывает компрометацию вашего сайта. Но после крупного инфраструктурного инцидента разумно проверить учётные записи, обновить пароли панели, FTP/SSH, базы и WordPress, если они могли быть затронуты или использовались повторно. Включите многофакторную защиту там, где она доступна, и проверьте список администраторов, ключи интеграций и подключённые приложения.
Просмотрите журналы входов и изменения файлов за период восстановления. Не удаляйте подозрительные данные до того, как сохраните копию и зафиксируете время обнаружения. Если нашли неизвестного администратора, изменённый платёжный адрес или скрипт, ограничьте доступ к затронутой части и обратитесь к специалисту. Смена всех паролей без разбора может нарушить интеграции, поэтому составьте перечень зависимостей и обновляйте секреты последовательно.
Когда можно вернуть проект в обычный режим
Составьте короткий акт внутренней приёмки: что сверено, что не удалось проверить, какая копия использована и какие события ещё нужно разбирать. Для сайта-визитки достаточно проверить страницы, форму, почту и доступы. Для магазина дополнительно нужны сверка оплат и остатков, контроль очередей вебхуков и подтверждение, что в систему не попадают дубли.
Назначьте ответственного и срок повторной проверки через сутки. Снимите тестовый бэкап уже восстановленного проекта, сохраните его отдельно от аккаунта хостинга и проверьте, что его можно открыть. Документация WordPress рекомендует резервировать и файлы, и базу; одна только база не содержит тему, плагины и загрузки. Подробнее — в руководстве WordPress по резервированию.
Соберите журнал восстановления
Запишите последовательность событий: когда пропал доступ, когда провайдер сообщил о восстановлении, когда стали доступны файлы и база, какие действия выполняли сотрудники. Укажите источник каждой отметки — письмо, тикет, журнал мониторинга или снимок экрана. Такая хронология помогает отделить установленный факт от предположения и объяснить команде, почему часть содержимого отличается от привычной версии.
Для каждого замеченного расхождения создайте отдельную задачу: адрес страницы или номер записи, что ожидалось, что найдено, дата последней известной правильной версии и владелец исправления. Не поручайте разным сотрудникам одновременно возвращать одно и то же состояние через панель хостера и импорт файлов: это усложняет поиск источника изменения.
Возвращайте посетителей постепенно
Перед обычной работой выберите несколько критичных маршрутов и проверьте их с телефона и компьютера: вход, поиск, форма, оформление заказа и страница подтверждения. Откройте журналы ошибок, посмотрите, не повторяются ли сбои при запросах к базе или файловому хранилищу. На первом этапе попросите коллегу выполнить контрольное действие, которое не создаёт реальный заказ и не списывает деньги.
После запуска наблюдайте за новыми записями и письмами. Если система восстановления предоставляет только архив, сначала разверните его на копии и сравните контрольные файлы. Если восстановление делается через поддержку, запросите точное время снимка и список компонентов, которые были возвращены. Публичная страница может быть доступна, хотя часть фоновых задач или интеграций ещё не восстановлена.
Если проверка выявила пропуски, не загружайте старый архив поверх текущих данных без анализа. Более новая заявка могла поступить после восстановления, и повторный импорт может затереть её. Сохраните рабочую копию, экспортируйте базу и приложите к обращению конкретные URL, временные отметки и идентификаторы отсутствующих записей.
Частые вопросы
Если главная открылась, значит восстановление завершено?
Нет. Проверьте личный кабинет, базы, внутренние страницы, домен, письма, формы и функции, которые важны для бизнеса. Уточните у провайдера, завершена ли работа именно с вашим аккаунтом.
Можно ли сразу принимать новые заказы?
Только после проверки оплаты, уведомлений и сохранности данных. Если восстановленная копия старше момента сбоя, сначала разберите пропущенный период и синхронизируйте заказы.
Нужно ли менять хостинг после сбоя?
Решение зависит от критичности проекта, срока восстановления, качества коммуникации, условий договора и доступности независимых копий. Перед переездом протестируйте новый сайт и предусмотрите обратное переключение.
Источники
- Официальные сообщения Beget о ходе восстановления, проверено 11 ноября 2026 года.
- WordPress: резервное копирование файлов и базы данных.
- WordPress: перенос сайта на новый сервер.