План Б для сайта: что делать, если хостинг лёг надолго

Хостинг ложится не на пятнадцать минут, а на часы и иногда на сутки. План Б держится на трёх вещах: копия сайта лежит вне хостинга, время жизни DNS-записей заранее снижено, заглушка с контактами готова и поднимается за пятнадцать минут.

Хостинг умеет лежать не пятнадцать минут, а двое суток. За шесть лет работы я видел это трижды: у одного провайдера умер RAID-контроллер и данные поднимали из ленточного архива почти сутки, у второго дата-центр остался без питания на 19 часов, третьего просто выселили из стойки за долги перед арендодателем. В такие моменты резервный хостинг для сайта превращает катастрофу в неприятный час работы, а его отсутствие превращает аварию в двое суток тишины на всех каналах. Ниже разбираю, что держать наготове, зачем заранее занижать TTL, где поднять заглушку с телефоном за пятнадцать минут и в каком порядке переключаться, чтобы не потерять заявки.

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

Насколько это вообще реально

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

Вот что я реально встречал у клиентов и коллег, с честной оценкой продолжительности.

Тип аварии	Как часто вижу	Обычная длительность	Спасает ли план Б
Перезагрузка ноды, сбой веб-сервера	несколько раз в год	5-40 минут	не нужен, дешевле подождать
Отказ дисков, восстановление из архива хостера	раз в 2-3 года на клиента	4-30 часов	да, это его основной сценарий
Потеря питания или связности ЦОДа	реже, но регулярно у мелких провайдеров	3-20 часов	да
Блокировка аккаунта за нагрузку или спам-рассылку	пару раз в год на всю мою базу	от 2 часов до нескольких суток	да
Приостановка за неоплату (карта не прошла)	самая частая из «длинных»	до момента оплаты, обычно часы	да, но лечится автоплатежом
Хостер закрылся или продан и мигрирует	раз в несколько лет	дни	да, это уже переезд

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

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

Что должно лежать вне хостинга

План Б начинается не с второго сервера, а с того, что у вас есть из чего поднять сайт. Если единственная копия лежит в /home/user/backups/ на том же аккаунте, что и сайт, плана нет: при отказе дисков умрёт и она.

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

Архив файлов. Полный слепок корня сайта, включая wp-content/uploads или /upload/ у Битрикса. Для типовой визитки это 200-600 МБ, для магазина с фотографиями 3-15 ГБ. Обновлять раз в неделю достаточно, потому что код меняется редко, а картинки докидываются медленно.

Дамп базы. Тут наоборот: ежедневно, а для магазина дважды в сутки. База маленькая (обычно 20-300 МБ в сжатом виде) и содержит заказы, заявки, комментарии, настройки.

Экспорт почты. Ящики вида info@вашдомен.ru живут на том же хостинге и падают вместе с ним. Если письма забираются по POP3 и лежат только на сервере, авария означает потерю переписки. Настройте IMAP плюс локальную копию в Thunderbird или пересылку копий на резервный ящик.

Доступы. Регистратор домена, панель хостинга, DNS-провайдер, админка CMS, платёжный шлюз, аккаунт для SSL. Хранить в менеджере паролей, а не в переписке с подрядчиком, у которого в момент аварии может сесть телефон.

Реквизиты DNS. Экспорт зоны в виде текстового файла. Когда переключаетесь в спешке, страшнее всего забыть MX-записи и TXT для SPF и DKIM: сайт поднимете, а почта уйдёт в спам у всех получателей.

Скрипт, который я ставлю клиентам на shared-хостинг. Забирает базу и файлы, кладёт в rclone-удалёнку (Яндекс Объектное Хранилище, Selectel, обычный Яндекс Диск), чистит старое.

#!/bin/bash
set -euo pipefail
SITE=/home/u1234/example.ru/public_html
DEST=/home/u1234/tmp-backup
STAMP=$(date +%F)
mkdir -p "$DEST"

# 1. Дамп базы. Логин и пароль в ~/.my.cnf, а не в аргументах команды.
mysqldump --single-transaction --quick --default-character-set=utf8mb4 
  example_db | gzip -9 > "$DEST/db-$STAMP.sql.gz"

# 2. Файлы. uploads отдельно, чтобы не таскать гигабайты каждый день.
tar czf "$DEST/code-$STAMP.tar.gz" -C "$SITE" 
  --exclude='wp-content/uploads' --exclude='wp-content/cache' .

# 3. Отправка за пределы хостинга.
rclone copy "$DEST" backup:example-ru/daily --transfers=2 --bwlimit=4M

# 4. Чистим локальную промежуточную папку и старое в облаке.
rm -f "$DEST"/*.gz
rclone delete backup:example-ru/daily --min-age 30d

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

Проверка копии обязательна. Раз в квартал разворачиваю дамп на локальной машине или на staging и смотрю, открывается ли главная. Битый gzip или дамп, оборвавшийся на середине из-за таймаута, выглядит как нормальный файл ровно до момента, когда он вам понадобится.

TTL записей DNS: половина плана делается заранее

Самая обидная часть длинной аварии в том, что готовый резерв не помогает мгновенно. Вы подняли копию сайта на другом сервере, поменяли A-запись, а половина посетителей ещё сутки идёт на мёртвый IP, потому что провайдеры кэшируют ответ на TTL.

TTL (time to live) это срок в секундах, в течение которого резолвер имеет право отдавать закэшированный ответ. По умолчанию регистраторы ставят 3600 (час), а иногда 14400 или 86400. Сутки кэша при аварии означают сутки простоя даже с готовым резервом.

Что делать: заранее, в спокойное время, опустить TTL на A и AAAA-записи до 300 секунд. Пять минут кэша немного нагружают DNS-сервер и совершенно не влияют на скорость сайта для пользователя (запись резолвится один раз за сессию и дальше живёт в кэше браузера).

Посмотреть текущее значение можно так:

# Текущий TTL и адрес
dig +noall +answer example.ru A

# Что реально отдаёт авторитетный сервер зоны, минуя кэш провайдера
dig @ns1.example-hosting.ru example.ru A +noall +answer

# Проверить, что MX и SPF не потерялись после правок
dig example.ru MX +short
dig example.ru TXT +short

Вывод вида example.ru. 300 IN A 92.53.123.166 означает, что запись обновится у всех максимум за пять минут. Вывод example.ru. 86400 IN A ... означает сутки ожидания, и правку надо делать сегодня, а не в день аварии.

Важная деталь: снижать TTL нужно за время, равное старому TTL. Если сейчас стоит 86400, то ваши изменения на 300 сами доедут до резолверов только через сутки. Поэтому это работа на профилактике, а не на пожаре.

Второй момент: держите домен и DNS у регистратора, а не в панели хостинга. Когда хостер лежит целиком, его DNS-серверы лежат вместе с ним, и вы физически не сможете переключить запись. Бесплатные DNS от регистратора, Yandex Cloud DNS или Cloudflare (с оговоркой про доступность в РФ, проверяйте на своей аудитории) снимают эту зависимость. У меня был клиент, который час искал, почему панель управления DNS не грузится. Ответ: она хостилась там же, где сайт.

Заглушка с контактами за пятнадцать минут

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

Заглушка это один HTML-файл: логотип, строчка «Сайт временно недоступен по техническим причинам, работаем в обычном режиме», телефон кликабельной ссылкой tel:, мессенджер, адрес и часы работы. Никаких форм: форму некому обрабатывать.

Где её поднять за четверть часа:

• GitHub Pages: репозиторий, файл index.html, включить Pages в настройках. Бесплатно, живёт годами, домен привязывается CNAME.
• Любой второй хостинг, где у вас уже есть аккаунт (например, тот, на котором крутится сайт другого проекта).
• VPS за 300-500 рублей в месяц, если он у вас есть под что-то ещё.
• Отдельный лендинг на конструкторе, если он уже оплачен.

Ключевое условие: заглушка должна существовать до аварии. Сверстать страницу в момент, когда телефон разрывается от звонков клиентов, вы не будете.

Файл заглушки я держу в том же облаке, что и бэкапы, с уже прописанными контактами. Переключение на неё это одна правка A-записи.

Отдельно про HTTPS. Если заглушка поднимается на новом IP без сертификата, браузер покажет предупреждение об опасном соединении, и это хуже, чем ошибка загрузки. GitHub Pages выдаёт сертификат автоматически, на VPS ставится Let’s Encrypt за пару минут:

sudo certbot --nginx -d example.ru -d www.example.ru --agree-tos -m admin@example.ru

Переключение на резервный хостинг: порядок действий

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

1. Убедитесь, что это надолго. Спросите поддержку прямым вопросом: «Дайте оценку времени восстановления». Ответ «в течение часа» это ожидание. Ответ «прогноз дать не можем» это сигнал к переключению. Заодно проверьте статус-страницу и профильные чаты: если лежит вся площадка, там уже паника.
2. Разверните копию на резерве. Распакуйте архив, залейте дамп, поправьте wp-config.php или .settings.php под новые доступы к базе.
3. Проверьте на резерве до переключения DNS. Это делается через файл hosts на вашей машине, без всякой публичности.
4. Поднимите сертификат на резервном сервере для того же домена.
5. Переключите A-запись на новый IP. Если TTL заранее 300, через пять минут пойдёт трафик.
6. Проверьте почту и формы. Отправьте тестовую заявку, убедитесь, что письмо дошло и в CRM или Telegram упало уведомление.
7. Повесьте на сайт уведомление о временном режиме, если часть функций не работает (например, оплата).

Проверка через hosts выглядит так. В Windows файл лежит в C:WindowsSystem32driversetchosts, в Linux и macOS в /etc/hosts, редактируется с правами администратора:

# Пока DNS ещё смотрит на старый сервер, локально шлём себя на резервный
203.0.113.45   example.ru
203.0.113.45   www.example.ru

После этого открываете https://example.ru в браузере и видите резервную копию, а весь остальной интернет видит старый сервер. Тыкаете формы, каталог, личный кабинет. Строку из hosts потом убираете, иначе через неделю будете искать, почему у вас сайт открывается не так, как у всех.

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

На чём переключение обычно ломается

Список собран из собственных факапов и клиентских историй.

• Забыли MX-записи. Меняя A-запись, люди иногда правят зону целиком и теряют почту. Домен продолжает работать, письма перестают приходить, узнаёте через неделю от обиженного клиента.
• Резерв поднят на другой версии PHP. Сайт с PHP 8.2 приезжает на сервер с 7.4 и падает белым экраном. Версию проверяйте заранее, при настройке резерва, а не в момент аварии.
• Права на файлы после распаковки. Классика: tar разворачивается от root, веб-сервер не может писать в uploads, картинки не грузятся. Лечится chown и стандартными 644 на файлы, 755 на папки.
• Старые пути в базе. Если резерв поднимается на техническом домене вроде backup.example.ru, ссылки и картинки в базе останутся с боевым доменом. Для WordPress лечится wp search-replace, для Битрикса правкой настроек сайта.
• Кэш и CDN. Если перед сайтом стоит CDN, переключать надо origin в панели CDN, а не A-запись домена.
• Второй сервер у того же провайдера. Резерв в том же дата-центре умирает вместе с боевым. Резервный хостинг для сайта имеет смысл брать у другой компании, а лучше в другом городе.
• Пароли от резерва лежат на боевом сервере. Видел и такое: файл с доступами хранился в закрытой папке сайта, которая лежала вместе с хостингом.

Возврат обратно и заявки, пришедшие на резерв

Про обратное переключение забывают почти все, а грабли там серьёзнее.

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

Что делаю я:

1. Дожидаюсь, пока боевой хостинг стабильно проработает хотя бы 12 часов. Провайдеры часто поднимают сервис и через час снова роняют.
2. Снимаю с резерва свежий дамп базы и папку uploads.
3. Заливаю дамп с резерва на боевой сервер как основной, а не наоборот. Резерв за время аварии стал источником правды, старая база устарела.
4. Сверяю счётчики: количество записей в таблице заказов или заявок до аварии и после. Расхождение должно совпадать с числом обращений за период.
5. Переключаю A-запись обратно и оставляю резерв работающим ещё сутки. Часть посетителей досидит на старом кэше DNS, и пусть они видят живой сайт, а не ошибку.
6. Через сутки резерв гашу и делаю новый эталонный бэкап.

Отдельная история, если на время аварии вы перевели формы на почту или на Telegram-бота. Тогда заявки за период лежат в мессенджере, и их надо руками занести в CRM. Договоритесь с менеджером заранее, кто это делает, иначе половина потеряется в переписке.

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

Сколько стоит держать план Б

Считаю по типовому сайту услуг: WordPress, 300 МБ файлов, база 60 МБ, две формы заявки.

Компонент	Вариант	Цена в месяц, ориентир
Хранилище для копий вне хостинга	S3-совместимое, 20 ГБ	60-150 руб.
Мониторинг доступности	бесплатный тариф на 50 URL	0 руб.
Заглушка	GitHub Pages	0 руб.
Тёплый резерв (сайт развёрнут, обновляется раз в неделю)	shared у второго провайдера	250-500 руб.
DNS у регистратора с TTL 300	входит в обслуживание домена	0 руб.
Работа на настройку и квартальные учения	2-3 часа разово, потом по часу в квартал	по ставке

Итого инфраструктура плана Б для визитки или сайта услуг обходится в 300-650 рублей в месяц. Это меньше, чем стоит один потерянный заказ у большинства моих клиентов.

Для магазина цифры другие: тёплый резерв с ежедневной синхронизацией базы обычно требует VPS от 800 рублей и настроенной репликации, плюс регулярная проверка, что резерв не разъехался с боевым. Здесь уже честнее говорить не про план Б, а про полноценную отказоустойчивость, и это отдельный бюджет.

Холодный вариант (копии в облаке плюс готовая заглушка, без развёрнутого второго сервера) стоит около 100 рублей в месяц и даёт время восстановления 2-4 часа вместо суток. Для большинства малого бизнеса этого достаточно. Тёплый резерв сокращает время до 20-40 минут и нужен тем, у кого сайт принимает оплату.

Чек-лист: что сделать на этой неделе

Пробегитесь по пунктам, это займёт вечер.

• [ ] Проверить, куда уезжают бэкапы. Если на тот же аккаунт, где сайт, настроить выгрузку наружу.
• [ ] Развернуть последнюю копию локально и убедиться, что она рабочая.
• [ ] Посмотреть dig +noall +answer домен A и опустить TTL до 300.
• [ ] Убедиться, что DNS управляется у регистратора, а не в панели хостинга.
• [ ] Сохранить экспорт DNS-зоны текстовым файлом, отдельно выписать MX и TXT.
• [ ] Сверстать заглушку с телефоном и положить в облако.
• [ ] Собрать доступы (регистратор, хостинг, DNS, админка, эквайринг) в менеджер паролей.
• [ ] Настроить мониторинг, который проверяет отправку формы, а не только код 200 на главной.
• [ ] Записать в календарь квартальную проверку: развернуть бэкап, прогнать переключение через hosts.

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

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

Частые вопросы

Нужен ли резервный хостинг маленькому сайту

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

Что делать, если хостинг лёг надолго

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

Почему важен параметр времени жизни DNS

От него зависит, как быстро переключение дойдёт до посетителей. Значение в час означает час ожидания. Небольшим его держат постоянно, а не вспоминают перед переездом.

Что делать с заявками, пришедшими на резерв

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