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

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

Архитектурные причины возникновения сбоя

Платформа 1С:Предприятие 8.3 использует комбинированную схему хранения учетных записей на уровне СУБД:

1. Таблица v8users — содержит отдельные строки для каждого пользователя с их идентификаторами UUID, именами, настройками и хэшами паролей.
2. Бинарный файл users.usr, упакованный в виде BLOB-данных в служебной таблице Params (или PARAMS).

Проанализируем механику сбоя: если информационная база отключается от кластера некорректно (например, когда базу в СУБД переводят в состояние OFFLINE при активных сеансах и кэше процессов rphost / rmngr), нарушается синхронизация между физическими таблицами и серверным кэшем srvinfo. При первом входе платформа видит поврежденный слепок пользователей. В момент добавления новой учетной записи платформа целиком перезаписывает файл users.usr в таблице Params на основе текущего пустого состояния, затирая все прежние записи в v8users.

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

Самое быстрое и действенное решение при возникновении серверного кэш-глюка — удалить регистрацию базы из кластера 1С и добавить её заново. Разберем правильный порядок действий:

1. Открываем консоль Администрирование серверов 1С:Предприятия.
2. Находим проблемную информационную базу, открываем её свойства и включаем блокировку начала сеансов и регламентных заданий.
3. Завершаем все активные соединения в ветке «Сеансы».
4. Удаляем информационную базу из списка кластера. Критически важно: при запросе подтверждения выбираем вариант «Оставить базу данных без изменений», чтобы не удалить саму базу в СУБД.
5. Создаем в кластере новую информационную базу с подключением к существующей базе на сервере СУБД (указываем то же имя базы данных и параметры подключения).
6. Запускаем Конфигуратор и проверяем список пользователей.

Способ 2. Очистка кэша кластера серверов 1С

Если простая перерегистрация не помогла, причиной может являться поврежденный кэш сеансовых контекстов в каталоге данных кластера. Выполним полную очистку кэша сервера:

1. Останавливаем службу агента сервера (1C:Enterprise 8.3 Server Agent или ragent).
2. Переходим в рабочий каталог кластера серверов (по умолчанию: C:\Program Files\1cv8\srvinfo или /home/usr1cv8/.1cv8/1C/1cv8/ в Linux).
3. Находим каталоги сеансовых данных и временных файлов вида snccntx*, а также кэш внутри папки соответствующего кластера (каталог с GUID базы) и очищаем их.
4. Запускаем службу сервера 1С.

Способ 3. Прямое восстановление таблиц пользователей из резервной копии СУБД

Если в результате перезаписи бинарного контейнера записи пользователей были физически стерты из v8users, восстановим только метаданные пользователей из свежего SQL-дампа без необходимости полного разворачивания всей базы данных. Разберем пример SQL-запроса для Microsoft SQL Server:

-- Очищаем поврежденную таблицу пользователей в рабочей базе
DELETE FROM [РабочаяБаза].[dbo].[v8users];

-- Копируем записи пользователей из резервной копии
INSERT INTO [РабочаяБаза].[dbo].[v8users]
SELECT * FROM [КопияБазы].[dbo].[v8users];

-- Синхронизируем бинарный контейнер users.usr в таблице Params
UPDATE [РабочаяБаза].[dbo].[Params]
SET [BinaryData] = (
    SELECT [BinaryData] 
    FROM [КопияБазы].[dbo].[Params] 
    WHERE [FileName] = 'users.usr'
)
WHERE [FileName] = 'users.usr';

После выполнения запроса перезапускаем рабочий процесс кластера 1С и проверяем доступ под учетными записями.

Способ 4. Сброс контейнера пользователей при невозможности восстановления

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

1. В СУБД выполняем команду удаления служебного файла пользователей: DELETE FROM [РабочаяБаза].[dbo].[Params] WHERE [FileName] = 'users.usr';
2. Очищаем таблицу v8users: DELETE FROM [РабочаяБаза].[dbo].[v8users];
3. Заходим в базу через Конфигуратор (вход будет выполнен без запроса пароля под полными правами).
4. Создаем учетную запись администратора заново. После сохранения создастся новая корректная структура users.usr, и последующие пользователи будут сохраняться в штатном режиме.
5. Если конфигурация построена на базе БСП (Библиотека стандартных подсистем, например, УТ 11, ERP, КА), заходим в режиме предприятия под созданным администратором и в разделе Администрирование -> Настройки пользователей и прав привязываем учетную запись к соответствующему элементу Справочник.Пользователи.

Регламент корректного переноса базы между кластерами

Чтобы избежать подобных сбоев в будущем, сисадминам и программистам следует строго соблюдать последовательность отключения базы:

1. Запретить установку новых соединений в кластере через консоль управления или обработку блокировки соединений.
2. Штатно завершить все фоновые задания и сеансы пользователей.
3. Удалить регистрацию базы из кластера 1С средствами консоли 1С (опция «Оставить базу данных без изменений»).
4. Не переводить базу данных в СУБД в состояние OFFLINE принудительно, пока служба сервера 1С удерживает активные соединения с сервером баз данных.
5. Подключить существующую базу данных в целевом кластере 1С.