Копии лежали в том же зале дата-центра: разбор и выводы

MAATRIX

Команда была уверена, что резервные копии лежат «в другом дата-центре» — так значилось в описании тарифа у провайдера, так называлась вторая машина в инвентаре, так это объясняли новым инженерам на онбординге. А потом ночью погас целый зал, и выяснилось, что прод и бэкап всё это время стояли в паре стоек друг от друга, на одном вводе электропитания. Разбираем, как разошлись слова «второй сервер» и «второй зал», что показывал мониторинг в момент аварии и что нужно проверять до того, как это станет вашей историей.

Что сломалось

Инфраструктура была обычной для среднего проекта: продовый сервер с приложением и PostgreSQL у одного хостера, и второй сервер — «бэкап-нода» — тоже у него же, но по документации на другой площадке. Ночной cron гонял borgbackup на этот второй сервер по SSH, копии хранились семь дней с дедупликацией, раз в неделю запускалась контрольная выгрузка дампа базы. На бумаге всё выглядело правильно: два физических сервера, два IP из разных подсетей, отдельный аккаунт для бэкап-пользователя с правами только на дозапись через borg --append-only.

Авария случилась около трёх часов ночи. Сначала отвалился мониторинг продового сервера — потеря пинга, алерт в Telegram. Дежурный инженер открыл панель, чтобы посмотреть на состояние бэкап-ноды и оценить, из чего восстанавливаться при худшем сценарии — и обнаружил, что бэкап-нода тоже не отвечает. Оба сервера пропали одновременно.

Через сорок минут провайдер опубликовал статус-страницу: авария на вводе электропитания одного из залов дата-центра — сработала защита при переключении с городской сети на резервный генератор, автоматика ATS не подхватила нагрузку вовремя, часть стоек осталась без питания на 52 минуты. Восстановили обе машины почти сразу после появления питания, данные не пострадали — в этот раз просто повезло, что авария была по питанию, а не по воде или дыму. Но сам факт, что «резервная» копия оказалась недоступна ровно тогда же, когда и прод, требовал разбора: если бы авария затронула диски физически, второй копии для восстановления просто не было бы.

Что показали логи и мониторинг

Первым делом подняли таймлайн по метрикам, чтобы понять — совпадение это или системная проблема:

03:02:14 — icmp_seq потерян до prod-01 (мониторинг Zabbix, интервал 30с)
03:02:19 — icmp_seq потерян до backup-01
03:02:44 — оба хоста помечены DOWN, эскалация в Telegram
03:03:10 — дежурный инженер онлайн, проверяет both hosts через отдельный VPN-джамп — недоступны
03:41:02 — backup-01 отвечает на ping
03:43:55 — prod-01 отвечает на ping
03:54:00 — статус-страница провайдера: инцидент на вводе питания зала D3

Ключевая деталь — оба хоста легли и поднялись почти синхронно, с разницей в единицы секунд. При независимых физических площадках так не бывает: даже при общей аварии у провайдера (например, проблема с апстрим-каналом) время реакции разных залов и разного оборудования обычно отличается на десятки секунд-минуты за счёт разных UPS, разных маршрутов и разной очереди на восстановление. Здесь же оба сервера синхронно исчезли и синхронно появились — это указывало на общий физический ресурс, а не на два независимых инцидента подряд.

Второй сигнал нашли в mtr-логах, которые команда, по счастью, гоняла раз в сутки для профилактики (сохраняли в файл на джамп-хосте в третьей локации):

mtr -rw -c 20 prod-01.example.net
mtr -rw -c 20 backup-01.example.net

Оба трейса до аварии проходили через один и тот же узел на предпоследнем хопе — L3-свитч с одинаковым hostname в reverse DNS. До этого момента на это просто не обращали внимания: два разных IP, два разных hostname серверов — какая разница, через какой свитч они торчат наружу.

Какие гипотезы отбросили

Пока восстанавливали доступ, разбирали версии произошедшего — по порядку, от самой удобной к самой неприятной:

• DDoS или сетевая атака. Отбросили быстро: не было аномального трафика в NetFlow ни на одном из серверов, а провайдер сам подтвердил аварию на своей стороне ещё до того, как её начали искать снаружи.
• Совпадение двух независимых сбоев. Версия «просто не повезло, оба сервера упали в одну минуту случайно» не выдерживала критики при разнице в 5 секунд между потерей пинга на обоих хостах и синхронным восстановлением с разницей в 3 секунды. Вероятность такого совпадения для независимых площадок близка к нулю.
• Проблема на стороне мониторинга, а не серверов. Проверили: сам Zabbix-сервер стоял у третьего провайдера, отдельно, и продолжал отвечать всё время инцидента — значит, недоступность была реальной, а не артефактом наблюдателя.
• Обычный плановый апгрейд без предупреждения. У провайдера не было записи о плановых работах на эту ночь, а статус-страница явно называла это инцидентом (incident), а не maintenance.
• Ошибка маршрутизации на аплинке дата-центра целиком. Была близка к правде, но не объясняла, почему статус-страница провайдера указывала конкретно на «зал D3», а не на весь ЦОД — значит, проблема была локализована в одном физическом сегменте, а не на уровне сети целиком.

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

Реальная причина: два сервера — один зал

Написали в поддержку провайдера прямой вопрос: в каком зале (building/hall/room code) физически стоят prod-01 и backup-01. Ответ пришёл через час: оба сервера — в зале D3, разные стойки, но один и тот же PDU-сегмент на вводе, то есть одна и та же цепочка «городская сеть → ATS → генератор → распределительный щит» для обеих машин.

Как так вышло, если бэкап-сервер заказывали отдельно и осознанно «для отказоустойчивости»? Разобрали цепочку решений:

1. При первой аренде продового сервера выбрали тариф в конкретном ЦОД провайдера — без указания зала, потому что в форме заказа такого поля не было вовсе.
2. Через полгода при заказе второй машины под бэкапы выбрали тот же дата-центр (тот же город, тот же провайдер) просто потому, что там уже был налажен приватный канал и не хотелось тянуть трафик бэкапов через интернет лишний раз.
3. В карточке тарифа у провайдера название площадки было общее — «ЦОД №2, уровень Tier III» — без разбивки по залам. Инженеры прочитали это как «дата-центр» в бытовом смысле — здание, а по факту это оказался комплекс из нескольких залов с независимым питанием, но «ЦОД №2» относилось ко всему комплексу целиком.
4. Никто не запросил у поддержки код зала при заказе — не было такой практики, потому что сам вопрос «а в каком именно зале стоит мой сервер» до этого момента никому не приходил в голову.

То есть формально было выполнено требование «второй сервер, отдельный от прода» — но не было выполнено требование «отдельный домен отказа». Второй hostname, второй IP, вторая биллинговая запись — но общий ввод питания и общий физический периметр. При аварии по питанию, охлаждению, пожаре в этом зале или физическом повреждении стоек оба сервера отказали бы синхронно — что почти и произошло, просто авария оказалась достаточно короткой и не задела диски.

Отдельно стоит сказать: это не единичная особенность конкретного провайдера, а системная ловушка формулировок. «Второй сервер», «другой аккаунт», «отдельная подписка» — это про биллинг и логическое разделение, а не про физическую изоляцию. Провайдер не обманывал — он просто не был обязан сообщать код зала, если его не спросили явно. Похожая логика разобрана в статье про антипаттерн, когда бэкап лежит на том же сервере, что и прод: там ошибка нагляднее, потому что оба каталога на одном диске, а здесь она спрятана на уровень глубже — за фасадом «двух разных серверов».

Что изменили: чек-лист физической изоляции

После разбора инцидента поменяли не только технологию, но и сам процесс заказа инфраструктуры для копий:

• Перенесли резервную копию в другую страну. Вместо второго сервера в том же ЦОД взяли машину в другом регионе — не потому что это модно, а потому что при межстрановой аренде физическая изоляция гарантирована по определению: разные здания, разные энергосети, разная юрисдикция на случай изъятия оборудования.
• Добавили запрос кода зала/стойки в чек-лист заказа. Теперь при аренде любого сервера, который должен быть независимым доменом отказа от другого, первым делом в тикете поддержки спрашивают building/hall/room code и, если провайдер может дать, — номер PDU или UPS-группы.
• Ввели третью копию по правилу 3-2-1. Кроме прод-сервера и удалённого бэкапа добавили третью копию — офлайн-снапшот на объектное хранилище с версионированием и retention-политикой, независимый от обоих провайдеров. Логику и экономику этого разобрали отдельно в статье про правило 3-2-1 для бэкапов и как выполнить его дёшево.
• Настроили регулярный mtr/traceroute-снимок маршрутов до прод- и бэкап-серверов, с сохранением в отдельном логе и алертом, если предпоследний хоп у обоих серверов совпадает — это дешёвый косвенный индикатор общей физической инфраструктуры, который не требует доверия к документации провайдера.
• Добавили тестовое восстановление по расписанию, а не «когда-нибудь проверим» — раз в месяц поднимают тестовую машину и разворачивают на неё последнюю резервную копию целиком, включая проверку контрольных сумм и работоспособности приложения. Практику детально описали в статье как проверить, что бэкап рабочий, не восстанавливая всё.
• Задокументировали домены отказа в внутренней wiki: для каждой пары «прод + резерв» явно записано, чем именно они изолированы друг от друга — географией, энергией, провайдером, — и на основании чего это утверждение сделано (ответ поддержки, whois, независимая проверка).

Как проверить свои копии прямо сейчас

Если вы не уверены, что ваш «второй сервер» на самом деле второй домен отказа, а не сосед по залу, это можно проверить за один вечер, без ожидания следующей аварии.

Сначала — сетевая проверка, она не требует доступа к документации провайдера:

# сравнить маршруты до прод- и бэкап-сервера
mtr -rw -c 20 prod.example.net > prod-route.txt
mtr -rw -c 20 backup.example.net > backup-route.txt
diff prod-route.txt backup-route.txt

# посмотреть, к какой сети/автономной системе приписан каждый IP
whois $(dig +short prod.example.net) | grep -iE 'netname|origin|country'
whois $(dig +short backup.example.net) | grep -iE 'netname|origin|country'

# грубая оценка задержки — серверы в одном зале почти всегда отвечают за доли миллисекунды друг другу
ssh backup.example.net "ping -c 5 prod.example.net"

Если предпоследний хоп в трассировке совпадает, или whois показывает одну и ту же подсеть/AS, или пинг между серверами меньше миллисекунды — это повод для прямого вопроса в поддержку, а не окончательный вывод: разные ЦОД одного оператора связи иногда действительно дают такую задержку через приватный канал. Поэтому второй шаг — прямой запрос:

• Попросите у поддержки провайдера код зала/здания (building/hall/room) для каждого из ваших серверов, а не просто «в каком дата-центре».
• Уточните, общий ли ввод электропитания (PDU/UPS-группа) — большинство провайдеров уровня Tier III могут дать этот ответ по тикету за несколько минут, потому что у них это записано в CMDB.
• Если вам важна не только физическая, но и юридическая изоляция (например, на случай блокировки или изъятия оборудования в одной юрисдикции), проверьте, в какой стране физически находится площадка — иногда «европейский» ЦОД по факту стоит в одной конкретной стране, что не всегда очевидно из названия тарифа.
• Сохраните эти ответы поддержки как часть документации по инфраструктуре — при следующей ротации персонала или смене провайдера это будет единственным источником правды, не полагающимся на маркетинговые формулировки тарифа.

Для нового бэкап-контура разумно сразу закладывать географическую разнесённость на уровне выбора локации, а не выяснять её постфактум. Если прод стоит в России, логичный вариант резервной копии — сервер в другой стране: например, аренда сервера в Великобритании под бэкап-контур даёт независимую электросеть, независимую юрисдикцию и достаточно короткий сетевой путь для регулярной синхронизации инкрементальных копий без огромных задержек.

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