Резервная площадка в другом городе: зачем нужна и как организовать

Бэкапы есть, сервер надёжный, дата-центр уровня Tier III. Кажется, этого достаточно. До момента, когда падает не сервер, а площадка целиком: авария на канале, работы у оператора связи, отказ электропитания. Сервер при этом полностью исправен, данные на месте, но недоступны, и ждать приходится столько, сколько потребуется чужим инженерам.

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

Чего не закрывают бэкапы

Резервная копия и резервная площадка решают разные задачи, и путать их дорого.

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

Вторая площадка отвечает на вопрос, где продолжить работу. Она не заменяет копии, а сокращает простой: инфраструктура уже развёрнута, остаётся переключить трафик.

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

Почему именно другой город

три уровня резерва, чем они отличаются по стоимости и времени переключения.
три уровня резерва, чем они отличаются по стоимости и времени переключения.

Второй сервер в том же дата-центре защищает от отказа железа, но не от аварии самой площадки. Общие у них питание, охлаждение, каналы связи и физическое расположение.

Географически разнесённая площадка снимает целый класс проблем:

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

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

Для проектов, размещённых в Москве, логичная вторая точка - площадка в другом регионе России: данные остаются в стране, требования 152-ФЗ выполняются, а сетевая независимость есть. Именно так обычно используют сервер в Казани - как георезерв для московских проектов.

Три уровня резерва

Выбор всегда компромисс между стоимостью и временем восстановления.

УровеньЧто держится наготовеПереключениеСтоимость
ХолодныйТолько копии данныхЧасыМинимальная
ТёплыйРазвёрнутый сервер, данные синхронизируютсяМинутыСредняя
ГорячийОба сервера в работе одновременноСекундыДвойная

Холодный резерв - это фактически хранилище копий на другой площадке. Дёшево, но при аварии сервер придётся поднимать с нуля.

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

Горячий резерв - обе площадки принимают трафик, переключение автоматическое. Дорого, сложно и оправдано, когда даже минуты простоя недопустимы.

Начинать разумно с тёплого: он закрывает большую часть рисков за понятные деньги.

Что синхронизировать

Ошибка новичков - копировать всё подряд. Разделите на три категории.

Данные, которые меняются постоянно. База и загруженные пользователями файлы. Их синхронизируют регулярно, и именно интервал определяет, сколько вы потеряете при аварии.

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

Код приложения. Разворачивается из репозитория. Отдельно синхронизировать не нужно, достаточно выкатывать на обе площадки, см. как выложить приложение на сервер.

Для файлов удобен rsync по расписанию, для базы - штатная репликация или регулярная выгрузка дампа, см. передачу файлов.

Как переключаться

Самое узкое место схемы, и оно не техническое, а про время.

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

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

Второй момент: узнать об аварии надо раньше клиентов. Внешняя проверка доступности с оповещением обязательна, иначе схема с резервом бесполезна, см. мониторинг VPS.

Проверка: без неё резерва нет

Непроверенный резерв - это предположение, а не защита. Проверка проводится по расписанию, хотя бы раз в квартал.

1. Переключиться на резерв в спокойное время и поработать на нём хотя бы час. 2. Проверить целостность данных: свежесть базы, наличие загруженных файлов. 3. Проверить внешние связи: платежи, почта, интеграции, которые могут быть привязаны к IP-адресу основного сервера. 4. Замерить фактическое время переключения и сравнить с ожиданиями. 5. Вернуться обратно и убедиться, что данные, накопленные на резерве, не потерялись.

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

Частые ошибки

Считают резервную копию резервной площадкой. Копия отвечает, откуда взять данные, площадка - где продолжить работу.

Ставят второй сервер в том же дата-центре. От отказа железа защищает, от аварии площадки нет.

Не снижают TTL заранее. В момент аварии выясняется, что переключение растянется на часы.

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

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

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

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

Чем резервная площадка отличается от бэкапа? Бэкап - это данные, из которых можно восстановиться. Площадка - развёрнутая инфраструктура, куда можно переключиться. Одно не заменяет другое, нужны оба.

Зачем резерв именно в другом городе? Второй сервер в том же дата-центре разделяет с основным питание, охлаждение и каналы. Географически разнесённая площадка защищает от аварии инфраструктуры целиком.

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

Как быстро происходит переключение? При тёплом резерве - минуты, если TTL домена заранее снижен. При холодном - часы, потому что сервер нужно разворачивать. Основную задержку даёт не техника, а кеширование DNS.

Как часто синхронизировать данные? Настолько часто, насколько не жалко потерять. Интервал синхронизации равен объёму данных, который вы потеряете при аварии.

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


Нужна вторая площадка для георезерва? VPS в Казани на площадке Tier III - независимый узел, не связанный с московскими площадками, оплата в рублях и активация за 3 минуты. Основную инфраструктуру при этом можно держать в Москве, у одного провайдера и в одном личном кабинете.