1С и инфраструктура 2025–2026. Что меняется на серверной стороне

Зачем эта запись

Я веду 1С на разных площадках 12 лет. Видел УТ 10.3 на медленных каналах с тонким клиентом, перебирал MS SQL 2008 R2 на железе тех лет, тащил миграции УТ 10.3 на УТ 11.5 в производственных компаниях порядка сотни пользователей. Веду площадки с ERP на Linux и Postgres Pro, где MS-стека уже не осталось.

Эта запись для CIO или владельца компании на ~50–500 пользователей 1С, который смотрит на 2026 год и понимает простую вещь. Серверная сторона меняется быстрее, чем менеджеры успевают переучиваться. У MS SQL основная статья экономии это лицензии, и под импортозамещение она обычно перевешивает (цифры дальше, в блоке «Экономика перехода»). Windows Server остаётся, но всё чаще как доживающий пласт. КриптоПро вытеснил MS CryptoAPI ещё пять лет назад. HASP USB-ключи доживают свой век. AI добавил новый слой требований к мониторингу и бэкапу.

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

Стек 2026, что меняется

Когда я составляю карту инфраструктуры на новый год, у меня в голове две колонки. Что было MS-центричным и что туда переходит на 2026. Без выбора «сразу всё или ничего». Миграция идёт слоями.

Левый столбец не запрещён. Я веду площадки, где Windows Server и MS SQL ещё живут и будут жить минимум до конца года. Правый столбец — это карта решений, к которой движется большинство среднего и крупного бизнеса в РФ под давлением 187-ФЗ, санкций и экономики лицензий.

MS SQL → PostgreSQL для 1С

Это самая частая миграция, которую я веду или сопровождаю с 2022 года. На середину 2026 у меня внутри головы карта типичных грабельных мест и реалистичные сроки.

Какие версии PostgreSQL подходят для 1С

«Чистый» community PostgreSQL под 1С не работает. Нужны патчи 1С для совместимости с особенностями платформы (виртуальные таблицы, СКД, регистры расчёта). Поэтому на 2026 в проде используют один из трёх вариантов.

• PostgreSQL от 1С. Официальная сборка 1С с патчами. Бесплатна для держателей подписки ИТС. Скачивается с releases.1c.ru.
• Postgres Pro Standard / Enterprise от Postgres Professional. Major-линейка к 2026 дошла до 18, но под 1С в проде чаще берут 17.x с пакетом оптимизаций. Платно, зато с официальной поддержкой, патчами и конфигами под платформу.
• Tantor от «Тантор Лабс» (Группа Астра), ориентирован на экосистему Astra Linux. Сертификация по требованиям ФСТЭК для КИИ-объектов.

Грабли, которые я ловил

EXPLAIN-планы. Привычка читать MS SQL execution plans в SSMS на PostgreSQL не переносится один-в-один. PG EXPLAIN ANALYZE даёт другую модель. Приходится переучиваться на чтение узлов (Seq Scan, Index Scan, Bitmap Heap Scan, Hash Join, Nested Loop). Полезно держать рядом плагин auto_explain для медленных запросов.

VACUUM и autovacuum. На MS SQL про bloat практически не думаешь. На PostgreSQL это центральная тема. Если autovacuum настроен неаккуратно, таблицы 1С (особенно регистры расчёта) бьются bloat-ом, индексы пухнут, запросы тормозят. Базовый набор настроек у меня всегда такой:autovacuum_max_workers=6, autovacuum_vacuum_scale_factor=0.05, autovacuum_vacuum_cost_limit=2000. И мониторинг bloat через pg_stat_user_tables.

Реалистичные сроки миграции

На моих проектах:

• База до 100 ГБ, ~50 пользователей, типовая конфигурация без тяжёлых доработок. Один уикенд от dump до полноценного старта.
• База 300–800 ГБ, ~120 пользователей, средние доработки, ERP 2.5 или УТ 11.5 с расширениями. Проект на 2–3 месяца с тестовой миграцией и параллельной эксплуатацией.
• База 1.5–10 ТБ, ~300+ пользователей, тяжёлые регистры, ERP с производством. 4–6 месяцев с переносом через DT-выгрузку или автономный сервер, тестовой нагрузкой и параллельным запуском.

Если кто-то обещает «10 ТБ за выходные», попросите показать пример реального проекта с метриками. Бывают тулзы типа SoftPoint Database Replication, которые сокращают окно простоя до 3 часов на 10+ ТБ. Это работает, но это отдельный платный инструмент и отдельный этап подготовки.

Windows Server → Linux под 1С

На моих площадках Windows Server теперь живёт в двух ролях. Либо клиентские терминалы, либо доживающий кусок инфраструктуры. Сервер 1С на 2026 у меня по умолчанию Linux. Из трёх дистрибутивов в РФ я работаю с такими.

• Astra Linux Special Edition 1.7 / 1.8. Для КИИ-объектов и госконтрактов. Сертификация по ФСТЭК, мандатное разграничение доступа (МРОСЛ ДП), своя экосистема (ALD Pro вместо AD, Postgres Pro Standard в репах). На 2026 актуальна 1.8.
• RedOS 7+. Менее зарегламентированная, но сертифицированная. Часто проще в администрировании, чем Astra, если у вас нет жёстких требований по СЗИ.
• Ubuntu 22.04 LTS. Для коммерческого сектора без требований КИИ. Большое сообщество, проще найти специалистов, проще обновляться. Подходит для торговли, услуг, небольшого и среднего B2B.

Что не переехало автоматом

Когда я первый раз поставил 1С-сервер на Astra 1.7, наступил на несколько вещей сразу:

• Печать на сетевые принтеры через CUPS. Настройка драйверов от HP/Kyocera/Ricoh для Linux отдельный квест. Особенно для МФУ с проприетарными протоколами.
• Сканеры (для документов прихода в УТ 11.5 / ERP 2.5). TWAIN на Linux работает не везде. На клиентах ставят SANE + дописывают обработки.
• Внешние компоненты. Старые компоненты под ComConnector / OLE работают только под Windows. Linux-сборки компонент часто приходится заказывать у разработчика отдельно.
• Печать ШК на термопринтеры (TSC, Zebra, Honeywell). Драйверы Linux есть, но некоторые проприетарные функции (rotate, watermark) работают только под Windows.

Кластер 1С на Linux

Кластер 1С на Linux устроен так же, как и на Windows. Те же три компонента. ragent (агент сервера), rmngr (менеджер кластера), rphost (рабочий процесс). Разница в том, как они запускаются и как ведут себя при сбоях.

На Astra и Ubuntu я запускаю кластер через systemd-unit видаsrv1cv8-<версия>.service (точное имя зависит от установленной платформы — сверяю по релизу с releases.1c.ru). Все rphost-процессы выводятся в один общий лог, что удобно для grep. На Windows процессы разбегаются по службам, приходится агрегировать руками.

Failover кластера 1С

Базовое резервирование рабочих процессов (режим «использовать как резервный») и устойчивость кластера 1С есть и на ПРОФ. Еслиrphost падает, его подхватывает резервный. КОРП нужен не ради самого failover, а для тонкого управления. Это распределение нагрузки по рабочим серверам, привязка требований назначения функциональности к конкретной БД, управление памятью rphost.

Отказоустойчивость СУБД

Это отдельный слой, не путать с кластером 1С. Под ERP я ставлю отказоустойчивый кластер Postgres Pro Enterprise на BiHA. Это встроенная физическая репликация плюс автоматический failover с выборами лидера и узлом-рефери против split-brain. Стороннее кластерное ПО не нужно.

BiHA в Standard доступен начиная с версии 17 (в Enterprise с 16). На более старых Standard (16 и ниже) BiHA нет. Там потоковая физическая репликация (streaming) на горячий резерв, а переключение через Patroni или своим скриптом. Multimaster в Enterprise — это про другое. Запись идёт на несколько узлов через логическую репликацию (shared-nothing). Он не работает поверх «общего хранилища» и берётся под геораспределённую запись, не под обычный failover одной площадки.

Профили безопасности

На Astra с включённым МРОСЛ ДП нужно отдельно настраивать уровни конфиденциальности для процессов 1С. Иначе сервер не запустится, будет ругаться на доступ к ресурсам. Документация Astra на этот счёт подробная, но первый раз можно потратить день на отладку.

КриптоПро вместо MS CryptoAPI

ЭЦП для 1С на Linux — это КриптоПро CSP 5.0+. На Windows тот же КриптоПро используется уже минимум пять лет. MS CryptoAPI в российских конфигурациях не применяется, потому что не поддерживает ГОСТ 34.10/34.11.

Что меняется на 2026.

• КриптоПро CSP 5.0 (актуальная линейка 5.0, 5.0 R2, 5.0 R3, последняя сборка 5.0 R3+, 5.0.13003) стабильна для Linux на ядрах 5.x/6.x, заключение ФСБ действует до 1 мая 2029. Главное, уйти с ветки 4.0. Её сертификаты ФСБ истекли 15 января 2026 без продления, бессрочные лицензии 4.0 на 5.0 не переносятся. Совместима с Astra 1.7/1.8 и RedOS 7+. Работает с токенами Рутокен ЭЦП 2.0 / 3.0, JaCarta, ESMART.
• Для веб-клиента 1С есть отдельный плагин КриптоПро ЭЦП Browser plug-in. Браузеры под Linux (Chrome, Yandex Browser) поддерживают его без бубна.
• На сервере 1С нужно явно прописать путь к КриптоПро для компоненты signtool. Иначе ЭЦП будет валиться с ошибкой «provider not found».

HASP USB-ключи → программные ключи

USB-ключи HASP отслужили своё. У них три фундаментальные проблемы:

• Физический ключ нужно куда-то воткнуть. На облачных VPS это невозможно. На физическом сервере в ЦОДе нужен USB-over-IP (Sealnet, AnywhereUSB).
• Ключ может выйти из строя. Новый заказывают через дистрибьютора, и это недели ожидания. Всё это время лицензий нет.
• Обновление лицензий по ключу делается через утилиту в конфигураторе, требует физического присутствия рядом с сервером.

Программные ключи в 1С существуют давно (одновременная работа программных и аппаратных лицензий поддерживается ещё с 8.2.10, привязка программной лицензии к HASP добавлена в релизах 8.3.12 в конце 2018). Но для новых внедрений в облаках и на VPS они стали безальтернативным стандартом. Активация через PIN-код, привязка к железу или виртуалке. Воткнуть USB в облачный сервер некуда, выбора нет.

Мониторинг через Prometheus, Grafana, 1C-exporter

Zabbix у клиентов ещё живёт, но на новых проектах я ставлю стек Prometheus + Grafana + Alertmanager. Причины две. Проще описывать алерты YAML-ом и больше готовых экспортёров.

Для 1С нужны три экспортёра:

• node_exporter. Стандарт для метрик ОС (CPU, RAM, disk I/O, сеть).
• postgres_exporter. Метрики СУБД (active connections, replication lag, bloat, cache hit ratio, slow queries).
• 1c-exporter. Форки на GitHub, парсят технологический журнал 1С (logcfg.xml) и выдают метрики по rphost-процессам, длительности транзакций, блокировкам, аварийным завершениям сеансов.

Алертинг настраиваю на 8–10 ключевых метрик. Это rphost OOM, replication lag PG > 30 секунд, deadlock в 1С > 5 за час, autovacuum stall, превышение количества активных соединений к PG, slow queries > 10 секунд. Этого хватает, чтобы видеть боль раньше, чем её увидят пользователи.

Бэкап через WAL-G, Restic, pg_probackup

Бэкап PostgreSQL для 1С — отдельная дисциплина. Привычка делать ночной pg_dump на NAS работает на маленьких базах (до 100 ГБ). На больших становится больно. Дамп идёт часами, восстановление ещё дольше, RPO ползёт к 24 часам.

На 2026 у меня стек такой:

• WAL-G. Опенсорс, наследник WAL-E (изначально Citus Data, сейчас развитие поддерживает Yandex Cloud). Ставится и настраивается отдельно. Постоянно архивирует WAL-сегменты в объектное хранилище (S3-совместимое), делает point-in-time recovery с точностью до секунды.
• pg_probackup от Postgres Pro. Поддерживает инкрементальные бэкапы на основе WAL и проверку целостности. Удобен для Postgres Pro Enterprise.
• Restic. Для файлового бэкапа всего сервера (включая /etc, конфиги 1С, журналы). Шифрование из коробки, дедупликация, инкрементальные снапшоты.
• Кибер Бэкап (Киберпротект) или RuBackup (Группа Астра). Берут, когда нужна одна коммерческая система с агентами под физику, виртуалки и БД, а не россыпь утилит. Обе в реестре отечественного ПО, работают на Astra и RedOS, имеют версии с сертификацией ФСТЭК. Это целевая замена корпоративному бэкап-комбайну под новые внедрения, в том числе под КИИ.

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

187-ФЗ КИИ как триггер миграции

Если ваша компания попадает под 187-ФЗ (критическая информационная инфраструктура, то есть банки, ТЭК, транспорт, здравоохранение, связь, оборонка, частично крупное производство), вопрос миграции с MS-стека уже не «нужно ли», а «сколько у нас времени».

На 2026 регуляторы (ФСТЭК, ФСБ, отраслевые) ужесточили требования к сертифицированным средствам защиты, импортозамещению ОС и СУБД, мониторингу инцидентов. Microsoft и иностранные дистрибутивы по умолчанию не сертифицированы, и это автоматически делает компанию уязвимой к проверкам.

Если попадаете под 187-ФЗ, план миграции на Astra + Postgres Pro + КриптоПро должен быть к концу 2026. Не обязательно завершить, но утверждённая дорожная карта с бюджетом и владельцами должна быть на руках.

Экономика перехода

Раздел для CIO и владельца, а не для админа. Дальше идёт порядок величин по прайсам вендоров на 2025–2026 (Microsoft, Postgres Pro, is1c.ru). Точные суммы под конкретный проект считаются по числу ядер, редакциям и срокам поддержки, поэтому цифры ниже это ориентир, а не коммерческое предложение.

Что входит в TCO MS-стека

• Лицензии MS SQL по ядрам. Standard стоит порядка 380–400 тыс ₽ за пакет 4 ядра, Enterprise от ~1,1 млн ₽ за пакет 2 ядра. Лицензируется попарно, минимум 4 ядра на процессор.
• Windows Server плюс клиентские лицензии (CAL) на пользователей или устройства. Это отдельная статья сверху СУБД.
• С 2022 добавился фактор недоступности обновлений и официальной поддержки в РФ. В деньгах не выражается, но в риск-модель КИИ ложится тяжело.

Что входит в TCO импортозамещённого стека

• Postgres Pro по ядрам. Standard это годовая подписка от ~36 тыс ₽ за ядро (бессрочная от ~160–195 тыс ₽). Enterprise под 1С это бессрочная лицензия в диапазоне от ~200 до ~360 тыс ₽ за ядро в зависимости от схемы (на сервер, на ядро, сертифицированная ФСТЭК) плюс ежегодная поддержка. Разброс по прайсам дилеров большой, точную цифру под конкретную схему подтверждайте у вендора.
• Отечественная ОС. Astra Linux SE или RedOS по числу серверов. На Ubuntu этой статьи нет, но Ubuntu не закрывает требования КИИ.
• Подписка ИТС у вас и так есть, а сборка PostgreSQL от 1С внутри неё, без отдельной платы за СУБД, если хватает её возможностей.

Вывод для бюджета простой. Лицензии СУБД дают понятную и крупную экономию, она и оправдывает переход экономически. А вот эксплуатация PostgreSQL обходится дороже привычного MS SQL по людям и компетенциям. Эту строку в смету закладывают заранее, иначе экономия на лицензиях частично растворяется в незапланированных расходах на сопровождение.

Грабли миграции, которые повторяются

Случай 1. Метод аутентификации в pg_hba.conf

Классика на старых релизах платформы. После миграции базы на Postgres Pro конфигуратор работает нестабильно, то открывается, то нет, а вpg_log чисто. Причина вот в чём. В pg_hba.conf для подсети сервера 1С стоит scram-sha-256, а платформа на старом релизе умеет только md5. Лечится сменой метода на md5. На свежих релизах платформы метод аутентификации уже не имеет значения, поэтому первым делом стоит сверить версию.

Случай 2. shared_buffers и effective_cache_size

По умолчанию PostgreSQL ставит shared_buffers=128MB. Для 1С под нагрузкой это в 10–20 раз меньше нормы. Без настройки база живёт, но тормозит. Правило простое. shared_buffersберу как 25% от RAM сервера, effective_cache_size как 75%. При RAM 64 ГБ выходит shared_buffers=16GB, effective_cache_size=48GB.

Случай 3. Сертификаты КриптоПро после reboot

На Astra с включённым МРОСЛ ДП встречается такое. После reboot сервиса 1С контейнеры с сертификатами КриптоПро становятся невидимыми для сервера. Команда certmgr -list их находит, а сервер 1С нет. Решение простое. Переустановка сертификатов под пользователемusr1cv8 (а не от root), правильный атрибут уровня конфиденциальности.

Случай 4. Обмен через КД 3.0 EnterpriseData после миграции

При миграции базы с MS SQL на PG все настройки обмена через EnterpriseData сохраняются, но регламентные задания обмена могут встать. Лечится перерегистрацией обмена через помощник и ручным запуском первой синхронизации.

Зачем читал

Если у вас 1С на MS SQL + Windows и вы под 187-ФЗ, план миграции нужно начинать в 2026, не откладывая. Готов на первом звонке разобрать вашу текущую конфигурацию и оценить реалистичные сроки. Запись через форму контакта.

Про релизы конфигураций УТ 11.5 / ERP 2.5 / БП 3.0 на 2026 я писал отдельно в записи про новое в 1С на 2026. Про AI на базе 1С (классификация обращений через GigaChat, MCP-сервер) рассказываю в записи про 1С + AI. Те же подходы я собрал в один сквозной кейс с цифрами и сроками (тоже агрегат под NDA, не один заказчик) в кейсе УТ 10.3 → УТ 11.5 + AI.