На приёмочных испытаниях Efsol отключила основную площадку промышленной компании. Сервисы 1С перешли в резервный ЦОД примерно за пять минут. Пользователи потеряли только несохранённые действия.
Эту цифру опубликовал CNews в мае 2026 года. За ней стоят два независимых ЦОД, три экземпляра SQL Server, отдельный свидетель, кластер 1С и резервные копии вне основного контура.
Небольшой компании необязательно повторять такую архитектуру целиком. Но принцип переносится без скидки на масштаб: потеря основной площадки не должна уничтожать ни рабочую базу, ни способ её восстановить.
Задача администратора — заранее ответить на два вопроса. Сколько компания проживёт без 1С и сколько операций пользователи готовы повторить после переключения. Эти ответы определяют состав резерва точнее, чем бюджет или число серверов.
Бэкап возвращает данные, DR возвращает работу
Резервная копия хранит состояние базы на определённый момент. Она пригодится после удаления данных, повреждения файла или неудачного обновления.
Но копия сама не запустит сервер СУБД, кластер 1С, авторизацию и доступ пользователей. Для этого нужен план аварийного восстановления, или DR-план. В нём описаны резервная площадка, передача данных, порядок переключения и ответственные сотрудники.
Efsol прямо указывает на риск копий внутри одного ЦОД. При потере площадки компания лишается и продуктивной системы, и архива для восстановления.
Даже внешняя копия ещё не делает инфраструктуру отказоустойчивой. Если новый сервер придётся искать после аварии, простой будет измеряться сроком поставки и настройки. Такой резерв защищает данные, но не рабочий день.
Сначала назначьте RTO и RPO
RTO — срок, за который 1С должна вернуться после отказа. Его удобнее обсуждать не как техническую метрику, а как время без продаж, отгрузок или закрытия смены.
RPO показывает допустимую потерю данных. Если RPO равен 15 минутам, после аварии сотрудники могут повторно внести операции за этот промежуток.
В проекте Efsol сервисы переключились примерно за пять минут. В опубликованном кейсе Nubes резервный контур вернул 1С за 20–25 минут. Фактическая потеря данных там не превысила одной минуты.
Эти результаты нельзя переносить в смету как обещание. У проектов разные площадки, каналы связи, способы репликации и порядок запуска сервисов. Они показывают другое: RTO и RPO проверяют отключением рабочего контура, а не чтением проектной схемы.
| Требование бизнеса | Какой контур потребуется | Что проверить на испытании |
|---|---|---|
| Простой измеряется минутами | Запущенные резервные узлы 1С и СУБД, постоянная репликация | Время от отказа до входа пользователя |
| Допустима длительная пауза | Холодный резерв с подготовленными установочными файлами и копиями | Срок развёртывания сервера и восстановления базы |
| Нельзя потерять последние операции | Синхронная либо близкая к синхронной репликация | Отставание реплики и результат контрольной операции |
| Достаточно вернуть состояние на начало дня | Внешняя проверенная копия без постоянной реплики | Восстановление копии на отдельной площадке |
Сначала согласуйте RTO и RPO с руководителем. Только после этого выбирайте способ репликации и состояние резервных серверов.
Что защищают три SQL-инстанса и отдельный свидетель
До проекта Efsol вся инфраструктура заказчика работала в одном ЦОД. Новая схема разделила её между двумя независимыми площадками.
Контур баз данных построили на Microsoft SQL Server Always On. Два SQL-инстанса разместили в основном ЦОД, третий — в резервном. Такая схема закрывает отказ отдельного узла и потерю площадки.
Свидетель вынесли на третью площадку. Он участвует в определении кворума, когда основные участники не видят друг друга. Без независимого голоса обе стороны могут принять себя за рабочую и начать расходиться по данным.
Серверы приложений тоже объединили в кластер. При отказе одного узла рабочие процессы переходят на оставшиеся. Параметры такого контура собраны в инструкции про переключение рабочих серверов и процессов 1С.
Один кластер 1С не спасёт от потери СУБД. Реплика SQL Server не поможет, если пользователи не смогут пройти авторизацию или подключиться к резервной сети. DR-проект проходит всю цепочку от клиентского сеанса до дисков с базой.
| Что отказало | Чем закрыт риск в схеме Efsol | Какая общая точка отказа может остаться |
|---|---|---|
| Сервер приложений 1С | Кластер серверов 1С | Один сетевой сегмент или общий гипервизор |
| Один SQL-инстанс | Три экземпляра SQL Server Always On | Ошибка репликации или неверный кворум |
| Основной ЦОД | Резервный SQL-инстанс и сервисы 1С во втором ЦОД | Свидетель внутри одной из двух площадок |
| Рабочая база | Копии Veeam и дополнительная запись на ленту | Копии доступны из того же административного контура |
| Канал управления | VPN, MFA и разделение сети по VLAN | Общая учётная запись с доступом к обеим площадкам |
Резервировать нужно весь путь пользователя до базы. Замена одного сервера оставляет соседние точки отказа без защиты.
Как уменьшить архитектуру до масштаба небольшой компании
Базовая схема начинается с двух независимых площадок. Основная остаётся в офисе или ЦОД. Резервную размещают в другом городе либо в изолированном облачном контуре.
На резервной площадке держат совместимые версии ОС, СУБД и платформы 1С. Совпадение версий снижает риск, что база восстановится, но приложение не запустится из-за другого драйвера или уровня платформы.
Так работал контур Nubes. Резервные виртуальные машины получили те же версии программ, что и основные серверы клиента. Между площадками настроили защищённый VPN-туннель.
Базу передают на резервную площадку через репликацию СУБД. Интервал зависит от RPO: часовая синхронизация не подходит компании, которая готова повторить лишь несколько последних операций.
Внешние копии хранят отдельно от обеих рабочих реплик. В проекте Nubes использовали S3-хранилище с глубиной 30 дней. Efsol дополнила копии Veeam ленточным хранилищем.
Для небольшой компании минимальная схема выглядит так:
- основная площадка с рабочими узлами 1С и СУБД;
- резервная площадка в другом городе или изолированном облаке;
- второй узел 1С с совместимой версией платформы;
- реплика базы с контролем отставания;
- свидетель в третьем независимом контуре;
- внешние копии, недоступные из обычной учётной записи администратора;
- защищённый канал и отдельный порядок доступа к резерву.
Эта схема не задаёт число процессоров, объём памяти или дисков. Их рассчитывают по рабочей нагрузке. Резерв должен выдержать хотя бы критические операции на период ремонта основной площадки.
Холодный резерв дешевле до первой проверки времени
Холодный резерв выключен или не подготовлен к немедленному запуску. После аварии администратор создаёт машины, устанавливает программы, восстанавливает базу и меняет маршруты.
Такой вариант подходит, если компания принимает длительный простой. Его всё равно нужно собирать на испытании целиком. Иначе заявленное время восстановления останется предположением.
Тёплый резерв уже содержит настроенные серверы и регулярно получает данные. Администратору остаётся завершить синхронизацию, поднять сервисы и переключить пользователей.
Горячий резерв работает постоянно и принимает изменения почти без задержки. Он нужен при коротком RTO, но требует контроля репликации, кворума и лицензий 1С.
Списанный сервер можно использовать для контрольных восстановлений и обучения администратора. Перед этим проверьте питание, диски и сеть: отдельная инструкция объясняет, как подготовить выведенный сервер к резервным испытаниям.
Такой стенд не заменяет резервную площадку. Если он стоит в той же серверной, пожар, затопление или отключение здания затронут обе машины.
SLA облака не задаёт время возврата 1С
В кейсе Nubes облачная площадка работала с SLA 99,9%. Этот показатель описывает доступность услуги провайдера, но не срок запуска конкретной базы.
Посчитаем годовой предел недоступности по самому проценту. В году 365 × 24 × 60 = 525 600 минут. Доля 0,1% даёт 525,6 минуты, то есть 8 часов 45 минут 36 секунд.
Этот расчёт не предсказывает реальный простой и не описывает условия договора. Он показывает масштаб: SLA 99,9% нельзя читать как обещание вернуть 1С за несколько минут.
В том же проекте целевой RTO составлял не более 30 минут. На испытании переключение заняло 20–25 минут. Фактическая потеря данных не превысила одной минуты при целевом RPO до 15 минут.
SLA отвечает за площадку провайдера. RTO отвечает за вашу 1С вместе с базой, авторизацией, сетью и клиентскими подключениями.
Авторизация и административный доступ входят в DR
После переключения пользователь должен не только увидеть сервер, но и войти в 1С. Зависимость от одного контроллера домена способна остановить резервный контур при работающей базе.
Проверьте вход обычного пользователя, а не только запуск консоли администратором. Для инфраструктуры с LDAP пригодится отдельный сценарий отказоустойчивой авторизации 1С через LDAPS.
В проекте Efsol сеть разделили с помощью VLAN. Подключение к инфраструктуре шло через VPN, а специалисты Efsol использовали MFA.
Для Windows Server задействовали Active Directory, GPO, аудит действий, Just Enough Administration, Protected Users, Credential Guard и LAPS. Этот набор ограничивает административные полномочия и оставляет журнал действий.
Разделение нужно не только против случайной ошибки. Если одна учётная запись открывает рабочие серверы, резервный ЦОД и архивы, шифровальщик получает тот же маршрут.
Приёмка начинается с отключения основного контура
Проект нельзя принимать по списку серверов. На испытании основная площадка должна исчезнуть из схемы так, как она исчезнет при аварии.
Efsol моделировала отказ основного ЦОД и переключение сервисов 1С. IBS включает в проверку автоматическое переключение узлов, репликацию базы, восстановление копии и резервный канал связи.
Перед тестом зафиксируйте время последней подтверждённой транзакции. Затем отключите основной контур и замерьте время до рабочего сеанса пользователя. Разница даст фактические RPO и RTO для вашей схемы.
Отдельно восстановите резервную копию. Делайте это в другом экземпляре СУБД: проверка не должна заменять рабочую реплику или менять продуктивную базу.
После запуска проведите документ, сформируйте отчёт и проверьте внешние подключения. Работающая служба ещё не доказывает, что бизнес вернулся к работе.
Завершает испытание обратное переключение. Если порядок возврата на основную площадку не описан, первая авария закончится ручным проектированием под давлением.
Минимальный проект DR для согласования
В проекте должны быть две независимые площадки, кластер 1С и реплика СУБД. Свидетель размещают вне обеих площадок, а копии — вне рабочего контура.
Доступ к резерву защищают отдельно. Порядок переключения записывают до испытаний, затем исправляют по фактическим результатам.
Принимайте проект по пяти признакам:
- основной ЦОД отключён во время испытания;
- пользователь вошёл в 1С через резервную площадку;
- администратор измерил простой и потерю данных;
- резервная копия восстановлена в отдельном контуре;
- обратное переключение описано и проверено.
Если все пять пунктов выполнены, у компании есть рабочий DR-план. Если проверена только копия, у компании по-прежнему есть только копия.
Архитектура зависит от размера базы, лицензий, сети и допустимого простоя. Когда эти параметры конфликтуют, закажите техническую оценку резервного контура 1С до покупки серверов и облачных ресурсов.