← На главную

При работе с СУБД PostgreSQL часто возникает ситуация, когда резервная копия базы данных представляется в виде обычного текстового файла с расширением .sql. Попытка восстановить такой файл через стандартную функцию Restore в графических клиентах (например, в pgAdmin3) может завершиться ошибкой, так как программа по умолчанию ожидает архив в специальном или tar-формате. Разберем причинно-следственные связи этой проблемы и проанализируем доступные варианты решения.

Выясним причину ошибки при стандартном восстановлении

Файл резервной копии с расширением .sql — это обычный текстовый скрипт, состоящий из SQL-команд (таких как CREATE TABLE, INSERT INTO или COPY). При выборе пункта меню Restore в графических интерфейсах pgAdmin вызывается служебная утилита pg_restore. Эта утилита предназначена исключительно для работы с сжатыми архивами в кастомном (custom) или tar-формате и категорически не поддерживают исполнение открытого текстового кода SQL.

Для корректной загрузки текстовых дампов необходимо либо выполнить этот файл как SQL-скрипт в среде управления СУБД, либо воспользоваться консольной утилитой psql.

Способ 1. Восстановление через командную строку psql (Рекомендуемый вариант)

Рассмотрим наилучший и самый надежный способ разворачивания .sql дампов, который подходит для баз данных любого объема, включая информационные базы 1С.

1. Подготовим целевую базу данных на сервере PostgreSQL. База должна быть создана с кодировкой UTF8 и корректной локализацией.
2. Запустим командную строку или терминал на сервере и выполним команду чтения файла скрипта утилитой psql: psql -h localhost -U postgres -d name_of_db -f C:\backups\backup_file.sql
3. Если восстановление выполняется в среде ОС Windows, предварительно зададим кодировку сеанса, чтобы избежать искажения кириллицы в данных 1С:
   Скопировать код

   
   set PGCLIENTENCODING=UTF8
   psql -h localhost -U postgres -d name_of_db -f C:\backups\backup_file.sql
   

Для гарантированной остановки процесса при возникновении критических ошибок добавим в команду специальный ключ: --set ON_ERROR_STOP=on.

Способ 2. Выполнение скрипта через графический редактор pgAdmin

Проанализируем порядок действий при работе через графический клиент pgAdmin, если дамп имеет небольшой размер (до нескольких сотен мегабайт):

1. Подключимся к серверу PostgreSQL и раскроем дерево объектов до нужной базы данных.
2. Нажмем правой кнопкой мыши по целевой базе и выберем пункт Query Tool (в pgAdmin 3 — пункт Create Script).
3. В окне редактора скриптов откроем наш файл с расширением .sql через иконку открытия файла.
4. Нажмем кнопку выполнения (Execute / F5) для запуска текстовых команд.

Важное замечание: Не рекомендуется открывать текстовые дампы размером в несколько гигабайт в окне редактора запросов pgAdmin. Это приведет к критическому переполнению оперативной памяти и зависанию приложения.

Способ 3. Выбор типа файла в мастере Restore pgAdmin 4

Если используется pgAdmin 4, то восстановить файл .sql через пункт меню Restore все же возможно, если правильно указать фильтр файлов:

1. Нажмем правой кнопкой мыши по базе данных и выберем Restore....
2. В окне выбора файла изменим тип отображаемых файлов с «Custom or tar» на «All files» или «sql».
3. Укажем путь к файлу дампа и запустим процесс восстановления.

Особенности восстановления баз данных 1С

При работе с информационными базами 1С учтем следующие важные нюансы:

• Состояние целевой базы: Текстовый дамп следует загружать только в заново созданную пустую базу данных. В противном случае возникнут конфликты первичных ключей и существующих структур таблиц.
• Отключение служб: Перед процедурой восстановления отключим базу от кластера серверов 1С (остановим службу ragent) или завершим все активные фоновые сеансы.
• Права и роли: Если дамп содержит инструкции смены владельцев объектов (ALTER OWNER) или назначения прав (GRANT), в целевой СУБД заранее создадим соответствующие роли или выполним загрузку от имени суперпользователя postgres.

Рекомендации по выбору формата резервных копий

Для повседневной работы с базами 1С на базе PostgreSQL рекомендуется отказаться от выгрузки в простой текстовый формат .sql и использовать кастомный формат резервных копий. При формировании бэкапа утилитой pg_dump указывают ключ -F c, что создает архив формата .backup. Такие архивы легко восстанавливаются штатным средством pg_restore, позволяют выполнять параллельное многопоточное восстановление (ключ -j) и существенно экономят дисковое пространство.