Когда основной хостинг недоступен, запасной сервер полезен лишь в том случае, если на нём уже подготовлены сайт, база, сертификат и процедура переключения. «Купим VPS в день аварии» — это не план восстановления: сервер может требовать настройки, а на восстановление базы и проверку интеграций уйдут часы. После событий у Beget в начале ноября 2026 года многие владельцы бизнеса заново оценивают, сколько простоя и потери данных их проект способен пережить. Решение начинается не с покупки тарифа, а с двух цифр: RTO и RPO.
Сначала определите допустимый простой
RTO — максимально приемлемое время между отказом и восстановлением работы. RPO — насколько давними могут быть данные в точке восстановления, то есть сколько новых операций бизнес допустит потерять. AWS в документации по аварийному восстановлению отдельно подчёркивает: цели задаёт сама организация в зависимости от последствий простоя и потери данных.
Для каталога с редкими заявками допустим RTO в несколько часов и копирование базы раз в ночь. Для магазина с постоянными оплатами это может быть неприемлемо: потерянные заказы сложнее восстановить, чем файлы сайта. Спросите отдел продаж, сколько заявок приходит в обычный час и сколько стоит их потеря. Затем обсудите с бухгалтерией и поддержкой, сколько времени команда способна вручную принимать заказы.
Выберите уровень резерва
Холодный резерв — архивы и инструкции хранятся отдельно, сервер при аварии создают с нуля. Это дешевле, но RTO длиннее: нужно развернуть систему, загрузить данные, проверить сайт и DNS.
Тёплый резерв — сервер уже существует и настроен, данные копируются регулярно, но часть сервисов запускается только при переключении. Это компромисс для небольшого бизнеса. Нужно заранее знать, где взять актуальные конфигурации, сертификат и ключи интеграций.
Горячий резерв — запасная среда постоянно готова принимать трафик и получает изменения почти непрерывно. Такой режим требует мониторинга синхронизации и аккуратного управления записью в базу. Два одновременно работающих сайта без правил синхронизации могут создать конфликтующие заказы и остатки.
Рейтинг VPS/VDS для резервной площадки
����ࢭ� VPS ����� ���, � �ਫ������ �㦭� �⤥��� �ࢥ�� ����ன�� ��� ��࠭�� �����⮢������ ���㦥���. �ࠢ��� ���頤�� �� ����樨, ������ � ���᮫�, ����� � �������������, ��⥬ �����⮢�� � ���⠩� ��४��祭�� �� ���ਨ.
Что должно быть на VPS
Опишите проект как список компонентов: файлы, база, версия PHP, веб-сервер, фоновые задачи, почтовые и платёжные интеграции, DNS, сертификаты, загрузки и внешние API. Для каждого пункта укажите, кто владеет доступом и как его восстановить. Не храните пароль в общей инструкции: используйте защищённое хранилище секретов и отдельные роли.
Настройте резервное копирование файлов и базы на независимое хранилище. Снимок диска на том же VPS помогает при неудачном обновлении, но не защитит от потери доступа к аккаунту или всей площадке. Копия должна быть за пределами основного хостинга, а её восстановление — проверено. WordPress отдельно предупреждает, что копия базы не включает файлы сайта, поэтому оба набора нужно сохранять.
Не переносите в запасную среду неподтверждённые настройки. Сначала разверните тестовую копию, проверьте права файлов, адрес базы, постоянные ссылки, PHP-расширения и фоновые задания. Отключите тестовую отправку писем, реальные платежи и действия, которые могут дублировать заказы. Перед аварией храните короткий runbook с последовательностью действий и критериями «можно переключать».
Переключение DNS — только последняя часть
Заранее уменьшите TTL у записей, которые потребуется менять, но сделайте это до инцидента: уже закешированные ответы продолжат действовать до истечения старого TTL. При этом значение TTL не заставит все сети обновиться мгновенно. Cloudflare объясняет, что низкий TTL ускоряет применение будущих изменений, но увеличивает число DNS-запросов, а существующий кеш живёт до указанного срока.
В день переключения сначала остановите изменения в старой базе или включите режим обслуживания. Затем финально перенесите последние данные, проверьте тестовую копию через локальное сопоставление домена или временный адрес, смените DNS и следите за обеими площадками. Не допускайте одновременной записи в две базы. Если резервный сервер отстаёт, обозначьте окно, когда заказы временно принимаются вручную.
Решите заранее, как выглядит откат. Возврат DNS на старый сервер после того, как пользователи уже записали данные на новый, не вернёт их автоматически. Поэтому для каждого шага укажите владельца, время, ожидаемый результат и способ сравнить базы.
Испытание резервной площадки
Проведите плановую репетицию на копии: отключите основной адрес только для тестовой группы или временного домена, восстановите файлы и базу, затем пройдите сценарии клиента. Засеките фактическое время. Сверьте его с RTO. Возраст базы сравните с выбранным RPO. Если цель не выполняется, поменяйте частоту копий или процедуру, а не просто перепишите показатель в таблице.
Минимальный тест включает главную и несколько внутренних страниц, авторизацию, формы, тестовую оплату, почту, новые изображения и восстановление одной копии. Запишите, сколько времени заняли доступы, передача архива, настройка окружения и DNS. Повторяйте такую проверку после крупного изменения CMS, плагинов, структуры базы или договора с провайдером.
Расходы состоят не только из тарифа VPS. Добавьте оплату диска для копий, исходящего трафика, лицензий, мониторинга и часов специалиста. Выбирайте конфигурацию по измеренной нагрузке, а не по принципу «самый мощный сервер». Для проекта без системного администратора управляемый вариант может оказаться дешевле, чем самостоятельное устранение ошибок в ночь аварии.
Распределите роли до аварии
В небольшой компании один человек часто одновременно знает пароль от панели, настраивает DNS и принимает решения о восстановлении. Если он недоступен, техническая инструкция может оказаться бесполезной. Назначьте основного и резервного ответственного, выдайте им отдельные учётные записи с минимально необходимыми правами и проверьте, что восстановление доступа работает.
Разделите техническое решение и бизнес-решение. Администратор может подтвердить, что резервная копия развернулась, но запуск заказов должен согласовать владелец магазина или операционный менеджер после проверки платежей и остатков. В инструкции укажите, кто имеет право включить сайт на запись, кто оповещает команду и кто принимает решение о возврате на основную площадку.
Посчитайте полную стоимость резерва
Стоимость аварийного восстановления складывается из VPS/VDS, хранения копий, исходящего трафика, лицензий, мониторинга и работы специалиста. Добавьте регулярные часы на проверку и обновление среды. Самый дешёвый тариф может не подойти по диску или поддержке, а мощный сервер без синхронизации данных не сокращает простой.
Для оценки можно сравнить два сценария: холодный резерв, который поднимается после события, и подготовленный сервер, где остаётся только финальное переключение. Запишите фактические сроки тестового восстановления, а не рекламные ожидания. Сопоставьте ежегодные расходы с потерями от недоступности: пропущенные обращения, ручная обработка заказов, возвраты и репутационные последствия.
Частые вопросы
Нужен ли отдельный VPS, если есть ежедневные бэкапы?
Нет, если ваш допустимый простой позволяет восстановить проект на новом сервере в нужный срок. Но сначала измерьте полное время восстановления, а не только время создания копии.
Можно ли автоматом переключать DNS при недоступности?
Можно, но только после проверки здоровья приложения и согласованности данных. Проверка одного IP или порта не гарантирует, что сайт принимает записи и подключён к актуальной базе.
Какой провайдер гарантирует резервирование?
Не полагайтесь на общий ярлык. Запросите документацию о типе копий, зоне хранения, сроке, процедуре восстановления и тесте. Условия тарифа и SLA проверяйте перед оплатой.