Бэкап и восстановление базы 1C в PostgreSQL через pgAdmin

Бэкап базы 1C в PostgreSQL через pgAdmin возможен, но его нельзя воспринимать как универсальную замену регламентному резервному копированию. pgAdmin вызывает стандартные инструменты PostgreSQL, поэтому важно понимать, что именно копируется: серверная база PostgreSQL, роли, права и данные, а не файловая выгрузка 1C формата .dt.

Когда pgAdmin подходит, а когда нет

pgAdmin подходит для разового резервного копирования небольшой или тестовой базы, учебного восстановления, переноса на стенд и проверки структуры. Для регулярного production-бэкапа лучше использовать автоматизированный регламент: pg_dump, проверка восстановления, контроль логов, хранение нескольких копий и понятный план отката.

Для 1C особенно важно не путать разные виды резервных копий. Выгрузка .dt создается средствами 1C. Дамп PostgreSQL создается средствами PostgreSQL. Это разные механизмы, с разными сценариями восстановления.

Что проверить перед backup

Перед тем как делать бэкап базы 1C в PostgreSQL через pgAdmin, зафиксируйте исходные данные: имя базы, владельца, роли, версию PostgreSQL, размер базы и наличие активных подключений.

SELECT current_database(), current_user, version();

Размер базы:

SELECT pg_size_pretty(pg_database_size('base_1c')) AS db_size;

Активные подключения:

SELECT pid, usename, datname, state, query
FROM pg_stat_activity
WHERE datname = 'base_1c'
ORDER BY state, pid;

Если база активно используется, согласуйте окно работ. Для критичных баз не делайте восстановление или эксперименты без копии и плана отката.

Как сделать backup через pgAdmin

1. Подключитесь к серверу PostgreSQL в pgAdmin.
2. Найдите базу 1C в разделе Databases.
3. Нажмите правой кнопкой по базе.
4. Выберите Backup.
5. В Filename укажите имя файла, например base_1c.backup.
6. В Format выберите Custom.
7. Включите подробный лог, если нужно сохранить диагностическую информацию.
8. Запустите Backup и дождитесь завершения без ошибок.

CLI-эквивалент:

pg_dump -h localhost -p 5432 -U postgres -Fc -d base_1c -f base_1c.backup

Custom-формат удобен тем, что восстанавливается через pg_restore и поддерживает гибкие параметры восстановления. Для больших баз это обычно практичнее, чем plain SQL.

Как проверить backup

Минимальная проверка — убедиться, что файл создан и pgAdmin не показал ошибок. Нормальная проверка — восстановить дамп в отдельную тестовую базу и проверить, что PostgreSQL видит таблицы, права и данные.

pg_restore -l base_1c.backup | head

Команда pg_restore -l показывает содержимое custom-дампа без восстановления. Это полезная быстрая диагностика, но она не заменяет тестовый restore.

Как восстановить в новую базу

Не восстанавливайте дамп поверх рабочей базы без отдельного плана. Безопасный сценарий — создать новую базу и восстановить туда.

1. Создайте новую базу, например base_1c_test_restore.
2. Нажмите по ней правой кнопкой.
3. Выберите Restore.
4. Выберите файл base_1c.backup.
5. Запустите Restore.
6. После восстановления проверьте таблицы, роли и подключение тестового клиента.

createdb -h localhost -p 5432 -U postgres base_1c_test_restore
pg_restore -h localhost -p 5432 -U postgres -d base_1c_test_restore base_1c.backup

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

После restore проверьте не только факт завершения операции. Нужны минимум четыре проверки: таблицы появились, данные читаются, роли и права не сломались, тестовое подключение 1C проходит в ожидаемом режиме.

SELECT table_schema, COUNT(*) AS tables_count
FROM information_schema.tables
WHERE table_type = 'BASE TABLE'
GROUP BY table_schema
ORDER BY table_schema;

Если restore выполнялся на другом сервере, особенно внимательно проверяйте роли. В дампе могут быть владельцы объектов, которых нет на новом сервере.

Частые ошибки

Конфликт ролей. На новом сервере нет пользователя, который владел объектами в старой базе. Решение зависит от регламента: создать нужные роли заранее или восстановить с параметрами, которые не переносят владельца.

Разные версии PostgreSQL. Перед переносом между major-версиями обязательно делайте тестовое восстановление. Не проверяйте такой сценарий впервые на рабочей базе.

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

Недостаточно прав. Пользователь pgAdmin должен иметь права на чтение объектов при backup и создание объектов при restore. Для полного восстановления часто нужен администратор PostgreSQL.

Проблемы с encoding и locale. Если база создается вручную перед restore, параметры кодировки и локали должны соответствовать ожиданиям приложения и исходной базы.

Чем отличается backup PostgreSQL от выгрузки 1C

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

Выгрузка 1C .dt создается средствами платформы 1C и относится к логике информационной базы. Ее часто используют для типовых административных операций внутри экосистемы 1C. Это не тот же самый формат, что backup PostgreSQL, и заменять один другим без понимания регламента нельзя.

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

Перед восстановлением: план отката

Для базы 1C нельзя начинать restore с фразы «попробуем». До восстановления должен быть ответ на пять вопросов: куда восстанавливаем, кто подключается после восстановления, как проверяем результат, что делаем при ошибке и где находится последняя рабочая копия.

• Восстановление идет в новую базу, а не поверх рабочей.
• Известна версия PostgreSQL на источнике и приемнике.
• Есть список ролей и владельцев объектов.
• Есть окно работ и понимание активных пользователей.
• Есть контрольные проверки после restore.
• Есть исходный backup, который не изменяется во время проверки.

Контрольные SQL-запросы для администратора

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

SELECT datname,
       pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database
WHERE datname = 'base_1c';

SELECT rolname
FROM pg_roles
ORDER BY rolname;

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

Если база переносится на другой сервер, список расширений и ролей особенно важен. Ошибка может проявиться не в момент restore, а позже, когда приложение обратится к объекту, владельцу или расширению, которого нет на новом сервере.

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

После тестового восстановления зафиксируйте результат в коротком журнале. Это дисциплинирует процесс и помогает не спорить по памяти, когда случится реальная авария.

Проверка	Что записать
Файл backup	имя, дата, размер
Restore	куда восстановили, время начала и окончания
Таблицы	количество таблиц по схемам
Роли	есть ли ошибки владельцев
Подключение 1C	результат тестового подключения
Итог	годится ли копия для восстановления

Если проверка не прошла, это не провал, а полезное обнаружение проблемы до аварии. Исправьте регламент и повторите restore на тестовой базе.

Когда стоит остановиться и позвать администратора

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

• База занимает десятки или сотни гигабайт.
• Нет свежей проверенной копии.
• Неизвестна версия PostgreSQL или конфигурация сервера.
• Нет доступа к ролям владельцев объектов.
• В базе есть активные пользователи 1C.
• Восстановление нужно выполнить на production-сервере.
• Нужно переносить базу между разными ОС или major-версиями PostgreSQL.

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

Как подготовить тестовый стенд

Идеальный вариант проверки — отдельный тестовый сервер или отдельная база на том же сервере, куда можно восстановить дамп без риска для пользователей. Название тестовой базы должно явно отличаться от рабочей: например, base_1c_restore_check, а не почти такое же имя, которое легко перепутать.

CREATE DATABASE base_1c_restore_check
  OWNER postgres
  ENCODING 'UTF8';

После восстановления проверьте, что никто из пользователей 1C не подключается к тестовой базе случайно. Для теста лучше использовать отдельный контур, отдельное имя базы и отдельные настройки подключения.

Как работать с активными подключениями

Для backup через pg_dump обычно не нужно останавливать PostgreSQL, но для административных работ вокруг 1C важно понимать активность пользователей. Если вы восстанавливаете базу, удаляете тестовую копию или меняете структуру, активные подключения могут мешать.

SELECT pid, usename, client_addr, state, backend_start, query
FROM pg_stat_activity
WHERE datname = 'base_1c'
ORDER BY backend_start;

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

-- Пример только для согласованного административного окна:
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'base_1c'
  AND pid <> pg_backend_pid();

Что сохранить вместе с backup

Один файл .backup лучше сопровождать короткой карточкой. В ней должны быть версия PostgreSQL, имя исходной базы, имя пользователя, дата создания, команда или способ создания backup, результат тестового restore и замечания по ролям.

Backup card:
source_db: base_1c
created_at: 2026-05-18 23:00
postgres_version: PostgreSQL 17.x
format: Custom
created_by: pgAdmin Backup
restore_test_db: base_1c_restore_check
restore_test_result: success
notes: роли проверены, активных ошибок restore нет

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

Что не стоит делать через pgAdmin с базой 1C

pgAdmin дает доступ к таблицам PostgreSQL, но это не значит, что данные 1C можно безопасно править вручную. Не редактируйте строки, не удаляйте таблицы, не меняйте структуру и не «чините» данные SQL-командами без четкой инструкции от специалиста по 1C и PostgreSQL. Для платформы 1C внутренняя структура базы — часть механизма работы информационной базы.

Допустимые действия для обычного административного сценария через pgAdmin — посмотреть размер, проверить подключения, сделать backup, восстановить в тестовую базу, посмотреть технический результат restore. Ручное исправление данных — отдельная зона риска.

Как встроить pgAdmin в нормальный регламент

pgAdmin можно оставить как визуальный инструмент контроля, но регламент должен быть шире. В нем стоит указать, когда создается backup, где хранится файл, кто проверяет restore, сколько копий хранится, кто имеет доступ к серверу и какие действия запрещены без согласования.

• Ежедневные копии создаются автоматически, а не вручную.
• pgAdmin используется для разовой проверки и восстановления на тестовый контур.
• Каждый backup имеет карточку с датой, версией PostgreSQL и результатом restore.
• Доступ к production-базе ограничен администраторами.
• Проверка restore выполняется регулярно, а не только после сбоя.
• Отдельно описано, когда нужна выгрузка средствами 1C.

Такой регламент не усложняет жизнь, а снижает количество решений в момент аварии. Когда есть готовая последовательность действий, администратор не тратит время на догадки и не делает опасные шаги под давлением.

Итоговый порядок действий

1. Собрать информацию о базе: имя, размер, версия PostgreSQL, роли, активные подключения.
2. Сделать backup через pgAdmin или командой pg_dump в Custom-формате.
3. Сохранить карточку backup.
4. Создать отдельную тестовую базу.
5. Восстановить дамп туда, не трогая рабочую базу.
6. Проверить таблицы, роли, расширения и тестовое подключение.
7. Зафиксировать результат restore.
8. Только после успешной проверки использовать копию как рабочий элемент плана восстановления.

Если любой из шагов непонятен, это повод остановиться и уточнить регламент. Для базы 1C на PostgreSQL осторожность важнее скорости.

Как сформулировать задачу для администратора

Если работу будет выполнять администратор, не отправляйте ему только фразу «сделать backup через pgAdmin». Лучше описать задачу конкретно: какая база, какой сервер, зачем нужна копия, куда восстановить для проверки, какое окно работ допустимо и какой результат нужен на выходе.

Задача:
Сделать backup базы base_1c на сервере pg-prod-01.
Формат: Custom.
Проверка: восстановить в base_1c_restore_check.
После restore проверить список таблиц, роли и тестовое подключение.
Рабочую базу не изменять.
Результат: файл backup + короткий отчет проверки.

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

Если после проверки остаются ошибки или предупреждения, их нужно разобрать до того, как backup попадет в список пригодных для аварийного восстановления и будет считаться рабочей страхующей копией.

Главное правило

Backup без тестового restore — это не проверенная резервная копия, а только файл с надеждой. Для базы 1C на PostgreSQL это особенно критично: перед любыми работами должен быть понятный путь назад, а восстановление нужно проверить на отдельной базе.

Что читать дальше

Связанные материалы из базы:

Бэкап и восстановление через pgAdmin — общий материал без 1C-специфики.

Бэкап PostgreSQL — pg_dump, pg_restore и автоматизация.

Пользователи и права PostgreSQL — роли и доступы.

Пароль PostgreSQL — смена и сброс пароля.

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

Можно ли заменить выгрузку 1C .dt дампом PostgreSQL?

Это разные механизмы. Дамп PostgreSQL копирует базу на уровне PostgreSQL. Выгрузка .dt создается средствами 1C. Что использовать, зависит от регламента, версии платформы, размера базы и сценария восстановления.

Можно ли делать backup через pgAdmin на рабочей базе?

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

Что важнее: создать файл или проверить restore?

Проверить restore. Файл backup может существовать, но быть бесполезным в реальной аварии из-за ролей, версии PostgreSQL, прав или ошибок восстановления.