Холодный резерв сервера 1С в другом дата-центре: поднять офис за час после пожара или потопа

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

Как погибает сервер физически — и почему это не редкость

Начну с примера. Клиент — торговая компания, 18 рабочих мест, сервер 1С стоял в шкафу в подсобке рядом с кухней. Прорвало трубу отопления на этаже выше. Вода шла не сразу в стойку, а по стене, скопилась в коробе с кабелями и потом залила блок питания сервера. Сгорело всё разом: материнка, диски, RAID-контроллер. Резервные копии были — на внешнем диске, который лежал в той же тумбе. Тоже залило.

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

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

Что такое холодный резерв и чем он отличается от обычного бэкапа

Резервная копия базы 1С — это файл. Чтобы из файла снова заработала бухгалтерия, нужно железо, установленная 1С, СУБД, драйверы, лицензии, настроенная сеть, RDP-доступы для сотрудников. Восстановление с нуля — это минимум сутки, даже если бэкап цел и под рукой. А если бэкап хранился в том же офисе — восстанавливать физически нечего.

Холодный резерв — это заранее подготовленная виртуальная машина в облаке, в другом дата-центре, максимально далеко от офиса территориально. На неё уже установлена операционная система, СУБД (обычно MS SQL или PostgreSQL), сама платформа 1С той же версии, что и на боевом сервере, настроены роли и права. Она выключена или в спящем режиме — отсюда «холодный». Раз в сутки, а у некоторых клиентов раз в 4-6 часов, туда автоматически заливается свежая копия базы через VPN-туннель или обычный rsync по расписанию.

Разница с горячим резервом (когда вторая машина постоянно включена и синхронизируется в реальном времени) — в цене. Горячий кластер для 1С — это репликация СУБД, лицензии на вторую копию платформы, постоянная работа второго сервера. Для компании на 20-50 рабочих мест это может стоить от 25 тысяч рублей в месяц и выше. Холодный резерв — это виртуалка, которая большую часть времени просто хранит данные и почти ничего не потребляет, поэтому и цена другая — обычно 5-9 тысяч в месяц за конфигурацию под среднюю базу 1С.

Как это работает на практике: от пожара до рабочего стола за час

Расскажу на конкретном примере — юрфирма, 22 рабочих места, база 1С:Бухгалтерия плюс отдельная база документооборота, суммарно около 40 ГБ. Мы держим для них холодный резерв в облаке на другой площадке, физически это другой ЦОД, не связанный с офисным провайдером и даже не в том же районе Москвы.

Что происходит, если офис недоступен — сгорел, залило, обесточен на неделю. Первое: я или дежурный инженер получает сигнал (у клиента настроен телеграм-бот на мониторинг доступности офисного сервера, если он не отвечает больше 20 минут — приходит алерт). Второе: включаем резервную виртуалку в облаке — это занимает 2-3 минуты, она уже настроена. Третье: разворачиваем последний бэкап базы поверх готовой 1С — если резерв синхронизировался ночью, теряем максимум сутки данных, обычно меньше. Четвёртое: меняем DNS-запись или публикуем RDP/веб-доступ к новому серверу, рассылаем сотрудникам новый адрес подключения.

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

Что нужно, чтобы это реально сработало, а не осталось на бумаге

Тут есть нюанс, который многие упускают: недостаточно просто где-то хранить файл бэкапа. Нужна именно готовая инфраструктура, куда его можно накатить без танцев с бубном. У меня были клиенты, которые сами себе организовали «резерв» — складывали архив базы на Яндекс.Диск. Хорошая идея, но когда реально пришлось восстанавливаться, оказалось, что нет ни сервера под это, ни лицензии на 1С, ни настроенной СУБД. В итоге всё равно потеряли три дня на разворачивание с нуля, просто данные хотя бы не потеряли.

Правильная схема — это связка из нескольких вещей одновременно: регулярная выгрузка базы (я обычно ставлю Cron-задачу или используем встроенный планировщик 1С на выгрузку .dt или бэкап SQL средствами самой СУБД), канал передачи данных в другой ЦОД (VPN-туннель между офисом и облаком, либо просто зашифрованная передача по расписанию через WireGuard или OpenVPN), и сама целевая виртуалка с преднастроенным окружением, идентичным продакшену — та же версия платформы 1С, та же редакция конфигурации, тот же релиз СУБД.

Отдельно нужно продумать лицензии. У 1С есть нюанс с аппаратными ключами защиты HASP — если у клиента физический USB-ключ, а не программная лицензия, его тоже нужно либо продублировать (софтверный дубликат лицензии докупается отдельно), либо иметь план на случай, что ключ погиб вместе с сервером. Я обычно рекомендую клиентам переходить на программные лицензии 1С именно из-за этого — их проще восстановить удалённо, без физического носителя.

Сколько это стоит и когда окупается

Возьмём среднюю компанию на 30 рабочих мест, база 1С весит 15-25 ГБ. Виртуалка под холодный резерв — 4 vCPU, 8 ГБ RAM, 100 ГБ диска — в облаке обходится примерно в 3500-5000 рублей в месяц, если держать её выключенной большую часть времени и платить только за хранение диска плюс минимальные часы работы на синхронизацию. Плюс настройка канала передачи и лицензия на СУБД (если не бесплатная версия PostgreSQL) — ещё 1500-3000 рублей. Итого выходит 5-9 тысяч рублей в месяц, разово настройка — от 25 до 45 тысяч рублей в зависимости от сложности инфраструктуры.

Теперь посчитаем, что теряет компания без резерва. Юрфирма из моего примера выше — 22 сотрудника, средняя ставка юриста 3500 рублей в час. Простой в три дня — это минимум 500-600 тысяч рублей недополученной выручки, не считая репутационных потерь перед клиентами, у которых горят сроки по судам. Торговая компания теряет ещё быстрее — не можешь выставить счета, не можешь отгрузить товар, склад стоит.

У меня простое правило, которое я говорю всем клиентам на встрече: если один день простоя 1С стоит компании больше 15-20 тысяч рублей, холодный резерв окупается уже на первом реальном инциденте. А инциденты, поверьте, случаются чаще, чем кажется — не обязательно пожар, иногда просто рейдерский захват здания управляющей компанией, отключение электричества на неделю из-за долгов арендодателя, или банальная кража сервера ночью.

Частые возражения клиентов — и почему они не работают

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

«Это же лишние расходы, у нас и так сервер работает нормально» — до первого раза. Я не продаю страховку от того, что случится обязательно. Я продаю страховку от того, что случается редко, но когда случается — обходится в разы дороже подписки за несколько лет вперёд. Как ОСАГО: платишь каждый год и надеешься не понадобится.

«А если у нас никогда не было проблем с офисом» — у клиента с пожаром на Дербеневской тоже никогда не было. Здание стояло 15 лет, ни разу не горело. Загорелось один раз — и этого хватило, чтобы девять дней сидеть без базы 1С. Физическая инфраструктура непредсказуема именно потому, что вы её не контролируете — вы не управляете электрощитовой соседей и трубами отопления над вашим потолком.

С чего начать, если решили внедрить резерв

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

Второй шаг — выбор облачной площадки. Я рекомендую брать ЦОД в другом городе или хотя бы в другом районе с независимым энергоснабжением от офиса. Не имеет смысла держать резерв в соседнем доме на том же вводе электричества.

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

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

Сколько данных мы потеряем, если офис погибнет между синхронизациями?
Зависит от частоты синхронизации — обычно я настраиваю от одного раза в сутки до раза в 4-6 часов для активных баз. Максимальная потеря данных равна интервалу между синхронизациями, то есть при синхронизации раз в 6 часов вы теряете максимум полдня операций, которые придётся вносить вручную по бумажным документам или почте.

Можно ли работать с резервного сервера долго, пока восстанавливают офис?
Да, холодный резерв рассчитан именно на это — можно работать неделями, пока чинится или переезжает офис. Позже, когда основной сервер восстановлен, данные, накопленные за время работы на резерве, переносятся обратно, а резервная машина снова переводится в спящий режим.

Подойдёт ли холодный резерв, если у нас 1С работает в сервисе аренды, а не на своём сервере?
Если база уже в облаке у арендодателя типа 1cFresh, риск физической утраты железа снимается автоматически — это забота провайдера. Резерв в таком случае имеет смысл делать не от пожара, а от отказа самого сервиса — например, держать выгрузку базы в другом облаке на случай блокировки аккаунта или проблем у провайдера.

Нужно ли держать резерв, если у нас 5 рабочих мест и небольшая база?
Для микробизнеса часто дешевле и разумнее держать не полноценный резервный сервер, а просто регулярную выгрузку базы в облако и договор с подрядчиком на быстрое развёртывание 1С на любой доступной виртуалке в течение нескольких часов — платить за постоянно готовую виртуалку в этом случае может быть экономически не оправдано.