Атаки на дата-центры: как подготовить сайт к отказу площадки
11 октября 2026 года «Яндекс» сообщил о повреждении инфраструктуры дата-центра во Владимире после атаки БПЛА и полной остановке его работы. Yandex Cloud рекомендовал клиентам задействовать альтернативные планы аварийного восстановления. Это зафиксировано в официальном сообщении платформы.
В ночь с 1 на 2 ноября 2026 года кибератаке подверглась инфраструктура Beget. В официальной хронологии инцидента компания сообщила, что злоумышленники проникли на управляющие серверы и запустили ПО, предназначенное для уничтожения данных. Для ограничения атаки серверы отключили от сети. Восстановительные работы затронули DNS, почтовые сервисы и виртуальный хостинг.
В разборе инцидента Beget также сообщил о потере бинарных резервных копий VPS и сохранении файловых бэкапов. При этом на момент публикации сообщения получить файловые копии было невозможно до восстановления инфраструктуры провайдера: серверы требовали ручной проверки перед запуском.
Этот случай показывает, почему при планировании резерва важны и сохранность копий, и возможность независимо получить к ним доступ. Если сайт, DNS, почта и хранилище бэкапов зависят от общей инфраструктуры, один инцидент может одновременно осложнить работу проекта и его перенос. В плане восстановления нужно предусмотреть доступную копию данных и управление доменом при недоступности основной площадки.
Для владельца сайта здесь возникает очень конкретный вопрос: если основная площадка сегодня станет недоступна, откуда мы возьмём данные и на чём запустим проект?
Причиной может оказаться атака, пожар, авария электроснабжения, ошибка администратора или потеря доступа к аккаунту. План восстановления должен работать при любом из этих сценариев.
Начните с двух вопросов бизнесу
Первый: сколько последних данных можно потерять? Для сайта с редко меняющимися услугами ответ может измеряться днями. Для магазина с заказами — минутами.
Второй: сколько времени сайт может оставаться недоступным? Несколько часов простоя корпоративного сайта и несколько часов простоя сервиса, через который идёт вся выручка, имеют разную цену.
Эти параметры называют RPO и RTO. RPO задаёт допустимую потерю данных во времени, RTO — целевой срок восстановления. Такой подход описан, например, в рекомендациях AWS по аварийному восстановлению.
Допустим, магазин согласовал RPO в один час. Тогда копия, сделанная вчера ночью, уже не решает поставленную задачу. Если согласован RTO в четыре часа, время на получение сервера, скачивание архива, восстановление базы и переключение трафика должно поместиться в этот срок. Это проверяют на учениях.
Что восстанавливать: проект с Git и без него
Состав резервных копий зависит от того, как организована работа с кодом. Здесь возможны два варианта.
Если проект без системы контроля версий, сохраняйте полный комплект: актуальные файлы сайта, базу данных, загруженные изображения и документы, конфигурацию и необходимые ключи. Единственная рабочая копия кода на сервере исчезнет вместе с ним. Дальше для такого проекта действует обычная схема: независимые бэкапы и проверка восстановления всего сайта.
Для проектов с регулярной технической поддержкой или командой разработки лучше хранить код в Git или другой системе контроля версий. Это позволяет отслеживать изменения и возвращаться к нужной версии проекта. Возможности контроля версий описаны в официальной книге Git. Git-репозитории можно размещать, например, в Gitea, GitLab или GitHub. Важно, чтобы доступная копия репозитория находилась за пределами рабочей площадки.
У нас код проектов хранится в Gitea, которая работает на отдельном VPS в другом дата-центре. Поэтому при отказе основного сервера исходники можно получить с отдельной площадки и развернуть проект заново. Основные регулярно меняющиеся данные, для которых нужны бэкапы в такой схеме, — база и загруженные файлы. Настройки окружения и секреты тоже должны быть доступны для восстановления.
| Часть проекта | Откуда восстанавливать |
|---|---|
| Код | Из удалённого репозитория: нужна версия, совместимая с восстанавливаемой базой |
| База данных | Из согласованного дампа или другой пригодной резервной копии |
| Загруженные файлы | Из независимых копий изображений, документов, медиа и вложений |
| Окружение | Из сохранённых настроек, инструкции и файлов фиксации зависимостей; необходимые пакеты должны быть доступны |
| Секреты | Из защищённого хранилища или зашифрованной копии с доступным ключом |
Под файлами, которые часто называют «статикой», здесь прежде всего понимаются пользовательские загрузки. CSS, JavaScript и изображения шаблона могут уже находиться в репозитории или воспроизводимо собираться из исходников. Проверяйте конкретный проект: нужные для запуска файлы, которых нет в Git и которые нельзя получить заново, должны попадать в бэкап.
Эта схема работает, если изменения кода фиксируются и отправляются в удалённый репозиторий. Правки, оставшиеся только на рабочем сервере, из него не восстановить. Записывайте, какая версия кода развёрнута на сайте, и проверяйте её совместимость с копией данных при пробном восстановлении.
Самой Gitea тоже нужно резервирование: репозиториев, базы, настроек и используемых файловых хранилищ. Другой дата-центр помогает разделить риск отказа площадки, но история версий не заменяет независимую копию на случай удаления или компрометации сервиса. Состав резервной копии и порядок восстановления описаны в документации Gitea.
Проверьте, переживут ли копии отказ площадки
Архив в соседней папке удобен для отката после неудачного обновления. При недоступности всего сервера он окажется недоступен вместе с сайтом.
С внешними копиями нужно уточнить детали. В другом ли дата-центре они находятся? Кто управляет доступом? Можно ли скачать их при недоступности основного кабинета? Есть ли у администратора ключ расшифровки?
| Где находится копия | Что проверить |
|---|---|
| На рабочем сервере | Есть ли дополнительная копия за его пределами |
| У того же провайдера | Физическую площадку, отдельность сервиса и доступ при сбое кабинета |
| У другого провайдера | Порядок выгрузки, скорость скачивания и независимость доступов |
| На отключаемом носителе | Актуальность копии, сохранность носителя и возможность расшифровки |
Особенно полезно проверить сценарий, в котором рабочий сервер полностью скомпрометирован. Если с него можно тем же ключом удалить все внешние архивы, резерв тоже уязвим. Подход с отдельными, защищёнными копиями и регулярной проверкой восстановления рекомендует CISA.
Один из способов разделить доступы — pull-бэкап: отдельный резервный сервер сам подключается к рабочему и забирает данные. Приватный ключ для этого подключения и доступ к архивам хранятся на резервной стороне. Рабочему серверу не выдаются учётные данные для входа в резервное хранилище. Получение файлов по такой схеме поддерживает, например, rsnapshot. Чтобы обойтись без локального архива, данные можно передавать потоком; для базы нужна согласованная выгрузка, а на принимающей стороне — проверка успешного завершения.
Выберите подходящий уровень резерва
Для небольшого сайта может хватить внешней копии, инструкции и заранее выбранной площадки для запуска. Для проекта с жёсткими требованиями к простою потребуется подготовленное окружение или работающий резерв.
| Вариант | Что подготовлено заранее | Что останется сделать при аварии |
|---|---|---|
| Восстановление из копии | Архивы, доступы, конфигурация и инструкция | Получить ресурсы, развернуть окружение, восстановить данные |
| Подготовленная резервная площадка | Сервер и основное ПО | Доставить актуальные данные, проверить приложение и переключить трафик |
| Работающий резерв | Второе окружение и механизм актуализации данных | Выполнить предусмотренное переключение и проверить целостность |
Выбор зависит от допустимого простоя и стоимости обслуживания. Однажды оплаченный запасной VPS ещё не означает, что на нём можно запустить сайт. Версии ПО, конфигурацию и доступы придётся поддерживать в актуальном состоянии. Разные стратегии и связанные с ними затраты разобраны в документации AWS.
Восстановлению понадобятся доступы за пределами сервера
Отдельно сохраните доступ к регистратору домена, DNS, почте, репозиторию, резервному хранилищу и системе мониторинга. Для двухфакторной авторизации нужны доступные резервные коды или другой предусмотренный способ восстановления.
Если инструкция лежит только на упавшем сервере, её будет довольно неудобно читать. Держите доступную копию документации отдельно и проверьте, что ответственный человек действительно может её открыть.
В инструкции полезно записать версии PHP и базы данных, список сервисов, порядок запуска очередей и планировщика, необходимые переменные окружения и расположение ключей. Секреты храните в защищённом хранилище с отдельным управлением доступом.
Что делать при переключении
- Уточнить масштаб инцидента и найти последнюю пригодную копию.
- Зафиксировать, какая площадка будет принимать изменения данных. Если старая система ещё доступна, согласовать остановку записи или другой способ исключить расхождение баз.
- Восстановить проект в изолированном окружении: получить код из репозитория или полной копии, установить зависимости, вернуть настройки, базу и загруженные файлы. Проверить совместимость версии кода и данных. На время проверки отключить реальные платежи, рассылки и внешние задания.
- Проверить базу, изображения, авторизацию, формы и нужные интеграции.
- Переключить трафик предусмотренным способом. Для DNS учитывать кеширование записей и время распространения изменений.
- Запустить очереди и фоновые задачи на выбранной рабочей площадке, проверить мониторинг и резервное копирование.
Открывающаяся главная страница — только часть проверки. Если заявки уходят в старую базу, а платежные уведомления приходят на прежний сервер, бизнес всё ещё работает с проблемами.
Как выбирать географию размещения
Смотрите на независимость площадок: дата-центры, провайдеров, доступы, сеть и возможность оплаты. Размещение в другой стране добавляет свои условия — доступность для аудитории, задержки, документы и правила обработки данных.
Для сайтов с персональными данными граждан РФ нужно отдельно учитывать требования к локализации при сборе и к трансграничной передаче. Они установлены статьями 18 и 12 закона № 152-ФЗ. Архитектуру основного сайта и резервного хранения выбирают с учётом состава данных и применимых требований.
Для проектов, которым подходит зарубежное размещение, можно посмотреть VPS и серверы Host4Biz. При выборе резервной площадки проверяйте её независимость от основного размещения и возможность восстановить именно ваш стек.
Ссылка на Host4Biz партнёрская: при заказе я получаю вознаграждение от хостинга.
Что проверить на своём проекте
Начните с небольшого упражнения: восстановите сайт на отдельном сервере и засеките время. Запишите, чего не хватило: доступа, дампа базы, ключа, пакета, инструкции или человека, который знает порядок действий.
После такого запуска будет понятен следующий шаг: достаточно наладить копирование, нужен подготовленный резерв или придётся менять архитектуру. Результатом проверки должен стать работающий проект и измеренное время восстановления.
Если нужна помощь с проверкой копий, подбором площадки и планом восстановления, напишите задачу студии. О регулярном обслуживании есть отдельная статья: почему сайт может ломаться, даже когда кажется, что всё работает.
