Хранилище конфигураций 1С на сервере: назначение и архитектура

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

В отличие от обычной файловой информационной базы (файл .1CD), хранилище живёт на сервере, доступно по сети и требует отдельной СУБД — обычно MS SQL Server или PostgreSQL. Это добавляет требования к серверному оборудованию, но даёт командную разработку, откат версий и защиту от потери кода.

Зачем нужно хранилище 1С на сервере

Основная задача — синхронизация работы программистов. Когда один разработчик меняет форму документа, а второй дописывает отчёт, хранилище фиксирует каждое изменение отдельно. Затем программисты обмениваются правками: забирают изменения коллег и отправляют свои. Конфликты 1С подсвечивает и помогает разрешить вручную.

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

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

Как устроено хранилище: архитектура и компоненты

Хранилище конфигураций состоит из трёх частей: серверная база данных, клиентские рабочие места программистов и платформа 1С, которая управляет обменом данными.

Серверная база данных

Это основное хранилище данных. Обычно используют MS SQL Server или PostgreSQL. База содержит таблицы с объектами конфигурации (формы, модули, отчёты), таблицы версий (каждая правка — отдельная запись), таблицы пользователей и прав доступа.

Размер базы растёт с каждым сохранением версии. Если команда активно разрабатывает систему, за год база может занять десятки гигабайт. Отсюда требования к дисковой подсистеме: нужны быстрые SSD-накопители для оперативной работы с версиями и HDD большого объёма для долгосрочного хранения истории.

SQL-сервер работает как отдельный процесс, независимый от платформы 1С. Это значит, что хранилище можно разместить на выделенном сервере, отдельно от прикладных баз данных 1С. Так база хранилища не конкурирует за ресурсы с рабочими базами — учётом, зарплатой, торговлей.

Клиентские рабочие места

Программисты подключаются к хранилищу через конфигуратор 1С. Каждый работает с локальной копией конфигурации: забирает изменения из хранилища, вносит свои правки, тестирует локально, затем отправляет обратно в хранилище. Если два программиста меняли один объект, 1С покажет конфликт и предложит объединить версии.

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

Платформа 1С

Платформа 1С 8.3 управляет хранилищем: принимает версии от клиентов, сохраняет в SQL-базу, отдаёт нужные версии по запросу, сравнивает объекты и подсвечивает конфликты. Платформа работает и на сервере (в составе сервера 1С), и на клиенте (в составе конфигуратора).

Обмен данными идёт по протоколу TCP/IP. Сервер хранилища слушает стандартный порт 1541 (по умолчанию). Клиенты подключаются, передают метаданные объектов, а SQL-база сохраняет их в сжатом виде.

Требования к серверному оборудованию

Для хранилища 1С нужен сервер с достаточными ресурсами для SQL-базы и платформы 1С. Основные требования:

• Процессор: минимум 4 ядра, рекомендуется 8-16 ядер. SQL Server активно использует многопоточность при работе с версиями. Подойдут серверные процессоры Intel Xeon или AMD EPYC.
• Оперативная память: от 16 ГБ, рекомендуется 32-64 ГБ. SQL Server кеширует индексы и данные в памяти. Чем больше памяти, тем быстрее поиск версий и сравнение объектов. Используйте серверную DDR4 ECC-память.
• Дисковая подсистема: SSD обязателен для файлов базы данных (.mdf, .ldf). Лог транзакций лучше тоже на SSD — так откат версий и восстановление после сбоя быстрее. Для резервных копий подойдут HDD в RAID 5 или RAID 6.
• Сеть: гигабитный Ethernet (1 Гбит/с) минимум. Если программистов больше 10, лучше 10-гигабитный канал. Используйте серверные сетевые карты с поддержкой Jumbo Frames для снижения задержек.
• Отказоустойчивость: резервный блок питания, ECC-память, RAID-контроллер с кешем. Потеря данных хранилища — критичное событие, восстановить версии без резервной копии невозможно.

Пример конфигурации сервера для хранилища 1С (команда до 15 программистов):

Компонент	Спецификация
Процессор	Intel Xeon Silver 4314 (16 ядер, 2.4 ГГц)
Оперативная память	64 ГБ DDR4 ECC (4 × 16 ГБ)
Диски для SQL-базы	2 × 960 ГБ SSD NVMe в RAID 1
Диски для резервных копий	4 × 4 ТБ HDD SATA в RAID 5
RAID-контроллер	Аппаратный контроллер с 2 ГБ кеша, BBU
Сетевая карта	Dual-port 10 GbE
Блоки питания	2 × 800 Вт (резервирование N+1)

Для малых команд (3-5 человек) можно использовать более скромную конфигурацию: 4-8 ядер, 16 ГБ памяти, один SSD 480 ГБ. Но обязательно оставьте запас по памяти и дискам — хранилище растёт со временем.

Выбор СУБД: MS SQL Server или PostgreSQL

Платформа 1С поддерживает несколько СУБД для хранилища. Самые распространённые — MS SQL Server и PostgreSQL.

MS SQL Server

Традиционный выбор для хранилищ 1С. Преимущества:

• Стабильность и надёжность. 1С давно работает с SQL Server, все нюансы отработаны.
• Инструменты мониторинга и оптимизации (SQL Server Management Studio, профилировщик запросов).
• Встроенные механизмы резервного копирования, репликации, кластеризации.
• Хорошая документация и поддержка от Microsoft.

Недостатки:

• Лицензии платные. SQL Server Standard стоит от 200 тысяч рублей за двухъядерную лицензию. Для серверов с 16 ядрами цена высокая.
• Требователен к ресурсам. Даже пустая база SQL Server занимает несколько гигабайт памяти.

PostgreSQL

Бесплатная альтернатива. Преимущества:

• Открытая лицензия, бесплатна для любого использования.
• Хорошая производительность на современных версиях (PostgreSQL 13 и выше).
• Меньше требований к ресурсам, чем SQL Server.
• Поддержка продвинутых возможностей (JSONB, полнотекстовый поиск, расширения).

Недостатки:

• Меньше инструментов для администрирования из коробки. Придётся использовать pgAdmin или сторонние утилиты.
• 1С поддерживает PostgreSQL официально, но некоторые администраторы считают её менее привычной.

Выбор зависит от бюджета и экспертизы команды. Если есть лицензии SQL Server и опыт работы с ним — используйте SQL Server. Если бюджет ограничен или уже используете PostgreSQL для других задач — PostgreSQL подойдёт.

Настройка хранилища: основные шаги

Создание хранилища конфигураций проходит в несколько этапов.

Шаг 1: Подготовка сервера и СУБД

Установите SQL Server или PostgreSQL на сервер. Создайте пустую базу данных для хранилища. Настройте права доступа: пользователь 1С должен иметь права на создание таблиц, индексов, выполнение запросов. Для SQL Server обычно используют Windows-аутентификацию или SQL Server-аутентификацию. Для PostgreSQL — пользователя с ролью CREATEDB.

Проверьте доступность сервера по сети. Откройте порт СУБД в файрволе (1433 для SQL Server, 5432 для PostgreSQL). Убедитесь, что клиенты могут подключиться к серверу по IP или DNS-имени.

Шаг 2: Создание хранилища через конфигуратор 1С

Запустите конфигуратор 1С, откройте меню «Конфигурация → Хранилище конфигурации → Создать хранилище». Укажите тип СУБД, адрес сервера, имя базы данных, логин и пароль. 1С создаст таблицы и структуру хранилища автоматически.

Задайте параметры хранилища: имя, комментарий, политику хранения версий (сколько версий хранить, как часто архивировать старые). Рекомендуется хранить все версии без удаления — дисковое пространство дешевле, чем риск потерять важную версию.

Шаг 3: Подключение базы данных к хранилищу

Откройте информационную базу в конфигураторе, выберите «Конфигурация → Хранилище конфигурации → Подключить к хранилищу». Введите параметры подключения (адрес, логин, пароль). 1С сравнит конфигурацию базы с хранилищем. Если хранилище пустое, конфигуратор предложит загрузить текущую конфигурацию в хранилище как первую версию.

После подключения появится возможность работать с версиями: сохранять изменения в хранилище, забирать изменения коллег, сравнивать версии, откатываться на предыдущие релизы.

Шаг 4: Настройка прав доступа

В хранилище можно разграничить права: кто может сохранять версии, кто только читать, кто администрирует хранилище. Права настраиваются через конфигуратор 1С в разделе «Хранилище конфигурации → Администрирование → Пользователи».

Создайте учётные записи для каждого программиста. Назначьте роли: разработчик (может сохранять и забирать версии), администратор (может управлять пользователями и настройками хранилища). Для аудиторов можно создать роль только на чтение.

Практические сценарии использования

Командная разработка конфигурации

Программист А работает над отчётом, программист Б дописывает обработку, программист В исправляет форму документа. Каждый работает локально, периодически забирает изменения коллег из хранилища и отправляет свои правки. Конфликты возникают редко — когда два человека меняли один объект. 1С подсвечивает конфликтные строки, программисты решают вручную, какую версию оставить.

Такой подход ускоряет разработку: не нужно ждать, пока коллега закончит правки. Каждый работает параллельно, а хранилище синхронизирует результат.

Откат на стабильную версию после ошибки

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

Аудит изменений

Руководитель отдела разработки хочет понять, кто и когда менял модуль учёта зарплаты. Открывает хранилище, смотрит историю версий объекта «МодульЗарплата». Видит список всех изменений: дата, автор, комментарий. Может сравнить любые две версии и увидеть построчные изменения. Это помогает отследить, когда появилась ошибка и кто её внёс.

Типичные проблемы и их решение

Хранилище тормозит при работе с большими объектами

Если конфигурация содержит большие формы или модули (сотни килобайт кода), сравнение версий может занимать минуты. Причина — недостаток памяти на SQL-сервере или медленные диски.

Решение: увеличьте память SQL Server (параметр max server memory), переведите базу данных на SSD, настройте индексы в таблицах хранилища. Если база хранилища разрослась до сотен гигабайт, выполните её обслуживание: пересоберите индексы, обновите статистику запросов.

Конфликты при слиянии версий

Два программиста изменили один модуль. При отправке версии 1С показывает конфликт. Программистам приходится вручную сравнивать строки и решать, какую версию оставить.

Решение: договоритесь о разделении зон ответственности. Например, один программист работает с отчётами, второй — с документами. Используйте ветки разработки (если платформа 1С поддерживает). Чаще синхронизируйтесь с хранилищем — забирайте изменения коллег до начала работы, чтобы видеть актуальную версию кода.

Потеря связи с хранилищем

Программист работает удалённо через VPN. Связь оборвалась в момент отправки версии. 1С выдаёт ошибку, версия не сохранилась.

Решение: используйте стабильный VPN-канал с низкой задержкой. Настройте таймауты подключения в конфигураторе 1С (по умолчанию 30 секунд, можно увеличить до 120 секунд). Для критичных правок сохраняйте версии локально в виде файлов конфигурации (.cf) — на случай сбоя связи.

Резервное копирование хранилища

Хранилище конфигураций — критичный компонент инфраструктуры. Без резервных копий потеря базы хранилища означает потерю всей истории разработки.

Используйте встроенные средства СУБД для резервного копирования. Для SQL Server настройте регулярные Full Backup (раз в сутки) и Differential Backup (каждые 4-6 часов). Для PostgreSQL используйте pg_dump или непрерывное архивирование WAL-файлов.

Храните резервные копии на отдельном диске или сетевом хранилище. Проверяйте копии на восстановимость хотя бы раз в месяц — разверните копию на тестовом сервере и убедитесь, что база открывается и версии доступны.

Рекомендуется хранить копии в нескольких местах: локально на сервере (быстрое восстановление), на сетевом хранилище (защита от сбоя сервера), в облаке или офсайт-площадке (защита от пожара, затопления).

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