В октябре 2026 г. за 4 дня остановились 3
8, 9 и 11 октября 2026 г. один за другим остановились 3
Если ваш сайт лежал в одной из пострадавших зон, вопрос «что делать» уже не теоретический. Ответ зависит от одного: есть ли у вас копия сайта и базы за пределами
Обстоятельства аварий я здесь не обсуждаю. Речь о том, как владельцу сайта пережить потерю площадки и что сделать, чтобы в следующий раз она не стала потерей бизнеса.
Что произошло и кого это коснулось
По данным SecurityLab, первой 8 октября остановилась площадка в Сасово (зона ru-central1-b), 9 октября пострадали модули ru-central1-a). Работающими остались зоны ru-central1-d и ru-central1-e, но с ограниченной доступностью. С 10 октября провайдер перевел выдачу квот на виртуальные машины и диски в ручной режим, а 11 октября приостановил выдачу дополнительных квот.
Последнее для владельцев сайтов важнее всего. Квота — это лимит ресурсов, которые клиент может запустить. Работающие серверы она не выключает, но поднять новую виртуальную машину взамен погибшей без нее нельзя. То есть даже клиенты с резервной копией в том же облаке не всегда могли быстро развернуть сайт в соседней зоне.
Пострадали не только клиенты облака напрямую. Сайт может жить на другом хостинге, но зависеть от сервиса, который работает в облаке: от платежного шлюза, сервиса доставки, CRM, хранилища картинок. В том же материале SecurityLab перечислены сбои у десятка известных сервисов, хотя автор оговаривается, что совпадение по времени еще не доказывает связь с аварией.
Где на самом деле лежит ваш сайт
Большинство владельцев знают название хостинга. Почти никто не знает, в каком
Проверьте 4 вещи:
- Где работает сайт. Название провайдера,
дата-центр или зона доступности. В облаке это видно в консоли у каждой виртуальной машины. - Где лежит база данных. На том же сервере, в управляемом сервисе того же облака или отдельно.
- Где хранятся резервные копии. На том же сервере, в хранилище того же провайдера или у другого.
- Какие внешние сервисы нужны сайту, чтобы принимать заказы. Оплата, доставка, обмен с 1С, отправка писем.
Самая частая картина, которую я вижу при приеме сайтов на поддержку: сайт, база и копии лежат на одном сервере. Копии делаются каждую ночь, отчеты зеленые, и все это исчезает вместе с сервером. Такая копия спасает от ошибки программиста или вируса, но не от потери площадки.
Облачные провайдеры делят инфраструктуру на зоны доступности именно для таких случаев. В документации Yandex Cloud сказано, что каждая зона изолирована от сбоев в других зонах, а приложения, развернутые сразу в нескольких зонах, получают отказоустойчивость. Октябрь показал предел этой схемы: когда выбывают 2 зоны из 4 подряд, резерва в оставшихся на всех не хватает.
3 уровня защиты от потери площадки
Защита от аварии
| Уровень | Что делается | Что переживет | Чего не переживет |
|---|---|---|---|
| 0. Копия на том же сервере | Ночной архив файлов и базы рядом с сайтом | Ошибку программиста, неудачное обновление, заражение | Потерю сервера, диска, |
| 1. Копия в другом | Архив уходит в хранилище в другой зоне или регионе | Аварию одного | Проблемы всего провайдера: блокировку аккаунта, ограничения квот, массовую аварию |
| 2. Копия у другого провайдера | Архив уходит в хранилище независимой компании | Потерю основного провайдера целиком | Только одновременную потерю обоих |
| 3. Готовая резервная площадка | Второй сервер у другого провайдера с актуальной копией, план переключения | Все перечисленное, с простоем в часы | — |
Для большинства корпоративных сайтов и небольших магазинов разумный минимум — уровень 2: ежесуточная копия у другого провайдера. Он стоит недорого: хранилище для архива сайта обычно укладывается в сотни рублей в месяц. Уровень 3 нужен тем, у кого час простоя стоит дороже, чем месяц содержания второго сервера: крупным магазинам, сервисам с личными кабинетами, сайтам, через которые идет основной поток заказов.
Вот как выглядит минимальная копия уровня 2 на обычном сервере с сайтом на PHP и MySQL:
#!/bin/bash
# Ежесуточная копия базы и файлов в хранилище другого провайдера
set -e
DATE=$(date +%F)
mysqldump --single-transaction -u backup site_db | gzip > /backup/db-$DATE.sql.gz
tar -czf /backup/files-$DATE.tar.gz -C /var/www site
# offsite — заранее настроенное в rclone S3-хранилище другой компании
rclone copy /backup offsite:site-backups/$DATE
# локально держим только 7 последних дней
find /backup -type f -mtime +7 -deleteСкрипт запускается по расписанию раз в сутки. Пароль к базе хранится в файле настроек MySQL, в самом скрипте его нет. Ключ доступа к внешнему хранилищу лучше выдать с правом только на запись: тогда тот, кто получит доступ к серверу, не сможет стереть старые копии.
И одно правило, о котором забывают чаще всего: копию нужно хотя бы раз развернуть. Архив, из которого сайт ни разу не поднимался, — это надежда, а не резерв. Раз в квартал разверните копию на тестовом сервере и проверьте, что сайт открывается, заказ оформляется, админка работает.
Если авария уже случилась
Порядок действий, когда сайт не открывается
- Убедитесь, что проблема у провайдера. Страница статуса хостинга, сообщения в его каналах, ответ поддержки. Если сайт лежит один, а у провайдера все хорошо, это другая история и другой порядок действий.
- Найдите последнюю копию вне пострадавшей площадки. Дата, полнота (файлы и база), где она лежит, кто имеет к ней доступ.
- Решите, ждать или переезжать. Если провайдер называет срок восстановления в часах и он вас устраивает, иногда разумно подождать. Если сроков нет, как в октябрьской ситуации, начинайте переезд параллельно с ожиданием.
- Разверните сайт на другой площадке. Новый сервер, копия файлов и базы, проверка, что все работает по временному адресу.
- Переключите домен. Измените
A-записи в DNS на новый сервер. Если DNS обслуживается у того же пострадавшего провайдера, сначала перенесите управление DNS к регистратору или в другой сервис. - Предупредите клиентов. Короткое сообщение на сайте и в соцсетях: что случилось, что с заказами, как связаться. Люди спокойнее относятся к сбою, о котором им сказали.
Пятый пункт часто становится ловушкой. Сайт и DNS у одного провайдера — значит, при его аварии вы не можете даже указать домену новый адрес. Управление DNS стоит держать отдельно от хостинга, у регистратора домена или в независимом сервисе. Время жизни записей (TTL) для основных записей сайта лучше заранее держать небольшим, например 1 ч.: тогда после смены адреса посетители начнут попадать на новый сервер быстрее.
Подробно о переезде без потери позиций — в материале о миграции сайта. В аварийном режиме из него стоит взять главное: не меняйте адреса страниц и не трогайте структуру, переносите сайт как есть.
Что спросить у хостера и подрядчика
После октябрьских событий эти вопросы стоит задать даже тем, кого авария не коснулась. Ответы займут у подрядчика полчаса, а у вас появится понятная картина рисков.
- Где физически стоит сервер, в каком
дата-центре или зоне. - Где лежат резервные копии и как давно из них в последний раз восстанавливали сайт.
- Сколько займет восстановление на другой площадке, если основная пропадет. Ответ в часах, а не «быстро».
- Кто управляет DNS и сможет ли он сменить адрес, если хостинг недоступен.
- Какой уровень доступности обещает договор с хостером (SLA) и что положено при его нарушении.
- Что в договоре сказано о
форс-мажоре .
Про последний пункт без иллюзий. По п. 3 ст. 401 ГК РФ лицо в предпринимательской деятельности отвечает за неисполнение обязательства, если не докажет, что помешала непреодолимая сила, то есть чрезвычайные и непредотвратимые обстоятельства. Если провайдер сошлется на такие обстоятельства и докажет их, компенсацию по SLA вы, скорее всего, не получите. Но даже компенсация за простой обычно ограничена долей месячной оплаты хостинга и не покрывает ваши потерянные заказы. Деньги за аварию бизнесу никто не вернет, поэтому защищаться приходится копиями, а не договором. Это не юридическая консультация: конкретные условия смотрите в своем договоре с провайдером.
Отдельно о сервисах, от которых зависит сайт. Если оплата, доставка или CRM работают у одного провайдера, при его аварии сайт может открываться, но не принимать заказы. Для критичных интеграций стоит заранее знать запасной вариант: альтернативный способ оплаты, прием заказов по телефону, ручной режим обмена с 1С. Схема похожа на ту, что нужна при защите от
Частые вопросы
Мой сайт на обычном хостинге, в облаке его нет. Меня это касается?
Касается. Обычный хостинг тоже стоит в конкретном
Как часто нужно делать резервную копию сайта?
Частота зависит от того, сколько данных вы готовы потерять. Для корпоративного сайта, где контент меняется раз в неделю, достаточно ежесуточной копии. Для интернет-магазина с заказами каждый час база копируется чаще, вплоть до непрерывной репликации на резервный сервер. Файлы сайта меняются реже базы, их можно копировать раз в сутки.
Сколько стоит держать копию у другого провайдера?
Объектное хранилище для архивов обычного сайта стоит сотни рублей в месяц: архив корпоративного сайта весит от сотен мегабайт до нескольких гигабайт, магазина с фотографиями — десятки гигабайт. Настройка ежесуточной выгрузки занимает у разработчика несколько часов один раз. Дороже обходится только полноценная резервная площадка со вторым сервером, и она нужна не всем.
Можно ли полностью исключить простой при аварии?
Полностью — только с сайтом, который постоянно работает на 2 площадках у разных провайдеров с автоматическим переключением. Это сложная и дорогая схема, оправданная для крупных сервисов. Для большинства бизнесов реалистичная цель — восстановиться за несколько часов и не потерять заказы последних суток.
С чего начать на этой неделе
Не нужно строить отказоустойчивую архитектуру за один день. Начните с 2 действий: выясните, где лежат копии вашего сайта, и попросите подрядчика настроить ежесуточную выгрузку к другому провайдеру. Это закрывает самый опасный сценарий — когда после аварии восстанавливать просто не из чего.
Мы в
Литвиненко Д. 
Осокин Г. 
Вербицкая К. 
