Как сделать копию базы 1С в PostgreSQL

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

Выбор способа зависит от цели. Для тестовой копии на том же сервере достаточно createdb с шаблоном или pg_dump с восстановлением в новую базу. Для резервного копирования на случай аварии нужен pg_dump в custom-формате или физическая копия через pg_basebackup. Для миграции на другой сервер с другой версией PostgreSQL подходит только логический дамп.

Ниже разобраны рабочие способы с командами, условиями выбора, проверкой результата и типичными ошибками. Все команды выполняются от пользователя с правами суперпользователя PostgreSQL (обычно postgres) либо от владельца базы.

Какой способ копирования выбрать

Существует три практических подхода, и у каждого своя область применения. Логический дамп (pg_dump) создаёт файл с командами, воспроизводящими структуру и данные; его можно развернуть на другом сервере и даже на другой версии PostgreSQL. Физическая копия (pg_basebackup или копирование каталога данных) дублирует кластер побайтово — быстро, но только на ту же версию СУБД и ту же архитектуру. Копирование через шаблон (createdb -T) — самый быстрый способ получить клон базы внутри одного сервера.

Если задача — «сделать копию базы 1С для тестов на этом же сервере», выбирайте createdb с шаблоном. Если нужен файл-архив, который можно хранить и разворачивать где угодно, — pg_dump в формате custom. Если речь о резервном копировании всего сервера 1С — pg_basebackup с архивацией WAL.

Подготовка: сеансы, права и свободное место

Перед копированием проверьте три вещи. Первое — активные подключения к базе: pg_dump умеет снимать консистентный снапшот при работающих пользователях, но createdb -T завершится ошибкой, если к исходной базе кто-то подключён. Второе — права: учётная запись, от которой выполняется команда, должна иметь право чтения всех объектов базы; проще всего работать от postgres. Третье — свободное место на диске: дамп большой базы в несжатом виде может занимать объём, сопоставимый с размером данных.

Активные сеансы к конкретной базе можно посмотреть запросом к pg_stat_activity и при необходимости завершить их принудительно. Со стороны 1С сеансы корректнее закрывать через консоль кластера серверов 1С — так пользователи получат предупреждение, а не обрыв соединения.

SELECT pid, usename, application_name, state FROM pg_stat_activity WHERE datname = 'base1c';
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'base1c' AND pid <> pg_backend_pid();

Копия через pg_dump и pg_restore

Основной рабочий инструмент — pg_dump с флагом -Fc (custom-формат). Такой дамп сжат, поддерживает параллельное восстановление и выборочное извлечение объектов. Команда снимает консистентный снапшот базы, поэтому пользователи могут продолжать работать — копия будет соответствовать состоянию базы на момент старта дампа.

sudo -u postgres pg_dump -Fc -f /backup/base1c_$(date +%Y%m%d).dump base1c

Восстановление выполняется в два шага: создаётся пустая база, затем в неё разворачивается дамп через pg_restore. Флаг -j ускоряет процесс за счёт параллельных потоков, но работает только с форматами custom и directory.

sudo -u postgres createdb base1c_copy
sudo -u postgres pg_restore -d base1c_copy -j 4 /backup/base1c_20260101.dump

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

1. 1
   Уведомите пользователей и при необходимости заблокируйте новые сеансы
2. 2
   Снимите дамп: pg_dump -Fc -f файл база
3. 3
   Создайте пустую базу: createdb имя_копии
4. 4
   Разверните дамп: pg_restore -d имя_копии -j 4 файл
5. 5
   Зарегистрируйте копию в консоли кластера 1С
6. 6
   Проверьте вход в копию и целостность данных

Быстрая копия на том же сервере через createdb -T

PostgreSQL умеет создавать базу как копию существующей через механизм шаблонов. Команда createdb -T base1c base1c_copy выполняется за секунды или минуты даже для больших баз, потому что данные копируются на уровне файлов внутри кластера. Это оптимальный способ сделать тестовую копию перед обновлением конфигурации.

sudo -u postgres createdb -T base1c base1c_copy

Ключевое ограничение: во время копирования к исходной базе не должно быть ни одного активного подключения, включая фоновые процессы самого PostgreSQL, подключённые именно к этой базе. Иначе получите ошибку «source database is being accessed by other users». Поэтому способ применим в нерабочее время или после принудительного завершения сеансов.

Физическая копия кластера через pg_basebackup

Когда нужно скопировать не одну базу, а весь сервер 1С со всеми информационными базами, ролями и настройками, используется pg_basebackup. Утилита создаёт бинарную копию всего каталога данных по протоколу репликации, не останавливая работу сервера. Для её работы на сервере должны быть настроены параметры wal_level, max_wal_senders и разрешение на подключение репликации в pg_hba.conf.

sudo -u postgres pg_basebackup -h 127.0.0.1 -U postgres -D /backup/cluster_copy -Fp -Xs -P

Полученный каталог можно использовать как основу для резервного сервера или для развёртывания полного клона на другой машине с той же версией PostgreSQL. Учитывайте: отдельную базу из такой копии «вытащить» штатными средствами нельзя — придётся поднимать весь кластер и уже из него делать pg_dump нужной базы.

Альтернатива: выгрузка .dt средствами 1С

Выгрузка информационной базы в файл .dt через конфигуратор не зависит от СУБД и переносит данные между платформами — например, с PostgreSQL на MS SQL или в файловый вариант. Это единственный способ, если копия должна быть независимой от инфраструктуры СУБД. Недостатки: требуется монопольный доступ, процесс на больших базах занимает часы, а файл .dt нередко оказывается больше дампа pg_dump.

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

Проверка результата и автоматизация

Копия считается рабочей только после проверки восстановления. Минимальный контроль: pg_restore завершился без ошибок (код возврата 0), база открывается в psql, количество записей в ключевых таблицах совпадает с источником, в копию можно войти через клиент 1С. Для регулярных копий настройте автоматическую проверку — например, ночное восстановление свежего дампа в отдельную базу с отчётом об ошибках.

Автоматизация сводится к скрипту в cron или планировщике systemd: pg_dump с ротацией файлов по дате, контроль кода возврата, отправка уведомления при ошибке. Храните копии на отдельном диске или сервере — дамп, лежащий на том же массиве, что и база, не спасёт при отказе оборудования.

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