В ночь на 2 ноября 2026 года инфраструктура крупного хостинг-провайдера Beget подверглась массированной кибератаке. В результате была нарушена работа ряда сервисов. Компания приступила к восстановлению инфраструктуры, однако точные сроки возвращения всех сервисов к полноценной работе пока не определены.
В официальном сообщении Beget указал, что восстановление NS-серверов является одним из главных приоритетов, параллельно ведутся работы над почтовой системой. Также компания сообщила, что ей доступны файловые резервные копии подавляющего большинства ресурсов виртуального хостинга и облачной инфраструктуры. При этом восстановление данных потребует продолжительного времени.
Отдельно Beget уведомил клиентов об обстоятельствах, обладающих признаками непреодолимой силы (форс-мажора), со ссылкой на положения договоров и пункт 3 статьи 401 Гражданского кодекса РФ. Для владельцев сайтов это ещё одно напоминание: независимо от распределения ответственности по договору необходимо самостоятельно предусмотреть возможность восстановления проекта при длительной недоступности инфраструктуры провайдера.
Мы не будем оценивать действия провайдера или рассуждать о юридической стороне произошедшего. Эта ситуация интересна нам с другой точки зрения: она наглядно показывает, насколько опасно строить инфраструктуру интернет-проекта, полностью полагаясь на одного поставщика услуг. Проблема гораздо шире и не ограничивается резервными копиями. Даже если файлы сайта и база данных сохранились, это ещё не означает, что вы сможете открыть сайт, получить доступ к почте или самостоятельно перенести проект на другую площадку.
Почему резервных копий у хостинг-провайдера недостаточно
Большинство хостинг-провайдеров предлагают автоматическое резервное копирование. Это полезная и необходимая услуга, но у неё есть принципиальное ограничение: резервные копии зачастую остаются частью той же инфраструктуры, от которой зависит работа вашего сайта. Это особенно заметно в нескольких ситуациях:
- Сервер, на котором размещён сайт, вышел из строя. При наличии доступной резервной копии восстановление на другой площадке вполне реально.
- Недоступна панель управления хостингом. Вы знаете, что копии существуют, но не можете самостоятельно получить к ним доступ.
- Проблемы возникли у DNS-провайдера. Сам веб-сервер продолжает работать, но посетители не могут найти его по доменному имени.
- Недоступны одновременно хостинг, DNS и сервисы управления. Вы не можете ни восстановить сайт привычным способом, ни быстро перенаправить пользователей на другой сервер.
Во всех этих случаях наличие резервной копии само по себе не решает проблему. Важно не только сохранить данные, но и иметь независимую возможность ими воспользоваться.
Отдельная проблема, о которой часто забывают, — DNS
В инциденте Beget особенно показателен вопрос восстановления NS-серверов. Многие владельцы сайтов при подключении хостинга просто указывают предложенные провайдером NS и больше не возвращаются к этим настройкам. Между тем DNS — один из важнейших компонентов инфраструктуры. Именно эта система позволяет определить IP-адрес сервера, на котором находится сайт.
Упрощённо процесс выглядит так:
- Пользователь вводит доменное имя сайта, например example.ru.
- DNS-резолвер выясняет, какие авторитетные NS-серверы обслуживают домен.
- Авторитетный сервер возвращает IP-адрес сайта.
- Браузер подключается к полученному IP-адресу и загружает страницу.
Теперь представим, что веб-сервер исправен, файлы и база данных находятся на месте, но NS-серверы хостинг-провайдера перестали отвечать. В этом случае сайт может продолжать работать технически, но пользователи не смогут открыть его по доменному имени. Браузер просто не получит необходимую DNS-информацию.
Почему у одних пользователей сайт открывается, а у других нет
DNS-ответы не запрашиваются у авторитетных серверов при каждом открытии сайта. Для уменьшения нагрузки DNS-резолверы кэшируют полученную информацию на определённое время. Этот интервал называется TTL (Time To Live). Например, если TTL DNS-записи составляет 3600 секунд, полученный IP-адрес может оставаться в кэше в течение часа.
Поэтому при отказе NS-серверов часть посетителей некоторое время может продолжать открывать сайт: у их интернет-провайдера или публичного DNS-сервиса ещё сохранился ранее полученный IP-адрес. Однако после истечения срока хранения записи DNS-резолверу потребуется получить актуальную информацию. Если авторитетные серверы по-прежнему недоступны, запрос может завершиться ошибкой.
Существуют механизмы, позволяющие некоторым DNS-резолверам временно возвращать устаревшие записи, если обновить их не получается. Например, Serve Stale, описанный в RFC 8767. Но рассчитывать на него как на гарантированный механизм доступности сайта нельзя.
Есть и ещё один нюанс: если DNS обслуживается только у хостинг-провайдера, резервная копия сайта в независимом облаке не поможет посетителям найти новый сервер. Для этого необходимо иметь возможность изменить DNS-записи и направить домен на другую площадку.
Что делать, если DNS-серверы хостинга недоступны
Допустим, ваш сайт размещён у Beget, и там же находятся DNS-серверы домена. При возникновении проблем с NS вы решили перенести DNS-обслуживание к другому оператору. Это вполне рабочее решение, но есть важное условие: у вас должен быть независимый доступ к управлению доменом у регистратора.
Здесь важно понимать разницу между тремя услугами:
- Регистрация домена — услуга, в рамках которой регистратор управляет доменом и его делегированием, в том числе позволяет менять NS-серверы;
- DNS-хостинг — услуга оператора, который обслуживает DNS-зону и отвечает на запросы об IP-адресах, почтовых серверах и других параметрах домена;
- Хостинг сайта — предоставление серверных ресурсов для размещения файлов, баз данных и приложений.
Эти услуги необязательно должны находиться у одной компании. Более того, для важных бизнес-проектов их разделение позволяет существенно снизить риски.
Если домен зарегистрирован у независимого регистратора
Это наиболее удобная ситуация. Даже при полной недоступности хостинг-провайдера у вас остаётся возможность управлять доменом.
В случае отказа DNS-серверов необходимо:
- Создать DNS-зону у независимого DNS-провайдера;
- перенести в неё все необходимые записи: A, AAAA, CNAME, MX, TXT, CAA и другие используемые записи;
- добавить почтовые настройки SPF, DKIM и DMARC, а также записи для проверки домена во внешних сервисах;
- проверить, что новые NS-серверы отвечают и возвращают корректные данные;
- изменить NS-серверы в панели независимого регистратора.
Важный момент: для переноса необходимо заранее иметь актуальную копию DNS-зоны. Если старые NS-серверы уже недоступны, получить полный перечень записей у прежнего оператора может не получиться. Именно поэтому мы рекомендуем сохранять конфигурацию DNS отдельно от хостинга.
После изменения делегирования DNS-запросы постепенно начнут обслуживаться новым оператором. Однако переключение не всегда происходит мгновенно: рекурсивные резолверы могут ещё некоторое время использовать закэшированную информацию о предыдущем делегировании.
Отдельного внимания требует DNSSEC. Если он включён, при смене DNS-провайдера необходимо правильно обновить DS-запись у регистратора. Несоответствие DS и новых ключей подписи DNS-зоны может привести к тому, что DNS-резолверы будут отклонять ответы.
Если управление доменом зависит от хостинг-провайдера
А вот здесь ситуация значительно сложнее. Предположим, что у одного провайдера находятся хостинг, DNS и управление доменом, а доступ к настройкам домена осуществляется только через его личный кабинет. Если инфраструктура управления недоступна, вы можете оказаться без возможности изменить NS-серверы и перенаправить домен на другую площадку.
Создать DNS-зону у другого оператора недостаточно. Пока в родительской DNS-зоне домена сохраняется делегирование на старые NS-серверы, запросы пользователей будут направляться именно туда. В результате даже готовый резервный сервер с восстановленным сайтом не решит проблему: посетители не смогут добраться до него по привычному адресу.
В такой ситуации остаётся добиваться восстановления доступа к управлению доменом и взаимодействовать с регистратором по предусмотренным процедурам. Быстрого универсального технического обхода здесь нет.
Поэтому мы рекомендуем регистрировать домены у независимого регистратора и не связывать возможность управления доменом с доступностью хостинга. Домен — самостоятельный актив бизнеса, и доступ к нему должен сохраняться независимо от состояния сервера.
Можно ли иметь два независимых DNS-провайдера
Да. Для проектов, где даже кратковременная недоступность домена критична, можно организовать обслуживание DNS-зоны у двух независимых операторов. Для этого используется схема Primary DNS / Secondary DNS:
- первый оператор обслуживает основную DNS-зону;
- второй независимый оператор получает её копию и обслуживает зону на собственных авторитетных NS-серверах;
- изменения записей автоматически передаются на вторую площадку;
- в делегировании домена указываются NS-серверы обоих операторов.
Синхронизация может выполняться с помощью механизмов AXFR и IXFR, которые позволяют передавать DNS-зоны между серверами. Для защиты такого обмена используется, в частности, TSIG.
В результате при отказе одного DNS-провайдера второй продолжает отвечать на запросы. Пользователям не требуется ждать изменения делегирования домена.
Но здесь важно понимать один технический нюанс: недостаточно просто указать NS-серверы разных компаний. Все авторитетные серверы должны возвращать согласованные данные. Если у одного оператора IP-адрес сайта изменился, а у второго остался старый, разные пользователи будут получать разные ответы. Поэтому необходимы автоматическая синхронизация и контроль актуальности DNS-зоны.
Также нужно правильно настроить DNSSEC, если он используется. Для независимых операторов может потребоваться схема Multi-Signer DNSSEC, описанная в RFC 8901.
Дополнительную информацию можно найти в документации Cloudflare по Secondary DNS и передаче DNS-зон.
При этом два NS-сервера одной компании, даже если они расположены в разных дата-центрах, не равнозначны двум независимым DNS-провайдерам. У них всё ещё могут быть общие системы управления, сетевые зависимости и инфраструктурные компоненты.
Резервная копия сайта не равна возможности его восстановить
Теперь вернёмся непосредственно к резервному копированию. Предположим, вы регулярно создаёте архивы сайта и отправляете их в S3-хранилище. Основной хостинг полностью вышел из строя. Кажется, что проблема решена: достаточно взять последний архив, развернуть сайт на новом сервере и изменить IP-адрес в DNS.
На практике всё несколько сложнее. Для полноценного восстановления проекта необходимо заранее понимать, какие именно данные нужны для его запуска и где их получить.
Что должно попадать в резервную копию
Для полноценного восстановления одного архива файлов сайта недостаточно. Резервное копирование должно охватывать все компоненты, необходимые для запуска проекта:
- Файлы сайта: CMS, программный код, изображения, документы, загруженные пользователями файлы, модули и дополнительные компоненты;
- базы данных: контент, заказы, пользователи, настройки, история операций и другие динамические данные. Важно обеспечить целостность и согласованность копии;
- конфигурация сервера: версии PHP, настройки веб-сервера и PHP-FPM, параметры баз данных, задания cron и необходимые системные зависимости;
- конфигурационные файлы и ключи доступа: параметры подключения, API-ключи, переменные окружения и другие необходимые секреты, которые следует хранить отдельно и в зашифрованном виде;
- DNS-зона: все записи домена, чтобы не восстанавливать настройки вручную в критический момент;
- почта: если почтовые ящики находятся на том же сервере, необходимо отдельно предусмотреть сохранение самих сообщений.
Особенно часто забывают о почте. Даже после переноса сайта на новый сервер MX-записи могут продолжать указывать на старую инфраструктуру. В результате сайт уже работает, а электронная почта по-прежнему недоступна. Поэтому, если почта критична для бизнеса, для неё тоже необходимо предусмотреть независимую инфраструктуру или понятный сценарий восстановления.
Сколько данных можно потерять и сколько времени займёт восстановление
В профессиональной практике используются два показателя, которые помогают оценить готовность проекта к аварии:
- RPO (Recovery Point Objective) — максимально допустимая потеря данных, выраженная во времени. Например, при ежедневном резервном копировании RPO может составлять до 24 часов;
- RTO (Recovery Time Objective) — целевое время восстановления работоспособности. Например, бизнес рассчитывает вернуть сайт к работе не позднее чем через четыре часа после аварии.
Это два разных параметра. Ежедневное резервное копирование не означает, что сайт можно восстановить за несколько часов. Если после инцидента приходится искать новый сервер, устанавливать операционную систему, настраивать веб-сервер, восстанавливать базу данных, проверять конфигурацию, выпускать SSL-сертификат и менять DNS, процесс может затянуться.
Поэтому для серьёзного проекта важно иметь не только архив данных, но и заранее подготовленный план аварийного восстановления. Для небольшого корпоративного сайта достаточно актуальной копии и проверенной инструкции по переносу на другой хостинг. Для интернет-магазина или сервиса, который ежедневно обрабатывает заказы, может потребоваться готовый резервный сервер и более частое копирование базы данных.
Где правильно хранить резервные копии сайта
Мы рекомендуем не ограничиваться резервными копиями, которые создаёт сам хостинг. Дополнительный архив должен находиться за пределами его инфраструктуры и быть доступным независимо от состояния основного провайдера. Для этого можно использовать несколько вариантов.
Отдельное S3-хранилище
Один из наиболее удобных способов автоматизации резервного копирования — объектное хранилище S3. Оно позволяет регулярно отправлять архивы файлов и баз данных на независимую площадку.
При выборе такого решения важно учитывать не только стоимость и объём хранения, но и независимость учётных записей. Желательно использовать отдельный аккаунт, ограничить права доступа, включить версионирование и, если сервис поддерживает такую возможность, защиту объектов от удаления (Object Lock).
Это особенно важно при кибератаках и компрометации учётных данных. Злоумышленник не должен иметь возможности одновременно удалить рабочий сайт и все его резервные копии.
Собственное NAS или WebDAV
Если у вас есть собственный сервер или сетевое хранилище NAS, можно настроить автоматическую передачу архивов по WebDAV, SFTP и другим протоколам. Однако принципиально важно, чтобы хранилище находилось на отдельной площадке. NAS, установленный в той же серверной, что и основной сервер сайта, не защищает от аварии дата-центра, проблем с электропитанием или общей сетевой инфраструктуры.
Яндекс Диск или Google Drive
Для небольших проектов можно использовать обычные облачные диски. Это доступный способ хранить дополнительные копии сайта без необходимости самостоятельно обслуживать сервер хранения. Можно настроить автоматическое создание архивов и их регулярную выгрузку в облако. При этом следует учитывать ограничения по объёму, шифровать архивы и обеспечить независимый доступ к учётной записи.
Внешний физический накопитель
Для действительно важных данных стоит предусмотреть физическую копию на внешнем HDD или SSD, которая хранится отдельно от рабочей инфраструктуры. В идеале после создания резервной копии накопитель отключается от сети и помещается в безопасное место. Это существенно снижает риск одновременного уничтожения рабочих данных и архивов при кибератаке.
Такой подход особенно полезен для проектов, где потеря данных может иметь серьёзные финансовые или юридические последствия.
Правило 3-2-1 для защиты данных
В профессиональной практике резервного копирования давно используется правило 3-2-1:
- 3 копии данных — оригинал и минимум две резервные копии;
- 2 разных типа носителей — например, сервер и облачное хранилище или внешний накопитель;
- 1 копия за пределами основной площадки — в другом дата-центре, независимом облаке или физически отдельном месте.
Для современных веб-проектов мы рекомендуем дополнительно учитывать независимость систем управления и доступа. Например, если основной сервер и S3-хранилище используют одну учётную запись, её компрометация может поставить под угрозу обе копии. Поэтому желательно разделять права доступа, использовать двухфакторную аутентификацию и защищать архивы от изменения и удаления.
Есть и ещё одно правило, которое часто игнорируют: резервную копию необходимо периодически проверять восстановлением. Сам факт успешного создания архива ещё не гарантирует, что из него получится запустить работающий сайт.
Что мы предлагаем в РАМЕВА
Мы давно уделяем особое внимание не только доступности сайтов, но и сохранности данных наших клиентов. Именно поэтому рассматриваем резервное копирование как самостоятельную задачу, а не просто дополнительную функцию хостинга.
В рамках наших услуг доступны несколько вариантов защиты:
- Хостинг с ежедневным резервным копированием: для размещаемых проектов предусмотрено регулярное создание резервных копий. Подробнее можно узнать на странице нашего хостинга;
- независимое хранение резервных копий: можно организовать дополнительное копирование данных на отдельные площадки, в S3-хранилища или собственные системы хранения;
- физическое хранение копий в сейфе: создаём полную копию сайта, баз данных и почтовых ящиков, записываем её на защищённый внешний накопитель и помещаем на хранение в закрытый сейф на независимой площадке.
Последний вариант особенно интересен тем, кто хочет иметь физическую копию данных, не зависящую от доступности хостинга, облачных сервисов и сетевой инфраструктуры.
Важно понимать, что физическое хранение не заменяет независимый DNS и не обеспечивает автоматический перенос сайта на другой сервер. Это дополнительный уровень защиты, который позволяет сохранить данные даже в ситуации, когда электронные хранилища и серверная инфраструктура недоступны.
Подробнее об услугах резервного копирования и защиты сайтов можно узнать на странице «Защита сайта и резервное копирование».
Также рекомендуем нашу предыдущую публикацию «О важности резервного копирования на физический носитель», в которой мы подробнее рассказывали о рисках хранения всех копий в цифровой инфраструктуре.
Что стоит проверить владельцу сайта уже сейчас
Необязательно сразу строить сложную отказоустойчивую архитектуру. Для начала стоит разобраться, от каких сервисов зависит работа вашего проекта. Рекомендуем проверить следующее:
- Где зарегистрирован домен и есть ли у вас независимый доступ к панели регистратора?
- Какие NS-серверы обслуживают домен? Не принадлежат ли они той же компании, у которой размещён сайт?
- Сохранена ли актуальная копия DNS-зоны со всеми необходимыми записями?
- Есть ли резервная копия сайта и базы данных за пределами инфраструктуры основного хостинга?
- Можно ли получить доступ к архивам, если личный кабинет хостинг-провайдера недоступен?
- Есть ли необходимые настройки, конфигурационные файлы и доступы для развёртывания проекта на другом сервере?
- Когда в последний раз вы действительно проверяли восстановление сайта из резервной копии?
Для технических специалистов проверить текущее состояние DNS можно с помощью утилиты dig:
dig +trace NS example.ru
dig @ns1.example.net example.ru SOA
dig @ns2.example.net example.ru A
dig @1.1.1.1 example.ru A
dig @8.8.8.8 example.ru MXЗамените example.ru и ns1.example.net на собственный домен и реальные адреса DNS-серверов. Такие проверки позволяют увидеть, куда делегирован домен, отвечают ли авторитетные серверы и какие данные получают независимые DNS-резолверы. Если вы используете DNSSEC, дополнительно следует проверить актуальность DS-записи у регистратора и соответствие ключей подписи DNS-зоны.
Вместо заключения
Сбой у Beget — хороший повод пересмотреть подход к резервному копированию и размещению сайтов. Речь не о том, чтобы срочно менять хостинг: проблема гораздо шире и касается любого провайдера.
Надёжность проекта определяется не только тем, насколько хорошо защищён основной сервер. Важно, сможете ли вы управлять доменом, обеспечить работу DNS, получить резервную копию, восстановить базу данных и запустить сайт на другой площадке, если привычная инфраструктура внезапно станет недоступна.
Минимум, который должен быть у каждого серьёзного проекта, — независимый доступ к домену, резервная копия вне основного хостинга и проверенная возможность восстановления сайта.
Не стоит ждать следующей аварии, чтобы выяснить, что резервные копии находятся вместе с основным сервером, DNS обслуживается там же, а доступ к управлению доменом зависит от одного личного кабинета.
Специалисты РАМЕВА помогут оценить текущую схему размещения вашего сайта, выявить критические точки отказа и подобрать подходящий вариант резервного копирования и независимого хранения данных.
