Как восстановить базу данных 1С из бекапа PostgreSQL без ошибок типов данных и конфликтов объектов?

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

Проблема отсутствующего типа данных mvarchar и расширения mchar

Одной из самых распространенных ошибок при восстановлении является сообщение: ERROR: type "public.mvarchar" does not exist. Давайте выясним причину этого явления. Сборки PostgreSQL, оптимизированные для работы с 1С, используют специальные типы данных mchar и mvarchar для корректной сортировки и обработки строк. Эти типы не являются стандартными для оригинального PostgreSQL.

Почему возникает ошибка? Чаще всего это происходит из-за использования ключа -n public (ограничение только схемой public) при создании бэкапа. В этом случае определения типов и расширений, которые могут лежать вне этой схемы или требовать глобальной инициализации, не попадают в дамп должным образом.

Разберем, как исправить ситуацию перед началом восстановления. Если вы восстанавливаете базу в новую, пустую БД через pgAdmin или psql, выполните следующий SQL-запрос от имени суперпользователя:

CREATE EXTENSION IF NOT EXISTS mchar;

Только после того, как расширение mchar будет подключено к вашей базе, СУБД сможет распознать типы public.mvarchar и успешно создать таблицы, использующие эти типы (например, системные таблицы 1С _acc34 и другие).

Конфликты объектов при создании базы через консоль 1С

Рассмотрим ситуацию, когда при восстановлении возникают ошибки типа already exists для функций (например, binrowver) или индексов. Проанализируем типичный сценарий: администратор создает базу в консоли серверов 1С, а затем пытается «накатить» в неё дамп PostgreSQL.

В чем заключается ошибка подхода? Когда сервер 1С создает базу данных, он не просто создает пустую оболочку. Он сразу инициализирует её структуру: создает служебные таблицы (Config, Params, DBSchema) и набор функций (binrowver, v8_mchar_equal и другие). Когда запускается pg_restore, он пытается создать эти же объекты из файла бэкапа, что и приводит к конфликту.

Посмотрим на правильный алгоритм действий:

1. Создаем абсолютно пустую базу данных средствами PostgreSQL (через createdb или pgAdmin). Важно назначить правильного владельца (Owner), под которым 1С будет подключаться к базе.
2. Выполняем восстановление дампа в эту пустую базу.
3. Только после завершения восстановления регистрируем эту базу в консоли сервера 1С. В этом случае 1С увидит, что структура уже есть, и не будет пытаться пересоздать функции.

Если же база уже создана сервером 1С и вам нужно восстановить данные именно в неё, используйте ключи --clean и --if-exists. Это заставит pg_restore сначала попытаться удалить существующие объекты перед их созданием из бэкапа:

"C:\Program Files\PostgreSQL\10.3-2.1C\bin\pg_restore.exe" --host=localhost --port=5432 --username=postgres --dbname=base_name --clean --if-exists --verbose "d:\bkp1c\your_backup.bek"

Ошибка «Запись не найдена в менеджере имен базы данных»

Если после завершения восстановления (даже если pg_restore выдал WARNING с кодом 1) при попытке войти в 1С вы получаете сообщение «Запись не найдена в менеджере имен базы данных», это означает, что база восстановлена не полностью.

Проанализируем ситуацию: из-за ошибок в начале процесса (например, отсутствие того самого типа mvarchar) pg_restore пропустил создание некоторых таблиц. В 1С есть критически важные таблицы метаданных. Если данные в таблице DBSchema не соответствуют реальному набору таблиц в SQL или если таблица Config пуста, менеджер имен 1С не сможет сопоставить объекты метаданных (справочники, документы) с физическими таблицами.

Важно понимать: код завершения 1 при восстановлении базы 1С — это практически всегда нерабочая база. Добивайтесь восстановления с кодом 0. Обращайте внимание на ERROR: column "_fld1015" does not exist. Это признак того, что индексы пытаются создаться для таблиц, создание которых ранее завершилось ошибкой.

Влияние локали и операционной системы

Рассмотрим нюанс с версиями Windows. При использовании PostgreSQL 10.3 на разных версиях ОС (например, Windows Server 2012 vs 2016) могут отличаться системные библиотеки ICU и настройки локали. Если база была выгружена с одной локалью, а восстанавливается в базу с другой, это может привести к непредсказуемым ошибкам в индексах.

При инициализации кластера PostgreSQL для 1С всегда следует явно указывать русскую локаль. Если вы создаете новый экземпляр сервера (инстанс), используйте команду:

initdb.exe -D "C:\PostgreSQL\data" --locale=ru_RU.UTF-8

Это обеспечит корректную сортировку (Collation), которую ожидает платформа 1С.

Рекомендации по автоматизации бэкапа

Проанализируем строку запуска pg_dump, которую использовал автор темы. Использование ключа -n public является рискованным для 1С. Разберем более надежный вариант батника для создания бэкапа, который минимизирует потерю системных типов:

@echo off
set PGPASSWORD=ваш_пароль
set DATETIME=%date:~6,4%-%date:~3,2%-%date:~0,2%_%time:~0,2%-%time:~3,2%-%time:~6,2%
set DATETIME=%DATETIME: =0%

"C:\Program Files\PostgreSQL\10.3-2.1C\bin\pg_dump.exe" --format=c --blobs --host=localhost --port=5432 --username=postgres --file="d:\bkp1c\base_%DATETIME%.dump" base_name 2>"d:\bkp1c\backup_log_%DATETIME%.log"

if %ERRORLEVEL% neq 0 (
    echo Ошибка при создании бэкапа! Проверьте лог.
)

Основные выводы нашего анализа:

1. Всегда проверяйте наличие расширения mchar перед восстановлением.
2. Старайтесь восстанавливать базу в «чистую» СУБД, а не в уже созданную сервером 1С структуру.
3. Избегайте ключа -n public, чтобы не терять определения специфических типов данных 1С.
4. Если восстановление прошло с ошибками, база считается невалидной, даже если в неё можно зайти в режиме конфигуратора.

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