Ситуация, когда центральная информационная база («Ц») безвозвратно утеряна, а резервные копии оказались повреждены, является критической для любого бизнеса. Однако, если у вас сохранились рабочие периферийные узлы (базы «А» или «Б»), данные можно восстановить, «повысив» один из этих узлов до статуса центрального. В этой статье мы подробно разберем, как превратить подчиненную базу в полноценную головную и восстановить обмен данными в распределенной информационной базе (РИБ).
Прежде чем приступать к активным действиям, проанализируем состояние имеющихся данных. Если в вашей системе настроен Полный план обмена, то любая периферийная база содержит идентичный набор данных. Если же миграция была частичной (например, по организациям или складам), то для полного восстановления может потребоваться сбор данных из нескольких узлов (сначала из базы «А», затем дозагрузка недостающего из базы «Б»).
Важное правило: никогда не проводите эксперименты на «живой» периферийной базе. Первым делом создаем полную копию рабочей базы «А» и все дальнейшие манипуляции выполняем исключительно в этой копии.
Любая периферийная база «знает», что она подчинена центральной. Пока эта связь существует, многие административные действия в базе ограничены. Нам необходимо разорвать эту связь, чтобы база считала себя автономной. Для этого воспользуемся встроенным механизмом платформы 1С.
Запустим копию базы в режиме «1С:Предприятие» и создадим внешнюю обработку (или воспользуемся консолью кода). Нам нужно выполнить метод УстановитьГлавныйУзел, передав в него пустое значение (Неопределено). Разберем пример кода:
// Отключаем признак подчиненности базы
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этой строки база перестанет быть периферийной. Теперь мы можем редактировать конфигурацию (если она была закрыта для изменений) и управлять планами обмена без ограничений.
Теперь наша база автономна, но она все еще считает себя узлом «А». Для полноценного восстановления центральной базы нам нужно выполнить «рокировку» кодов в плане обмена. Проанализируем ситуацию в окне Планы обмена:
ЭтотУзел. Раньше у него был код «А». Нам нужно изменить его на код, который был у центральной базы (например, «Ц»).Важный нюанс: Не забудьте проверить Префикс информационной базы в настройках параметров учета. Новая центральная база должна иметь тот же префикс, который был у погибшей «Ц», чтобы нумерация новых документов продолжалась корректно и не возникало дублей с документами из узла «А».
После того как мы программно изменили структуру узлов, нам необходимо настроить транспорт сообщений. Разберем шаги по настройке синхронизации:
Рассмотрим ситуацию с базой «Б». Она все еще «думает», что ее центром является старая, удаленная база. Чтобы она начала обмениваться с нашей новой «Ц», в базе «Б» также нужно обновить настройки синхронизации, чтобы ее идентификатор GUID центрального узла совпал с новым GUID нашей восстановленной базы.
Одной из главных проблем при восстановлении РИБ является рассинхронизация номеров сообщений. Система хранит счетчики НомерПринятого и НомерОтправленного. Если они не совпадут, обмен заблокируется.
Проанализируем программный способ обнуления счетчиков в новой центральной базе для узла «Б»:
УзелОбъекта = ПланыОбмена.ПолнотекстовыйПоиск.НайтиПоКоду("Б").ПолучитьОбъект();
УзелОбъекта.НомерОтправленного = 0;
УзелОбъекта.НомерПринятого = 0;
УзелОбъекта.Записать();
Аналогичную процедуру обнуления счетчиков (в отношении новой центральной базы) нужно провести во всех живых периферийных узлах. После этого система начнет нумерацию пакетов с единицы, и коллизий не возникнет.
Чтобы быть уверенными, что все данные актуализированы, рекомендуется выполнить регистрацию изменений. В новой центральной базе выделите узел «Б», нажмите правой кнопкой мыши и выберите пункт Зарегистрировать все объекты (или воспользуйтесь обработкой «Регистрация изменений для обмена»). Это заставит систему при следующем обмене сравнить все данные и переслать в периферийную базу то, чего там может не хватать, или обновить существующие записи.
В процессе обсуждения выяснилось, что архивы на NAS могут не открываться стандартными средствами. Проанализируем дополнительные методы спасения данных из битых архивов:
7z.exe с ключом x -y -kb (keep broken files) может вытащить часть данных..bak файл. Попробуйте открыть файл простым блокнотом и посмотрите первые символы заголовка. Если там нет сигнатуры 7z, значит файл упакован другим методом.Резюме: Восстановление из РИБ — это трудоемкий, но надежный процесс. Главное — четко соблюдать последовательность: копирование -> отвязка от центра -> переименование узлов -> обнуление счетчиков -> перерегистрация данных. Это позволит вернуть систему в рабочее состояние даже при полной потере серверной инфраструктуры.