Одна база без кластера: как работает и запускается автономный сервер 1С:Предприятия

Автономный сервер 1С — это программа ibsrv, которая поднимает одну информационную базу без кластера серверов: без агента, менеджера и отдельных рабочих процессов. Он входит в поставку платформы с версии 8.3.14, работает с файловой базой или с базой в СУБД и сам принимает подключения тонкого и веб-клиента по HTTP. Управляют им утилитой командной строки ibcmd.

Нужен он там, где полноценный кластер избыточен, а файловая база по сетевой папке уже не устраивает: тестовые стенды, сборка и проверка конфигураций, небольшие офисы, доступ к базе через интернет без IIS или Apache. Настройка сводится к трём шагам: подготовить базу, запустить ibsrv с параметрами и оформить его службой.

Когда автономный сервер 1С действительно нужен

Автономный сервер — не «облегчённый кластер», а отдельный режим со своей нишей. Типовые сценарии такие.

• 🧪 Тестовые и учебные стенды. Подняли базу из .dt одной командой, проверили обновление, удалили. Не нужно регистрировать базу в кластере и выдавать права в консоли.
• ⚙️ Автоматическая сборка (CI). ibcmd загружает конфигурацию из файлов или .cf, применяет изменения, выгружает .dt — всё без графического интерфейса и без запуска Конфигуратора. Удобно в контейнерах на Linux.
• 🌐 Доступ к базе по HTTP без веб-сервера. ibsrv сам является HTTP-сервером. Тонкий клиент и браузер подключаются к нему по адресу, как к опубликованной базе.
• 🏢 Небольшой офис или удалённая точка. Одна база, несколько пользователей, нет администратора, который будет сопровождать кластер.
• 📦 Переходный вариант. Файловая база стала тормозить по сети, а покупать и настраивать полноценный сервер пока рано.

Когда автономный сервер не подходит:

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

Как устроен автономный сервер и чем он отличается от кластера

В классической клиент-серверной схеме клиент обращается к агенту сервера (порт 1540), тот передаёт его менеджеру кластера (1541), а работу выполняют рабочие процессы из диапазона портов, заданного в свойствах рабочего сервера. Базы регистрируются в кластере, управление идёт через консоль или rac.

В автономном режиме всё это заменяет один процесс ibsrv:

Порт HTTP по умолчанию — 8314. Нужно несколько баз — запускаете несколько процессов ibsrv на разных портах и с разными каталогами данных.

Где лежат файлы после установки платформы:

• Windows: C:\Program Files\1cv8\8.3.xx.xxxx\bin\ibsrv.exe и ibcmd.exe;
• Linux: /opt/1cv8/x86_64/8.3.xx.xxxx/ibsrv и ibcmd.

Версия платформы у сервера и у клиентов должна совпадать, как и при работе с кластером.

Пошаговая настройка автономного сервера 1С

Шаг 1. Подготовьте базу

Есть готовая файловая база — можно сразу переходить к шагу 2. Если база есть только в виде выгрузки, создайте её и загрузите .dt:

ibcmd infobase create --db-path=/srv/1c/buh
ibcmd infobase restore --db-path=/srv/1c/buh /backup/buh.dt

Для базы в PostgreSQL вместо --db-path указывают параметры СУБД:

ibcmd infobase create --dbms=PostgreSQL --db-server=localhost \
  --db-name=buh --db-user=postgres --db-pwd=secret --create-database

Шаг 2. Подготовьте каталог данных

ibsrv хранит служебные файлы (журнал регистрации, временные данные, настройки сеансов) в отдельном каталоге. Создайте его рядом с базой и выдайте права пользователю, от имени которого будет работать сервер:

mkdir -p /srv/1c/buh-data
chown -R usr1cv8:grp1cv8 /srv/1c/buh /srv/1c/buh-data

Шаг 3. Запустите сервер вручную

Пробный запуск в консоли, чтобы увидеть ошибки сразу:

/opt/1cv8/x86_64/8.3.xx.xxxx/ibsrv --db-path=/srv/1c/buh \
  --data=/srv/1c/buh-data --name=buh --address=any --port=8314

Имена параметров сверяйте с ibsrv --help для своей версии платформы: набор опций расширяется от релиза к релизу. Удобнее вынести параметры в файл конфигурации: его заготовку создаёт ibcmd server config init, а сервер запускают с указанием этого файла.

Шаг 4. Подключите клиента

В окне запуска 1С нажмите «Добавить», выберите добавление существующей базы и вариант расположения «На веб-сервере». Адрес — http://имя-сервера:8314. Браузером база открывается по тому же адресу.

Шаг 5. Оформите запуск службой

Ручной запуск закончится вместе с сеансом администратора. На Linux создайте юнит systemd /etc/systemd/system/ibsrv-buh.service:

[Unit]
Description=1C standalone server (buh)
After=network.target

[Service]
User=usr1cv8
ExecStart=/opt/1cv8/x86_64/8.3.xx.xxxx/ibsrv --db-path=/srv/1c/buh --data=/srv/1c/buh-data --name=buh --address=any --port=8314
Restart=on-failure

[Install]
WantedBy=multi-user.target

Затем systemctl daemon-reload и systemctl enable --now ibsrv-buh. На Windows процесс регистрируют службой стандартными средствами системы (sc create с путём к ibsrv.exe и параметрами) и запускают от отдельной учётной записи.

Файловая база под автономным сервером

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

Что улучшается:

• ✅ Нет прямого доступа пользователей к файлу 1Cv8.1CD. С базой работает только процесс сервера. Пользователь не может скопировать или случайно удалить файл, если у него нет прав на папку.
• ✅ Обрыв сети не бьёт по файлу базы. При работе через общую папку разрыв связи у одного клиента в момент записи — частая причина повреждения 1Cv8.1CD. Под автономным сервером клиент общается с сервером по HTTP, а пишет в файл только ibsrv на той же машине. Разрыв связи обрывает сеанс, но не прерывает запись в файл на полпути.
• ✅ Работа через интернет. Тонкий клиент по HTTP терпимее к задержкам канала, чем файловый доступ по SMB.

Что остаётся как было:

• база остаётся файловой: ограничения по объёму и числу одновременных пользователей такие же, как у файлового варианта;
• монопольный доступ по-прежнему нужен для обновления структуры базы, загрузки .dt, тестирования и исправления.

Доступ и безопасность

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

Минимальный набор мер:

1. 🔐 Пользователи и пароли в базе. База без списка пользователей откроется любому, кто знает адрес. Заведите пользователей и включите аутентификацию 1С.
2. 🧱 Брандмауэр. Порт 8314 (или ваш) открывайте только для адресов офиса или VPN. Выставлять его в интернет напрямую не стоит.
3. 🔒 Шифрование канала. Встроенный сервер работает по HTTP. Для доступа извне ставьте перед ним обратный прокси с TLS (например, nginx с сертификатом) или пускайте пользователей через VPN.
4. 👤 Отдельная учётная запись ОС. ibsrv запускается не от администратора и не от root. Права на каталог базы и каталог данных — только у этой учётной записи.
5. 🗝️ Пароль администратора базы в командах ibcmd. Если в базе есть пользователи, служебные команды требуют --user и --password. Не храните пароль открытым текстом в скриптах, доступных всем.

Филиал без постоянной связи: РИБ вместо одного сервера

Частая путаница: «автономным» называют и сервер, и офис, который работает без связи с центром. Автономный сервер не умеет синхронизировать базы. Если склад или магазин должен продолжать работать при обрыве канала, а потом догонять центр, нужна распределённая информационная база (РИБ).

Как это устроено:

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

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

Автономный сервер и РИБ хорошо сочетаются: в филиале периферийная база может работать под ibsrv, а не по сетевой папке. Тогда у филиала и защищённый файл базы, и самостоятельная работа без центра.

Синхронизация после восстановления связи

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

Для РИБ порядок после восстановления канала такой:

1. Запустите обмен со стороны филиала: выгрузите накопленные изменения и отправьте в центр.
2. В центре загрузите сообщение и выгрузите ответ: туда попадут изменения центра и подтверждение полученного.
3. В филиале загрузите ответ. Номера сообщений у узлов выровняются.
4. Если менялась конфигурация центра, периферийная база при загрузке получит изменения конфигурации. Их надо применить — потребуется монопольный доступ к базе филиала.
5. Проверьте коллизии: если один объект правили и в центре, и в филиале, приоритет определяется правилами обмена, по умолчанию — у главного узла.

Мониторинг и обслуживание

Консоли кластера у автономного сервера нет, поэтому наблюдают за ним средствами ОС и самой 1С.

Регулярное обслуживание:

• 💾 Резервные копии. Выгрузка ibcmd infobase dump в .dt по расписанию. Для файловой базы можно копировать каталог базы, но только остановив службу.
• 🔄 Обновление конфигурации. Через Конфигуратор с подключением к базе либо через ibcmd config load и ibcmd config apply. Применение изменений структуры требует монопольного доступа.
• ⬆️ Обновление платформы. Новый релиз ставится в отдельный каталог. Поменяйте путь в юните службы, перезапустите её и обновите клиентов до той же версии.

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