Сервер для 1С в 2026. PostgreSQL, Linux, Astra, кластер

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

С 1С я работаю больше двадцати лет. Начинал ещё на 7.7, на «клюшках», когда конфигуратор и предприятие запускались по отдельности, а свод отчёта собирался в табличном документе руками. Прошёл обычные формы 8.0 и 8.1, управляемые формы 8.2, всю линейку 8.3. Делал внедрения и миграции в производственных компаниях, переносил УТ 10.3 на УТ 11.5 на сотни пользователей. Сейчас веду площадки на ERP под Linux и Postgres Pro, где Microsoft-стека не осталось вообще.

За эти годы стек под 1С менялся целиком, и не один раз. Поэтому переход с MS SQL на PostgreSQL и с Windows на Astra для меня не новый тренд, а очередная смена пласта. Просто теперь её подгоняют санкции и 187-ФЗ.

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

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

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

Главный вопрос не «как мигрировать», а «обязан ли я и когда». Ответ зависит от того, попадаете ли вы под 187-ФЗ о критической информационной инфраструктуре.

187-ФЗ относит к критической инфраструктуре компании из конкретных сфер. Это здравоохранение, наука, транспорт, связь, энергетика, банки и финансовый рынок, ТЭК, атомная энергия, оборонная промышленность, ракетно-космическая, горнодобывающая, металлургическая и химическая. Критерий — это сфера деятельности, а не размер бизнеса. Небольшая компания из значимой сферы под закон попадает, крупный ритейл вне перечня нет.

Юридический триггер появился в апреле 2025. ФЗ-58 от 7 апреля 2025 года, вступил в силу 1 сентября 2025, добавил в 187-ФЗ статью 10.1. На значимых объектах КИИ обязательно ПО из единого реестра российских программ, если в реестре есть аналог. ИП из субъектов КИИ при этом исключили. На простом языке это значит вот что. Для значимого объекта остаться на MS SQL, когда в реестре есть Postgres Pro, это прямое нарушение.

По срокам. Если вы под 187-ФЗ, на середину 2026 у вас должно быть уже сделано категорирование, а не «начнём к концу года». Отраслевые планы перехода должны были выйти к 1 июня 2026. Целевые даты завершения ориентировочно 2028 по программному обеспечению и 2030 по доверенным программно-аппаратным комплексам, отраслевые отсрочки до 2031–2036 ещё уточняются. Стек выбирается от реестров и сертификатов ФСТЭК, а не от трёх популярных брендов. Astra, Postgres Pro и КриптоПро — это пример, который критериям удовлетворяет, а не требование закона.

Если КИИ вас не касается, переход не срочный. Но MS-лицензии юрлицу в РФ официально не продают с 2022 года, обновлений и поддержки нет. Так что драйвер всё равно есть, просто не регуляторный, а санкционный и экономический. Похожую логику по этапам замещения всего MS-стека я разбирал в записи про замещение Microsoft-стека в производстве.

Стек 1С на 2026, что меняется по слоям

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

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

Требования к серверу 1С

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

Три принципа, которые важнее любой таблицы. Первый. От средней нагрузки сервер 1С и сервер СУБД разношу на разные машины. На одном хосте rphost и PostgreSQL дерутся за память и диск. До полусотни пользователей и небольшой базы один хост ещё допустим, дальше нет.

Второй. Память — это главный ресурс, диск второй, ядра третий. Под PostgreSQL диск только NVMe в зеркале или RAID10. RAID5 под СУБД не ставлю, штраф чётности на запись убивает производительность. Гонюсь за частотой ядра, а не за их числом, один сеанс 1С плохо параллелится.

Третий, и на нём чаще всего горят чужие внедрения. Сервер 1С и СУБД держу в одной локальной сети, минимум гигабит, лучше десять. Между ними нельзя WAN и нельзя разные площадки. Протокол 1С к СУБД очень болтливый, на каждый round-trip закладывается задержка. Если между rphost и PostgreSQL десятки миллисекунд, система встаёт колом даже на быстром железе.

Виртуализация под 1С — это норма, zVirt или «Брест». Но для боевого PostgreSQL фиксирую память без overcommit, беру толстый диск или проброс NVMe и выключаю memory ballooning. На больших базах от полутора терабайт смотрю в сторону bare-metal ради предсказуемости. Как я выбираю саму серверную платформу в РФ после 2022 года, разбирал отдельно в записи про HPE, Dell и Lenovo и канал.

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

PostgreSQL под 1С — это не обычный community-PostgreSQL, а сборка с патчами от 1С. Голый community 1С официально не поддерживает. Платформа на нём стартует, но патчи совместимости не наложены, и часть нагрузки с временными таблицами и спецзапросами ведёт себя нестабильно. Поэтому в проде берут один из трёх вариантов.

• PostgreSQL с патчем 1С. Официальная сборка 1С. Бесплатна для держателей подписки ИТС, скачивается с portal.1c.ru.
• Postgres Pro Standard или Enterprise от Postgres Professional. Мажорная линейка на 2026 это 18, под 1С официально заявлены 17 и 18 (Enterprise 18 несёт максимум оптимизаций). Платно, зато официальная поддержка, патчи и встроенный BiHA.
• Tantor от «Тантор Лабс», это дочерняя компания ГК «Астра». Ориентирован на экосистему Astra Linux, есть редакция с сертификацией ФСТЭК. На 2026 дотянут до версии 17.

Критерий выбора простой. Сборка от 1С даром, но эксплуатацию тянешь сам. Postgres Pro платно, зато поддержка, оптимизации и BiHA из коробки. Tantor когда инфраструктура уже на Astra и нужен один вендор с сертификатом ФСТЭК.

Как перенести базу 1С на PostgreSQL

Из коробки у платформы два штатных пути. Утилита ibcmd умеет конвертацию между СУБД, с линейки 8.3.23 у неё многопоточная выгрузка и загрузка, на больших базах это уже не один dt в один поток. И планы обмена, когда нужен постепенный переход с фильтрацией данных. Классическая выгрузка в dt и загрузка в новую базу тоже работает, но на больших базах долгая, потому что восстанавливает с пересозданием индексов. Платные инструменты репликации вроде SoftPoint беру, когда штатными средствами не уложиться в окно простоя, а не как единственный быстрый вариант. Полный сквозной кейс такого переезда с цифрами и сроками я собрал в кейсе миграции УТ 10.3 на УТ 11.5.

Базовый тюнинг PostgreSQL под 1С

На 2026 базовый тюнинг под 1С я не пишу руками с нуля. Postgres Pro ставит его сам. При initdb запускается pgpro_tune, и для редакции под 1С указывается пресет 1c.tune. Он сам задаёт shared_buffers в четверть оперативки, work_mem 512 МБ, temp_buffers 256 МБ, поднимает число воркеров autovacuum под количество ядер и включает 1С-специфику. На голом community PostgreSQL этой утилиты нет, там всё руками.

Что проверяю глазами после автонастройки. effective_cache_size методика 1С советует ставить в половину или две трети оперативной памяти, я беру две трети. Это подсказка планировщику, сколько данных реально лежит в кеше операционной системы, память она не выделяет. max_locks_per_transaction поднимаю до 256, иначе на тяжёлых проведениях ловишь out of shared memory. Локаль базы только ru_RU.UTF-8, иначе сортировки и сравнения строк в 1С едут, а переколлация на работающем кластере — это боль. И отдельно отключаю Transparent Huge Pages на уровне ОС, иначе под нагрузкой PostgreSQL ловит рваные задержки.

Грабли PostgreSQL под 1С

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

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

1С на Linux. Astra, RED OS, Ubuntu

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

• Astra Linux Special Edition 1.8. Боевая версия с 1 августа 2024 года, собрана на Debian 12. Под КИИ, госконтракты и гостайну. Сертификат ФСТЭК, мандатное разграничение доступа (МРОСЛ ДП), своя экосистема, ALD Pro вместо Active Directory и Postgres Pro в репозиториях. Версия 1.7 на Debian 10 ещё живёт под уже развёрнутый парк, но под новый сервер её ставить смысла нет.
• RED OS 8. Вышла в феврале 2024, на ней и работаю под новые проекты. RPM-based, ближе к привычному RHEL, проще в администрировании, чем Astra, если нет жёстких требований по защите информации. Важный момент по срокам. RED OS 7.3 снимается с поддержки 31 декабря 2026 года. Кто в 2026 ставит сервер на 7.3, берёт ОС, которой жить меньше года. Под новое внедрение только 8.
• Ubuntu 24.04 LTS. Для коммерческого сектора без требований КИИ. Большое сообщество, проще найти людей и обновляться. Версия 22.04 поддерживается до апреля 2027, но новый сервер логичнее сразу на 24.04.

Выбор между ними простой. КИИ или гостайна — это Astra. Коммерция без этих требований — это RED OS или Ubuntu, что ближе команде.

Установка 1С на Astra Linux

Сервер 1С под Linux ставится из deb-пакетов для Astra и Ubuntu и из rpm для RED OS. После установки переезжает не всё автоматом. На Astra с включённым мандатным разграничением нужно отдельно настроить уровни конфиденциальности для процессов 1С, иначе сервер не запустится и будет ругаться на доступ к ресурсам. Документация Astra на этот счёт подробная, но первый раз можно потратить день на отладку. На RED OS этой возни нет, но пути и имена пакетов отличаются от deb-систем.

Клиентский доступ, когда сервер на Linux

Самый частый страх перед переходом на Linux звучит так. «А на чём тогда будут работать люди». Отвечаю сразу. Перевод сервера 1С на Linux не требует трогать рабочие места. Тонкий клиент 1С под Windows спокойно ходит на сервер 1С под Linux, на рабочих местах ничего не меняется.

Вариантов доступа четыре, и выбор зависит от того, что нужно на рабочем месте.

• Толстый клиент. Полный функционал, но тяжёлый в обслуживании. Под новые внедрения почти не ставят.
• Тонкий клиент. Рабочая лошадка. Ставится на Windows или на Astra, ходит на сервер 1С под Linux. Все функции, работа с оборудованием, печать.
• Веб-клиент. Публикуется на Apache через модуль wsap24.so, работает в браузере. Удобен для отчётов и мобильного доступа. Но честно, он не равен тонкому по функционалу и скорости. Работа с файлами, печать и оборудование там урезаны.
• RDP на Windows Server. Когда рабочие места трогать нельзя вообще, людей сажают на терминальный сервер. Тут ловушка. Это тянет за собой Windows Server и терминальные лицензии RDS CAL. То есть «ушли от Windows» получается только наполовину.

Важная мелочь про деньги. RDS CAL — это терминальные лицензии Microsoft, они не имеют отношения к клиентским лицензиям 1С. Это разные счета и отдельный санкционный риск.

Периферия — это отдельный квест, который как раз и всплывает при переезде.

• Печать на сетевые принтеры идёт через CUPS. Драйверы HP, Kyocera, Ricoh под Linux — это отдельная история, особенно для МФУ с проприетарными протоколами.
• Сканеры для документов прихода. TWAIN на Linux работает не везде, на клиентах ставят SANE и дописывают обработки.
• Печать штрихкода на термопринтеры (TSC, Zebra, Honeywell). Драйверы есть, но часть проприетарных функций работает только под Windows.
• Внешние компоненты. Старое под ComConnector или OLE работает только под Windows. Linux-сборки часто приходится заказывать у разработчика отдельно.

Вывод. Сервер уезжает на Linux безболезненно. А вот периферию и доступ к оборудованию надо инвентаризовать заранее, это частый источник сюрпризов на внедрении.

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

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

Кластер я запускаю из инстанс-юнита systemd, который кладёт сама платформа. Имя у него с собакой, вида srv1cv8-8.3.27.xxxx@.service. Это шаблон, поэтому регистрирую через systemctl link, а запускаю как srv1cv8-8.3.27.xxxx@default.service, где default — это имя инстанса. Так на одном хосте уживается несколько кластеров одной версии. На RED OS пакеты rpm, пути и имена немного другие, чем на Astra и Ubuntu с их deb. Все rphost при этом пишут в один общий лог, что удобно для grep, на Windows процессы разбегаются по службам.

Failover кластера 1С

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

Дальше важно не смешать два разных слоя. Отказоустойчивость кластера 1С и отказоустойчивость СУБД — это разные вещи, и резервировать надо оба.

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

Это отдельный слой, не путать с кластером 1С. Под ERP я ставлю отказоустойчивый кластер PostgreSQL, и тут три уровня инструментов.

BiHA — это встроенный в Postgres Pro механизм высокой доступности. Физическая репликация плюс автоматический failover с выборами лидера по алгоритму Raft и узлом-рефери против split-brain. Стороннее кластерное ПО не нужно. BiHA доступен в Postgres Pro Enterprise начиная с версии 16 и в Standard начиная с 17. На более старых Standard его нет.

Там, где BiHA нет, ставят потоковую физическую репликацию на горячий резерв, а переключение делают через Patroni. Только учтите, Patroni сам по себе не работает. Ему нужен распределённый конфиг-стор, чаще всего etcd, и тоже минимум на трёх узлах ради кворума. Это плюс инфраструктура и плюс точка отказа, которую закладывают в проект заранее. BiHA тем и хорош, что несёт это в себе.

Multimaster в Enterprise это уже не про failover. Это синхронный кластер, где пишут сразу на несколько узлов, схема shared-nothing, логическая репликация с кворумом, минимум три узла. Он даёт масштабирование чтения и высокую доступность локального кластера, но для типовой 1С избыточен. Платформа штатно работает с одной точкой записи, несколько мастеров ей не нужны. И важная оговорка против частого заблуждения. Геораспределённый кластер на multimaster сам вендор делать не советует, на задержках сети синхронный кворум начинает мешать. Если нужен именно геораспределённый отказоустойчивый кластер, это делается на BiHA через каскадную репликацию, а не на multimaster.

На Astra с включённым мандатным разграничением процессам PostgreSQL и 1С отдельно настраивают уровни конфиденциальности, иначе сервис не стартует.

Лестница отказоустойчивости

Я думаю про отказоустойчивость тремя ступенями. Выбирают ступень не по красоте, а по тому, сколько стоит час простоя.

Первая, малый бизнес. Один сервер плюс бэкап, RPO до суток, простой на время восстановления переживаем. Вторая, средний. Резервные rphost в кластере 1С плюс streaming-реплика PostgreSQL на горячий резерв, переключение через Patroni. Третья, крупный и КИИ. Кластер 1С на КОРП плюс Postgres Pro Enterprise с BiHA, авто-failover с выборами лидера и узлом-рефери.

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

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

• Уходить надо с ветки 4.0. Её сертификаты ФСБ истекли 15 января 2026 без продления, и подписи, созданные на 4.0, с 16 января уже не квалифицированные. Лицензия 4.0 на 5.0 не переходит, 5.0 покупается отдельно.
• Актуальная линейка — это 5.0, сборки R2 и R3, последняя 5.0 R3 (5.0.13003). Стабильна на Linux на ядрах 5.x и 6.x, совместима с Astra 1.8 и RED OS 8. Работает с токенами Рутокен ЭЦП 2.0, JaCarta, ESMART. Тут важно не путать две даты. Сертификаты соответствия ФСБ на сборку 5.0 R3 обновлены 25 ноября 2025 и действуют до 25 ноября 2028. А разрешённая эксплуатация самого СКЗИ — это до 1 мая 2029, дальше срок продлевают.
• Для веб-клиента 1С есть отдельный плагин, КриптоПро ЭЦП Browser plug-in. Браузеры под Linux, Chrome и Yandex Browser, поддерживают его без бубна.
• На сервере 1С под Linux подписывает криптоменеджер платформы поверх КриптоПро CSP и внешней компоненты из БСП, раньше это был XMLDSig, сейчас ExtraCryptoAPI. В настройках программы электронной подписи обязательно заполнить «Пути к программе на серверах Linux», это путь к libcapi10.so и libcapi20.so в /opt/cprocsp/lib/amd64. Сертификат с контейнером ставится в профиле пользователя usr1cv8, под которым работает кластер, а не от root. Пропустите это, и подписание упадёт с ошибкой «криптопровайдер не найден».

Лицензия сервера 1С и ключи

Тут две темы, которые часто путают. Сколько лицензий вообще нужно и на чём они физически живут.

Сколько лицензий нужно

• Серверная лицензия. Бывает ПРОФ и КОРП. Не путать с КОРП-конфигурацией, БП КОРП — это про функционал бухгалтерии, а сервер КОРП — это про управление кластером. Большинству хватает сервера ПРОФ, КОРП берут под тонкое управление нагрузкой и под несколько рабочих серверов.
• Клиентские лицензии на одновременные подключения. Они не зависят от способа доступа. Толстый клиент, тонкий, веб или RDP, для 1С это всё равно одно подключение. Это лицензия 1С, не RDS CAL.
• Лицензия на конфигурацию (УТ, ERP, БП). Отдельная история, про релизы я писал в записи про новое в 1С на 2026.

В бюджете это разовая покупка лицензий, то есть CAPEX, плюс ежегодная подписка ИТС, то есть OPEX. ИТС важна не ради одних обновлений. В неё входит и сборка PostgreSQL от 1С.

HASP-ключи уходят

USB-ключи HASP отслужили своё. У них три проблемы. Физический ключ некуда воткнуть на облачном VPS. Ключ может выйти из строя, а новый заказывают через дистрибьютора неделями. Обновление лицензий по ключу требует физического присутствия рядом с сервером.

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

Если ключ всё же аппаратный, а сервер физический в ЦОДе, его пробрасывают через USB-over-IP. Из железа это DIGI AnywhereUSB или SEH myUTN, из софта USB/IP или USB Network Gate. Но чаще проще другое. Берут сетевой ключ HASP, ставят Sentinel License Manager на одну машину, и остальные тянут лицензию по сети без всяких USB-концентраторов.

Порты и сеть для сервера 1С

Базовый набор портов кластера 1С небольшой. Вот что открывают на сервере приложений 1С и на сервере СУБД.

Несколько правил по сети. Порт СУБД, 5432, наружу не открывают, он нужен только между сервером 1С и сервером СУБД, и они в одной локальной сети. Диапазон rphost 1560–1591 — это значение по умолчанию, его можно сузить или сдвинуть в настройках кластера, но firewall должен пускать весь диапазон, иначе рабочие процессы не поднимутся. Публикацию базы наружу я закрываю reverse-proxy на nginx с TLS, а не отдаю Apache напрямую в интернет.

Мониторинг через Prometheus и качество 1С

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

• node_exporter. Метрики операционной системы, CPU, память, диск, сеть.
• postgres_exporter. Метрики СУБД, активные соединения, лаг репликации, bloat, cache hit ratio, медленные запросы.
• 1c-exporter. Опенсорсные экспортёры с GitHub. Самый живой это prometheus_1C_exporter (LazarenkoA, больше двухсот звёзд). Он снимает метрики через утилиту администрирования кластера rac. Это сеансы, соединения, клиентские лицензии, загрузка по процессам, доступная производительность рабочих серверов, регламентные задания. Длительность вызовов и блокировки берут с другой стороны, из технологического журнала, его настраивает logcfg.xml. Для этого есть отдельные экспортёры APDEX. На практике ставлю оба, они дополняют друг друга.

Пороги алертов подбираю под площадку, не копирую вслепую. Для синхронной BiHA-реплики лаг даже в десяток секунд — это сигнал, для асинхронной географической реплики и минута норма. По дедлокам смотрю не абсолютное число, а рост относительно обычного фона базы, иначе на нагруженной ERP с управляемыми блокировками завалит ложными срабатываниями. Базовый набор это OOM рабочего процесса, лаг репликации, рост дедлоков, остановка autovacuum, упор в лимит соединений, медленные запросы.

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

Прикладной уровень и качество

Всё выше про железо и СУБД, здоров ли сервер. Есть второй уровень, комфортно ли пользователю. У 1С для этого свой инструментарий. Центр контроля качества и Корпоративный инструментальный пакет собирают APDEX, метрику отзывчивости операций, и гоняют нагрузочные сценарии. Для малого бизнеса избыточно, ставлю на крупных ERP. Но знать про него стоит.

Резервное копирование и непрерывность

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

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

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

Инструмент — это половина дела. Принцип такой. Три копии, два разных типа носителя, одна вне площадки. Минимум одна копия неизменяемая, чтобы её не стёр ни шифровальщик, ни скомпрометированный администратор. RuBackup и Кибер Бэкап такую защиту копий умеют, у самописного стека на WAL-G это решается версионированием и lock-политикой бакета. Хранить копии в РФ есть где, это Yandex Object Storage, Selectel, VK Cloud или свой MinIO. Бакет с включённым шифрованием и версионированием. Ключи от репозитория Restic и доступ к бакету — это секреты, они живут не в скрипте бэкапа, а в хранилище секретов или хотя бы в файле под sops.

И главное правило. Бэкап, который ни разу не разворачивали, это не бэкап. Метрика тут не «когда сняли последнюю копию», а «когда последний раз успешно подняли из неё рабочую базу». Поэтому тест восстановления я не просто делаю раз в квартал руками, а гоняю скриптом. Поднял dev-копию из последнего бэкапа, прогнал smoke, база стартует, документы открываются, пользователь логинится, записал дату. Если этого не делать, битый бэкап вы найдёте в день инцидента, и это будет худший день.

Экономика сервера 1С. TCO и окупаемость

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

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

Лицензии MS SQL по ядрам считаю сегодня справочно. Новых лицензий Microsoft юрлицу в РФ официально не продаёт с 2022 года, поддержки и обновлений от вендора нет. По листовому прайсу Microsoft Standard стоит около 3900 USD за пакет 2 ядра, Enterprise около 15 000 USD за те же 2 ядра, лицензируется попарно, минимум 4 ядра на процессор. В рублях это порядка 350 тысяч за Standard и 1,3 миллиона за Enterprise на пару ядер, но это цена на бумаге. Реально берут на вторичном рынке или через параллельный импорт, без вендорской поддержки. Под КИИ это само по себе стоп-фактор, а не вопрос цены. Сверху идут Windows Server и клиентские лицензии CAL.

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

Postgres Pro по ядрам, минимум 2 ядра на сервер. Под 1С обычно берут Enterprise для 1С. Бессрочная лицензия около 157 тысяч за ядро, с трёхлетней гарантией около 216 тысяч, сертифицированная под ФСТЭК для КИИ около 188 тысяч. Годовая подписка около 72 тысяч за ядро. Standard под 1С дешевле. Точную цифру под вашу схему подтверждайте у вендора, разброс по дилерам есть. Отечественная ОС, Astra или RED OS, считается по числу серверов, это десятки тысяч за сервер. Подписка ИТС у вас и так есть, а сборка PostgreSQL от 1С внутри неё, без отдельной платы за СУБД.

За сколько окупается

Грубая модель окупаемости такая. Экономия сидит в лицензиях СУБД, подписка Postgres Pro на ядро дешевле MS SQL в разы, а против MS SQL Enterprise разрыв доходит до порядка. Расход — это разовый проект миграции, для базы 300–800 ГБ это месяцы работы команды, плюс DBA в год. Если экономия на лицензиях кратно больше годового удорожания эксплуатации, проект окупается на горизонте проекта, а не одного года. На средней площадке реальная окупаемость выходит 2–4 года, дальше идёт чистая экономия.

Скрытые расходы прячутся в эксплуатации. Postgres Pro требует живого DBA. VACUUM, EXPLAIN, статистика, мониторинг bloat. Это не «поставил и забыл», как привыкли с MS SQL. На MS SQL справлялся эникейщик, PostgreSQL требует квалификации, и это либо наём DBA, либо аутсорс. Сюда же переписывание тяжёлых отчётов СКД под планировщик PostgreSQL и перевыпуск программных ключей при миграциях виртуалок.

А если не мигрировать. Для значимого объекта КИИ это не вариант. Остаться на MS SQL при наличии аналога в реестре это нарушение статьи 10.1, со штрафами и предписаниями. Для всех остальных цена бездействия мягче, но она есть. Это растущий технический долг на стеке, который не обновляют и не поддерживают.

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

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

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

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

При миграции базы с MS SQL на PostgreSQL все настройки обмена через EnterpriseData сохраняются, но регламентные задания обмена могут встать. Обмен не зависит от СУБД, это уровень платформы, а встают задания из-за того, что после загрузки в новую базу их расписание и состояние требуют перезапуска. Лечится перерегистрацией обмена через помощник и ручным запуском первой синхронизации.

Короткий чек-лист, на чём ещё горят

• Локаль и сортировка. Кластер PostgreSQL инициализировать сразу с ru_RU.UTF-8. На неправильной локали кириллица сортируется не по-человечески, а переколлация на работающей базе это боль.
• Часовой пояс. Рассинхрон таймзоны между ОС, PostgreSQL и 1С даёт пляшущие даты в документах и отчётности.
• Антивирус. Каталоги сервера 1С и PostgreSQL, PGDATA, временные файлы rphost, WAL, добавить в исключения. Иначе производительность в пол.
• THP. Transparent Huge Pages на сервере СУБД отключить, иначе рваные задержки под нагрузкой.
• NUMA. На двухсокетных серверах смотреть привязку памяти, иначе PostgreSQL может ходить в «чужую» память соседнего сокета.

Сложить все эти слои в один переход это отдельная история по месяцам, я разбирал её в сквозном кейсе миграции УТ 10.3 на 11.5. На уровне инфраструктуры путь всегда один. Поднять стенд, прогнать тестовую миграцию с нагрузочным тестом, пожить в параллельной эксплуатации, переключиться с планом отката наготове. Старый контур MS держим живым ещё несколько дней после переключения, на случай если что-то всплывёт.

Зачем читал

Если коротко. Под 187-ФЗ переход обязателен, и на середину 2026 категорирование уже должно быть сделано. Без КИИ это вопрос экономики и недоступности MS, то есть не «надо ли», а «когда удобно». По деньгам экономия сидит в лицензиях СУБД, расход в эксплуатации и разовом проекте, окупаемость на средней площадке 2–4 года. По технике сервер уезжает на Linux безболезненно, рабочие места не трогаем, главные грабли это локаль, сеть между 1С и СУБД, периферия и тяжёлые отчёты СКД.

Если у вас 1С на MS SQL и Windows, на первом звонке за 30 минут разберём вашу конфигурацию, прикинем категорию объекта, реальный срок миграции и порядок бюджета. Принесите число ядер сервера СУБД, размер базы и список интеграций, этого хватит для первой оценки. Запись через форму контакта.

Про релизы конфигураций УТ 11.5, ERP 2.5, БП 3.0 на 2026 я писал отдельно в записи про новое в 1С. Отдельная история это MCP-сервер для 1С, когда базу подключают к ИИ-ассистенту через Model Context Protocol. Про AI на базе 1С рассказываю в записи про 1С и AI. Те же подходы я собрал в один сквозной кейс с цифрами и сроками в кейсе УТ 10.3 на УТ 11.5.

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