Сбой Beget: как защитить сайт и данные от потери

Масштабный сбой Beget показал неприятную вещь: сайт может исчезнуть не потому, что его взломали напрямую. Иногда достаточно, чтобы серьёзная проблема произошла у хостинг-провайдера.

В описываемом инциденте у Beget оказались недоступны сайты, VPS, DNS-серверы, почта и часть инфраструктуры управления. Причиной стала масштабная кибератака, затронувшая не отдельный сервер, а управляющий контур провайдера. Часть сервисов пришлось восстанавливать практически вручную, а некоторые данные и резервные копии оказались недоступны.

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

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

Что случилось с Beget

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

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

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

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

Отдельным последствием стала приостановка аккредитации Beget как регистратора доменов в зонах .RU и .РФ. Это не означает автоматическую потерю уже зарегистрированного домена, но показывает, что проблема вышла за пределы обычного сбоя хостинга. Владельцам сайтов важно разделять три разных ресурса: домен, DNS и сам сервер.

Почему сайт может не работать, даже если файлы не потеряны

У сайта есть несколько независимых компонентов. Файлы и база данных находятся на сервере. Домен зарегистрирован у регистратора. DNS указывает, на какой сервер направлять посетителей. Сертификат отвечает за HTTPS. Почта работает через отдельные записи и сервисы.

Если ломается любой из этих элементов, сайт может стать недоступным.

Файлы сайта могут физически сохраниться, но DNS-серверы перестанут отвечать. В этом случае браузер не поймёт, куда направлять запрос. Или сервер будет работать, но пропадёт доступ к панели управления и владелец не сможет изменить настройки.

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

Главная ошибка владельцев сайтов

Большинство компаний считают резервной копией файл, который лежит на том же сервере, что и основной сайт.

Это не резервная копия.

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

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

Для важных проектов лучше использовать правило 3–2–1: иметь минимум три копии данных, хранить их на двух разных типах носителей или в разных системах, а одну копию держать отдельно от основной инфраструктуры.

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

Что должно входить в резервную копию

Полный бэкап сайта включает не только папку с файлами.

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

Если проект работает на CMS, необходимо отдельно сохранять конфигурацию CMS и список установленных модулей. Для интернет-магазина критичны заказы, клиенты, остатки, промокоды и настройки оплаты. Для корпоративного сайта — формы заявок, интеграции с CRM и почтовые уведомления.

Если используется Docker, Kubernetes или другой способ контейнеризации, в резервную копию должны попадать образы, Dockerfile, конфигурации, секреты и сценарии развёртывания. Сам контейнер не является полноценным бэкапом: его можно пересоздать, но без данных и конфигурации приложение не восстановится.

Как часто нужно делать бэкапы

Частота зависит от того, сколько данных компания готова потерять.

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

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

RTO показывает, за какое время сайт должен снова заработать. Восстановить небольшой сайт за несколько часов и вернуть в работу интернет-магазин за 15 минут — это разные требования и разные бюджеты.

Без этих показателей разговор о резервных копиях остаётся абстрактным. Компания может делать бэкапы каждый день, но не иметь ответа на вопрос, кто и как будет восстанавливать сайт ночью.

Резервную копию нужно проверять восстановлением

Файл с названием backup-final.zip ещё не доказывает, что сайт можно восстановить.

Архив может оказаться повреждённым. В нём может не быть базы данных. Резервная копия может ссылаться на файлы, которые не попали в архив. Пароль от хранилища может быть у бывшего сотрудника. Скрипт восстановления может не работать на новой версии сервера.

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

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

Домен нельзя держать в одном месте с хостингом

История Beget особенно ясно показала, почему домен и хостинг лучше разделять.

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

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

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

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

Как защитить доступы к серверу и панели управления

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

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

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

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

Административные права должны быть только у тех, кому они действительно нужны. Разработчику не обязательно иметь доступ к биллингу и регистратору домена. Контент-менеджеру не нужен доступ к базе данных. Подрядчику не следует выдавать постоянный root-доступ.

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

Не храните все сервисы в одной инфраструктуре

Однопровайдерная архитектура удобна, пока всё работает. Она проще в администрировании и часто дешевле. Но при крупной аварии становится единой точкой отказа.

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

Для интернет-магазина или SaaS-сервиса потребуется более серьёзная схема. Можно держать резервный сервер в состоянии горячего ожидания, реплицировать базу данных, автоматически проверять доступность сайта и переключать DNS при аварии.

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

Мониторинг должен быть независимым

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

Проверка доступности должна выполняться из внешней системы. Она должна контролировать не только HTTP-код 200, но и содержимое страницы, время ответа, работу DNS, SSL-сертификат, формы и ключевые API-интеграции.

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

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

Что делать, если сайт уже оказался недоступен

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

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

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

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

План защиты сайта на ближайшую неделю

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

После этого стоит восстановить копию на тестовом сервере. Если это невозможно, значит, резервная система не готова к реальной аварии.

Затем необходимо включить двухфакторную аутентификацию, разделить доступы, убрать старые аккаунты и вынести мониторинг за пределы хостинга. Последний шаг — составить короткую инструкцию: кто принимает решение о переключении, где находится бэкап, как изменить DNS и кто отвечает за связь с клиентами.

Вывод

Сбой Beget — это не аргумент против конкретного хостинг-провайдера. Это напоминание о том, что любой провайдер может стать точкой отказа, независимо от его размера, репутации и стоимости услуг.

Безопасная инфраструктура строится не вокруг обещания «у нас всё надёжно», а вокруг готовности к ситуации, когда основной сервис недоступен. У компании должны быть независимые резервные копии, отдельный контроль домена и DNS, защищённые доступы, внешний мониторинг и понятный план восстановления.

Хостинг — это место, где работает сайт. Но не место, где должна существовать единственная копия бизнеса.

Частые вопросы о защите сайта после сбоя хостинга

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

Достаточно ли автоматического бэкапа в панели хостинга?

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

Нужно ли переносить домен от хостинг-провайдера?

Не всегда, но домен должен быть оформлен на владельца бизнеса, а доступ к регистратору — защищён двухфакторной аутентификацией. Для критичных проектов полезно отделить домен и DNS от основного хостинга.

Как часто проверять резервные копии?

Не реже одного раза в квартал. Для важных сервисов — после каждого изменения архитектуры и регулярно на тестовой площадке.

Что делать интернет-магазину?

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