Обновлено 6 ноября 2026 года. Официальные сообщения проверены в 19:41 МСК; последнее найденное обновление Beget опубликовано 6 ноября в 18:04 МСК.
Что изменилось 6 ноября. По уточнённой оценке Beget, файловые копии сможет получить только половина пользователей VPS. Компания заново строит облачную инфраструктуру; это не означает уничтожение всех её сервисов. На виртуальном хостинге уже запущено более 60%. Полное восстановление проектов хостинга обозначено как цель, а не завершённый результат. Сообщение Beget
Сайт не открывается, клиенты ждут ответа, а вы пытаетесь понять главное: можно ждать восстановления — или пора собирать проект из того, что сохранилось у вас? После нового сообщения Beget ответ зависит не только от вида услуги, но и от подтверждённого наличия копии именно вашего ресурса.
Для бизнеса важно вернуть связь с покупателями, найти оплаченные заказы и сохранить доступные данные. Это можно делать параллельно с работами провайдера. Даже если полной копии сайта нет, информация в CRM, учётной системе, платёжном сервисе и у разработчика может помочь восстановить часть функций и разобраться с обязательствами.
С чего начать в вашей ситуации
| Где был размещён проект | Ближайшее действие |
|---|---|
| Виртуальный хостинг | Уточните статус своего сервера и доступность копии. Если сайт заработал, проверьте данные и путь до заявки или покупки |
| VPS, независимая копия есть | Проверьте её дату и состав, подготовьте восстановление в отдельном окружении и сверку недостающих данных |
| VPS, доступной копии нет | Запросите подтверждение по своему ресурсу и одновременно соберите независимые источники. Общая оценка провайдера не определяет судьбу конкретного архива |
Ниже — текущие сведения по услугам, объяснение объявленных сроков и последовательность восстановления. Практическая часть включает проверку бэкапа, перенос, сверку оплат, почту, SEO и чек-лист перед возвращением рекламы. Начните с пяти действий, которые можно организовать уже сейчас.
Что сделать сейчас, пока сайт не работает
- Установите, что именно сломалось. Сайт целиком, оплата, почта, сервер или только панель? Найдите название услуги и её ID в счёте или переписке. Ошибка 502 сама по себе не объясняет причину, а доступность главной страницы хостинга ничего не говорит о вашем проекте.
- Остановите расходы на неработающие сценарии. Приостановите рекламу и рассылки, ведущие на недоступные страницы или в сломанную корзину. Проверьте путь до заявки или покупки, а не только посадочную страницу.
- Верните клиентам возможность связаться с вами. Укажите действующий телефон, мессенджер или независимую почту в доступных каналах компании. Отправьте туда пробное обращение: оно должно дойти до конкретного сотрудника.
- Соберите копии и сведения о данных. Попросите разработчика назвать место хранения, дату и состав каждого архива. Сохраните исходники отдельно; проверять восстановление нужно на дубликате.
- Назначьте ответственного за изменения. Он согласует действия исполнителей и записывает, что изменено, когда и с каким результатом. Особенно важно исключить одновременное переключение DNS и восстановление разных баз несколькими людьми.
Не переустанавливайте сервер и не удаляйте доступные файлы ради проверки гипотезы. Сначала администратор должен сохранить то, что ещё можно использовать. К концу первого разбора у вас должны быть три вещи: перечень неисправностей, работающий контакт для покупателей и человек, отвечающий за следующий шаг.
Ждать Beget или восстанавливать сайт самостоятельно
Ответ зависит прежде всего от данных, которыми вы располагаете. Покупка нового сервера даёт площадку для запуска, но не возвращает базу и файлы. Смена DNS тоже только направляет посетителя по другому адресу: по этому адресу уже должен быть подготовлен сайт или временная страница связи.
Прежде чем выбирать сценарий, откройте счёт или спросите подрядчика: какая услуга используется, где находятся база и загрузки, кто управляет доменом, есть ли копии вне Beget. Домен, сайт и почта могут обслуживаться разными компаниями. Иногда перенос всего проекта не нужен: достаточно восстановить одну зависимость.
| Ситуация | Разумный следующий шаг |
|---|---|
| Есть полная проверяемая копия, доступ к DNS и исполнитель | Оценить независимое восстановление и подготовить тестовый запуск |
| Копия есть, но в ней не хватает свежих заказов | Сначала спланировать сверку; при необходимости запустить каталог без оформления заказа |
| Beget подтвердил копию вашего ресурса, но пока её не выдаёт | Уточнить дату и состав, подготовить окружение и собрать данные после даты копии |
| Наличие копии у Beget не подтверждено | Отправить идентификаторы ресурса, искать независимые источники, организовать резервный приём обращений |
| Сайт уже работает, но повреждена отдельная функция | Проверить её зависимость; полный перенос может не требоваться |
| Пригодная копия не найдена | Определить, что можно восстановить из других источников и что придётся создавать заново |
Есть полная копия и исполнитель — можно готовить независимое восстановление, не дожидаясь общего запуска. Сначала нужно проверить копию в отдельном окружении, затем оценить недостающие данные и только после этого переключать посетителей.
Если Beget подтвердил наличие вашего архива, запросите сведения о его составе и параллельно соберите выгрузки из CRM, учётной системы и платёжного сервиса. Если подтверждения нет, не стройте весь план на ожидании выдачи копии. Если сайт уже работает, ищите конкретную неисправность: например, форма может отправлять заявки через недоступную почту, хотя веб-сервер исправен.
У ожидания должна быть контрольная точка: время следующего обновления статуса и разговора с исполнителем. На этой встрече нужны ответы на вопросы «что удалось получить», «что проверено» и «что мешает следующему шагу». Формулировка «ждём хостинг» без этих сведений оставляет бизнес без плана.
Что произошло с Beget и что известно о восстановлении
Серверная инфраструктура.
Beget сообщил о доступе атакующих к управляющей части инфраструктуры и запуске скриптов удаления данных. Подробный путь первоначального проникновения в проверенных публикациях не раскрыт. Поэтому объяснять случившееся обычной перегрузкой, называть конкретную уязвимость или приписывать атаку определённой группе оснований нет. Сообщение провайдера
В опубликованной хронологии указаны следующие события. Время московское.
| Когда | Что сообщил провайдер |
|---|---|
| 2 ноября, около 02:00 | Предполагаемое начало атаки и получение доступа к управляющим серверам |
| 2 ноября, 02:30 | Запуск вредоносного ПО для удаления данных |
| 2 ноября, около 02:40 | Обнаружение несанкционированного доступа |
| 2 ноября, 02:55 | Отключение серверов от сети для сдерживания атаки |
| 2 ноября, 14:00 | Возобновление работы выделенных серверов без администрирования Beget |
| 2 ноября, 17:00 | Восстановление NS-серверов |
| 3 ноября | Поэтапное возвращение почтовых сервисов, хостинга и управления доменами |
| 4 ноября, 01:00 | Запуск первых сайтов на восстановленных серверах виртуального хостинга |
| 5 ноября, 15:22 | Сообщение о ходе восстановления и предварительных сроках доступа к бэкапам |
| 6 ноября, 18:04 | Уточнение оценки сохранности копий VPS и плана дальнейших работ |
Источники: хронология на сайте Beget, сообщения 5 ноября и 6 ноября. Время начала атаки и её обнаружения сам провайдер обозначает как предположительное.
Состояние услуг: что подтверждено и что уточнить по своему проекту
В таблице указана дата сведений по каждой услуге. Более ранний статус не означает, что с тех пор состояние конкретного ресурса не менялось.
| Услуга | Сообщение провайдера | Что проверить владельцу |
|---|---|---|
| Виртуальный хостинг | 6 ноября: запущено более 60%; для остальных ресурсов требуется восстановление из копий | Состояние своего сервера, дату восстановленной базы, полноту сайта |
| VPS | 6 ноября: копии ожидаются только для половины пользователей | Подтверждение наличия, состав и дату копии именно своего VPS |
| S3 и Kubernetes | 3 ноября заявлена утрата рабочих данных | Независимые выгрузки; сведения о VPS не подтверждают сохранность этих ресурсов |
| Выделенные серверы | 5 ноября: запущены все без администрирования Beget и 40% под его администрированием | Вариант услуги, доступность приложения и его зависимостей |
| Домены и DNS | Работает отдельный интерфейс domains.beget.ru | Доступ к домену и действующие записи |
| Почта | 5 ноября: работают 99% почтовых серверов | Приём, отправку, письма форм и сервисные уведомления |
| Панель и бэкапы | 6 ноября: поэтапный запуск функций, восстановление связей аккаунтов с услугами | Совпадение ресурсов с договором и прежними идентификаторами |
Источники: сообщения 3 ноября, 5 ноября и 6 ноября. Проценты запуска инфраструктуры не позволяют вычислить вероятность восстановления вашего сайта или полноту его данных.
Почему мы изменили сведения о копиях. В раннем сообщении провайдер заявлял о сохранности файловых бэкапов VPS. Новая оценка существенно уже. Прежнее заявление осталось фактом хронологии, но использовать его как подтверждение наличия любой клиентской копии больше нельзя.
Если ресурс не отображается в панели, сверяйте его по старому ID, IP, домену и аккаунту из счёта или переписки. Отсутствие строки в интерфейсе само по себе не устанавливает, есть ли архив. Попросите поддержку подтвердить это отдельно; пароли и секретные ключи для идентификации отправлять не нужно.
Когда всё заработает: к чему относятся объявленные сроки
Единой подтверждённой даты возвращения всех клиентских проектов нет. В сообщении от 6 ноября названы отдельные этапы:
- Хостинг: начало восстановления первых серверов из бэкапов планируется на 7 ноября.
- Скачивание бэкапа хостинга через панель: ориентир — пять дней от сообщения 6 ноября.
- Облако: подключение первых серверов планируется через 1–2 дня; затем интеграция и тестирование.
Это планы провайдера на момент публикации, а не подтверждение готовности функций. Основание и контекст сроков
Ни один из этих ориентиров не означает, что все данные VPS вернутся через два или пять дней. Подготовленная инфраструктура, сопоставленная клиенту копия, работающий сайт и сверенные заказы — разные результаты. Даже полученный архив ещё предстоит проверить и развернуть.
Для своего проекта запрашивайте оценку по четырём этапам:
| Этап | Что должно быть подтверждено |
|---|---|
| Инфраструктура | Сервер доступен, нужные службы запускаются |
| Данные | Копия получена; известны её дата, состав и недостающий период |
| Приложение | Сайт и внешние зависимости работают в проверенном окружении |
| Работа бизнеса | Заявки доходят, платежи сверены, заказы можно выполнять |
Исполнитель может оценить настройку окружения и тестирование, но срок получения ещё недоступного архива останется неизвестным. Пусть эти зависимости будут явно указаны в плане. Если пригодной копии нет, речь уже о пересборке проекта и поиске сохранившейся информации; включение сервера не вернёт удалённые записи.
Сначала сохраните доступные данные и защитите доступы
До восстановления составьте список того, что уцелело: архивы, выгрузки базы, диски, журналы, локальные файлы разработчика, репозиторий и настройки. Для каждого источника запишите дату, место хранения и владельца доступа. Фраза «копирование было включено» должна превратиться в проверяемый ответ: какой файл можно получить и что в нём находится.
Исходные архивы перенесите в защищённое хранилище и работайте с дубликатами. Попросите специалиста зафиксировать контрольные суммы: по ним можно проверить, не изменился ли файл. Ограничьте доступ к копиям участниками восстановления — внутри могут находиться данные клиентов и ключи интеграций. Открытый чат для передачи таких архивов не подходит.
Если предстоит разбор взломанного окружения, согласуйте сохранение дисков и журналов со специалистом по безопасности. Очистка и переустановка могут уничтожить следы, необходимые для расследования. Найденный в интернете «скрипт восстановления» не стоит запускать на единственном сохранившемся экземпляре данных.
Какие пароли и ключи проверить
Панель хостинга — только один из доступов. В конфигурации сайта могли находиться пароли базы и почты, ключи CRM, платёжного сервиса, хранилища, ботов и других интеграций.
Вместе с администратором составьте перечень затронутых доступов и порядок их замены. Отзывайте ключи через проверенные панели соответствующих сервисов с доверенного устройства. Для каждого изменения отметьте, какое подключение нужно обновить, чтобы не оставить восстановленную систему с неработающей интеграцией. Новые секреты должны попадать в проверенное окружение.
Beget рекомендовал заменить учётные данные, которые могли храниться на серверах. Сообщение об отсутствии выявленных попыток скачивания пользовательских данных не доказывает, что утечки точно не было. Позиция провайдера
Если выявлены признаки доступа посторонних к персональным данным, передайте факты ответственному за их защиту и юристу. Оценка таких обстоятельств должна идти параллельно с техническими работами.
Как понять, пригодна ли резервная копия
Независимая копия помогает только тогда, когда известны её состав, дата и порядок восстановления.
Большой архив с надписью «backup» ещё ничего не говорит о возможности вернуть магазин. В нём могут быть шаблоны и изображения, но отсутствовать база с товарами, пользователями и заказами. Проверять нужно состав и пробное восстановление.
| Что нужно | Что может отсутствовать без этой части |
|---|---|
| Код и шаблоны | Страницы, оформление, программная логика |
| База данных | Заказы, пользователи, материалы, настройки и другие изменяемые данные |
| Изображения и вложения | Фотографии товаров, документы, пользовательские загрузки |
| Конфигурация | Подключения к базе и сервисам, настройки приложения |
| Окружение | Подходящие версии языка, базы, расширений и системных служб |
| Внешние зависимости | Поиск, хранение файлов, уведомления, интеграции с учётной системой |
Для WordPress обычно нужны и файлы, и база. Официальная документация рассматривает их как отдельные части резервирования. Репозиторий с темой и плагинами не заменяет базу работающего магазина. Руководство WordPress
Для статического сайта полный набор готовых страниц иногда позволяет восстановить публичную часть быстрее. Но форма обратной связи, поиск или личный кабинет могут обращаться к отдельному сервису. Их наличие нужно проверить, даже если все страницы уже открываются.
Образ сервера, файлы и база решают разные задачи
Образ виртуальной машины обычно содержит состояние её дисков и помогает вернуть окружение ближе к исходному. Файловая копия сохраняет выбранный набор файлов; систему, службы и часть настроек может потребоваться установить заново. Даже подтверждённая файловая копия конкретного VPS не означает, что вы получите готовый сервер со всеми настройками.
Для базы нужен поддерживаемый способ восстановления. Логическая выгрузка и физическая копия требуют разных действий. Произвольное копирование файлов работающей базы не всегда даёт согласованный набор данных. В частности, документация MySQL описывает подготовку физических копий перед запуском. Пояснения MySQL
Уточните у создателя архива формат базы, необходимые версии программ и порядок восстановления. Затем попросите показать результат на тестовом сервере: нужные таблицы, последние записи и работу приложения. Успешная распаковка подтверждает чтение архива, но не полноту проекта.
Чек-лист пригодной копии
- Известны дата, время и часовой пояс создания.
- Понятно, какому сайту или серверу она принадлежит.
- Состав проверен: код, база, загрузки и необходимые настройки.
- Архив полностью скачан, а исходный экземпляр сохранён отдельно.
- Известны необходимые версии программ и способ восстановления базы.
- Выполнена проверка на повреждения и подозрительные изменения.
- Копия развёрнута в изолированном тестовом окружении.
- Проверены важные данные и действия пользователя.
- Зафиксировано, каких новых данных в ней не хватает.
Копия до начала удаления данных тоже требует проверки. Дата архива не доказывает, что к этому моменту в окружении ещё не было посторонних изменений. И наоборот: антивирусная проверка не подтверждает полноту заказов. Это разные проверки с разными задачами.
Копия полная, но старая: определите, какой период нужно восстановить
Допустим, условный магазин сохранил базу 31 октября, а 1 ноября продолжал принимать заказы. После запуска из этой копии покупки за 1 ноября могут отсутствовать, хотя платежи уже прошли и часть товаров отправлена. Проблемный период начинается с даты копии, а не только с момента отключения сайта.
За этот интервал соберите заказы, платежи, отгрузки, изменения остатков, новые учётные записи и загрузки. Сравните данные с CRM, 1С, платёжным сервисом, доставкой и письмами. Источники дополняют друг друга: платёж подтверждает операцию, но не обязательно содержит состав корзины.
Перед импортом определите правила сопоставления записей. Добавление всех выгруженных заказов подряд создаёт дубли, а полная замена таблиц способна стереть новые обращения. Разработчик должен проверить объединение на копии и показать, какие записи добавлены, совпали или требуют ручного решения.
Остались файлы или код: обозначьте границу восстановления
Попросите разработчика перечислить функции, которые можно вернуть из доступного набора. Публичные страницы иногда удаётся запустить отдельно, а форму подключить к работающему сервису. Каталог, личные кабинеты и история покупок могут зависеть от отсутствующей базы.
Если цены, остатки или оплата не подтверждены, отключите оформление заказа и дайте действующий контакт. Для доступа к ранее оплаченным материалам понадобится отдельная сверка прав пользователя. Не выдавайте неполную копию за готовый магазин.
Копия не найдена: проверьте независимые источники
Если пригодного архива нет, используйте отдельную инструкцию: как восстановить сайт после потери данных Beget без полного бэкапа. В ней — поиск источников, пересборка каталога, сверка заказов и выбор функций для первого запуска.
Посмотрите архивы обслуживания, компьютер прежнего разработчика, выгрузки CMS, репозиторий, облачные диски компании и учётную систему. Уточните у Beget статус конкретного ресурса и зафиксируйте ответ: архив найден, поиск продолжается или восстановление из копий провайдера невозможно. От этого зависит дальнейший план.
Макеты, старые изображения и сохранённые страницы веб-архива помогают пересобрать публичный сайт. Они не восстанавливают заказы, пароли и закрытые разделы. Если других источников нет, часть информации может оказаться невосстановимой — это нужно учитывать в плане и в общении с клиентами.
У исполнителя, обещающего «вернуть любые данные Beget», спросите, откуда именно он собирается их получить. Без сохранившегося источника такое обещание нельзя проверить. Не передавайте коды подтверждения незнакомым людям, предлагающим ускорить выдачу копии.
Готовый запрос в поддержку Beget
Вместо общего «когда заработает?» отправьте сведения, по которым можно определить ресурс и дальнейшие действия.
Здравствуйте. Аккаунт: [логин или номер договора]. Услуга: [тип и ID], сайт: [домен]. После инцидента недоступно: [краткое описание].
Подскажите, пожалуйста:
- Каково состояние именно этой услуги: ожидает запуска, проверяется, требуется восстановление данных?
- Есть ли её резервная копия, за какую дату и время?
- Входят ли в неё база данных, файлы сайта и пользовательские загрузки? В каком формате сохранена база?
- Проверялась ли целостность копии? Можно ли получить её для независимого восстановления?
- Каков порядок получения и где появится следующее подтверждённое обновление?
Независимая копия у нас [есть за дату / не найдена]. Связаться со мной можно по [работающий адрес].
Отправляйте обращение через официальный доступный канал. Не добавляйте пароли, секретные ключи и полные базы клиентов. Сохраните номер обращения и дополняйте его новыми существенными данными, чтобы история вопроса не распалась на десяток одинаковых сообщений.
После проверки копий зафиксируйте короткий итог: что восстановимо, на какую дату, чего не хватает и где искать недостающее. Это основание для решения о переносе и оценки объёма работ.
Как восстановить сайт и переключить его без потери новых данных
До переключения домена восстановленную копию нужно проверить в отдельном окружении.
Следующие шаги предназначены для работы с администратором или разработчиком. Владельцу бизнеса важно согласовать состав проекта, участвовать в проверке заказов и понимать момент, после которого посетители начинают работать с новой системой.
Шаг 1. Составьте карту проекта и распределите проверки
Перечислите сайт, базу, загрузки, DNS, почту, внешние API, фоновые задания и аналитику. Добавьте поддомены: кабинет, магазин или сервис документов могут обслуживаться отдельно. Для каждого элемента нужны место размещения, доступ и способ проверки.
Назначьте одного человека на переключение, другого — на проверку клиентских действий. Администратор проверяет сервер и подключения; сотрудник магазина сверяет цены, способы доставки и статусы реальных заказов. Договоритесь, кто разрешает открыть продажи и по каким результатам.
Шаг 2. Подготовьте чистое окружение
Установите необходимые версии языка, базы и системных служб. Не переносите неизвестные системные файлы с пострадавшего сервера автоматически. Если проект работает на устаревшем ПО, совместимость и обновление нужно оценить отдельно: одновременная смена всех версий усложнит поиск ошибок.
Тестовую копию закройте аутентификацией или сетевыми ограничениями. Метка noindex управляет индексацией, но не защищает данные от просмотра. До проверки отключите реальные рассылки, списания, создание доставок и другие действия внешних интеграций. Развёрнутая старая очередь заданий не должна повторно отправлять сообщения клиентам.
Шаг 3. Проверьте восстановленный проект до изменения DNS
Откройте важные страницы, проверьте данные, вход, поиск, форму и корзину. Посмотрите, куда обращается приложение: восстановленный сайт может продолжать запрашивать изображения, базу или API на недоступном старом сервере.
Подготовка и тестирование новой инфраструктуры до переключения DNS входят и в рекомендации Google по смене хостинга. Порядок переезда без изменения URL
Сохраняйте действующий домен и адреса страниц. Перенос сервера не требует нового домена. Изменение CMS и структуры каталога лучше вынести в отдельную задачу: иначе будет трудно отличить последствия аварии от ошибок переделки.
Шаг 4. Сохраните и проверьте DNS-зону
При переносе проверьте весь путь до сайта: DNS, новый сервер, приложение и его зависимости.
Если меняется только веб-сервер, может быть достаточно исправить его адрес в существующей зоне. Смена NS затрагивает обслуживание всей DNS-зоны. Перед любыми изменениями сохраните текущие записи, включая настройки почты и поддоменов.
Администратору нужно проверить:
- A и AAAA для основного адреса и www;
- MX, отвечающие за приём почты;
- SPF, DKIM и DMARC для почтовых проверок;
- поддомены и записи подтверждения владения внешними сервисами;
- DNSSEC, если защита включена;
- сертификат HTTPS на новом сервере.
Старая AAAA-запись может отправлять посетителей по IPv6 на прежний сервер, даже если A-запись уже изменена. Ошибка при переносе DNSSEC способна нарушить проверку домена. Проверять нужно всю конфигурацию, а не только новую пару NS. Документация DNSSEC
Для доменов под управлением Beget открыт отдельный интерфейс domains.beget.ru. Согласно сообщению провайдера от 3 ноября, он поддерживает и международные домены. Изменения записей влияют на домен, только если тот использует DNS-серверы Beget. Код подтверждения отправляется на почту администратора домена. Официальная инструкция
Если эта почта недоступна, используйте официальный порядок восстановления доступа. Передавать код человеку, который сам предложил помощь в личной переписке, не следует.
Шаг 5. Выберите одну систему для новых заказов
После изменения DNS часть посетителей ещё может попадать на старый сервер из-за сохранённых ответов. TTL задаёт время их кеширования; его уменьшение не отменяет уже сохранённый ответ с прежним сроком. Как работает TTL
Представьте: новый магазин уже принимает заказы, а старый неожиданно вернулся в работу. Если у них независимые базы, покупки начнут расходиться между двумя системами. До переключения определите, какая база основная и где разрешена запись. При необходимости на переходный период ограничьте оформление заказа; техническую схему выбирает разработчик.
Если сайт открывается у вас, но не у клиента, это не обязательно новая авария. Запишите время, URL и ошибку, сравните доступ через другую сеть и передайте сведения администратору. Он проверит DNS-ответы и логи. Повторные изменения записей наугад только затруднят диагностику; универсального срока «ровно сутки» для всех случаев нет.
Шаг 6. Переключите трафик и проверьте рабочий домен
После изменения записей снова пройдите путь клиента. На основном адресе отдельно проверьте HTTPS, изображения, формы и возврат из платёжного сервиса: их настройки могут отличаться от тестового окружения.
Зафиксируйте время запуска и сохраните исходную конфигурацию. План исправления должен учитывать новые данные. Если после переключения уже появились заказы, простой возврат DNS назад оставит их в другой базе. Сначала сохраните и согласуйте эти записи, затем выполняйте выбранный вариант отката.
Результат этого этапа — один согласованный источник новых заказов и проверенный путь от страницы до обращения или покупки. Если часть функций ещё закрыта, опишите ограничения на сайте и передайте их сотрудникам.
Как сохранить обращения и разобраться с оплаченными заказами
Заказы, оплаты и отгрузки нужно сверить отдельно от технического запуска сайта.
Пока разработчик занимается сервером, команда может уменьшить потери от простоя. Для этого нужны работающий канал обращений и отдельная сверка обязательств перед покупателями.
Организуйте временный приём обращений
Выберите телефон, мессенджер компании, независимую почту или доступную CRM. Назначьте сотрудника и время ответа. В журнале фиксируйте дату обращения, номер заказа, контакт, суть вопроса, статус проверки и ответственного. Ограничьте доступ к журналу; реквизиты карт, пароли и лишние документы для такой работы не нужны.
Если принимаете новые заказы вручную, заранее определите их нумерацию и будущий перенос в основную систему. Сохраняйте связь между временным номером, оплатой и контактом покупателя. Это избавит от поиска владельца платежа после запуска сайта.
Сообщите клиентам, что им делать
Полезное сообщение отвечает на три вопроса: что сейчас доступно, куда обращаться и когда ждать следующей информации. Техническую хронологию можно оставить по ссылке.
На сайте временно недоступны оформление заказа и личный кабинет. Мы восстанавливаем работу после инцидента у хостинг-провайдера.
Если вы уже оплатили заказ, не оплачивайте его повторно. Напишите нам [проверенный контакт] и укажите номер заказа. Мы сверим платёж и сообщим статус.
По новым заказам и другим вопросам можно обратиться [контакт, часы работы]. Следующее обновление о работе сайта опубликуем [дата и время].
Используйте этот текст только после проверки перечисленных контактов и функций. Если заказы уже принимаются, измените первую строку. Не обещайте, что все данные сохранены, пока это не подтверждено для вашего проекта.
Время следующего сообщения выбираете вы: его можно соблюдать даже без новых сведений от хостинга. Дату полного восстановления, которой вы не знаете, сообщать не нужно.
Оплата есть, заказа нет: порядок сверки
Платёж и запись в базе магазина — отдельные события. Деньги могли поступить, пока сайт не получал уведомления. Или заказ существовал, но исчез после восстановления старой базы. Просить человека оплатить повторно до выяснения обстоятельств нельзя.
- Выгрузите операции за проблемный период. Учитывайте время после даты восстановленной копии, а не только часы недоступности сайта.
- Проверьте платёж в кабинете сервиса. Сопоставьте идентификатор операции, сумму, время, номер заказа и доступные сведения о покупателе. Скриншот клиента помогает найти операцию, но не заменяет её проверку.
- Установите состояние заказа. Есть ли запись в магазине или CRM? Известен ли состав? Был ли товар отправлен или доступ уже выдан?
- Согласуйте дальнейшее действие. Восстановление заказа, исполнение или возврат должны учитывать и оплату, и отгрузку. Иначе можно одновременно вернуть деньги и отправить товар.
- Зафиксируйте результат и ответьте покупателю. Нерешённые случаи оставьте в отдельном списке с ответственным и следующим действием.
Проверьте доставку платёжных уведомлений с разработчиком. Они не обязательно повторяются бесконечно: например, ЮKassa указывает повторную доставку в течение 24 часов, если не получено успешное подтверждение. После многодневного простоя нужна сверка через кабинет или API. Правила своего сервиса уточняйте отдельно. Документация ЮKassa
Перед повторной обработкой событий убедитесь, что одно уведомление не создаёт второй чек, отгрузку или выдачу доступа. Проверьте и номера новых заказов: старая база может повторно использовать идентификаторы, которые уже были выданы после даты копии.
Согласуйте остатки и направление обмена
Для каждого вида данных выберите основной источник. Например, подтверждение платежа берётся из платёжного сервиса, а сведения об отгрузке — из учётной системы. Конкретный выбор зависит от того, как устроен ваш бизнес.
Не включайте обмен старой базы с актуальной CRM или 1С вслепую. Сначала сохраните выгрузки и выясните направление синхронизации. Иначе устаревшие остатки и статусы перезапишут более свежую информацию. Конфликтующие записи должен видеть ответственный сотрудник, а не только разработчик.
Проверьте почту по четырём сценариям
Отправьте письмо с внешнего адреса, ответьте на него, заполните форму сайта и вызовите сервисное письмо покупателю. Открытый webmail не подтверждает работу всех этих путей.
Если письма не дошли, администратору нужны очереди и ошибки доставки. Часть отправителей могла получить отказ, часть сообщений могла остаться на повторной отправке. Обещать возвращение всех писем периода простоя нельзя. Важным клиентам, не получившим ответа, предложите повторить обращение через работающий канал.
Отдельно проверьте восстановление пароля, регистрацию и приглашения сотрудников. Они могут использовать старое SMTP-подключение, хотя обычная переписка уже работает.
Что делать с SEO после простоя
Для поиска важно вернуть полезные страницы по прежним адресам. Срок возвращения позиций заранее неизвестен; настройка, которая гарантированно сохранит их при длительной недоступности, отсутствует.
Выберите корректный режим на время работ
Для краткого полного отключения Google рекомендует ответ 503, например на один-два дня, и предупреждает о последствиях более долгого простоя. Если можно безопасно оставить каталог и тексты доступными, отключив покупку, это предпочтительнее полного исчезновения сайта. Рекомендации Google
503 не сохраняет страницы в поиске на неопределённый срок. При затяжном восстановлении определите с разработчиком и SEO-специалистом, какие разделы можно вернуть, что допустимо показать посетителю и какие действия пока закрыть.
Не заменяйте все URL одной заглушкой с кодом 200, не перенаправляйте весь каталог на главную и не ставьте рабочему домену noindex, чтобы «поисковик пока не смотрел». Такие изменения могут добавить проблемы с индексацией. Временная страница контактов помогает людям связаться с компанией, но не заменяет содержимое сотен товарных страниц.
Проверьте важные URL и измерение трафика
Составьте список главных услуг, категорий, товаров и статей из аналитики, sitemap и панелей поисковых систем. Для каждой страницы проверьте:
- прежний адрес и соответствующее ему содержимое;
- тексты, изображения и внутренние ссылки;
- ответ сервера, title, один H1 и canonical;
- отсутствие случайного noindex и ссылок на тестовый домен;
- мобильную версию и перенаправления.
Защиту тестовой копии оставьте на месте, а с готовой рабочей версии уберите случайно перенесённые ограничения. Убедитесь, что счётчики фиксируют контрольное посещение и отправку заявки. Падение визитов на графике может означать и недоступность страниц, и неисправность измерения.
В Яндекс.Вебмастере и Google Search Console проверьте обход и индексацию важных URL. Запишите даты простоя и переключения, после исправления запросите переобход доступными средствами. Принятый запрос не гарантирует немедленную индексацию или возврат позиций. Если снижение сохраняется, используйте пошаговый разбор причин падения позиций.
Чек-лист перед возвращением рекламы и обычной работы
Записывайте результат каждой проверки: кто её выполнил, когда и что осталось исправить.
Пройдите проверки вместе с исполнителем. Для каждого пункта записывайте результат, дату и проверявшего. Неработающей функции нужны понятное ограничение и ответственный за исправление.
Страницы и данные
- Открываются главная, важные разделы, категории и карточки.
- Изображения, документы и пользовательские загрузки доступны.
- Поиск и фильтры возвращают ожидаемые результаты.
- Цены, остатки, условия оплаты и доставки актуальны.
- Известна дата восстановленной базы и проверен период после неё.
- Нет неожиданных пользователей, изменений прав и посторонних материалов.
Обращения и продажи
- Тестовая заявка дошла до ответственного сотрудника и сохранилась в нужной системе.
- Корзина и оформление проверены на компьютере и телефоне.
- Проверен платёжный сценарий согласованным способом: в тестовом режиме, а при необходимости — контролируемой реальной операцией.
- Статус оплаты совпадает в платёжном сервисе, магазине и CRM.
- Не возникают дубли заказов, уведомлений и отгрузок.
- Работают письмо покупателю, восстановление пароля и личный кабинет.
- Временные ручные заказы перенесены или поставлены на отдельный контроль.
Техническая готовность
- Рабочий домен и поддомены направлены туда, куда запланировано.
- HTTPS исправен, браузер не предупреждает о сертификате.
- Внешние API, почта, фоновые задания и обмен с учётной системой проверены.
- Нет запретов индексации, случайно перенесённых с тестовой копии.
- Счётчики и цели аналитики фиксируют контрольные действия.
- Затронутые доступы проверены; новые секреты не размещены в недоверенном окружении.
- После стабилизации создана независимая копия и проверено её чтение.
- Настроено наблюдение за доступностью и важными действиями пользователя.
Рекламу включайте по готовности конкретного сценария. Рабочая заявка на услугу и сломанная корзина магазина требуют разных решений для кампаний. Если заказ пока принимается вручную, это должно быть ясно покупателю до отправки обращения.
Дополнительные проверки метаданных и индексации собраны в чек-листе SEO перед запуском.
Что изменить, когда работа восстановлена
Завершите инцидент коротким разбором: что остановило бизнес, какие данные удалось получить, что пришлось собирать вручную и где потеряли время. Из этого должны получиться назначенные задачи, а не только архив переписки.
Храните копии независимо и проверяйте восстановление
Архив в соседней папке пропадёт вместе с сервером. Отдельное хранилище тоже уязвимо, если удалить копии можно теми же скомпрометированными ключами. Обсудите разделение доступов, хранение нескольких версий и защиту части архивов от изменения и удаления.
Включите в резервирование базу, загрузки и настройки, необходимые для работы проекта. Для базы используйте поддерживаемый способ получения согласованной копии. Затем проведите пробное восстановление в отдельном окружении: измерьте время, запишите нужные доступы и проверьте действия пользователя.
Определите допустимую потерю данных и время простоя
Спросите себя: изменения за какой период сотрудники смогут восстановить вручную и сколько времени бизнес выдержит без основной функции? Сопоставьте ответы с частотой копирования и результатом тестового запуска.
Если магазин готов вручную сверить покупки за несколько часов, а база копируется раз в неделю, схема не соответствует задаче. Сайту с редко меняющимися текстами может подходить другой режим. Расписание и инструменты выбираются под реальные изменения проекта.
Следите за тем, ради чего клиент приходит на сайт
Кроме доступности страницы контролируйте доставку формы, работу корзины, платёжной интеграции и обмена остатками — в зависимости от проекта. Проверки не должны создавать нежелательные реальные списания и отгрузки.
Назначьте получателя уведомлений и канал, независимый от проверяемой системы. Сообщение об отказе почты, отправленное только на эту же почту, может остаться незамеченным.
Сохраните сведения о последствиях
Соберите договор, условия услуги, счета, номера обращений, сообщения провайдера и записи о недоступности. Отдельно зафиксируйте дополнительные расходы, проблемные операции и расчётные потери продаж. Это разные категории: весь недополученный трафик нельзя автоматически считать доказанным ущербом.
Вопросы возможной компенсации оцениваются по договору и обстоятельствам конкретного клиента. При споре передайте материалы юристу; общего обещания выплаты из факта аварии не следует.
Выберите ближайший шаг
Копия не найдена: запросите её статус и соберите независимые источники. Копия доступна: проверьте состав и тестовое восстановление. Сайт запущен: сверьте оплаты и пройдите чек-лист перед включением рекламы. Для выбранного шага назначьте исполнителя и время проверки результата.
Если нужна помощь с техническим состоянием сайта или последствиями для SEO, расскажите G-land о своей ситуации. Укажите, что не работает, какая услуга использовалась и какие копии доступны. Пароли и архивы с данными клиентов к первому сообщению прикладывать не нужно.
Мнение Артёма Канавина
В этой истории меня больше всего волнует момент, когда владелец бизнеса остаётся один с фразой «ждём восстановления». Он продолжает отвечать перед покупателями, платить за работу команды и принимать решения, хотя достоверной информации почти нет. Я считаю, что задача специалиста в такой ситуации — дать человеку опору: что мы знаем, что можем сделать сейчас и от чего зависит следующий шаг.
Я бы оценивал качество помощи по тому, становится ли после разговора понятнее, как действовать. Есть ли список сохранившихся данных? Кто проверяет оплаты? Когда будет следующая информация? Если ответы появились, работа движется, даже когда сервер ещё недоступен. Уверенное обещание срока без этих ответов меня бы насторожило.
Как SEO-специалист, я понимаю тревогу за трафик и позиции. Но сейчас важнее выполнить обязательства перед людьми, которые уже пришли на сайт. Вернуть возможность связаться, найти оплаченный заказ, объяснить задержку. Именно здесь решается, сохранит ли компания доверие, когда техническая часть снова заработает.
После восстановления я бы попросил провести одну практическую проверку: развернуть проект из независимой копии и показать, что из неё действительно можно продолжить работу. Для меня это убедительнее любого отчёта об успешном резервировании. Владелец должен знать, где находится его копия, кто имеет к ней доступ и кто умеет ею пользоваться. Такие вопросы стоит обсуждать ещё при запуске сайта и возвращаться к ним по мере роста проекта.
Артём Канавин, SEO-специалист G-land