Как перенести файловую базу 1С в PostgreSQL и проверить, что ничего не потерялось: опыт на «Нано-УТ» со временем каждого шага
База данных - Администрирование СУБД
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Перенос файловой базы 1С на PostgreSQL от выгрузки до проверки: что получилось, сколько заняло и что отвергла платформа. Опыт на «Нано-УТ 2.0» и сервере 1С 8.3.27 с журналами, сверкой до и после и автономной проверкой журналов в архиве.
- Сверка 26 показателей через платформу до и после переноса совпала построчно.
- На стенде при создании потребовалась роль суперпользователя; после загрузки её понизили.
- На стенде подошла локаль ru_RU: на C и C.utf8 платформа отказала.
- Базу PostgreSQL, созданную вручную, платформа на стенде не приняла; её создавали платформой.
- Одновременное проведение документов дало конфликты блокировок и в файловой, и в серверной базе.
Перенос базы на PostgreSQL проверяют сверкой до и после, а права роли, локаль кластера и многопользовательскую работу выбирают и проверяют заранее.
Для кого: администраторы и разработчики 1С, которые переводят файловые базы на сервер с PostgreSQL.
Перенос базы 1С с файлового варианта на сервер с PostgreSQL обычно описывают как набор настроек. Я сделала его на стенде от начала до конца и проверила результат сверкой до и после: взяла файловую «Нано-УТ 2.0» с 878 проведёнными продажами, выгрузила её в файл .dt, создала серверную базу на кластере 1С с PostgreSQL 17 в Docker, загрузила выгрузку и сравнила 26 числовых показателей: число справочников и документов, остатки, суммы; отдельно проверила поиск по наименованию и порядок сортировки. Это лабораторный опыт 22.10.2026; в приёмке 26.10.2026 проверены сохранённые журналы, полный перенос повторно не запускался. Потом проверила модули на серверной базе и одновременно провела документы тремя процессами в обеих базах. Что не проверила, написала в конце.
Результат. Выгрузка заняла 4,1 с, файл .dt 0,5 МБ; создание информационной базы 6,3 с; загрузка 19,8 с. Все 26 показателей совпали построчно. Платформа отказалась создавать базу ролью PostgreSQL без прав суперпользователя («нет доступа к языку c»); после создания роль понизили до обычной, и база продолжила работать. Платформа приняла только базу PostgreSQL с русской локалью и отвергла кластеры с локалью C и C.utf8. При одновременном проведении документов тремя процессами обе базы дали конфликты блокировок: в файловой проведено 40 документов из 45 за 251 с, в серверной 16 из 45 за 375 с.
Стенд
| Условие | Значение |
|---|---|
| Платформа | 1С:Предприятие 8.3.27.2130 (x86); кластер из ragent и ras на отдельных портах, база на сервере |
| СУБД | Postgres Pro 1C 17.10 в контейнере Docker Desktop (ВМ 4 ядра, около 3,8 ГБ памяти), параметры сервера не менялись: shared_buffers 128 МБ, work_mem 32 МБ, max_connections 250 |
| Конфигурация | «Нано-УТ 2.0» - наша учебная торговая конфигурация, плюс общий модуль стенда с наполнением, сверкой и нагрузкой |
| Данные | файловая база 10,5 МБ: 41 контрагент, 50 товаров, 878 проведённых документов «ПродажаТовара», 2590 строк движений по остаткам товаров |
| Компьютер | Intel Core i5-2400 3,1 ГГц (4 ядра, 2011 год), 7,9 ГБ ОЗУ, SATA SSD, Windows 11 Pro. Компьютер рабочий: во время опытов были открыты браузер и приложение Claude |
База маленькая, поэтому времена ниже относятся к этому набору данных и этому компьютеру. Перенос базы на гигабайты потребует другого времени.
Что сверяла
Сверку делает функция общего модуля стенда: через запросы 1С считает элементы всех справочников, документы всех видов, число строк и суммы по двум регистрам накопления и остатки по виртуальной таблице. Всего 26 строк «показатель - значение», вывод по базе до переноса:
| Показатель | Значение |
|---|---|
| Справочник.Контрагенты | 41 |
| Справочник.Номенклатура | 50 |
| Документ.ПродажаТовара | 878 |
| Документ.ПродажаТовара, сумма документов | 957083 |
| ТоварыНаСкладах, строк движений | 2590 |
| ТоварыНаСкладах, остаток количества | 49992311 |
| Продажи, строк движений | 2540 |
| Продажи, выручка | 957083 |
| Продажи, себестоимость | 7689 |
Отдельно от 26 числовых строк выполнялись три пробных запроса: поиск контрагента по наименованию строчными и прописными буквами и порядок сортировки наименований. Сверка идёт через платформу, то есть не по таблицам PostgreSQL: так проверяется то, что видит пользователь.
Порядок переноса
Выгрузка файловой базы:
Создание информационной базы на кластере вместе с базой PostgreSQL (сервер администрирования ras):
Загрузка:
На нашем компьютере выгрузка заняла 4,1 с (файл 499 909 байт при файловой базе 10,5 МБ), создание базы 6,3 с, загрузка 19,8 с. После загрузки в PostgreSQL оказалось 144 таблицы и 227 индексов, размер базы 17 МБ, кодировка UTF8, сортировка ru_RU.UTF-8.
Права роли PostgreSQL
Первая попытка создать базу ролью с правом CREATEDB и без прав суперпользователя закончилась отказом:
База PostgreSQL при этом уже создана, а информационной базы на кластере нет: остаток пришлось удалить вручную (DROP DATABASE). Повторная попытка той же командой с ролью суперпользователя прошла. После загрузки я понизила роль (ALTER ROLE ... NOSUPERUSER) и повторила сверку: база работала, все 26 показателей совпали, проверка модулей прошла. Права суперпользователя понадобились платформе только при создании базы; поведение при обновлении платформы и реструктуризации с обычной ролью я не проверяла.
Что показала сверка после загрузки
После загрузки те же 26 строк вывелись по серверной базе. Сравнение построчное, расхождений нет: число справочников, документов, суммы, остатки по складам (49 992 311) и выручка (957 083) совпали. Поиск контрагента по строке «ёлкин и сыновья» и по строке «ЁЛКИН И СЫНОВЬЯ» вернул один и тот же элемент в обеих базах: платформа сравнивает наименования без учёта регистра и в файловой базе, и на PostgreSQL. Порядок сортировки наименований тоже совпал с файловой базой; он разобран в разделе про локаль.
Журнал прогона, файл evidence/migration-run.txt (конец шага 5, шаги 6 и 6а):
Типовые запросы (отбор документов по периоду, остатки, выручка по контрагентам) повторены 20 раз подряд: в файловой базе 20 повторов заняли 0,15 с, в серверной 0,32 с, 16 200 строк результата в обеих. На такой малой базе серверный вариант медленнее: добавляются обращение к кластеру и СУБД. Вывод про скорость на больших данных из этого опыта сделать нельзя.
Какую локаль PostgreSQL принимает платформа
Порядок сортировки строк в запросах 1С определяет СУБД, поэтому локаль базы PostgreSQL выбирают заранее. Я добавила в базу контрагентов с разным регистром и буквой «ё» («арбуз», «Яблоко», «Банан», «ёж», «Бык», «вол»), выгрузила базу и загрузила её в PostgreSQL с локалью ru_RU.utf8. На кластерах с локалями C и C.utf8 создание информационной базы завершилось отказом, до загрузки дело не дошло.
В базе ru_RU.utf8 порядок сортировки и поиск совпали с файловой базой:
Регистр букв платформа игнорирует (поиск «ЯБЛОКО» нашёл «Яблоко»), а «ё» и «е» различает, и в файловой базе, и на PostgreSQL. Строчные и прописные буквы в порядке сортировки идут вперемешку по алфавиту («арбуз», «Банан», «Бык», «вол»).
Остальные локали платформа не приняла. Я подняла из того же образа два временных контейнера PostgreSQL, где кластер создан с локалью C и C.utf8, и пробовала создать информационные базы с локалями 1С ru, en и en_US. Во всех шести попытках ответ одинаков:
Для этого стенда подошла локаль ru_RU.UTF-8; отказ на C и C.utf8 относится к перечисленным версиям и настройкам. Менять локаль уже созданного кластера я не пробовала. Отдельный отказ я получила на базе, созданной вручную командой CREATE DATABASE ... OWNER с обычными параметрами: при создании информационной базы без --create-database платформа ответила «DATABASE не пригоден для использования». Причину я не выяснила, поэтому базу PostgreSQL создавали платформой.
Одновременное проведение документов
Три процесса провели по 15 документов продаж с общими товарами одновременно: сначала в файловой базе, потом в серверной.
Текст ошибки в обеих базах начинается с «Конфликт блокировок при выполнении транзакции»; в серверной базе у него добавлено «Превышено максимальное время ожидания предоставления блокировки». Для сравнения: при наполнении базы один процесс проводил документ примерно за 0,8 с (200 документов за 155 с), поэтому 45 документов подряд заняли бы около 35 с. Все три процесса проводят документы с общими пятью товарами, а проведение блокирует их остатки. Причину различия между файловой и серверной базой я не разбирала и никаких настроек блокировок не меняла; вывод только один: перед переходом на сервер многопользовательскую работу с общими остатками надо проверять отдельно.
Проверка модулей на серверной базе
После переноса я запустила /CheckModules на серверной базе (платформа, роль без прав суперпользователя):
Что не проверялось
- Базы на гигабайты и миллионы строк: стенд на 878 документов не показывает ни время переноса, ни поведение индексов на большом объёме.
- Кластер из нескольких рабочих серверов, резервные копии и восстановление средствами PostgreSQL, репликация.
- PostgreSQL ниже 17, Linux-сервер, версии платформы ниже 8.3.27.
- Регламентные задания, фоновые процессы, обмены с внешними системами, расширения конфигурации.
- Настройки PostgreSQL (
shared_buffers,work_memи другие) на скорость: параметры сервера на стенде не менялись. - Интерактивная работа пользователей через тонкий клиент: сверка и нагрузка шли через внешнее соединение.
Итог
Перенос файловой базы на PostgreSQL через .dt на стенде прошёл за полминуты, а сверка до и после совпала по всем 26 показателям. Три вещи стоит проверить заранее: права роли PostgreSQL при создании базы (суперпользователь на время создания), локаль базы (она меняет порядок сортировки) и поведение при одновременной работе нескольких пользователей. В архиве лежат журналы, их автономная проверка, SQL и чек-лист. Драйверы автоматического переноса из читательского комплекта исключены по результатам приёмки.
Источники
- PostgreSQL 17, управление базами данных (0, шаблоны и локаль)
- PostgreSQL 17, поддержка правил сортировки и кодировок
- Infostart, «Как получить полный доступ к данным файловой базы 1С» (загрузка файла dt в клиент-серверную базу на PostgreSQL как один из шагов)
Файл к статье
Архив pg-migration-companion.zip содержит заполненные журналы опыта 22.10.2026, verify.py для их сверки без платформы, SELECT-запросы queries/pg_state.sql и чек-лист подготовки переноса.
Автоматические драйверы переноса и локалей не включены: при приёмке обнаружены операции удаления баз и контейнеров без достаточного ограничения области, а также внешние зависимости, отсутствующие в комплекте. Архив помогает разобрать результат опыта и подготовить собственную сверку. Он не переносит вашу базу и не воспроизводит полный стенд одной командой.
При проверке 26.10.2026 из чистой распаковки python verify.py завершился успешно; изменение одного показателя и удаление раздела журнала приводили к отказу. Это проверка согласованности сохранённых журналов, а не новый прогон платформы.
Вступайте в нашу телеграмм-группу Инфостарт
