Восстановление базы 1С после форматирования
рис. 1
Как выяснилось, резервная копия данной базы у клиента более, чем годовой давности.
Первый этап в решении подобных задач — это создание поблочной копии оригинального накопителя (или как принято писать со времен, когда носителями были только накопители на гибких и жестких магнитных дисках — посекторной). При вычитывании обнаруживается нестабильная скорость чтения, что говорит о серьезном износе NAND памяти (многократное чтение NAND контроллером страниц NAND памяти и коррекция ошибок за счет избыточности кодов коррекции ошибок (ECC) весьма ресурсоемкая операции, что в итоге влияет на скорость чтения). При наличии непрочитанных участков необходимо заполнить их паттерном, который в дальнейшем нам поможет идентифицировать файлы, которые не были вычитаны целиком.
Далее приступаем к анализу. Необходимо установить, какая файловая система и в каких границах ранее была на USB flash. То есть, необходимо выполнить поиск регулярных выражений, характерных для различных метаданных файловых систем, но прежде, чем его начать, проверим простой вариант, который подразумевает, что границы разделов прежние. Для этого установим текущие параметры файловой системы.
Открываем LBA 0 (0×0 в файле образе) и проверяем там наличие таблицы разделов, либо наличие Boot сектора файловой системы.
рис. 2
В нашем случае видим по смещению 0×1C2 типа раздела 0×0B, означающее, что на данный момент на USB накопителе есть раздел FAT32, который начинается с 0×80 сектора (DWORD по смещению 0×1C6), длиной 0×003C2000 секторов (DWORD по смещению 0×1CA). Переходим к boot сектору описанного раздела в сектор 0×80 (в файле образа байтах 0×10000)
рис. 3
Необходимо вычислить начальную точку отсчета, то есть место нулевого кластера, относительно которого рассчитывается пространство, а также определить размер кластера.
Для этого нам нужны следующие параметры, описанные в boot секторе (будут указаны в виде смещения от начала сектора): размер сектора по смещению 0×0B — 0×200 (512 байт), количество секторов в кластере по смещению 0×0D — 0×08, размер кластера получается посредством перемножения размера сектора на количество секторов в кластере 0×08*0×0200=0×1000 (4096 байт), количество зарезервированных секторов до первой копии таблиц FAT — по смещению 0×0E=0×01FE (510 секторов), количество копий FAT — по смещению 0×10=0×02, размер одной копии FAT — по смещению 0×24=00000F01 (3841 секторов). Используя полученные параметры, произведем расчет положения начала области данных: 0×10000+0×01FE*200+0×00000F01×2*200=0×410000 (8320 сектор). Небольшой подвох от создателей FAT32 заключается в том, что на данный момент мы рассчитали начало области данных для раздела FAT32, но оно не является нулевой точкой отсчета, так как первые две записи в FAT таблице зарезервированы и не используются по прямому назначению, в связи с чем нулевой точкой принимается начало области данных за минусом 2 кластеров. В данном случае это будет 0×410000–0×1000*2=0×40E000 (8318 сектор).
Выполним проверку на предмет отсутствия записей в таблице размещения файлов и проведем процедуру сравнения копий на предмет разночтений.
Рис. 4
Сравнение копий FAT показало, что разночтения отсутствуют. Анализ содержимого одной из копий FAT показал, что согласно таблицы на разделе заполнен только один кластер.
Далее необходимо оценить корневой каталог на предмет удаленных записей. Позиция первого кластера корневого каталога указывается в boot сектор по смещению 0×2C=0×00000002. Для второго кластера в FAT указано FF FF FF 0F, что означает конец цепочки, то есть корневой каталог состоит из одного кластера.
рис. 5
По адресу, рассчитанному выше, мы видим корневую директорию (корневой каталог), в которой содержится единственная 32-байтная запись. По смещению 0×0B мы видим значение 0×08, которое указывает на тип записи — метка тома. Тот факт, что таблицы размещения файлов заполнены нулями, и в корневом каталоге нет намека на какие-либо иные записи, говорит о том, что данный раздел был отформатирован.
Для проверки предположения о том, что раздел не пересоздавался и все параметры файловой системы корректны, необходимо произвести поиск регулярного выражения 0×2E 0×2E 0×20 0×20 0×20 0×20 0×20 0×20 со смещением внутри сектора 0×20 (данное выражение признак начала директории FAT32).
рис. 6
При нахождении регулярного выражения необходимо удостовериться, что это действительно директория, по иным признакам, так как в некоторых случаях возможно совпадение и найденное регулярное выражение не является элементом директории. Согласно информации на рис. 6, можно сказать, что данная директория начиналась с 3 кластера (номер текущего кластера директории DWORD содержится в WORD по смещению 0×1A (младшая часть) и WORD по смещению 0×14 (старшая часть)) и описывалась в корневом каталоге, так как по смещениям 0×3A и 0×34 содержатся нули (начальный кластер родительской директории). Проверим, соответствует ли номер кластера данной директории нулевой точке отсчета файловой системы, созданной после форматирования. Для этого номер кластера директории умножим на размер текущего кластера и прибавим к нулевой точке 0×03*0×1000+0×40E000=0×411000. Как видим, расчетный адрес соответствует фактическому нахождению. Установить имя данной директории возможно только в случае, если ранее корневой каталог состоял более, чем из одного кластера, и ссылка на данную директорию была не в первом кластере, так как содержимое первого кластера при форматировании было полностью уничтожено вместе с таблицами размещения файлов.
Далее продолжим поиск регулярного выражения 0×2E 0×2E 0×20 0×20 0×20 0×20 0×20 0×20 со смещением внутри сектора 0×20.
рис. 7
Повторяем все проверки: 0×04*0×1000+0×40E000=0×412000. Снова видим соответствие положения директории параметрам текущей файловой системы. Но, кроме этого, видим, что есть номер кластера родительской директории 0×03, что говорит о том, что данная директория была вложенной, и взглянув на рис. 6, можно установить имя директории, которая изображена на рис. 7. Итак, согласно рис. 6, по смещению 0×4B видим значение 0×10 — это означает, что данная запись указывает на директорию, а по смещениям 0×5A и 0×54 число 0×00000004 — указатель на 4-й кластер. По смещению 0×40 — имя директории «BIN». Именно таким образом устанавливается взаимосвязь директорий в поврежденном FAT разделе. После выполнения еще некоторого числа проверок директорий в разных участках образа можно сделать окончательный вывод о том, что на данном накопителе состоялось форматирование в границах предшествующей файловой системы и параметры вновь созданной файловой системы унаследованы от предыдущей, то есть дальнейшие аналитические операции нужно проводить в рамках раздела, описанного в таблице разделов с учетом параметров текущей файловой системы.
Зная, что 1С база, состоящая из DBF файлов, должна содержать файл конфигурации 1CV7.MD, выполним поиск последовательности 0×31 0×43 0×56 0×37 0×20 0×20 0×20 0×20 0×4D 0×44. Для того, чтобы уменьшить количество заведомо ложных результатов, поиск лучше выполнять в рамках 32-байтных блоков с нулевым смещением.
Рис. 8
Таким образом, находим все директории, содержащие в себе указатель на файл 1CV7.MD. В нашем случае обнаружилась только одна такая директория, что позволяет предполагать, что мы нашли первый кластер необходимой директории. Далее следует анализ положения родительских директорий, вплоть до корневой директории. Каждая найденная директория прописывается в таблицу FAT (сначала как директория из одного кластера, посредством записи FF FF FF 0F для соответствующего элемента таблицы). Также в корневой директории прописывается ссылка на дочерний объект.
На текущем этапе мы выполним копирование найденных файлов с предположением об их непрерывности, так как обе копии FAT не содержат информации о фрагментации (напомним, что они были безвозвратно уничтожены системным администратором в результате необдуманного форматирования USB flash). После копирования директории 1С базы анализируем количество файлов. Учитывая, что фрагмент директории был размером в один кластер, то извлекли мы не более 126 файлов, что явно намного меньше, чем должно быть в директории с DBF и CDX файлами, относящимися к 1С базе. Примерно такой же результат выдадут программы автоматического восстановления, о чем свидетельствует результат, полученный системным администратором посредством использования R-Studio.
Среди извлеченных файлов есть 1CV7.MD (файл конфигурации) и 1СV7.DD (файл словаря данных). После выполнения проверки целостности создадим у себя на диске временную папку, куда поместим 1CV7.MD. Укажем данный путь при добавлении новой базы и откроем конфигуратор, посредством которого создадим чистую базу на основании этой конфигурации. Сравним сформированный DD файл с восстановленным, если описания и количество справочников идентичны, то никаких дополнительных действий не требуется, и, имея полный список файлов, можно приступать к поиску остальных фрагментов директории 1С базы. Для этого необходимо осуществить поиск последовательностей из ASCII кодов символов, используемых в именах недостающих DBF файлов. По мере обнаружения фрагментов директории дописывать в таблицу размещения файлов продолжение цепочки. После каждой операции дополнения цепочки директории выполнять копирование файлов и анализировать, насколько сократилась количество недостающих DBF файлов, и вновь формировать последовательность ASCII кодов символов для поиска следующего фрагмента.
рис. 9
Также необходимо помнить, что при записи цепочки фрагментов директории в таблицу размещения файлов, необходимо анализировать фрагменты, чтобы стыковались LFN записи. В случае только коротких записей цепочку можно писать с любым порядком фрагментов.
В данном случае выполнив поиск 5 последовательностей удалось найти все остальные фрагменты директории с базой 1С.
После того, как построена полная цепочка фрагментов директории, выполняем повторное копирование уже всех файлов 1С базы с предположением об их непрерывности. Пользовательская информация содержится в DBF файлах, поэтому необходимо проверить их целостность.
Основной метод контроля целостности DBF файла — это проверка информации, содержащейся в служебном заголовке и соответствует ли содержимое файла описанию в заголовке.
рис. 10
Первоначально проводится оценка заголовка: проверяется его длина, указанная по смещению 0×08, приводит ли указанное в нем смещение на конечный маркер 0×0D. Записи полей базы, начиная со смещения 0×20, описываются 32-байтовыми записями, в которых по смещению 0×00 следует имя поля, по смещению 0×0B тип поля, по смещению 0×10 — размер поля. Сумма размеров полей +1 (один дополнительный байт для каждой записи в базе является статусом записи в DBF) должна равняться содержимому по смещению 0×0A (размер одной записи в базе). На рисунке DBF файлы мы видим следующие длины полей: 0×09+0×10+0×10+0×10+0×10+0×10+0×01=0×5A.
Проведем проверку корректности размера файла. Для этого выполняем умножение количества записей, которое указано в заголовке по смещению 0×04 на размер одной записи в базе по смещению 0×0A с последующим сложением с содержимым по смещению 0×08.
0×00000003*0×005A+0xE1=0×01EF. По полученному смещению должен находиться маркер окончания файла 0×1A.
Для контроля целостности содержимого полей можно использовать визуальный метод.
рис. 11
В таком вариант просмотра нужно пролистывать содержимое записей от начала и до конца. В случае если заполнение однородное, в каждом поле располагаются типы данных, характерные для описанного в заголовке и инородного содержимого нет, то по завершении просмотра DBF файла можно сделать вывод о корректности его содержимого.
При обнаружении содержимого, не соответствующего описанию поля в заголовке базы, необходимо установить точное место, с которого начинаются некорректные данные.
Рис. 12
Исходя из описания полей в заголовке и содержимого конкретного DBF файла, можно формировать предположительные ASCII последовательности, которые должны находиться по заданным смещениями в недостающих фрагментах. При отсутствии однотипных баз на одном из накопителей (в том числе и файловых копий одной и той же базы) такой метод позволит относительно быстро найти все недостающие фрагменты в образе накопителя. Отдельно отметим, что возникнут дополнительные сложности в стыковке фрагментов, если размер записи в DBF файле маленький или кратен 16. При наличии иных однотипных баз задача будет многократно усложнена (это утверждение справедливо на всех этапах работ, начиная с поиска фрагментов нужной директории).
Необходимо проверить целостность каждого DBF файла, коих в одной 1С базе несколько сотен. По прохождении всех проверок и сборов фрагментов файлов последует финальная проверка в конфигураторе 1С Предприятия.
рис. 13
В идеальном варианте по результатам тестирования должны пройти успешно все пункты, отмеченные в чекбоксах. Если обнаруживаются ошибки по первым двум пунктам, то необходимо проанализировать лог ошибок в конфигураторе и выяснить, в каких DBF файлах присутствуют инородные данные, которые не были обнаружены при проверках. Если обнаруживаются ошибки при проверке логической целостности, то опять же необходимо анализировать лог ошибок, чтобы выяснить, заключается ли проблема базы в качестве ее сбора, либо в ошибках, допущенных разработчиками конфигурации 1С.
Обратим внимание на тот факт, что если бы данная USB flash не была отформатирована, то после ее вычитки процедура восстановления данных была бы значительно более простой, что сильно бы отразилось на стоимости и сроке выполнения работ в меньшую сторону. В заключение, хотелось бы предостеречь всех пользователей и обслуживающий персонал от необдуманных действий в аварийных ситуациях, которые многократно усугубляют проблему, а также пожелать почаще выполнять операции резервного копирования.
Комментарии (5)
Areso
26 апреля 2017 в 13:58 (комментарий был изменён)
0↑
↓
Как выяснилось, резервная копия данной базы у клиента более, чем годовой давности.
ССЗБ?26 апреля 2017 в 15:07
0↑
↓
Если бы все правильно делали бэкапы и их проверяли — индустрии восстановления данных не существовало бы, во всяком случае в том виде, и с тем распространением которая она получила сейчас)26 апреля 2017 в 15:25
0↑
↓
За это и заплатил.
26 апреля 2017 в 16:04
0↑
↓
Единственная копия работала с флэшки. Казалось бы, что могло пойти не так?
mikkisse
26 апреля 2017 в 16:27
0↑
↓
Спасибо! Как всегда очень интересно.
