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

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

Ниже разобраны рабочие способы: разовый дамп одной базы, копирование всех баз кластера, постановка задачи на расписание, контроль целостности копий и восстановление. Команды приведены для Linux и Windows с учётом специфики связки «1С:Предприятие + PostgreSQL».

Чем бэкап PostgreSQL отличается от выгрузки dt

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

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

Практическая рекомендация: основной ежедневный бэкап делать средствами PostgreSQL, а dt-выгрузку использовать эпизодически — перед обновлением конфигурации, переносом базы между платформами или передачей копии франчайзи.

Подготовка: что проверить перед первым бэкапом

Перед настройкой убедитесь, что знаете три вещи: имя базы данных (его видно в консоли кластера 1С или в pgAdmin), учётную запись с правами на чтение (обычно postgres) и путь, куда будут складываться копии. Каталог для бэкапов должен находиться не на том же диске, что и данные PostgreSQL, — иначе при отказе диска вы потеряете и базу, и копии.

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

Разовый бэкап одной базы через pg_dump

Основная команда выглядит так:

pg_dump -U postgres -h localhost -Fc -f /backup/ut_2026.dump ut_base

Здесь -U postgres — пользователь СУБД, -Fc — собственный сжатый формат PostgreSQL (custom), -f — путь к файлу, ut_base — имя базы. Формат custom предпочтителен: он сжимает данные и позволяет при восстановлении выбирать отдельные таблицы через pg_restore.

На Windows команда аналогична, меняется путь к утилите и файлу:

"C:\Program Files\PostgreSQL\14\bin\pg_dump.exe" -U postgres -Fc -f D:\backup\ut.dump ut_base

Чтобы не вводить пароль интерактивно, задайте его в переменной окружения PGPASSWORD в рамках сессии скрипта или используйте файл pgpass. Хранить пароль открытым текстом внутри самого скрипта небезопасно — ограничьте доступ к файлу скрипта на уровне прав ОС.

pg_dump -U postgres -h localhost -Fc -f /backup/ut_base_$(date +%Y%m%d_%H%M).dump ut_base

Копия всех баз и служебных объектов

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

Для копирования глобальных объектов используется pg_dumpall с ключом --globals-only:

pg_dumpall -U postgres --globals-only -f /backup/globals.sql

Либо можно снять полный дамп кластера целиком командой pg_dumpall без ключей, но такой файл восстанавливается только целиком и в текстовом формате — для ежедневных копий это менее удобно, чем набор отдельных дампов.

Автоматизация: расписание и ротация копий

Разовые копии вручную рано или поздно забываются, поэтому бэкап ставят на расписание. В Linux это делается через cron: создайте скрипт /opt/scripts/backup_1c.sh, добавьте команду pg_dump с датой в имени файла и строку удаления копий старше, например, 14 дней:

#!/bin/bash
pg_dump -U postgres -Fc -f /backup/ut_$(date +%Y%m%d).dump ut_base
find /backup -name "*.dump" -mtime +14 -delete

Затем добавьте задание в crontab, например на 2 часа ночи: 0 2 * /opt/scripts/backup_1c.sh. Время выбирайте вне окон регламентных заданий 1С и обменов, чтобы копирование не конкурировало за ресурсы.

В Windows используется Планировщик заданий: создайте bat-файл с аналогичной логикой (дату в имени файла можно получить через %DATE% или PowerShell) и назначьте запуск от учётной записи с правами на каталог бэкапов. Удаление старых файлов удобно делать командой forfiles или скриптом PowerShell.

1. 1
   Определите имя базы и проверьте доступ под пользователем postgres
2. 2
   Сделайте тестовый дамп pg_dump -Fc и оцените его размер
3. 3
   Напишите скрипт с датой в имени файла и ротацией старых копий
4. 4
   Поставьте скрипт в cron или Планировщик заданий на ночное время
5. 5
   Настройте копирование дампов на другое устройство или в сетевое хранилище
6. 6
   Раз в месяц проверяйте восстановление копии на тестовом сервере

Восстановление и проверка копий

Бэкап, который ни разу не восстанавливали, нельзя считать рабочим. Восстановление дампа формата custom выполняется утилитой pg_restore в заранее созданную пустую базу:

createdb -U postgres ut_base_test
pg_restore -U postgres -d ut_base_test /backup/ut_2026.dump

После восстановления зарегистрируйте тестовую базу в консоли кластера 1С (или добавьте её в список баз на тестовом клиенте) и войдите в неё: проверьте, что открываются документы за последние даты, строятся отчёты, нет ошибок в журнале регистрации. Это занимает 15–30 минут, но именно так выявляются битые дампы и нехватка прав.

Обратите внимание на версии: дамп, снятый pg_dump от PostgreSQL 14, штатно восстанавливается в 14 и выше, но не в более старую версию. Держите на тестовом стенде ту же версию СУБД, что и в продакшене.

Типичные ошибки и ограничения

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

Вторая ошибка — отсутствие ротации: диск переполняется, PostgreSQL может остановиться из-за нехватки места, если бэкапы лежат рядом с данными или журналами. Третья — использование pg_dump без ключа -Fc: текстовый дамп большой базы занимает в разы больше места и восстанавливается только целиком через psql.

Отдельно стоит упомянуть копирование каталога данных средствами ОС при работающем сервере. Такой «бэкап» почти гарантированно содержит несогласованные файлы и не поднимется. Физическое копирование допустимо только при остановленной службе PostgreSQL либо через специализированные инструменты вроде pg_basebackup с настроенным WAL-архивом.

Когда стоит привлечь специалиста

Описанных шагов достаточно для базового сценария: одна или несколько баз, ежедневный дамп, ротация, периодическая проверка. Но есть ситуации, где самостоятельная настройка рискованна: базы объёмом в сотни гигабайт, требования к восстановлению за минуты (RTO/RPO), кластеры с репликацией, необходимость point-in-time recovery через WAL-архивы.

В таких случаях внедряют инструменты уровня pg_basebackup, WAL-G или Barman, а их настройка и тестирование требуют опыта администрирования PostgreSQL. Ошибка в конфигурации непрерывного архивирования может остаться незамеченной до момента, когда копия реально понадобится.

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