Почему после восстановления базы 1С в PostgreSQL не подходит логин и пароль и как это исправить?

← На главную

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

В чем причина ошибки авторизации после восстановления

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

В этот момент происходит следующее:

Первичная инициализация кластером 1С: Сервер 1С самостоятельно создает в СУБД структуру служебных таблиц (в частности, v8users, params, paramsng, config) и записывает туда базовые технические данные пустой конфигурации.
Конфликт при наложении дампа: Текстовый дамп, сформированный утилитой pg_dump, содержит команды создания таблиц и вставки записей (INSERT). При попытке вставить строки в уже существующие таблицы СУБД возвращает ошибки дублирования первичных ключей (например, по индексам таблиц params или v8users).
Пропуск ошибок в psql: При стандартном вызове команды через перенаправление ввода утилита psql продолжает выполнение скрипта, пропуская конфликтные строки. В результате системные таблицы пользователей и параметры авторизации (файл users.usr в таблице params) либо остаются от пустой базы, либо оказываются поврежденными и рассинхронизированными.

Правильный алгоритм восстановления базы из резервной копии

Чтобы избежать логических конфликтов структуры, базу данных необходимо создавать исключительно средствами самой СУБД, заливать в нее резервную копию и только после этого подключать информационную базу к серверу 1С. Разберем этот процесс по шагам.

Шаг 1. Создание пустой базы в PostgreSQL

Создадим чистую базу данных через графическую утилиту pgAdmin или с помощью SQL-запроса, указав владельца, кодировку UTF8 и шаблон:


CREATE DATABASE basa
    WITH OWNER = postgres
    ENCODING = 'UTF8'
    LC_COLLATE = 'ru_RU.UTF-8'
    LC_CTYPE = 'ru_RU.UTF-8'
    TEMPLATE = template0;

Шаг 2. Разворачивание резервной копии

Развернем SQL-дамп в созданную пустую базу. Если используется текстовый формат дампа, рекомендуется запускать psql с параметром ON_ERROR_STOP=1, чтобы сразу обнаружить возможные ошибки синтаксиса или доступа:


"C:\Program Files\PostgreSQL\9.6.5-4.1C\bin\psql.exe" -h localhost -U postgres -v ON_ERROR_STOP=1 basa < "D:\Postgre_backup\BD\UT201802060110.sql"

Если бэкап создается в кастомном бинарном формате (параметр -Fc утилиты pg_dump), восстановление выполняется через pg_restore с ключами очистки существующих объектов:


pg_restore -h localhost -U postgres -d basa --clean --if-exists "D:\Postgre_backup\BD\backup.dump"

Шаг 3. Регистрация информационной базы в кластере 1С

Откроем консоль администрирования серверов 1С:Предприятия (или добавим базу в список запуска) и создадим информационную базу со следующими параметрами:

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

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

Экстренный сброс пользователей, если база уже повреждена

Если дамп уже был загружен поверх инициализированной базы, а доступа к оригиналу бэкапа нет, можно восстановить доступ к Конфигуратору путем временного переименования таблиц аутентификации на уровне PostgreSQL:

Остановим рабочие процессы или заблокируем сеансы к базе.
Выполним в СУБД скрипт переименования служебных объектов:


ALTER TABLE v8users RENAME TO v8users_old;
UPDATE params SET filename = 'users.usr_old' WHERE filename = 'users.usr';

Запустим базу в режиме Конфигуратор. Так как список учетных записей пуст, 1С запустится без запроса логина и пароля.
Не закрывая Конфигуратор, выполним обратный скрипт в PostgreSQL для восстановления исходных таблиц:


DROP TABLE v8users;
ALTER TABLE v8users_old RENAME TO v8users;
UPDATE params SET filename = 'users.usr' WHERE filename = 'users.usr_old';

В открытом Конфигураторе перейдем в меню Администрирование -> Пользователи, откроем нужного администратора и переустановим пароль, после чего сохраним изменения.

Обязательные действия после разворачивания базы

После завершения восстановления дампа в PostgreSQL обязательно выполним команду сбора статистики:

VACUUM ANALYZE;

Дампы утилиты pg_dump не переносят статистику распределения данных. Без выполнения ANALYZE планировщик запросов PostgreSQL будет строить неоптимальные планы, что приведет к существенному падению производительности при работе пользователей в 1С.