Как перевести 1С из файла в клиент-серверный режим

Переводите файловую 1С на клиент-серверный режим после замеров, а не по числу пользователей. Я покажу, как проверить конфигурацию, загрузить пробную копию через .dt, сверить данные и переключить сотрудников с понятным планом отката.

Когда файловую базу 1С пора переносить на сервер

Переходите на клиент-серверный режим не по магическому числу пользователей, а когда измеримые проблемы мешают работе: долго открываются формы, проведение документов упирается в ожидание, отчёты не укладываются в рабочее окно, а диагностика показывает конкуренцию за дисковый ввод-вывод или блокировки. В файловом варианте клиент напрямую обращается к файлу базы; в клиент-серверном клиент работает через кластер 1С, а тот обращается к СУБД. Это меняет архитектуру и инструменты администрирования, но не чинит плохой код и медленный диск по щелчку. Если нужна помощь с проектированием и переходом, я занимаюсь переносом 1С на сервер.

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

Для условной оптовой галереи «Бумажный маяк» с 24 рабочими местами исходной проблемой были отчёты до 15 минут и долгие проведения. Это повод измерить узкое место, а не обещать ускорение в несколько раз. После обследования мы подтвердили, что целевой клиент-серверный вариант подходит, подготовили тестовую копию и сравнили одинаковые операции до и после. Итог зависит от конфигурации, запросов, ресурсов и того, насколько правильно настроена новая среда. Миграция меняет место хранения и схему доступа; сначала докажите на тесте, что она решает именно вашу проблему.

Что выбрать: PostgreSQL или Microsoft SQL Server

Платформа 1С поддерживает несколько СУБД, в том числе PostgreSQL и Microsoft SQL Server; актуальный перечень и совместимые версии нужно сверять с требованиями именно вашей версии платформы. В клиент-серверной схеме есть клиент, кластер серверов 1С и сервер базы данных. Сервер 1С связывает клиентов с СУБД и выполняет прикладную логику, а не заменяет СУБД. Размещать сервер 1С и базу на одном компьютере технически возможно, но это не означает, что ресурсов хватит: расчёт зависит от нагрузки и конфигурации.

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

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

• Сверить версию платформы 1С с поддерживаемой версией СУБД.
• Посчитать лицензии 1С и, если применимо, Microsoft SQL Server.
• Запланировать сопровождение, резервное копирование и восстановление.

Как проверить конфигурацию и подготовить перенос

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

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

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

Как сделать резервную копию и тестовую базу

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

Один из стандартных способов перенести информационную базу 1С — выгрузить её в файл .dt, затем загрузить в целевую базу. Документация 1С прямо указывает такой сценарий для перехода между файловым и клиент-серверным вариантами. Но при загрузке содержимое текущей целевой базы полностью заменяется загружаемым файлом. Поэтому убедитесь, что выбрали пустую тестовую базу, проверьте путь и имя перед подтверждением и не выполняйте загрузку поверх рабочей базы. Подробности формата и последовательности есть в материале [выгрузка и загрузка базы 1С в .dt](https://itfresh.ru/articles/vygruzka-zagruzka-bazy-1s-dt.html).

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

Для восстановления PostgreSQL на выбранный момент времени нужны базовая копия и корректно настроенный архив WAL; сам журнал транзакций не является отдельной волшебной кнопкой. Это отдельная схема, которую следует проверить восстановлением. Для MS SQL Server режим восстановления и резервирование журнала зависят от выбранной модели восстановления. Частоту копирования выбирают по допустимой потере данных и времени восстановления, а не по универсальному совету «полная копия каждый день, журнал каждый час». Факты базы знаний о регулярных копиях полезны как напоминание, но интервал надо привязать к требованиям компании.

• Создать резервную копию исходной файловой базы и проверить восстановление.
• Подготовить отдельную тестовую базу в целевой СУБД.
• Выгрузить `.dt` и загрузить только в пустую целевую базу.
• Сверить данные и пройти сценарии, согласованные с пользователями.

Как переключить пользователей и сохранить путь назад

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

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

В первые рабочие дни следите за журналом регистрации 1С, журналами СУБД, длительностью контрольных операций и резервными копиями. Оповещение без назначенного человека, который реагирует, пользы не приносит. Сверьте итоги с ответственными сотрудниками и зафиксируйте обнаруженные расхождения. Если база открывается, это ещё не означает, что корректно работают регламентные задания, обмены и права. Мы в «АйТи-Фреш» берём на себя обследование и технический переход; после запуска обслуживание сервера стоит от 7 000 ₽/мес по прайсу. Конкретный план и окно определяем после проверки исходной среды.

Что проверить после миграции 1С

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

Проверьте резервное копирование уже целевой базы: задание должно завершаться без ошибки, копия должна попадать на отдельное хранилище, а восстановление — открывать базу на тестовом контуре. Зафиксируйте фактические сроки восстановления и ответственного. Для PostgreSQL не путайте обычный дамп с возможностью восстановиться на произвольный момент: для последнего нужны базовая копия и архивирование WAL, настроенные по документации и проверенные на практике. Для MS SQL Server состав расписания зависит от модели восстановления и целевого времени восстановления. В обоих случаях тест восстановления важнее красивого отчёта задания.

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

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