При администрировании баз данных "1С:Предприятие", работающих под управлением СУБД PostgreSQL, специалисты часто сталкиваются со сбоями при попытке восстановить базу из резервной копии формата .backup. Особенно остро эта проблема проявляется после обновления версии PostgreSQL или перехода на новые релизы утилит администрирования, таких как pgAdmin 4. В этой статье мы подробно разберем, почему происходят такие сбои, проанализируем стандартные сценарии резервного копирования и рассмотрим несколько надежных методов решения проблемы.
Для начала проанализируем стандартный пакетный файл (батник), который используется для автоматического создания резервных копий. Выясним структуру и параметры утилиты pg_dump, чтобы понимать, в каком формате создается архив:
@ECHO OFF
SET BackUpDir=D:\BackupPostgre\
echo %BackUpDir%
SET dmpfile=PartUchet-%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2%
IF "%TIME:~0,1%"==" " (SET dmpfile=%dmpfile%-0%TIME:~1,1%) ELSE (SET dmpfile=%dmpfile%-%TIME:~0,2%)
SET dmpfile=%dmpfile%-%TIME:~3,2%-%TIME:~6,2%.backup
SET dmpfile=%BackUpDir%%dmpfile%
SET PGPASSWORD=postgresuser
echo %dmpfile%
echo Copy has started
c:
cd C:\Program Files\PostgreSQL\10.5-24.1C\bin\
pg_dump --file=%dmpfile% --format=c --host=localhost --port=5432 --username=postgres PartUchet
echo Copy has ended
Обратим внимание на ключевой параметр в команде запуска: --format=c (или -F c). Этот флаг указывает утилите создавать резервную копию в специальном сжатом кастомном формате (custom). Данный формат является наиболее гибким для PostgreSQL, так как он позволяет выборочно восстанавливать объекты схемы, менять порядок загрузки данных и выполнять многопоточное восстановление. Однако для восстановления такого архива необходимо использовать исключительно специализированную утилиту pg_restore, а не простой импорт через SQL-запросы.
Многие администраторы пытаются выполнить восстановление стандартным способом через контекстное меню базы данных в веб-интерфейсе pgAdmin 4, но сталкиваются с неинформативными ошибками или зависанием процесса. Рассмотрим, почему это происходит:
pgAdmin III, написанного на C++, четвертая версия представляет собой веб-приложение на базе Python. Все процессы создания и восстановления бэкапов в ней выполняются в фоновом режиме через веб-службу. Это часто приводит к проблемам с обработкой больших объемов данных и потере контроля над процессом.pgAdmin 4 пытается использовать собственные встроенные версии утилит pg_dump и pg_restore. Если версия встроенных утилит отличается от версии установленной СУБД (например, у вас установлена модифицированная PostgreSQL 10.5-24.1C для "1С", а pgAdmin использует бинарники версии 11 или 12), процесс восстановления мгновенно завершается критической ошибкой из-за несовместимости структуры заголовков файлов.rphost удерживают постоянное соединение с ней. Пытаясь перезаписать таблицы, утилита восстановления натыкается на блокировки структуры и завершает работу аварийно.pgAdmin 4 (включая популярную версию 4.2) существовал неприятный баг: файлы резервных копий размером более нескольких десятков мегабайт не могли быть корректно загружены и обработаны графической оболочкой, что вызывало безмолвное падение процесса восстановления.Далее мы подробно разберем три наиболее эффективных способа решения этой проблемы, которые позволят вам успешно развернуть архив без отката на устаревшие программные продукты.
Чтобы избежать ошибок несовместимости версий бэкапа и утилиты восстановления, заставим pgAdmin 4 использовать "родные" бинарные файлы, поставляемые вместе с установленным сервером PostgreSQL. Пройдем по шагам этот процесс конфигурации:
pgAdmin 4 и перейдем в главное верхнее меню. Нажмем File и выберем пункт Preferences (Настройки).bin, где расположены исполняемые файлы нашей сборки PostgreSQL от компании "1С". По умолчанию путь выглядит следующим образом: C:\Program Files\PostgreSQL\10.5-24.1C\bin\. Убедимся, что именно в этой папке находятся файлы pg_dump.exe и pg_restore.exe.После выполнения этих действий графическая оболочка при запуске операции восстановления будет обращаться напрямую к правильной версии pg_restore.exe, что полностью нивелирует проблему конфликта версий заголовков архива.
Использование командной строки Windows (CMD) или консоли PowerShell позволяет полностью исключить из цепочки посредников в виде графической оболочки pgAdmin, веб-сервера приложения и Python-скриптов. Это гарантирует максимальную производительность и выводит подробный лог выполнения операции в реальном времени. Рассмотрим этот процесс подробно:
Win + R, введем cmd и нажмем Ctrl + Shift + Enter.
cd "C:\Program Files\PostgreSQL\10.5-24.1C\bin"
pg_restore напрямую. Нам потребуется передать набор обязательных параметров: хост, порт, имя пользователя СУБД, целевую базу данных и путь к архиву. Выполним следующую команду:
pg_restore.exe --host=localhost --port=5432 --username=postgres --dbname=PartUchet --verbose "D:\BackupPostgre\PartUchet-2019-02-20.backup"
postgres). Введем пароль (символы при вводе в целях безопасности отображаться не будут) и нажмем клавишу Enter.Разберем подробнее ключевые ключи запуска команды pg_restore:
--host=localhost (или -h) — адрес сервера СУБД, на котором разворачивается копия.--port=5432 (или -p) — сетевой порт, на котором запущен экземпляр PostgreSQL.--username=postgres (или -U) — имя суперпользователя базы данных для авторизации.--dbname=PartUchet (или -d) — имя целевой базы данных, в которую будут импортированы данные. База уже должна быть предварительно создана в СУБД (желательно пустой).--verbose (или -v) — режим подробного вывода логов. Позволяет в реальном времени видеть, какие таблицы, индексы, триггеры и внешние ключи восстанавливаются в данный момент, а также сразу локализовать возможные ошибки.Часто восстановление "поверх" существующей базы данных завершается неудачей из-за того, что сервер "1С" держит открытые сессии к таблицам. Разберем несколько подходов, помогающих временно изолировать базу данных на время проведения регламентных работ:
Откроем консоль администрирования серверов "1С:Предприятие". Перейдем к свойствам нашей информационной базы PartUchet. Установим флаг Блокировка начала новых сеансов включена, укажем понятные параметры начала и окончания блокировки, а также введем секретный код разрешения (например, 123). После этого завершим все активные сеансы пользователей в этой базе через дерево активных сеансов консоли "1С".
Если на сервере развернута только одна восстанавливаемая база данных и кратковременный простой не критичен для других пользователей, проще всего на время импорта полностью отключить службу сервера "1С:Предприятие". Для этого выполним в командной строке:
net stop "1C:Enterprise 8.3 Server Agent"
После завершения процесса восстановления базы запустим службу обратно:
net start "1C:Enterprise 8.3 Server Agent"
Мы можем принудительно завершить все активные транзакции и подключения к целевой базе данных непосредственно из среды PostgreSQL. Для этого откроем редактор SQL-запросов (Query Tool) в pgAdmin (подключившись к системной базе данных postgres) и выполним следующий скрипт:
SELECT pg_terminate_backend(pg_stat_activity.pid)
FROM pg_stat_activity
WHERE pg_stat_activity.datname = 'PartUchet'
AND pid <> pg_backend_pid();
Этот запрос находит все идентификаторы процессов (PID) операционной системы, которые держат открытые сессии к базе PartUchet, за исключением текущего сеанса администратора, и принудительно закрывает их, давая утилите pg_restore возможность монопольно захватить таблицы.
Самым безопасным методом при работе с "1С" является разворачивание бэкапа в абсолютно новую базу данных. Для этого выполним простые шаги:
PartUchet_New. При ее создании обязательно укажем владельца (Owner) — postgres (или того пользователя СУБД, под которым сервер "1С" подключается к базам данных) и кодировку UTF8..backup в эту вновь созданную базу PartUchet_New любым удобным способом (через отлаженную командную строку или pgAdmin с настроенными путями к бинарным файлам).PartUchet на PartUchet_New).PartUchet можно безболезненно удалить с диска.Таким образом, мы рассмотрели все причины сбоев и детально разобрали рабочие альтернативные варианты восстановления баз данных PostgreSQL. Настройка корректных путей к бинарным файлам СУБД в pgAdmin 4 и использование прямой утилиты командной строки pg_restore.exe гарантируют успешное проведение регламентных работ без необходимости отката на устаревшие версии программного обеспечения.