При администрировании баз данных под управлением СУБД PostgreSQL администраторы часто сталкиваются с проблемой восстановления резервных копий, созданных сторонними программами (например, PostgreSQL Backup). В результате работы таких утилит получается текстовый файл с расширением .sql. Попытка восстановить его через стандартный графический интерфейс pgAdmin (кнопка «Restore») часто заканчивается неудачей, так как программа ожидает бинарный формат файла (например, .backup или .tar). Еще хуже ситуация становится, когда база весит несколько гигабайт: pgAdmin просто намертво зависает.
В этой статье мы подробно разберем, как правильно и быстро восстановить базу данных из текстового дампа .sql, почему зависает графический интерфейс и какие настройки нужно выполнить на стороне PostgreSQL и сервера 1С:Предприятия, чтобы база успешно заработала.
Рассмотрим распространенную ошибку начинающих администраторов. Пытаясь восстановить файл .sql, пользователи часто открывают pgAdmin, выбирают базу данных, переходят в «Query Tool» (или «Create Script»), загружают туда текстовый файл резервной копии и нажимают на выполнение.
Если файл базы данных весит более нескольких десятков мегабайт, pgAdmin гарантированно зависнет (появится бесконечный индикатор загрузки). Выясним причину этого поведения:
Важное правило: Крупные файлы резервных копий в формате .sql категорически запрещено открывать и запускать через графические редакторы запросов pgAdmin. Для этого существуют специализированные консольные утилиты.
Для импорта текстовых дампов резервных копий любого объема следует использовать стандартную консольную утилиту psql, которая поставляется вместе с PostgreSQL. Она считывает файл построчно и сразу отправляет команды на сервер, минуя визуальный интерфейс.
Разберем по шагам процесс восстановления через командную строку:
cmd, в Linux — терминал).C:\Program Files\PostgreSQL\bin\) с помощью команды:
cd "C:\Program Files\PostgreSQL\15\bin"
psql -h localhost -p 5432 -U postgres -d имя_вашей_базы -f "C:\Backup\my_database.sql"
Проанализируем параметры этой команды подробнее:
-h localhost — адрес сервера, на котором развернута СУБД PostgreSQL.-p 5432 — порт подключения к СУБД (по умолчанию 5432, но может отличаться, если у вас установлено несколько версий PostgreSQL).-U postgres — имя пользователя с правами суперадминистратора СУБД.-d имя_вашей_базы — имя пустой базы данных, которую вы предварительно создали в PostgreSQL для восстановления.-f "путь_к_файлу.sql" — указывает утилите читать команды напрямую из файла. Это гораздо быстрее и стабильнее, чем использование стандартного перенаправления ввода оператором < (например, psql ... < backup.sql), так как оператор перенаправления задействует ресурсы командного интерпретатора ОС.Для оптимизации процесса восстановления и экономии ресурсов мы можем добавить дополнительные полезные аргументы:
-q (или --quiet) — отключает вывод логов о выполнении каждой команды (каждого INSERT или CREATE). Отрисовка миллионов строк в консоли сильно замедляет процесс импорта. С этим флагом консоль будет «молчать», пока база не восстановится.--set ON_ERROR_STOP=on — этот параметр мгновенно остановит импорт, если в процессе чтения файла возникнет критическая ошибка. В противном случае утилита продолжит засыпать базу последующими запросами, игнорируя сбой, что приведет к повреждению структуры данных.Если ваша база данных совсем небольшая (до 50-100 МБ), вы можете воспользоваться интерфейсом pgAdmin. Рассмотрим, как это сделать:
.sql.Текстовые дампы .sql, содержащие миллионы последовательных инструкций INSERT, восстанавливаются крайне медленно, поскольку СУБД вынуждена записывать изменения на диск и проверять транзакции для каждой строки. Чтобы радикально сократить время развертывания базы данных (особенно для крупных баз 1С), мы рекомендуем временно изменить параметры в файле конфигурации postgresql.conf перед началом импорта:
postgresql.conf, который находится в папке с данными СУБД (каталог data).fsync = off — отключает физическую синхронизацию данных с диском после каждой транзакции. Данные будут кэшироваться в оперативной памяти. Внимание: верните значение в on после импорта, иначе при аварийном отключении питания база данных будет разрушена!synchronous_commit = off — отключает ожидание записи транзакции на диск перед отправкой клиенту подтверждения.max_wal_size = 10GB (или выше) — уменьшит частоту записи контрольных точек (checkpoints), разгружая дисковую подсистему во время импорта.checkpoint_timeout = 30min — увеличивает интервал времени между контрольными точками.maintenance_work_mem (например, до 1 ГБ или 2 ГБ) — этот буфер напрямую используется для ускорения создания индексов и внешних ключей, которые генерируются в самом конце развертывания базы данных.psql.postgresql.conf в исходное состояние и повторно перезапустите службу.Если восстанавливаемая база предназначена для работы с платформой «1С:Предприятие», необходимо учитывать важные особенности администрирования:
Частая ошибка системных администраторов — неверная адресация портов после переноса СУБД на другой сервер или изменения конфигурации кластера 1С. Если после успешной заливки бэкапа платформа 1С выдает ошибку «Ошибка установки соединения» или «Ошибка при выполнении операции с информационной базой!», в первую очередь проверьте настройки подключения в консоли администрирования серверов 1С.
Убедитесь, что порт СУБД в свойствах информационной базы 1С соответствует реальному порту, на котором крутится служба PostgreSQL (по умолчанию 5432, но часто для 1С настраивают порты вроде 5433 или 5444).
Перед началом импорта резервной копии в уже существующую базу данных обязательно остановите службу сервера 1С:Предприятия (rphost) или временно заблокируйте регламентные задания и новые соединения в консоли администрирования 1С. Если этого не сделать, фоновые задания 1С начнут обращаться к таблицам в процессе восстановления, вызовут блокировку таблиц и прервут процесс развертывания бэкапа.
При создании новой пустой базы в PostgreSQL перед заливкой файла .sql критически важно правильно указать параметры локали. Для корректной работы русскоязычных баз 1С при создании базы используйте следующие настройки:
UTF-8ru_RU.utf8 (для Linux-серверов) или Russian_Russia.1251 / Russian_Russia.utf8 (для Windows).Если кодировки созданной базы СУБД не совпадут с кодировками оригинальной конфигурации, из которой делался дамп, платформа 1С откажется запускаться и выдаст ошибку несовместимости при попытке входа пользователей.
Хотя утилиты автоматизации бэкапов часто сохраняют резервные копии в текстовом формате .sql, для администрирования PostgreSQL этот формат является наименее эффективным. Рекомендуется использовать сжатый кастомный формат PostgreSQL (Custom, флаг -Fc при выгрузке через pg_dump).
Преимущества кастомного формата резервных копий (файлы с расширением .backup):
pg_restore и ключа -j. Например, команда:
pg_restore -j 4 -h localhost -U postgres -d имя_базы "C:\Backup\my_base.backup"
запустит процесс восстановления в 4 параллельных потока, задействовав сразу 4 ядра процессора, что ускорит операцию в несколько раз по сравнению с последовательным выполнением файла .sql.