Хостинг не отвечает, а старый сервер недоступен даже администратору. Восстановить сайт на другой площадке можно, если вне старого хостинга сохранились пригодная копия данных, ключи для её расшифровки и доступ к управлению доменом. Сначала нужно поднять закрытую копию и проверить её, затем разрешить переключение адреса и поэтапно вернуть приём заказов. Открытая главная страница ещё не означает, что восстановление завершено.
Кому это актуально и какие риски закрывает план
Этот порядок нужен владельцу сайта или интернет-магазина, который согласует аварийное восстановление с администратором. Его полезно подготовить заранее: во время сбоя не придётся выяснять, у кого домен и где хранится пароль от копий.
Какие риски закрывает
План помогает не запустить устаревшую базу без сверки, не отправить повторно старые письма и платежные запросы, не потерять управление доменом. Он не гарантирует нулевые потери: всё, что появилось после выбранного состояния данных, нужно отдельно найти и восстановить либо признать недоступным.
Если исправной копии или ключа расшифровки нет, перенос на новый хостинг сам по себе данные не вернёт. Сначала выясняют, что сохранилось у провайдера и во внешних системах; обещать полное восстановление до этой проверки нельзя.
1. Соберите доступы и назначьте ответственных
Владелец определяет допустимую потерю данных и решает, когда можно возобновить работу. Администратор отвечает за среду и переключение, разработчик — за запуск приложения, сотрудник, ведущий заказы, — за сверку с учётной системой и оплатами. В небольшой команде роли могут совпадать, но право разрешить запуск должно быть понятным.
Проверка независимости проста: представьте, что старый сервер и его панель недоступны. С другой машины должны быть доступны:
- хранилище копий и отдельный ключ или пароль для расшифровки;
- кабинет регистратора и управление DNS — записями, связывающими домен с адресом сервера;
- почта и резервные способы входа, не зависящие от отказавшего хостинга;
- версия кода, сведения об окружении и защищённый источник настроек приложения;
- кабинеты внешних сервисов, с которыми предстоит сверить данные.
Запишите ответственных и порядок получения доступа в защищённой инструкции. Пароли не включают в общий чек-лист и не пересылают вместе с выгрузкой базы. Оригинал резервной копии сохраняют: все попытки восстановления выполняют на отдельной площадке.
2. Выберите состояние данных, которое бизнес готов принять
Выбирают конкретную копию, а не просто самый новый архив. Нужны её время с часовым поясом, состав, версия приложения и результат проверки. Файлы, база и код должны соответствовать друг другу: свежая база со старым каталогом загрузок может ссылаться на отсутствующие документы.
Если копии хранятся в restic, список снимков позволяет выбрать конкретный ID. Проверка структуры репозитория и проверка всех сохранённых данных — разные операции; успешная проверка хранилища не подтверждает, что приложение запустится. Восстановление направляют в отдельный пустой каталог: согласно документации restic, существующие файлы в целевом каталоге по умолчанию могут перезаписываться.
Для выбранной копии составьте короткую карточку:
- до какого момента подтверждены данные;
- какие файлы и базы входят в комплект;
- какие изменения после этого момента ещё не сверены;
- где искать недостающее: в CRM, учётной системе, кабинете платёжного сервиса;
- кто принимает решение, если часть данных восстановить не удастся.
Например, в кабинете платёжного сервиса может быть успешная оплата, которой ещё нет в восстановленной базе. Это основание для сверки конкретной операции, а не для повторного списания. Не загружайте поверх восстановленного сайта случайный более свежий дамп: сначала установите, какие записи он добавит или заменит.
3. Поднимите сайт в закрытом окружении
Новую площадку выбирают по требованиям приложения: версии языка и базы данных, расширения, фоновые обработчики, файловое хранилище и необходимые ресурсы. Одновременно менять хостинг, версию CMS и структуру базы опасно для диагностики: при ошибке будет сложнее понять, что её вызвало.
До первого запуска закройте доступ посторонним и отключите исходящие письма, реальные платежи, вебхуки — автоматические уведомления другим системам, — обмены и задания по расписанию. Одного запрета индексации недостаточно: он не ограничивает доступ к данным. Для проверки нужны отдельная база и тестовые подключения, которые не меняют рабочую CRM или платёжный кабинет.
Проверьте каталог, поиск, вход в кабинет и сохранность пользовательских файлов. Форму и заказ проверяют на тестовых данных с безопасными приёмниками уведомлений. Результат сверяют в базе: сообщение «успешно» на экране не доказывает сохранение заказа.
Если причина недоступности неизвестна и есть признаки взлома, копию нельзя автоматически считать чистой. Сначала проверяют её происхождение и изменения кода; скомпрометированные доступы заменяют. Восстановление из копии и устранение причины инцидента — отдельные задачи.
4. Подготовьте домен, HTTPS и решение о переключении
До изменения публичных записей администратор проверяет новый сервер под рабочим именем сайта в закрытом режиме. Так можно заметить ошибки перенаправлений, cookies, ссылок и сертификата, которые не видны при открытии по IP-адресу.
Для HTTPS нужен действующий сертификат и правильная настройка TLS — защищённого соединения. Документация Let’s Encrypt предусматривает подтверждение владения доменом через DNS, в том числе когда веб-сервер закрыт от публичного доступа. Возможность этого способа и автоматического продления проверяют у используемого DNS-провайдера.
Что запросить у подрядчика перед запуском
Пройдите чек-лист вместе; напротив каждого пункта нужны ответственный и подтверждённый результат.
- Копия и данные — администратор и владелец: зафиксированы ID и время состояния, расхождения перечислены, решение по ним принято.
- Приложение — разработчик: основные сценарии прошли закрытую проверку, рабочие внешние вызовы были отключены.
- Домен и HTTPS — администратор: определены нужные DNS-записи, сертификат проверен, почтовые записи сохраняются.
- Заказы и оплаты — ответственный за операции: понятен порядок сверки пропущенных и повторных событий.
- Разрешение запуска — владелец: согласованы оставшиеся ограничения, наблюдение после запуска и условия повторной остановки.
DNS не переключается мгновенно у всех посетителей. Значение TTL задаёт срок хранения ответа в кэше; его уменьшение во время аварии не удаляет ответы, уже сохранённые ранее. Проверьте не только IPv4-запись, но и IPv6, адрес сервера за CDN или прокси, если они используются. Не меняйте всю DNS-зону без необходимости: можно нарушить работу почты и других сервисов. Если DNS тоже обслуживает недоступная площадка, сначала подготовьте полный набор записей у доступного провайдера. Смену обслуживающих серверов и настройки DNSSEC — проверки подлинности DNS-ответов — должен согласованно выполнить специалист через регистратора.
Если старый хостинг недоступен, возврат его адреса не является рабочим планом отката. Нужен сценарий остановки приёма новых данных на новой площадке, сохранения уже поступивших заказов и продолжения исправлений без их перезаписи старой копией.
5. Возвращайте интеграции по одной и подтвердите результат
После переключения проверьте доступность из разных сетей и убедитесь, что ответы приходят с нужной площадки. Просмотр каталога, приём заказов и обмен с внешними системами можно разрешать отдельными этапами — по готовности соответствующих проверок.
Не запускайте восстановленную очередь целиком вслепую. В ней могут оставаться задания на письма, изменение статусов или платежные действия, которые уже выполнились до сбоя. Сначала сверяют события с внешней системой и определяют, какие повторные операции безопасны. Затем возвращают обработчики и расписание по одному, наблюдая за результатом.
Восстановление можно принять, когда подтверждены три вещи: сайт доступен по правильному домену с исправным HTTPS; новые данные сохраняются и доходят до нужных систем; расхождения за период сбоя разобраны или имеют согласованный план. Дополнительно проверьте, что резервирование уже работает с новой площадки и уведомления об ошибках получает ответственный.
Частые вопросы
Можно ли переключить домен сразу после загрузки файлов?
Только после проверки приложения, данных и HTTPS. Файлы без подходящей базы, настроек и окружения могут дать работающую главную страницу и неработающий заказ.
Что делать, если старый сервер внезапно вернулся?
Не разрешать двум независимым копиям одновременно принимать заказы. Определить единственный рабочий экземпляр, ограничить запись на старом и сверить данные, которые могли появиться там во время переключения.
Нужно ли сразу запускать все фоновые задания?
Нет. Сначала выясняют их назначение и состояние внешних операций. Повторная обработка старого задания может отправить лишнее уведомление или повторить действие с заказом.
Когда достаточно своего администратора?
Когда команда может извлечь копию независимо от старого хостинга, показать закрытый запуск, объяснить расхождения данных и выполнить согласованный план переключения. Если неизвестны зависимости приложения, состояние оплат или поведение очереди, к этим проверкам нужен профильный специалист.
Как это решает OpenStart
В задачи поддержки сайта OpenStart входят резервные копии, контроль доступности и исправление сбоев сайта и интеграций. Для восстановления на другой площадке состав работ согласуют по фактическому состоянию проекта: доступным копиям, окружению и критичным сценариям. Срок реакции на обращение не равен сроку полного восстановления.
Первым этапом может быть оценка пригодности копии и плана запуска. Для обсуждения достаточно описания CMS, времени последней копии и того, какие сервисы недоступны; пароли и базу с данными в первоначальную заявку передавать не нужно. После обращения менеджер уточнит ограничения и согласует следующий шаг.