Ко мне обратился заказчик с проблемой: куда-то пропали данные в файловой базе 1С. Увидел я картину примерно следующего содержания: все файлы с данными (DBF) оказались разбитыми на три файла: оригинальный файл (содержит лишь заголовочную часть таблицы DBF) и два переименованных файла вида 1SACCS.DBF.id-{CKHJSOLIFCZ...KHEBS-20.10.2014 23@30@148834034}-email-deskripshen1c@gmail.com-ver-4.0.0.0.cbf.

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

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

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

Переносим кусок с данными из зашифрованного файла в пустой, удаляя перед этим в пустом файле символ окончания данных.

Далее берем DBF-редактор и пролистываем полученный файл, ищем "кракозябры".

Как правило, файл будет иметь два повреждения. Осуществляем перенос данных из архивного файла в текущий. Ищем искомую уникальную строку в архивном файле. Для журнала это будет IDDOC, для справочника - ID, для табличной части документа - IDDOC и LINENO и т. п.

В процессе вставки множества записей следим за тем, чтобы данные находились в том же порядке. Если это не так - проще удалить эти записи, чем выискивать уникальности (порядок записей может быть другим), а затем вставить на втором этапе.

Так поступаем с каждой таблицей содержащей данные. Если данные не изменялись - переписываем архивную копию.

Приступаем ко второму этапу, т.к. часть данных мы не восстановили, да и проконтролировать перенос лишний раз не помешает. Загружаем архивную и текущую базы в формат SQL. В провесе загрузки текущей базы появляются сообщения вида:

Документ.ПоступлениеМатериалов Обнаружены дублирующиеся номера строк документа. Произведена перенумерация строк. '0000023'
Документ.ПриходныйОрдер Обнаружены дублирующиеся номера строк документа. Произведена перенумерация строк. '00000019'
Документ.ТребованиеНакладная Обнаружены дублирующиеся номера строк документа. Произведена перенумерация строк. '0000020'

Это говорит о том, что в процессе вставки были захвачены ошибочные записи.

Переносим удаленные данные по документам.

Далее выполняем запрос:

INSERT INTO base.._1SJOURN
SELECT JB.IDJOURNAL, JB.IDDOC, JB.IDDOCDEF, JB.APPCODE, JB.DATE_TIME_IDDOC, JB.DNPREFIX
       , JB.DOCNO, JB.CLOSED, JB.ISMARK, JB.ACTCNT, JB.VERSTAMP 
FROM _1SJOURN JB
LEFT JOIN base.._1SJOURN J on JB.IDDOC = J.IDDOC
WHERE J.IDDOC IS NULL

Проделываем то же самое для операций и табличных частей документов:

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

Далее наводим порядок там, где строки были перенумерованы. Выбираем несоответствия и изменяем данные так, чтобы они соответствовали данным в архивной базе (update, delete).

В процессе тестирования и исправления обнаружилась неприятность. Файл конфигурации оказался поврежденным. Диагностика ничего не выявила. Пришлось разобрать и собрать 1cv7.md Gcomp-ом. Это помогло, к тому же файл сократился в размерах с 28 до 17 мегабайт. Но радость была недолгой, в процессе тестирования создалась куча сотрудников. Оказывается, данные в шапке реализации не соответствовали структуре таблицы. На картинке показаны отличия текущей (вверху) и архивной базы.

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

Для контроля посматриваем в сами данные. Например, на картинке показано, какой именно фрагмент занимает ссылка на справочник определенного вида.

Вот как должны располагаться поля и как они раположены в текущей конфигурации.

Сортируем их так, как это сделал шифровальщик или программист-вредитель.

Далее удаляем таблицу, сохраняем конфигурацию и запускаем 1С, чтобы она создала таблицу и снова переносим фрагмент с данными, исправляем данные о количестве записей.

И смотрим на результат.

На этом работа закончена. Проводим финальное тестирование и исправление. Пострадавшие свежие данные исправит заказчик по первичке (беглый осмотр выявил лишь несколько "кракозябр" в некритичных данных).

Потеря данных после обработки составит менее 1%, а при наличии архивных копий стремится к нулю.

Не забывайте делать бэкапы и ставить сложные пароли, если уж выставили сервер с базой в интернет. Да прибудет с вами сила.