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

Файловый режим 1С удобен на старте: база лежит в одном файле, не нужен отдельный сервер, всё работает «из коробки». Но у этого режима есть жёсткие ограничения по одновременной работе пользователей, объёму данных и надёжности. Рано или поздно растущий бизнес упирается в эти рамки, и вопрос перехода на клиент-серверную архитектуру становится практическим, а не теоретическим.

Клиент-серверный вариант предполагает три компонента: клиентское приложение, кластер серверов 1С:Предприятия и систему управления базами данных (MS SQL Server, PostgreSQL, Oracle или IBM DB2). Такая схема снимает большинство ограничений файлового режима, но требует лицензии на сервер 1С, лицензий на СУБД (кроме бесплатных вариантов PostgreSQL) и квалифицированного администрирования.

Ошибка в обе стороны обходится дорого: преждевременный переход — лишние расходы на лицензии и оборудование, а запоздалый — потерянные данные, простои и нервы сотрудников. Поэтому решение нужно принимать по конкретным признакам, а не «на вырост» или «потому что все так делают».

Признаки, что файловый режим уже не справляется

Самый надёжный способ понять, что пора переходить, — наблюдать за симптомами, а не за календарём. Файловая база хранится в одном файле 1Cv8.1CD, и механизм блокировок в ней работает на уровне всей таблицы. Пока один пользователь проводит документ, остальные ждут. При росте числа пользователей очередь из таких ожиданий становится основной причиной жалоб.

Типичные симптомы: система «подвисает» при одновременной работе нескольких человек, проведение документов занимает минуты вместо секунд, регулярно возникают ошибки «Конфликт блокировок при выполнении транзакции» и «Ошибка SDBL». Ещё один тревожный сигнал — разрушение файла базы после отключения электричества или обрыва сети: файловый формат чувствителен к таким сбоям, и восстановление через утилиту chdbfl не всегда помогает полностью.

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

Когда переходить не нужно

Клиент-серверная архитектура — это не только возможности, но и постоянные расходы: лицензия на сервер 1С, лицензии на СУБД (для коммерческих вариантов), выделенное оборудование или виртуальная машина, а главное — специалист, который будет обслуживать связку. Для небольшой компании эти затраты могут не окупиться.

Если в базе работают 1–3 человека, объём данных умеренный, жалоб на скорость нет, а резервное копирование настроено и регулярно проверяется — файловый режим остаётся разумным выбором. Часть проблем производительности в этом случае решается проще: перенос базы на SSD, отказ от сетевого диска в пользу веб-сервера, регламентное тестирование и исправление, очистка устаревших данных.

Сравнение файлового и клиент-серверного режимов

Чтобы решение было обоснованным, полезно сопоставить ключевые параметры двух архитектур применительно к вашей ситуации.

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

Выбор СУБД и лицензий

После принятия решения о переходе нужно выбрать СУБД. Практически чаще всего выбор стоит между MS SQL Server и PostgreSQL. MS SQL Server — коммерческий продукт с платными лицензиями, но с предсказуемой поддержкой и привычным инструментарием. PostgreSQL бесплатен сам по себе, существуют специальные сборки, адаптированные под требования 1С, однако его настройка и обслуживание требуют соответствующих навыков.

Сравнение вариантов СУБД

MS SQL Server

Подходит, если в компании уже есть лицензии и администратор Microsoft-стека. Ограничение — стоимость лицензий на сервер и клиентские доступы

PostgreSQL

Подходит при ограниченном бюджете: сама СУБД бесплатна, нужны сборки под 1С. Ограничение — требуется специалист по настройке и тюнингу

Oracle / IBM DB2

Оправданы в крупных организациях, где эти СУБД уже используются корпоративно. Для типового перехода избыточны

По лицензиям 1С потребуется лицензия на сервер 1С:Предприятия (отдельно для 32-битной и 64-битной версий, либо комбинированная), а клиентские лицензии, уже купленные для файловой работы, продолжают действовать. Перед покупкой сверьте число одновременных пользователей с номиналом имеющихся лицензий — при росте штата может понадобиться докупка.

Пошаговый порядок миграции

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

1. 1
   Сделайте полную резервную копию файловой базы и проверьте, что копия открывается
2. 2
   Выполните тестирование и исправление файловой базы, устраните найденные ошибки
3. 3
   Установите и настройте СУБД и сервер 1С:Предприятия, проверьте их взаимодействие
4. 4
   Создайте новую пустую информационную базу в консоли кластера серверов
5. 5
   Выгрузите файловую базу в файл .dt через конфигуратор в нерабочее время
6. 6
   Загрузите .dt в новую серверную базу через конфигуратор
7. 7
   Настройте права пользователей, регламентные задания и резервное копирование средствами СУБД
8. 8
   Проведите тестовую эксплуатацию: проведение документов, отчёты, обмены, печать
9. 9
   Переведите пользователей на новую базу, старую оставьте в режиме «только чтение» на переходный период

Выгрузку и загрузку выполняйте в нерабочее время с полным завершением сеансов пользователей. Для больших баз процедура может занять часы — заложите это в план и предупредите сотрудников. Критично до выгрузки прогнать тестирование и исправление: ошибки, скопившиеся в файловой базе, могут помешать загрузке или проявиться позже в самый неподходящий момент.

Проверка результата и типичные ошибки

После миграции нужно убедиться, что система работает корректно, а не просто «запускается». Проверьте итоги по ключевым регистрам до и после перехода, проведите несколько типовых документов, сформируйте основные отчёты, проверьте работу обменов с другими системами и печатных форм. Отдельно протестируйте регламентные задания — в клиент-серверном режиме они выполняются на сервере, и их настройки могли не перенестись.

Контрольные точки

Как проверить результат

Итоги по регистрам

Норма

Обороты и остатки совпадают с файловой базой

Тревожный признак

Расхождения в суммах или количестве

Регламентные задания

Норма

Выполняются по расписанию на сервере

Тревожный признак

Задания не запускаются или завершаются с ошибкой

Одновременная работа

Норма

Несколько пользователей проводят документы без конфликтов

Тревожный признак

Сохраняются ошибки блокировок

Резервное копирование

Норма

Бэкап средствами СУБД создаётся и восстанавливается

Тревожный признак

Копия есть, но восстановление не проверялось

Альтернативы полному переходу

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

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

Маршрут решения

Как выбрать действие

1–3 пользователя, жалоб нетОставайтесь на файловом режиме, настройте бэкапы и регламентное обслуживание

5–10 пользователей, работа по сетевому диску, случаются сбои файлаОпубликуйте базу через веб-сервер как промежуточный шаг и планируйте переход

Больше 10 пользователей, постоянные блокировки, база растётПланируйте миграцию на клиент-сервер с выбором СУБД и назначением ответственного

Нужен клиент-сервер, но нет своего администратораРассмотрите облачную аренду 1С вместо покупки собственного сервера

Часто задаваемые вопросы

Можно ли вернуться с клиент-серверного режима обратно на файловый?

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

Нужно ли менять конфигурацию при переходе?

Типовые конфигурации работают в обоих режимах без доработок. Проблемы возможны в самописных решениях и сильно доработанных конфигурациях, где использовались особенности файлового режима, например прямой доступ к файлам на локальном диске или запуск внешних программ на клиенте. Такие места нужно выявить и проверить при тестовой эксплуатации.

Сколько времени занимает миграция?

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

Что делать с резервным копированием после перехода?

Копирование файла больше не работает — данные теперь в СУБД. Настройте регламентное резервное копирование средствами самой СУБД (полные и разностные копии) и обязательно проверьте восстановление из копии на тестовой базе. Копия, из которой никогда не восстанавливались, нельзя считать надёжной.

Ускорит ли переход медленные отчёты?

Частично: серверное оборудование обычно мощнее рабочих станций, и блокировки перестанут тормозить параллельную работу. Но если отчёт медленный из-за неоптимального запроса или огромного объёма выборки, радикального ускорения не будет — потребуется оптимизация самого запроса или настроек СУБД.

Можно ли провести миграцию без остановки работы компании?

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