Этап 1. Обследование, определение проблемных мест.

Итак, перед нами "мёртвая" файловая база. Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.

1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки".

Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). "Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.

2. Технологический журнал (ТЖ) 1С:Предприятие. Прекрасная возможность узнать, на каком месте "спотыкается" платформа, если она "зависает", "падает", или выдаёт загадочное сообщение "Ошибка формата потока" (причём сама ошибка может быть где угодно, в любом из файлов системных таблиц). Закрываем все сеансы 1С, чтобы они нам не мешались, и настраиваем запись ТЖ. Для этого идём в папку "bin", где лежат исполняемые файлы текущей плафтормы "1cv8*.exe", находим там вложенную папку "conf", и создаём там файл настройки записи ТЖ "logcfg.xml" примерно следующего содержания (исходный текст файла настройки есть в прикреплённом архиве):

Вместо "C:\1cv8logs" можно указать любую существующую папку, куда будут писаться логи, но лучше создать новую, пустую, чтобы не было проблем с записью логов.
(Подробнее про настройку ТЖ можно почитать, например, здесь: http://help1c.com/faq/view/464.html )
Далее, запускаем нашу проблемную базу в режиме конфигуратора, дожидаемся вывода окошка с ошибкой, или краха приложения, и сразу же идём изучать содержимое записанного лога (он будет в файле "1cv8_PID\МеткаДаты.log"). На следующие события и ошибки не обращаем внимания (их наличие является нормальным):

Exception=NetDataExchangeException,Descr='server_addr=any:port_num descr=Ошибка сетевого доступа к серверу...
Exception=DatabaseException8,Descr="Отсутствует файл базы данных 'ПутьКБазе/1Cv8tmp.1CD'"
Файл не обнаружен 'SprScndInfo'

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

1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS - таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA - схема (структура) БД
_USERSWORKHISTORY - история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS - содержит файлы с параметрами БД
FILES - содержит прочие системные (служебные) файлы
CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME - имя файла
CREATION/MODIFIED - дата создания/изменения
ATTRIBUTES - атрибуты
DATASIZE - размер файла
BINARYDATA - содержимое файла (двоичные данные)

В случае полного отсутствия какой-либо системной таблицы (не путать с наличием пустой таблицы) 1С при старте базы выдаст сообщение "База данных полностью разрушена".

Теперь мы понимаем, что записи в ТЖ типа

22:42.0169-1,DBV8DBEng,2,process=1cv8,Trans=0,Func=selectFileName,FileName=ibparams.inf
22:42.0170-3,DBV8DBEng,1,process=1cv8,Trans=0,Func=readFile,CatName=Params,FileName=ibparams.inf

означают чтение файла "ibparams.inf" из таблицы PARAMS.

Итак, анализируем файл лога. Например, если происходит "Ошибка формата потока", а в конце файла лога мы видим примерно следующее:

41:29.3460-1,DBV8DBEng,2,process=1cv8,Usr=Админ,Trans=0,Func=restoreObject,tableName=DBChanges
41:29.3900-439,DBV8DBEng,2,process=1cv8,Usr=Админ,Trans=0,Func=restoreObject,tableName=DBSchema
41:29.3901-443,SDBL,1,process=1cv8,Usr=Админ,Trans=0,Sdbl=GET NGENERATIONS
41:29.4060-19207,SESN,1,process=1cv8,Func=Attach,IB=ПутьКБазе,Nmb=2,ID=GUID
41:29.4061-19210,SESN,1,process=1cv8,Func=Finish,IB=ПутьКБазе,Nmb=2,ID=GUID

то можно заключить, что ошибка формата потока возникла при работе с содержимым таблицы "DBSchema", следовательно, содержимое этой таблицы нужно будет изучить поподробнее.
Ещё, если в наличии есть какой-нибудь старый бэкап, можно применить такой приём: записать ТЖ при его старте, и сравнить его с ТЖ при старте проблемной базы, чтобы понять, какими сообщениями об исключениях можно пренебречь, а также, какие этапы при старте проблемной базы проходят нормально, а до каких дело не доходит.
По окончании данной процедуры файл "logcfg.xml" можно переименовать, чтобы не засорять ненужными логами диск.

3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).

При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ".new" - их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.

4. Открываем базу при помощи компоненты 1CDLib. Информация из п. 3 в полной мере относится и к этому пункту, меняется только методика работы с файлом базы - посредством скриптов, использующих функции компоненты, с последующим анализом лог-файла и извлечённых данных.
Вашему вниманию представлены два скрипта (являющихся внешними обработками для режима управляемого приложения 1С:Предприятие 8.2, их можно запустить, например, из созданной пустой базы), с помощью которых можно произвести полуавтоматическое обследование проблемной базы:
Обработка "SaveAllTables.epf" позволяет сохранить данные всех таблиц в виде структуры вложенных папок и файлов в папке "Objects" (создаётся там же, где находится файл базы), и далее их можно изучать при помощи обычного файлового менеджера. Также, после сохранения всех таблиц, полезно изучить содержимое лога "logdb1cd.log" - туда выводятся сообщения об ошибках, которые произошли при извлечении таблиц. Если сообщения об ошибках в нём отсутствуют, то можно сказать, что физических ошибок в структуре хранения таблиц в файле базы нет, и проблемы уже либо в отсутствии каких-то таблиц, либо в их некорректном содержимом.
Обработка "ViewRecords.epf" позволяет просматривать записи таблиц и сохранять в файлы BLOB-данные (файлы создаются в папках с именами соответствующих таблиц), предназначена, в первую очередь, для полуавтоматического анализа содержимого системных таблиц (хотя с помощью неё можно просмотреть и другие таблицы). В случае ошибок при извлечении BLOB-данных, или при их распаковке (если содержимым BLOB-поля являются запакованные по алгоритму Deflate данные), выводятся соответствующие сообщения.

5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.

Загрузив нашу базу в систему restoration-base-1c8, мы можем исследовать список таблиц:

а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:

Просмотр записей таблиц, к сожалению, не реализован.

На этом наш список, а также сам этап обследования заканчивается. Аккуратно фиксируем и систематизируем всю собранную информацию, которую мы будем использовать далее, в процессе "лечения". Конкретные, наиболее типичные проблемные ситуации и способы их устранения будут рассмотрены в следующих разделах.

Файлы:
Обработки с поддержкой формата БД 8.3.8:
Обработки для обследования.zip

Этап 2. Лечим базу.

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

В общем виде, скрипт выглядит так:

    FileDB=Новый("AddIn.T1CDLib.DB1CD");
    FileDB.OpenLogFile(ИмяЛога);
    Состояние("Чтение структуры файла");
    FileDB.Open1CDFile(ИмяФайла);
    Состояние("Обработка файла");

    // здесь выполняем различные операции по лечению базы

    FileDB.CloseFile();
    FileDB.CloseLogFile();

    Состояние("");

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

    FileDB.FixMainStreamHeader();

2. Если есть таблицы с некорректным размером одного или нескольких объектов (описание, записи, BLOB, индексы):

    FileDB.FixTableHeaders("TABNAME",Истина,Истина,Истина,Истина);

В моей практике бывали случаи, что chdbfl.exe при некорректном размере объектов какой-то таблицы не мог восстановить добрую половину данных этой таблицы, а вот после исправления размеров "терял" буквально пару-тройку записей, и это безо всякого изменения содержимого объектов такой таблицы.
3. Если есть некорректные записи в корневом объекте RootEntry:
Вывести содержимое корневого объекта в лог-файл можно так:

    FileDB.PrintRootEntry();

Удалить некорректную запись по индексу (нумерация - с 1) из корневого объекта:

FileDB.DeleteTableFromRootEntry(ИндексЗаписи);

Если содержимое какой-то потерянной таблицы нашлось в недрах файла БД (например, при помощи поиска в Hex-редакторе), но ссылка на неё отсутствует в корневом объекте, можно её добавить:

    FileDB.AddTableToRootEntry(ИндексБлокаЗаголовкаОписанияТаблицы);

Внимание: после манипуляций с корневым объектом нужно переоткрыть БД:

    FileDB.CloseFile();
    FileDB.Open1CDFile(ИмяФайла);

4. Если в перечне таблиц базы есть таблицы с окончаниями "OG", это означает, что база рухнула в процессе реструктуризации или ТиИ. В данном случае может помочь такая операция (удаление окончания из имени таблиц):

    ArrayPres=FileDB.GetTablesArray(Ложь);
    TablesArray=РазвернутьЗначение(ArrayPres);

    Для TabInd=1 По TablesArray.Count() Цикл
        TableInfo=TablesArray[TabInd-1];
        TableName=TableInfo.Name;
        Если ВРег(Прав(TableName,2))="OG" Тогда
            МасПереимТаб.Добавить(TableName);
        КонецЕсли;

    КонецЦикла;

    Состояние("Переименование таблиц");

    Для каждого ТекТаб из МасПереимТаб Цикл
        FileDB.RenameTable(ТекТаб,Лев(ТекТаб,СтрДлина(ТекТаб)-2));
    КонецЦикла;

Однако, надо понимать, что содержимое таких таблиц может не соответствовать текущей конфигурации БД. В случае ТиИ вероятность несоответствия невысока, а вот при прерванном обновлении может быть по-разному, но, в любом случае, попробовать стоит.

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

    МасПереносТаб=Новый Массив;
    МасПереносТаб.Добавить("Reference19");
    МасПереносТаб.Добавить("Document192");

    ПапкаБазы="ПутьКПроблемнойБазе";
    ПапкаБазыПред="ПутьКБазеИзБэкапа";
    ИмяФайла=ПапкаБазы+"1Cv8.1CD";
    ИмяФайлаПред=ПапкаБазыПред+"1Cv8.1CD";

    FileDB=Новый("AddIn.T1CDLib.DB1CD");
    Состояние("Чтение структуры файла");
    FileDB.Open1CDFile(ИмяФайла);

    FileDB2=Новый("AddIn.T1CDLib.DB1CD2");
    FileDB2.Open1CDFile(ИмяФайлаПред);

    Состояние("Перенос таблиц");

    Для каждого ТекТаб из МасПереносТаб Цикл
        TableName=ТекТаб;
        ПапкаТаб=ПапкаБазыПред+TableName+"\";
        ВремКат=Новый Файл(ПапкаТаб);
        Если (НЕ ВремКат.Существует()) Тогда
            СоздатьКаталог(ПапкаТаб);
        КонецЕсли;

        FileNameDescription=ПапкаТаб+"Description";
        FileNameRecords=ПапкаТаб+"Records";
        FileNameBLOB=ПапкаТаб+"BLOB";
        FileNameIndexes=ПапкаТаб+"Indexes";

        FileDB2.SaveTableDataToFile(TableName,FileNameDescription,FileNameRecords,FileNameBLOB,FileNameIndexes);

        FileDB.LoadTableDataFromFile(TableName,FileNameDescription,FileNameRecords,FileNameBLOB,FileNameIndexes);
    КонецЦикла;

    FileDB.CloseFile();

    FileDB2.CloseFile();

Естественно, ссылки на элементы этих таблиц, созданные после бэкапа, будут "битыми", однако это всё же лучше, чем ничего.

Нумерация пунктов соответствует рекомендуемому порядку операций: т.е., сначала нужно исправить заголовки базы и таблиц, затем "разобраться" с корневым объектом, а затем уже приступать к манипуляциям с таблицами.

Также нужно помнить, что после всех проделанных манипуляций очеь полезно "шлифануть" базу утилитой chdbfl.exe с установленной галкой "Исправлять обнаруженные ошибки". Эта процедура перепакует данные всех таблиц, избавив их от мусора и удалённых записей, а также полностью перестроит индексы (а из-за "протухших" индексов база может по-прежнему не запускаться ни в одном из режимов, хотя сами данные могут быть уже восстановлены полностью).

В следующем разделе будут рассмотрены различные ситуации при наличии проблем в конфигурации (таблицах CONFIG и CONFIGSAVE).

Этап 3. Лечим конфигурацию.

Проблемы в таблицах конфигурации - одна из самых частых причин "падения" файловой БД. Последствия бывают как лёгкие (невозможность открытия определённых объектов в режиме Предприятия и/или Конфигуратора, обновления конфигурации), так и тяжёлые (невозможность открытия БД ни в режиме Предприятия, ни в режиме Конфигуратора).

Как мы помним, конфигурация хранится в двух таблицах: CONFIG - содержит файлы конфигурации БД, CONFIGSAVE - содержит файлы основной (сохранённой, редактируемой) конфигурации. Если на этапе обследования были выявлены проблемы в этих таблицах ("битые" записи/файлы, существенно меньшее количество файлов по сравнению с типовой конфигурацией или конфигурацией из последнего бэкапа (это не касается таблицы CONFIGSAVE, т.к. для неё уменьшение количества записей может являться нормальной ситуацией, означающей, что изменения из основной конфигурации перенесли в конфигурацию БД), наличие файлов с окончаниями ".new" в имени, и пр.), то пора приступать к их лечению (для этого прибегнем к помощи компоненты 1CDLib).

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

    FileDB=Новый("AddIn.T1CDLib.DB1CD");
    Состояние("Чтение структуры файла");
    FileDB.Open1CDFile(ИмяФайла);

    FileDB.OpenTable(0,"CONFIGSAVE");
    FieldFileName="FILENAME";

    Состояние("Перебор записей");
    Рез=FileDB.MoveFirstRecord(0);
    Пока Рез Цикл
        Если НЕ FileDB.IsRecordDeleted(0) Тогда
            FileDB.DeleteRecord(0);
        КонецЕсли;

        Рез=FileDB.MoveNextRecord(0);
    КонецЦикла;

    FileDB.CloseFile();

В результате основная конфигурация будет приведена к конфигурации БД.

Также можно попытаться перенести данные этой таблицы из последнего бэкапа, но только в том случае, если с момента бэкапа изменения не переносились в конфигурацию БД. Хочется отметить, что вероятность наличия такого бэкапа ничтожно мала, но, всё-таки, отметим эту возможность.

Теперь перейдём к таблице CONFIG. Если содержимое этой таблицы сильно повреждено, пути восстановления следующие:
1.Если есть бэкап, с момента которого изменения в конфигурацию БД не вносились, или вносились незначительные изменения, не повлёкшие за собой реструктуризацию БД, то самый простой путь - перенести данные этой таблицы из бэкапа:

    МасПереносТаб=Новый Массив;
    МасПереносТаб.Добавить("CONFIG");

    ПапкаБазы="ПутьКПроблемнойБазе";
    ПапкаБазыПред="ПутьКБазеИзБэкапа";
    ИмяФайла=ПапкаБазы+"1Cv8.1CD";
    ИмяФайлаПред=ПапкаБазыПред+"1Cv8.1CD";

    FileDB=Новый("AddIn.T1CDLib.DB1CD");
    Состояние("Чтение структуры файла");
    FileDB.Open1CDFile(ИмяФайла);

    FileDB2=Новый("AddIn.T1CDLib.DB1CD2");
    FileDB2.Open1CDFile(ИмяФайлаПред);

    Состояние("Перенос таблиц");

    Для каждого ТекТаб из МасПереносТаб Цикл
        TableName=ТекТаб;
        ПапкаТаб=ПапкаБазыПред+TableName+"\";
        ВремКат=Новый Файл(ПапкаТаб);
        Если (НЕ ВремКат.Существует()) Тогда
            СоздатьКаталог(ПапкаТаб);
        КонецЕсли;

        FileNameDescription=ПапкаТаб+"Description";
        FileNameRecords=ПапкаТаб+"Records";
        FileNameBLOB=ПапкаТаб+"BLOB";
        FileNameIndexes=ПапкаТаб+"Indexes";

        FileDB2.SaveTableDataToFile(TableName,FileNameDescription,FileNameRecords,FileNameBLOB,FileNameIndexes);

        FileDB.LoadTableDataFromFile(TableName,FileNameDescription,FileNameRecords,FileNameBLOB,FileNameIndexes);
    КонецЦикла;

    FileDB.CloseFile();

    FileDB2.CloseFile();

Естественно, конфигурация откатится на момент бэкапа, т.е., если за это время были внесены какие-то изменения в модули или макеты, то они будут утеряны.

2. Если конфигурация является полностью типовой, либо типовой с незначительными изменениями, не повлёкшими за собой реструктуризацию БД, и которыми можно пренебречь, то можно перенести конфигурацию из развёрнутой новой базы с типовой конфигурацией. Но здесь есть одна проблемка - как точно узнать нужный релиз, если база не открывается ни в одном режиме? Выход есть: открываем декомпрессированное содержимое файла "root" - там мы увидим GUID нужного нам файла (например, для БП 2.0 это "e0666db2-45d6-49b4-a200-061c6ba7d569"), далее открываем декомпрессированное содержимое этого файла - там, недалеко от начала файла, мы увидим название конфигурации, редакцию, название и копирайты разработчика, и, что самое важное, номер релиза.

Далее - дело техники, нужно найти нужный релиз типовой конфигурции и перенести содержимое таблицы CONFIG в нашу проблемную базу. (Извлечь содержимое таблицы CONFIG можно при помощи обработки ViewRecords.epf из 1. Обследование.)

3.Если база рухнула во время обновления конфигурации БД (характерным признаком этого является наличие файлов с окончаниями ".new" в имени), то может помочь вот такой скрипт (удаляет файлы с окончаниями ".new"):

    FileDB=Новый("AddIn.T1CDLib.DB1CD");
    Состояние("Чтение структуры файла");
    FileDB.Open1CDFile(ИмяФайла);

    FileDB.OpenTable(0,"CONFIG");
    FieldFileName="FILENAME";

    Состояние("Перебор записей");
    Рез=FileDB.MoveFirstRecord(0);
    Пока Рез Цикл
        Если НЕ FileDB.IsRecordDeleted(0) Тогда
            FileName=FileDB.ReadSimpleValue(0,FieldFileName);
            Если (Прав(FileName,4)=".new") Тогда
                FileDB.DeleteRecord(0);
            КонецЕсли;
        КонецЕсли;

        Рез=FileDB.MoveNextRecord(0);
    КонецЦикла;

    FileDB.CloseFile();

В данной статье приведены наиболее типичные скрипты. Путей восстановления конфигурации, конечно, намного больше, можно написать любой скрипт с использованием функций компоненты 1CDLib - переименование, удаление файлов по определённым условиям, перенос определённых файлов из другой базы, и т.д.
Например, рецепты восстановления клиент-серверных БД типа http://infostart.ru/public/138797/ (приведён рецепт лечения после неудачного динамического обновления) легко и непринуждённо можно применять и для файловых баз, причём безо всяких лазаний в дебрях файла БД с Hex-редакторами и прочими "напильниками".
Сравните, например, шаманские танцы с бубном в http://infostart.ru/public/154556/ , которые ещё и не всегда могут увенчаться успехом, и простенький скрипт

    FileDB.OpenTable(0,"CONFIG");
    FieldFileName="FILENAME";

    Состояние("Перебор записей");
    Рез=FileDB.MoveFirstRecord(0);
    Пока Рез Цикл
        Если НЕ FileDB.IsRecordDeleted(0) Тогда
            FileName=FileDB.ReadSimpleValue(0,FieldFileName);
            Если (FileName="сommit") ИЛИ (FileName="dbStruFinal") Тогда
                FileDB.DeleteRecord(0);
            КонецЕсли;
        КонецЕсли;

        Рез=FileDB.MoveNextRecord(0);
    КонецЦикла;

Надеюсь, что данная статья поможет Вам в восстановлении базы, но ещё лучше не забывать про ежедневные бэкапы.

всё, дамы и господа, можно комментировать и задавать вопросы