Резервный сервер для ведомства: минимальная архитектура без 2 ЦОД

Что именно нужно пережить при отказе

Полезно сразу назвать вещи своими именами: отказ - это не только ситуация, когда «сервер умер». В небольшом ведомстве (обычно 5-50 рабочих мест) есть 1-2 сервиса, без которых работа встает: учетная система или база, документооборот, почта, общий файловый ресурс, доступ к специализированным реестрам.

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

Сбои бывают похожими по симптомам, но сильно различаются по последствиям:

• Поломка сервера целиком (плата, память, контроллер) - сервисы останавливаются сразу.
• Отказ дисков или хранилища - данные могут быть на месте, но система не поднимается.
• Проблемы с питанием (выбило автомат, «просадка», отказал ИБП) - внезапное выключение и риск повреждения данных.
• Потеря связи (провайдер, маршрутизатор, «лег» VPN) - сервер работает, но до него не добраться.
• Ошибка человека (удалили базу, неудачное обновление, шифровальщик) - железо целое, а работать нельзя.

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

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

Минимальные требования: RTO и RPO без сложных терминов

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

RTO - это сколько времени сервис может быть недоступен после сбоя. Проще: «сколько можно терпеть, пока снова заработает». RPO - это сколько данных вы готовы потерять. Проще: «насколько назад можно откатиться по времени».

Практичный шаг: выберите 3-5 критичных сервисов и назначьте владельцев со стороны бизнеса (не только ИТ). Например: почта, файловое хранилище, 1С или бухгалтерия, домен и авторизация, ведомственная система учета обращений. С владельцами проще согласовать реальные цифры, а не пожелание «чтобы не падало».

Для каждого сервиса ответьте на два вопроса:

• Максимальный простой (RTO): 30 минут, 4 часа, 1 день.
• Максимальная потеря данных (RPO): 15 минут, 1 час, 24 часа.

После этого разложите сервисы по уровням. Так вы не строите одинаковую защиту для всего подряд:

• Обязательно: без них работа встает (короткий RTO, небольшой RPO).
• Желательно: мешает, но можно пережить несколько часов.
• Может подождать: восстановление на следующий день допустимо.

Пример: для домена RTO 1-2 часа и RPO 1 час, для файлового архива RTO 1 день и RPO 24 часа, для бухгалтерии RTO 4 часа и RPO 4 часа (если документы вводят пакетами).

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

Где размещать резерв: рядом, в филиале или у партнера

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

На практике чаще всего выбирают одну из трех схем:

• В том же здании. Дешево, быстро и проще согласовать. Хорошо спасает от поломки основного сервера, ошибок обновления и части проблем с питанием (если резерв на отдельной линии и с ИБП). Не спасает от пожара, затопления, кражи, отключения здания целиком и иногда от сетевых проблем, если все проходит через один шкаф.
• В другом здании или филиале. Лучше по рискам: переживете проблемы с помещением, локальным электричеством и часть инцидентов безопасности. Цена вопроса часто не в железе, а в связи и администрировании: нужен стабильный канал, понятный доступ для ИТ и место, где оборудование реально обслужить.
• На площадке у партнера. Подходит, если есть доверенный партнер и формальные основания для размещения. Закрывает риски по зданию и часто дает более надежные условия (охрана, климат, питание). Но добавляет организационные вопросы: доступ, допуск к стойке, возможность попасть к оборудованию ночью.

Выбор удобно делать на простом примере. Если в офисе регулярно выбивает электричество, но крупных аварий по зданию не было десятилетиями, резерв рядом с хорошим ИБП уже даст эффект. Если же в здании идут ремонты и есть риск затопления, лучше смотреть на другое помещение.

Перед решением проверьте:

• есть ли отдельное питание и место под ИБП;
• насколько стабильна связь между площадками и кто за нее отвечает;
• кто имеет физический доступ к серверу и как это фиксируется;
• сколько времени нужно, чтобы добраться до оборудования при аварии;
• где будут храниться копии данных отдельно от самого резерва.

Если закупаете оборудование локально (например, серверы уровня S200 для резервной площадки), заранее закладывайте не только «железо», но и условия размещения. Они чаще всего определяют, переживет ли схема реальный отказ.

Минимальная архитектура: один хост, виртуальные сервисы, ИБП

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

Смысл виртуализации в том, что вы переносите не «железо», а готовые сервисы. При отказе основного сервера включаете нужные виртуальные машины на резервном хосте и продолжаете работу в упрощенном режиме.

Какие виртуальные машины держать отдельно

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

• контроллер домена и DNS (аутентификация пользователей, базовые политики);
• файловый сервис (общие папки, шаблоны, документы);
• прикладной сервис или БД (лучше отдельно, но при дефиците ресурсов иногда объединяют).

Если есть специализированные системы (документооборот, учет), заранее решите, что в аварии поднимается первым, а что может подождать.

Диски и питание: два места, где чаще всего ошибаются

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

По питанию обязательно нужен ИБП. Важно не только «держать 10-15 минут», но и уметь корректно завершать работу, если электричества нет долго. Настройте автоматическое выключение хоста и виртуальных машин по сигналу от ИБП, иначе риск повреждения файлов и баз резко растет.

Пример: отдел на 40 сотрудников держит резервный хост в серверном шкафу в офисе и заранее готовит 2-3 виртуальные машины. При аварии в первую очередь поднимают домен и файлы, а прикладную систему запускают следом, когда убедились, что питание и сеть стабильны. Для такого хоста часто выбирают платформы с надежной поддержкой и сервисом на месте, например из линейки GSE S200, если принципиальны местное производство и обслуживание.

Бэкапы и хранение копий: чтобы действительно восстановиться

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

Хорошая базовая схема - правило 3-2-1: три копии данных, на двух разных типах носителя, и минимум одна копия вне площадки. Для небольшой серверной это обычно означает: копия на локальном хранилище, копия на съемном носителе или отдельном NAS, и еще одна копия в другом месте (филиал, партнерская площадка, защищенное удаленное хранилище).

Частоту бэкапов задавайте не «по ощущениям», а по типу данных и цене потери:

• документы и общие папки: ежедневно ночью, плюс еженедельная полная копия;
• базы данных (учет, обращения, реестры): чаще, например каждые 1-4 часа, если данные постоянно меняются;
• конфигурации серверов и сетевого оборудования: после каждого изменения и раз в неделю на всякий случай;
• почта и ключевые сервисы (если есть): ежедневно, а важные журналы - отдельной политикой.

По хранению держите «быструю» копию рядом (чтобы восстановиться за часы), а «страховую» - отдельно. Простой вариант: локальный репозиторий на резервном хосте и съемный носитель, который выносят из серверной по расписанию. Более надежный - вторая площадка в другом здании или районе, чтобы пережить пожар, затопление или длительное отключение электричества.

Часто пропускают главное: проверку восстановления. Раз в месяц сделайте короткий тест: поднять копию на изолированной виртуальной машине и убедиться, что сервис реально запускается.

Минимальные проверки:

• открывается ли база/папки, не повреждены ли файлы;
• совпадает ли время последней успешной копии с ожиданиями (RPO);
• сколько заняло восстановление до рабочего состояния (RTO);
• есть ли журнал: кто запускал бэкап, были ли ошибки, куда ушли копии.

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

Сеть и доступ: как пользователи продолжат работать

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

Между площадками нужен канал, который выдержит обычный рабочий поток (почта, документооборот, файлы, удаленные рабочие места). Для небольшого ведомства часто хватает 100-300 Мбит/с, если вы не гоняете большие базы и не держите тяжелые VDI. Но важнее не «скорость на бумаге», а стабильность: потери пакетов и просадки убьют работу быстрее, чем «мало мегабит». Если бюджет позволяет, держите второй независимый канал (другой провайдер или LTE/5G как запасной вариант) хотя бы для ключевых сервисов.

Доступ к резервной площадке давайте через VPN и по принципу «только кому нужно». Обычно хватает:

• отдельной группы пользователей для критичных сервисов (делопроизводство, почта, учет);
• отдельного VPN-профиля или сегмента для администраторов;
• ограничений по устройствам и времени (где это реально);
• журналирования подключений.

Чтобы после переключения пользователи не искали «новый адрес сервера», заранее продумайте DNS и адресацию. Удобный вариант - постоянные имена сервисов (например, portal, mail, files), а при аварии меняется только запись DNS на новый IP. Учитывайте TTL: слишком большой TTL даст долгую «задержку переезда», слишком маленький увеличит нагрузку на DNS.

Оставьте отдельный административный доступ на случай проблем с основной сетью: консоль на месте, отдельный интернет-канал для VPN админов или хотя бы out-of-band доступ к сетевому оборудованию. Это запасная дверь, которая спасает, когда все пошло не по плану.

Пошаговый план внедрения за 2-6 недель

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

Начните с инвентаризации: какие сервисы есть (AD, файловые ресурсы, 1С, почта, ведомственная система, VPN), где лежат данные и кто ими пользуется. Затем зафиксируйте приоритеты: что должно подняться первым, что может подождать, и какие данные нельзя терять даже за последние 2-4 часа.

Дальше готовится площадка «минимум»: один хост с запасом по CPU и RAM, дисковая подсистема, ИБП, отдельный сетевой порт/канал. На практике удобно сразу завести 2-3 шаблона виртуальных машин (Windows Server, Linux, «пустая» VM под приложение), чтобы восстановление не превращалось в ручную сборку.

Параллельно настраиваются резервные копии: расписание, хранение, проверка восстановления. Если есть смысл, добавьте репликацию критичных VM или данных на резервный хост, но не пытайтесь реплицировать все подряд.

Чтобы уложиться в 2-6 недель, держите ритм по задачам:

• Неделя 1: инвентаризация, приоритеты, согласование RTO/RPO.
• Неделя 2: поставка и установка хоста, базовая виртуализация, шаблоны VM.
• Неделя 3: бэкапы, контрольное восстановление файлов и одной VM, журнал ошибок.
• Неделя 4: сценарий переключения (кто что делает), контакты, доступы, правило «если не получается за 15 минут - что дальше».
• Недели 5-6 (по необходимости): отработка узких мест, обучение дежурных, закрепление регламента.

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

Пример сценария для небольшого ведомства

Представим ведомство на 20 сотрудников. Каждый день они работают в учетной системе (база данных), хранят документы в файловом архиве и входят в рабочие ПК через домен. Интернет есть, но не всегда стабильный, поэтому рассчитывать только на облако рискованно.

По требованиям руководства учет должен восстановиться быстро: простой дольше 4 часов срывает прием обращений и отчеты. Файловый архив менее критичен по «свежести»: допустима потеря изменений за сутки (например, вчерашние сканы можно пересканировать). Остальные сервисы (внутренние порталы, тестовые базы, второстепенные папки) могут восстановиться в течение рабочего дня.

Схема без второго полноценного ЦОД выглядит так: в небольшом филиале (или другом здании ведомства) стоит один резервный сервер с виртуализацией, ИБП и отдельным дисковым хранилищем. Основные виртуальные машины (учет, домен, файлы) регулярно копируются на этот узел. Копии делаются по расписанию, а раз в квартал проводится тест восстановления, чтобы убедиться, что все реально запускается.

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

Порядок действий удобно держать на одной странице:

• Дежурный фиксирует инцидент и сообщает руководителю ИТ.
• Руководитель ИТ решает: восстанавливаемся на месте или включаем резерв в филиале.
• На резервном сервере запускают виртуальные машины учетной системы и домена, затем файловый сервис.
• Проверяют: вход под учетной записью, открытие базы, печать одного тестового документа, доступ к общей папке.
• Сообщают пользователям, что работа продолжается в аварийном режиме, и фиксируют время для отчета по RTO.

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

Типовые ошибки и ловушки

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

Проблемы начинаются с ответственности. Если «все знают, что Вася умеет», то в день аварии Васи может не быть, а инструкции, доступы и контакты подрядчиков окажутся в его личном мессенджере.

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

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

Техническая ловушка выглядит так: на одной виртуальной машине собрали все подряд - AD, почту, файловый сервер, 1С, мониторинг. В аварии вы не сможете быстро поднять главное, потому что все стало «одинаково важным». Нужны приоритеты: что поднимаем в первые 2 часа, а что может подождать.

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

Что чаще всего ломает план восстановления:

• нет назначенного ответственного и короткой инструкции «что делаем по шагам»;
• единственная копия данных хранится рядом с основным сервером;
• восстановление ни разу не проверяли на практике;
• все критичные сервисы сидят в одной VM без приоритетов;
• пароли и ключи не имеют резервного доступа (например, запечатанный конверт в сейфе).

Если берете оборудование у интегратора, например у GSE.kz, попросите не только спецификацию, но и простой план восстановления на 1-2 страницы. Он часто ценнее, чем еще один «запасной» диск.

Короткий чеклист перед запуском

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

Минимальный набор, который стоит пройти и зафиксировать письменно:

• Утвержден список критичных сервисов и их владельцев (например: домен и учетные записи, файловый ресурс, 1С/СЭД, почта, VPN). По каждому сервису ясно, кто отвечает за данные и кто подтверждает, что «работает нормально» после восстановления.
• RTO и RPO согласованы и понятны руководству: сколько времени офис может работать «вручную» и какую потерю данных организация готова принять. Если руководитель уверен, что «все должно подняться за 5 минут и ничего не потерять», это нужно проговорить до инцидента.

Дальше проверьте, что восстановление физически возможно:

• Есть минимум две независимые копии данных, и одна из них вне основной площадки. «Вне площадки» - это не «в другой папке на том же сервере», а отдельное устройство или место хранения.
• Есть короткая инструкция переключения на 1-2 страницы: что отключить, что включить, какие сервисы поднимаются первыми, где менять адреса/маршруты, как проверить доступ пользователям. Рядом - контакты ответственных: ИТ, связь/провайдер, безопасность, руководитель, который дает команду «переключаемся».

И последнее: не запускайте проект без реального теста.

• Зафиксирован результат последнего теста восстановления: дата, что именно восстанавливали (например, файловый ресурс и базу), сколько заняло времени, где было узкое место. Рядом - список исправлений и срок, когда их сделают.

Если хотя бы один пункт существует только «в теории», перенесите запуск и доведите до практики. Минимальная архитектура ценна только тогда, когда ее можно повторить по инструкции в стрессовой ситуации.

Следующие шаги: как превратить схему в рабочее решение

Чтобы резервная схема стала реальной защитой, а не «папкой с планом», начните с короткого набора входных данных: какие сервисы критичны (почта, документооборот, базы, файловые ресурсы), сколько пользователей в пике, какой общий объем данных и как быстро он растет.

Дальше честно выберите приоритет. У минимальной схемы всегда есть компромисс: можно сделать дешевле, можно сделать быстрее восстановление, а можно лучше защититься от крупного инцидента (пожар, затопление, долгий простой электричества). Если главный приоритет не назван заранее, архитектура получается «средней по всем пунктам» и не спасает в момент аварии.

Полезно закрепить решение в виде простых правил:

• какие сервисы поднимаются первыми и в каком порядке;
• кто принимает решение о переключении и кто его выполняет;
• какой максимум простоя допустим по каждому сервису;
• как проверяется, что бэкапы реально восстанавливаются;
• где хранятся пароли, ключи и инструкции, чтобы они были доступны при ЧС.

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

Если по итогам пилота выяснится, что не хватает мощности, надежности питания или сервиса, переходите к подбору оборудования и поддержки. Для госорганизаций часто важно, чтобы поставка и сопровождение были предсказуемыми. Здесь уместно рассмотреть локально произведенные серверы и интеграцию от GSE.kz (gse.kz): компания производит компьютеры и серверы в Казахстане, занимается системной интеграцией и обеспечивает 24/7 техническую поддержку через сервисную сеть.

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