После атаки на Beget: почему копия сайта должна жить у другого

2 ноября 2026 года хостинг Beget пострадал от кибератаки: злоумышленники добрались до управляющего слоя и запустили скрипты удаления данных. По сообщению компании, бинарные бэкапы VPS утеряны, у облака пропали данные, настройки CDN и IP-адреса. Сводку фактов мы дали в новости об атаке на Beget. Здесь — вывод для любого владельца сайта, а не только клиента Beget: копия, которая хранится у того же провайдера, не защищает от сбоя этого провайдера.

Почему бэкап у хостера — не бэкап

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

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

Три вопроса, которые стоит задать себе сегодня

1. Если провайдер завтра исчезнет вместе со всеми данными, где лежит последняя копия сайта и базы?
2. Сколько дней работы — заказов, заявок, записей — вы потеряете, если поднимете эту копию?
3. Кто знает, как развернуть сайт в другом месте, и сколько часов это займёт?

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

Минимальная схема, которая работает

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

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

Домен, DNS и почта — отдельная зона риска

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

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

Что сделать в ближайшую неделю

1. Выгрузите полную копию сайта и базы и положите её вне основного хостинга.
2. Настройте автоматическую выгрузку по расписанию и проверьте, что она реально создаётся.
3. Раз в месяц пробуйте развернуть копию на тестовом сервере. Копия, которую ни разу не восстанавливали, — это надежда, а не бэкап.
4. Проверьте доступ к регистратору домена и к DNS: логин, пароль, вторая почта, резервные коды.
5. Сделайте одностраничный план восстановления: кто, что и в каком порядке делает. Шаблон мы разбирали в материале о плане восстановления после аварии.
6. Смените пароли и ключи, если ваш сайт или почта были у Beget.

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

О чём не стоит делать выводов

На 4 ноября расследование атаки продолжается, и Beget не раскрывает детали, чтобы не мешать ему. Поэтому рано оценивать, насколько защищён этот или любой другой провайдер. Атаки на управляющий слой возможны у любого хостинга и облака. Вопрос не в выборе «неуязвимого» провайдера, а в том, чтобы сбой одного из них не останавливал ваш бизнес.