Ситуация, когда важные данные были удалены из базы 1С (например, программным вызовом Объект.Удалить()), а актуального бэкапа под рукой не оказалось, является критической для любого администратора или разработчика. Однако в файловом варианте работы (формат .1cd) физическое удаление данных происходит не мгновенно. Рассмотрим механизмы хранения информации в файловой базе и разберем по шагам методы, которые позволяют вернуть «утерянные» записи до того, как будет выполнено сжатие таблиц в рамках тестирования и исправления (ТиИ).
Проанализируем, что происходит внутри файла .1cd в момент удаления объекта. База данных 1С организована в виде страниц. Когда мы удаляем строку из таблицы, платформа не затирает эти байты нулями и не сдвигает остальные данные. Вместо этого в техническом заголовке записи устанавливается специальный флаг — маркер удаления. После этого запись перестает учитываться в индексах и не отображается в пользовательском интерфейсе или при обычных запросах к базе.
Важно понимать, что место, занимаемое удаленной записью, помечается как свободное для повторного использования. Если после удаления в ту же таблицу будут добавлены новые данные, система может записать их поверх старых. Критически важно: если вы обнаружили пропажу данных, немедленно прекратите любую работу в базе и сделайте копию файла .1cd. Любая транзакция на добавление может окончательно уничтожить шансы на восстановление.
Рассмотрим наиболее популярный способ, который обсуждался экспертами. Для низкоуровневого чтения файловых баз традиционно используется утилита Tool_1CD. Она позволяет просматривать содержимое таблиц, включая те записи, которые помечены как удаленные.
Однако современные версии платформы (начиная с 8.3.8) используют обновленный формат .1cd с увеличенным размером страниц, который старые версии Tool_1CD не поддерживают. Чтобы обойти это ограничение, разберем алгоритм действий:
1Cv8.1CD в отдельную папку.cnvdbfl.exe. Она находится в папке bin установленной платформы. Нам нужно конвертировать базу в формат, совместимый с версией 8.2.14, так как именно его понимает большинство инструментов для восстановления.
cnvdbfl.exe -c -f -8.2.14 "C:\MyBase\1Cv8.1CD"
cnvdbfl.exe -c -f -8.3 "C:\MyBase\1Cv8.1CD"
Выясним, как действовать, если автоматизированные утилиты не справляются или структура таблиц частично повреждена. В этом случае мы можем прибегнуть к прямому анализу файла через HEX-редактор. Каждая запись в 1С имеет уникальный идентификатор (GUID). Если нам известен GUID удаленного объекта (его можно извлечь из Журнала регистрации или найти по ссылкам в других связанных объектах), мы можем найти его в теле файла.
Проанализируем ситуацию: в HEX-редакторе поиск выполняется по последовательности байтов GUID. Найдя нужное вхождение, мы увидим соседние поля записи. Поскольку структура полей в 1С фиксирована для каждой таблицы, мы сможем вручную считать текстовые строки, числа и даты, принадлежавшие объекту. Этот метод особенно эффективен, когда нужно восстановить текстовую информацию, например, содержание свойств или комментарии менеджеров.
Рассмотрим еще один неочевидный, но эффективный метод. Если в базе был включен детальный Журнал регистрации, то даже после физического удаления объекта из БД, информация о нем сохраняется в файлах журнала (.lgp или .lgf). В журнале фиксируются события «Изменение» и «Удаление».
Часто в данных событиях сохраняется снимок состояния объекта. Мы можем программно прочитать Журнал регистрации, извлечь значения реквизитов удаленного объекта и создать его заново программно с тем же самым GUID, чтобы не нарушить ссылочную целостность базы. Пример кода для чтения журнала:
ВыбранныеСобытия = Новый Массив;
ВыбранныеСобытия.Добавить(Метаданные.СобытияЖурналаРегистрации.ДанныеИзменение);
ВыбранныеСобытия.Добавить(Метаданные.СобытияЖурналаРегистрации.ДанныеУдаление);
Фильтр = Новый Структура;
Фильтр.Вставить("Событие", ВыбранныеСобытия);
Фильтр.Вставить("ДатаНачала", НачалоДня(ТекущаяДата() - 86400)); // За последний день
ТаблицаСобытий = Новый ТаблицаЗначений;
ВыгрузитьЖурналРегистрации(ТаблицаСобытий, Фильтр, "Дата, Данные, ДанныеПредставление, Комментарий");
Посмотрим на более современные подходы. Сообщество разработчиков создало несколько библиотек на языке Python для парсинга файлов .1cd напрямую. Эти инструменты работают быстрее старых утилит и позволяют программно перебирать страницы данных, игнорируя фильтрацию по признаку удаления.
С помощью таких скриптов можно реализовать «грязное чтение» (dirty read):
Это позволяет избежать рискованной конвертации базы через cnvdbfl и работать с копией файла в режиме «только чтение».
Подводя итог, можно сказать, что восстановление без бэкапа — это всегда лотерея. Успех зависит от того, насколько интенсивно использовалась база после удаления. Главные правила спасения данных:
.1cd.Tool_1CD, используйте поиск по GUID в HEX-редакторе или данные из Журнала регистрации.Помните, что процедура конвертации базы для использования старых утилит может сама по себе привести к перестроению страниц и затиранию помеченных на удаление данных, поэтому всегда сохраняйте «чистый» оригинал файла до полного завершения спасательных работ.