Ошибка установки или изменения административных параметров информационной базы ibparams inf

в таблице params содержатся параметры информационной базы, в том числе «Национальные настройки информационной базы», возможно таблица побилась
в BinaryData есть строка filename:locale.inf, в которой должно быть указано {«ru_RU»,0,0,»»,-1,»»,»»,»»,»»,1}
если значение побилось, то исправь с помощью Hex или замени всю таблицу params из бекапа или демобазы (если конфигурация демобазы точно такая же)

1

«Национальные настройки информационной базы (ИБ) не соответствуют настройкам базы данных» — распространенная ошибка в работе систем 1С.

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

«Ошибка установки или изменения национальных настроек информационной базы»

по причине:

«Порядок сортировки не поддерживается базой данных».

Для базы-приемника проверяем настройки: «Администрирование -> Региональные установки информационной базы».

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

Как видим, настройки отличаются.

Решение

Для базы-приемника выставляем настройки, аналогичные базе-источнику, которая загружена из dt-файла.

Бывает так, что невозможно сменить региональные настройки базы-приемника.

Тогда приходится менять настройки в отдельной среде (другой сервер или другая СУБД, другая версия платформы 1С), в которой загружаем базу из dt-файла, меняем настройки на нужные, после чего выгружаем базу в dt-файл и загружаем в базу-приемник.

Бывает так, что невозможно загрузить dt-файл в файловую базу.

В таком случае придется либо уточнить региональные настройки у человека, который предоставил dt-файл, либо перебирать настройки -устанавливать и пробовать загрузку и т.д. до успеха.

Причина может быть в банальной смене свойства «Язык — Русский» в панели управления Windows -> «Язык и региональные стандарты».

Эта настройка может поменяться на, к примеру, «Русский — Молдова» (раскладка клавиатуры), и этого будет достаточно для того, чтобы произошел подобный сбой.

Как вариант профилактики:

— указать русский в качестве языка по умолчанию при установке платформы;

— запускать с ключом /Lru;

— прописать параметр запуска SystemLanguage=RU в конфигурационном файле conf.cfg;

— через конфигуратор настроить региональные установки информационной базы.

9 г. назад

Этап 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);
    КонецЦикла;

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