Как восстановить данные в головной базе 1С из подчиненного узла РИБ при наличии старого бэкапа

Ситуация, когда головная база распределенной информационной системы (РИБ) выходит из строя вместе с оборудованием, — один из самых серьезных вызовов для технического специалиста. Если у вас в распоряжении есть бэкап головной базы трехдневной давности и при этом стабильно работающая подчиненная (дочерняя) база, содержащая актуальные данные, проблему можно решить без потери информации. Рассмотрим подробно, как «дотянуть» недостающие данные за три дня из подчиненного узла в восстановленную из бэкапа головную базу.

Метод 1: Ручная регистрация изменений и синхронизация пакетов

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

Шаг 1: Восстановление и подготовка метаданных

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

1. Выгрузим файл конфигурации .cf из подчиненной базы.
2. В восстановленной головной базе перейдем в «Конфигурация» — «Сравнить, объединить с конфигурацией из файла» и загрузим выгруженный файл. Это необходимо, чтобы «подтянуть» структуру до актуального состояния.

Шаг 2: Корректировка номеров сообщений

Это критически важный этап. В восстановленном бэкапе счетчики принятых и отправленных сообщений «откатились» на три дня назад. Подчиненная база уже ожидает пакет с номером, например, 150, а головная после восстановления предложит ей пакет №140. Подчиненная база проигнорирует такой пакет. Нам нужно синхронизировать номера вручную:

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

Шаг 3: Регистрация данных в подчиненной базе

Теперь нам нужно заставить подчиненную базу «вспомнить», какие данные она должна передать. Для этого воспользуемся обработкой «Регистрация изменений для обмена»:

1. В подчиненной базе выберем узел головной базы.
2. Выберем все необходимые типы документов и справочников, созданных или измененных за последние 3 дня.
3. Нажмем «Зарегистрировать». Теперь эти объекты стоят в очереди на выгрузку.

Шаг 4: Выполнение обмена

Запустим стандартную процедуру обмена. Данные из подчиненной базы поступят в головную, заполнив «пробел» в три дня.

Метод 2: Повышение статуса подчиненного узла до главного

Если головная база повреждена настолько сильно, что восстановление из бэкапа нецелесообразно, или если объем данных за пропущенный период огромен, мы можем превратить актуальную подчиненную базу в полноценную автономную базу, а затем сделать её новой «головой».

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

// Сброс связи с главным узлом
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);

После выполнения этой команды база перестает считать себя подчиненной. Теперь она становится основной. Далее алгоритм действий следующий:

1. В этой новой «главной» базе создаем новый узел для будущей подчиненной базы.
2. Создаем начальный образ для нового подчиненного узла.
3. Настраиваем каналы связи заново.

Внимание: Этот метод радикален, так как требует перенастройки обменов на всех остальных точках, если их было больше двух.

Метод 3: Использование универсальной выгрузки XML

Если регистрация изменений кажется слишком сложной, можно воспользоваться обработкой УниверсальныйОбменДаннымиXML. Разберем особенности этого подхода:

1. В подчиненной базе выгружаем данные за нужный период, используя правила обмена (если они есть) или просто выгружая объекты по ссылке.
2. Важный нюанс: при загрузке в головную базу обязательно должен быть включен режим «Искать объект по внутреннему идентификатору» (GUID).

Рассмотрим, почему это важно. Если поиск будет идти по коду или наименованию, 1С может создать дубли справочников, что приведет к хаосу в учете. Штатный механизм РИБ всегда использует GUID, поэтому при использовании XML-выгрузки мы должны имитировать это поведение.

Важные завершающие действия

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

1. Пересчет итогов: Процедура обмена просто записывает наборы записей регистров. Чтобы отчеты показывали корректные остатки, выполним «Управление итогами» и установим их на текущую дату.
2. Восстановление последовательностей: Особенно актуально для 1С:Управление торговлей 10.3. Проведение документов через обмен может не восстановить границу последовательности партионного учета. Проанализируем состояние партий и запустим групповое перепроведение за восстановленные 3 дня.
3. Проверка удалений: Помним, что в старом бэкапе объекты, которые вы удалили за последние 3 дня, снова «живы». Если в подчиненной базе записи об их удалении уже были очищены, они могут не удалиться автоматически. Рекомендуем провести визуальный аудит последних операций.

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