После атаки на Beget: как бизнесу проверить готовность к восстановлению сайта
Отчёт «резервная копия создана» ещё не отвечает на главный вопрос бизнеса: когда снова можно будет принимать клиентов. Архив может сохраниться за недоступной панелью провайдера. А скачанные файлы сайта — оказаться бесполезными без базы с заказами.
В ночь с 1 на 2 ноября 2026 года инфраструктура Beget подверглась кибератаке. По официальной хронологии компании, злоумышленники запустили ПО для удаления данных; серверы отключили от сети для сдерживания атаки. Позже провайдер сообщил о проверке хранилищ резервных копий и подготовке восстановления пострадавших сайтов. Эти сообщения не дают оснований утверждать, что уничтожены все бэкапы или что каждый клиент потерял данные. Но они дают повод проверить собственный порядок восстановления.
Что делать, если основной хостинг временно недоступен целиком? Компании на виртуальном хостинге или VPS нужен проверенный путь от сохранённого архива до работающего сайта.
От чего защищена резервная копия?
Уточните у технической команды, от каких событий защищает выбранная схема. Другой диск помогает при поломке накопителя, другая площадка — при недоступности основной. Но если сайт и архивы управляются через общий аккаунт, его компрометация может затронуть оба.
Проверьте права ключа, которым рабочий сервер отправляет копии во внешнее хранилище. Возможность загружать архивы не должна автоматически давать право удалять всю их историю. Разделение административных доступов входит и в рекомендации FBI по киберустойчивости.
От удаления защищает отключённая от сети копия либо запрет изменения архива на заданный срок. В Amazon S3 эта функция называется Object Lock — блокировка версий файлов. В режиме governance ограничения могут обойти пользователи со специальными правами. В compliance защищённую версию нельзя удалить до конца срока даже администратору аккаунта.
Аналогичная защита от удаления доступна и у российских облачных провайдеров. Её наличие, режим блокировки и права на обход ограничений нужно проверять для конкретного хранилища.
При выборе резервного копирования оценивать стоит весь путь восстановления: сможете ли вы получить архив без основной панели, есть ли ограничения на выгрузку и можно ли развернуть данные на другой площадке. Объём хранилища отвечает только на часть этих вопросов.
Что именно получится вернуть из архива?
У магазина могут сохраниться код и фотографии, а заказы и остатки — остаться в базе, которая не попала в копию. Или база есть, но для запуска не хватает загруженных документов и настроек приложения.
Состав резерва нужно сверить с реальным устройством проекта. Обычно это файлы приложения, пользовательские загрузки, база данных и конфигурация, необходимая для запуска. Отдельно фиксируют версии компонентов, фоновые задания и зависимости от внешних сервисов. Секреты и ключи требуют защищённого хранения; важно заранее знать, как получить их или выпустить заново при аварии.
Обычное копирование файлов работающей системы управления базами данных (СУБД) не гарантирует пригодный бэкап. Например, PostgreSQL требует соблюдать условия файлового копирования или создания согласованного снимка — состояния, в котором связанные данные соответствуют друг другу и база может восстановить работу. Способ резервирования выбирают для конкретной СУБД и конфигурации.
Проверьте дату данных в восстановленной базе и наличие всей необходимой цепочки копий. Последний архив может уже содержать ошибку или последствия взлома, поэтому нужна история версий. Её глубину выбирают с учётом того, как быстро команда обнаруживает проблемы.
Сколько данных и времени бизнес готов потерять?
До настройки расписания полезно согласовать два ограничения. RPO описывает требование к точке, на которую нужно восстановить данные: в бизнес-разговоре — какой промежуток изменений допустимо потерять. RTO задаёт целевое время восстановления. Это требования к системе, а не результат, который автоматически появляется после покупки бэкапа.
Условный пример: исправная копия содержит данные на 02:00, а авария случилась в 17:00. Без дополнительных источников восстановления в ней не будет изменений за 15 часов. Для сайта с редко обновляемым каталогом это может быть приемлемо. Для магазина с заказами в течение дня — потребовать отдельной сверки с CRM и платёжной системой. Это расчёт сценария, а не статистика потерь.
Так же нужно считать время. Получение архива, подготовка сервера, загрузка базы, настройка приложения, проверка заказа и переключение трафика — отдельные этапы. Если команда измерила только распаковку, она ещё не знает, когда возобновятся продажи.
Как проверить восстановление без остановки сайта?
Полезное учебное условие: основной провайдер недоступен, его панелью и поддержкой воспользоваться нельзя. Рабочий сайт при этом продолжает работать. Команда восстанавливает копию в отдельной среде, не меняя DNS-записи, которые направляют посетителей на рабочий сервер, и не перезаписывая действующие данные.
Сначала — получить данные. Ответственный сотрудник должен войти в хранилище предусмотренным аварийным способом, скачать нужную версию и получить ключ расшифрования. Если для входа нужен код из почты на пострадавшем хостинге, проверка уже выявила зависимость. Аварийный доступ стоит предусмотреть как минимум для двух уполномоченных сотрудников.
Затем — собрать работающий сайт. Для теста используют отдельный адрес с ограничением доступа. Закрывают индексацию, отключают реальные платежи, рассылки и отправку заявок в рабочую CRM; фоновые задания проверяют до запуска. Копия не должна рассылать старые уведомления или повторно создавать заказы. Защита доступа нужна и потому, что тестовая база может содержать клиентские данные.
После — пройти путь клиента. Открыть главную недостаточно. Для магазина проверяют поиск товара, корзину и тестовый заказ, для сайта услуг — форму и получение тестовой заявки в безопасном тестовом канале. Отдельно смотрят вход в кабинет, вложения и те интеграции, без которых менеджер не сможет обработать обращение.
Наконец — зафиксировать результат. Запишите, на какую дату восстановлены данные, сколько занял каждый этап и что пришлось искать вручную. Вывод «сайт поднялся» слишком общий. Полезнее запись: «база восстановлена, форма работает, отправка писем требует отдельной настройки». Следующий тест должен проверить устранение найденных препятствий.
Если восстановление входит в задачи подрядчика по администрированию серверов, заранее согласуйте границы работ: кто получает копию, кто настраивает окружение и кто подтверждает работу бизнес-сценария. Маркетологу не обязательно проверять базу данных, но он может подтвердить, что заявка доходит до нужного сотрудника.
Практическая отправная точка — провести такое испытание сейчас и повторять после существенных изменений сайта, инфраструктуры или схемы резервирования. Дальнейшую периодичность определяют по критичности проекта. CISA рекомендует регулярно проверять доступность и целостность копий в сценарии аварийного восстановления.
Архив сохранился. Что ещё может задержать запуск?
Даже исправная копия не заменяет доступ к домену и DNS. Если управлять записями невозможно, одного нового сервера недостаточно, чтобы посетители начали попадать на него по привычному адресу. Проверьте владельца домена, доступ к регистратору, управление DNS и способ восстановления этих доступов. Изменение DNS также не гарантирует мгновенного переключения всех посетителей из-за кеширования.
Заранее определите резервную площадку: достаточно ли заказать сервер после инцидента или нужно подготовленное окружение. Решение зависит от целевого срока запуска и сложности приложения. Архив не резервирует серверную мощность автоматически.
У магазина после отката может возникнуть расхождение: платёж прошёл, а соответствующего заказа в восстановленной базе нет. До полноценного запуска нужно определить, как сверять операции с платёжным сервисом, CRM или учётной системой. Слепой повтор отправки операций способен создать дубли. Нужны ответственный за сверку и понятный порядок обработки спорных заказов.
Если причиной сбоя был взлом, сохранённый архив ещё предстоит проверить на признаки компрометации. Восстанавливать следует в подготовленной безопасной среде, устранив известный путь проникновения и заменив затронутые секреты. Иначе вместе с сайтом можно вернуть причину инцидента. Порядок такой проверки зависит от характера атаки; универсальной кнопки «чистая копия» нет.
7 вопросов хостеру и администратору
Эти семь вопросов можно отправить подрядчику перед испытанием. Ответы должны описывать вашу конфигурацию и подтверждаться проверкой.
- Где хранятся копии и как получить их без основной панели и поддержки?
- Можно ли доступом с рабочего сервера удалить архивы или изменить срок их хранения?
- Что входит в копию: база, файлы, загрузки, настройки — и чего не хватает для запуска?
- За какой период мы можем потерять изменения и насколько далеко назад можно выбрать рабочую версию?
- Кто получит архив, развернёт сайт и проверит заказ, если основной специалист недоступен?
- Где запустится сайт и кто сможет переключить домен и проверить интеграции?
- Когда в последний раз восстанавливали копию, сколько это заняло и какие проблемы ещё не устранены?
Что должно остаться у руководителя после проверки?
Результатом должна стать короткая рабочая инструкция: где взять пригодную копию, как войти при недоступности основной площадки, кто запускает сайт и кто проверяет приём заказов. В ней нужны измеренное время восстановления, дата доступных данных и список нерешённых зависимостей. Пароли в такую инструкцию не включают — указывают защищённый способ их получения.
Испытание должно подтвердить, что команда способна вернуть конкретный процесс: принять заявку, оформить заказ, передать его менеджеру. Измеренный результат покажет, что менять — частоту копирования, доступы, состав архива или подготовку резервной площадки. Так расходы на резервирование получают понятную связь с непрерывностью продаж.