Как пережить сбой хостинга: резервный сервер и DNS

2 ноября 2026 года Beget сообщил о массовом сбое после кибератаки. Недоступность затронула сайты клиентов, панель управления, почту, DNS и доступ к VPS; компания объявила форс-мажор. Восстановление DNS было названо приоритетом, но точных сроков полного возврата сервисов не было. Для меня этот случай - повод посмотреть на архитектуру сайта без привычного «наш хостинг надежный, значит, все в порядке».

Я не считаю, что каждому небольшому сайту необходим дорогой резервный дата-центр. Но почти любой владелец может убрать хотя бы одну критическую зависимость, которая сегодня кажется незаметной.

У сайта-визитки и интернет-магазина разные требования. Для первого во время аварии может быть достаточно страницы с телефоном и адресом. Для второго важны каталог, корзина, платежи, учет остатков и новые заказы.

Я начала бы не с покупки серверов, а с вопросов: сколько часов недоступности допустимо, сколько последних изменений можно потерять и какие функции действительно нельзя останавливать.

Если компания работает по телефону, временное зеркало с контактами может решить главную проблему. Если сервис автоматически принимает оплаченные заказы, понадобится сложная схема с актуальными данными и проверенным переключением.

Первая привычка, которую я изменила бы, - хранить резервные копии не только там, где работает сайт. Если и основные файлы, и архивы доступны через одну панель, при крупной аварии можно одновременно лишиться обоих.

Внешняя копия должна содержать не только файлы сайта, но и базу данных, загрузки пользователей, важные настройки и инструкции по восстановлению. Я проверила бы, что архив можно получить даже тогда, когда вход в основную панель недоступен.

Однако наличие бэкапа не делает сайт автоматически работающим. Копию еще нужно распаковать, восстановить базу, настроить окружение и убедиться, что все функции исправны. Это может занять время.

Именно поэтому рядом с вопросом «где лежит копия?» всегда должен быть второй: «за сколько времени мы реально поднимаем ее на другой площадке?»

Вторая площадка имеет смысл, если сбой первой не отключает и ее. Для этого я проверила бы, что резерв не использует тот же единственный кабинет, единую сеть, один DNS и один способ авторизации.

Есть два базовых подхода. Холодный резерв - когда сервер или среда готовы к развертыванию, но не обязательно обслуживают пользователей постоянно. Это дешевле, зато переключение занимает время. Горячий резерв - когда приложение уже запущено и получает актуальные данные, но стоит дороже и требует более аккуратной синхронизации.

Не стала бы называть два сервера полноценным резервированием, если оба зависят от одной точки отказа. Разные виртуальные машины внутри одной инфраструктуры могут одновременно оказаться недоступными.

Скопировать статические страницы проще, чем поддерживать две одновременно работающие базы заказов. Нужно решить, где разрешена запись, как изменения попадают на резерв и что происходит, если связь между серверами пропала.

Я бы не включала прием заказов на резервной копии, пока не проработан вопрос целостности данных. Две независимые копии, которые одновременно принимают новые записи, могут разойтись. После восстановления основного сайта их не получится бездумно объединить.

Для небольшой компании разумнее заранее согласовать с разработчиком простую схему: одна активная точка записи, понятный момент переключения и обратный переход после проверки.

DNS переводит доменное имя в адрес сервера. У записи есть TTL - время, на которое резолверы обычно кешируют ответ. Если TTL заранее уменьшен, обновленная запись может начать распространяться быстрее. Но короткий TTL не гарантирует мгновенное переключение для каждого пользователя.

Здесь есть принципиальная деталь сегодняшнего инфоповода: проблемы затронули и DNS. Если все авторитетные DNS-серверы домена недоступны, заменить IP внутри недоступной панели может быть невозможно. Даже заранее маленький TTL не исправит такую зависимость.

Я бы рассмотрела независимого DNS-оператора с несколькими авторитетными серверами и доступом, не зависящим от основной площадки. После настройки обязательно проверила бы делегирование домена, доступ к аккаунту и реальное поведение при смене адреса.

Важно помнить, что смена NS-серверов у регистратора - отдельная операция, которая тоже не происходит волшебно за секунду. Поэтому проектировать эту часть лучше в спокойный день.

Если сайт содержит много динамики, полную резервную копию запустить быстро трудно. Но для посетителя иногда достаточно одной легкой страницы на независимой площадке.

Я подготовила бы ее заранее: название компании, краткое описание услуг, телефон, альтернативный контакт, режим работы и понятное сообщение о временной недоступности основного сервиса.

У такой страницы нет корзины и личного кабинета. Зато ей не нужна основная база данных. Она может продолжать отвечать, даже когда основное приложение недоступно, если DNS и маршрутизация для резерва тоже подготовлены.

Я бы не размещала на зеркале форму, которая обещает принять заказ, если не уверена, что его можно надежно сохранить и обработать. Лучше честный номер телефона, чем потерянная заявка.

Нарисовать две стрелки на схеме легко. Реальная проверка сложнее: нужно имитировать потерю основного сервера и убедиться, что резерв открывается извне, сертификат действует, контакты верны, а обращения сохраняются.

Я предложила бы тест без опасных экспериментов с рабочим магазином. Например, на тестовом домене или в заранее согласованное окно с техническим специалистом. Полезно измерить не обещанное, а фактическое время восстановления.

После проверки я записала бы последовательность действий: кто принимает решение, кто меняет записи, как проверяется резерв, когда можно возвращать основной сайт. И обязательно сохранила бы эту инструкцию вне самого хостинга.

Небольшой сайт услуг. Внешние копии, независимый канал связи с клиентами, статичная аварийная страница. Зачастую этого достаточно, чтобы не пропасть для посетителей полностью.

Контентный сайт. Автоматический внешний бэкап файлов и базы, возможность быстро развернуть копию и независимый DNS. Важно не потерять новые публикации, поэтому нужно понимать допустимый возраст резервной версии.

Интернет-магазин или сервис с личными кабинетами. Отдельный план восстановления базы, резервная инфраструктура, мониторинг ключевых операций и отрепетированное переключение. Здесь цена ошибки может быть выше стоимости дополнительного сервера.

Универсального решения на все бюджеты нет. Но в любом варианте полезно убрать самый опасный сценарий: когда вместе с сайтом исчезают копии, почта, доступы и инструкция, что делать.

Я бы начала с четырех задач. Скачала бы независимую копию, проверила доступ к домену и DNS, подготовила простую аварийную страницу и договорилась о пробном восстановлении. Только после этого решала бы, нужен ли второй постоянно работающий сервер.

Устойчивость сайта начинается не с дорогого оборудования, а с понимания, что будет доступно, если основной хостинг исчезнет из сети.

А у вашего проекта есть независимая резервная площадка или хотя бы аварийная страница с контактами? Проверяли ли вы хоть раз переключение в реальности?

Время чтения - около 7 минут.