Утром 2 ноября владельцы сайтов на Beget столкнулись с недоступностью ресурсов и сервисов провайдера. Когда недоступны одновременно сайт, панель управления и связанные инфраструктурные службы, обычный план «зайти в кабинет и скачать резервную копию» может не сработать. Поэтому резервирование стоит проектировать так, чтобы восстановление не зависело от доступа к той же площадке.
Что известно об инциденте
В публикации Хабра от 2 ноября сообщалось о проблемах с сайтами на Beget, панелью и личным кабинетом, подключением к VPS, почтовыми серверами и DNS. Сам Beget сообщил о крупном инциденте, расследовании причин и восстановительных работах; позднее компания уточнила, что проблема затрагивает разные уровни инфраструктуры и что инженеры настраивают её непосредственно в дата-центрах. На момент опубликованных сообщений точная причина не была названа. Это описание ситуации на момент публикации новостей, а не итоговый отчёт об аварии.
Хабр: сообщения о сбое и обновления Beget · Коммерсантъ: сообщение компании и статус работ
Отдельно важно не делать вывод о причине по масштабу последствий. Формулировка «затрагивает все уровни» не объясняет, где начался сбой и как он распространялся. Без технического отчёта нельзя утверждать, что произошла атака, поломка конкретного оборудования или потеря данных. И нельзя считать, что восстановительные работы завершены, пока это не подтверждено актуальным сообщением провайдера и проверкой собственного сайта.
Резервная копия должна пережить сбой площадки
Если сайт и его резервные копии находятся в одной инфраструктуре, единичный инцидент может затронуть и то и другое. Для снижения этой зависимости храните копию файлов и базы данных в другом дата-центре. По возможности выбирайте другого провайдера: так уменьшается риск, что сбой одной площадки или учётной записи лишит вас и сайта, и копии.
Копируйте именно то, что нужно для запуска проекта: файлы сайта, базу данных и конфигурацию, без которой приложение не подключится к базе или внешним сервисам. Для некоторых сайтов отдельно нужны загруженные пользователями файлы, настройки веб-сервера, задания cron и сведения о версиях PHP или других компонентов. Состав зависит от конкретного проекта; зафиксируйте его в инструкции, а не полагайтесь на память одного администратора.
Копия должна быть актуальной относительно допустимой потери данных. Зафиксируйте время её создания и интервал резервирования. Для интернет-магазина, например, более старая база может не содержать свежие заказы; для сайта без изменений это может быть менее критично. Выбор интервала — решение владельца сайта с учётом того, сколько последних изменений он готов потерять при аварии.
Резервирование нельзя считать рабочим только потому, что файл появился в хранилище. Периодически восстановите копию на тестовую площадку и проверьте, что файлы читаются, база импортируется, сайт открывается, формы работают и данные относятся к ожидаемой дате. AWS также рекомендует проверять процесс восстановления и целостность резервных копий на практике.
AWS Well-Architected: резервное копирование и проверка восстановления
Подробнее о составе и хранении копий — в статье SolverWeb «Бэкапы сайта и базы данных».
План переноса: файлы, база, DNS и доступы
Резервная копия помогает только тогда, когда команда может развернуть сайт в другом месте. Подготовьте сценарий переноса заранее и храните его вне хостинга, вместе с контактами ответственных. В нём должны быть адреса хранилища копий, порядок восстановления, список зависимостей, данные для входа и последовательность переключения трафика.
До аварии проверьте, что у ответственных есть доступ к регистраторам домена, DNS-провайдеру, облачному хранилищу, почте и новому хостингу. Используйте отдельные учётные записи с нужными правами и храните аварийные доступы в защищённом менеджере паролей. Если доступ к DNS или домену контролируется через кабинет того же провайдера, предусмотрите независимый способ управления.
На резервной площадке заранее создайте окружение, совместимое с сайтом, либо опишите его настройку. Проведите тестовое восстановление: загрузите файлы, импортируйте базу, заполните конфигурацию, проверьте главную страницу, авторизацию, формы, платежи или другие критичные функции. Для полноценной проверки также проверьте основной домен на резервном сервере через hosts или curl --resolve, включая сертификат. Тестовую площадку закройте от посторонних; для оплаты и уведомлений используйте тестовые настройки.
Заранее инвентаризируйте DNS-записи: адреса сайта, поддомены, почтовые MX-записи, SPF, DKIM и записи интеграций. Если DNS обслуживает отдельный провайдер, убедитесь, что его кабинет и зона доступны без кабинета хостинга. Перед плановой миграцией обычно снижают TTL заблаговременно, учитывая прежний срок кэширования, чтобы уменьшить время кэширования старых ответов, но изменение DNS не переключает сайт мгновенно у всех пользователей. Cloudflare отдельно рекомендует заранее уменьшать TTL и затем проверять ключевые записи после переключения.
Cloudflare: подготовка DNS к переносу · Cloudflare: переключение и проверка DNS
Для динамического сайта остаётся вопрос изменений, сделанных после создания копии. При переносе интернет-магазина или сервиса может потребоваться временно ограничить записи, сделать финальную копию базы, перенести её и сверить новые заказы или заявки перед открытием сайта на новой площадке. Конкретный порядок зависит от приложения и доступных инструментов; без проверки нельзя обещать, что переключение пройдёт без простоя или потери последних изменений.
Короткий чек-лист владельца сайта
- Файлы и база копируются автоматически во внешнее хранилище в другом дата-центре; предпочтительно — у другого провайдера.
- Известно время последней успешной копии, срок хранения и кто получает уведомление об ошибке.
- Восстановление копии недавно проверяли на отдельной площадке; известны фактические шаги и проблемы.
- Записаны зависимости сайта: версия среды, конфигурация, почта, фоновые задачи, внешние API и интеграции.
- Доступы к домену, DNS, копиям и резервному хостингу не зависят от одного кабинета или одного человека.
- Есть порядок переключения DNS, проверки сайта и возврата к прежней схеме, если тесты не пройдены.
- Команда понимает, какие данные могут измениться между последней копией и переключением.
Для критичных проектов полезно заранее определить два ориентира: сколько времени допустимо восстанавливать сайт и сколько последних данных допустимо потерять. Это помогает выбрать частоту копирования и реалистичный сценарий переноса. Само наличие резервной площадки не гарантирует непрерывную работу: на время восстановления возможен простой, а DNS-кэши и синхронизация данных влияют на переключение.
Что делать во время сбоя
Сначала проверяйте официальные обновления провайдера и доступность сайта из нескольких сетей, фиксируйте ошибки и время наблюдения. Не меняйте DNS наугад: если резервная версия устарела или база продолжает меняться, посетители могут попасть на разные копии сайта, а новые заявки — разойтись между ними. Переключение имеет смысл, когда команда понимает, какую копию запускает, как обработает новые записи и как вернёт трафик.
Если сценарий ещё не подготовлен, используйте инцидент как повод составить его после восстановления доступа: вынесите копии за пределы текущей инфраструктуры, проверьте восстановление и запишите последовательность действий. Регламентная техническая поддержка сайта помогает закрепить такие проверки и ответственных.
Проверим готовность сайта к восстановлению
SolverWeb может проверить, где хранятся файлы и база, насколько свежая копия, можно ли развернуть её на другой площадке и что потребуется для переключения DNS. Если резервная схема ещё не описана, подготовим порядок переноса и проверим восстановление на тестовом окружении.
Обсуждение
Поделитесь мнением — первый комментарий задаст тон.