Люди в погоне за комфортными для них условиями работы зачастую не задумываются о безопасности и сохранности своих данных и рано или поздно сталкиваются с вопросами их утраты. Рассмотрим обращение клиента с USB Flash 2Gb Transcend. Со слов клиента, в один из дней при установке накопителя в USB порт компьютера было предложено ее отформатировать. Как утверждает клиент, он отказался от этого и обратился за помощью к системному администратору. Системный администратор, обнаружив, что при подключении USB накопителя «подвешивается» компьютер, не придумал ничего лучшего, чем согласиться с предложением операционной системы отформатировать его (никогда этого не делайте!). Далее системный администратор использовал популярную программу автоматического восстановления R-Studio. Результат ее работы в виде безымянных папок был скопирован клиенту на другой накопитель. При просмотре результата клиент обнаружил, что около четверти файлов не могут быть открыты и, что хуже всего, 1С Бухгалтерия 7.7 отказывалась запускаться с восстановленной базой, ссылаясь на отсутствие файлов.
рис. 1
Как выяснилось, резервная копия данной базы у клиента более, чем годовой давности.
Первый этап в решении подобных задач – это создание поблочной копии оригинального накопителя (или как принято писать со времен, когда носителями были только накопители на гибких и жестких магнитных дисках – посекторной). При вычитывании обнаруживается нестабильная скорость чтения, что говорит о серьезном износе NAND памяти (многократное чтение NAND контроллером страниц NAND памяти и коррекция ошибок за счет избыточности кодов коррекции ошибок (ECC) весьма ресурсоемкая операции, что в итоге влияет на скорость чтения). При наличии непрочитанных участков необходимо заполнить их паттерном, который в дальнейшем нам поможет идентифицировать файлы, которые не были вычитаны целиком.
Далее приступаем к анализу. Необходимо установить, какая файловая система и в каких границах ранее была на USB flash. То есть, необходимо выполнить поиск регулярных выражений, характерных для различных метаданных файловых систем, но прежде, чем его начать, проверим простой вариант, который подразумевает, что границы разделов прежние. Для этого установим текущие параметры файловой системы.
Открываем LBA 0 (0x0 в файле образе) и проверяем там наличие таблицы разделов, либо наличие Boot сектора файловой системы.
рис. 2
В нашем случае видим по смещению 0x1C2 типа раздела 0x0B, означающее, что на данный момент на USB накопителе есть раздел FAT32, который начинается с 0x80 сектора (DWORD по смещению 0x1C6), длиной 0x003C2000 секторов (DWORD по смещению 0x1CA). Переходим к boot сектору описанного раздела в сектор 0x80 (в файле образа байтах 0x10000)
рис. 3
Необходимо вычислить начальную точку отсчета, то есть место нулевого кластера, относительно которого рассчитывается пространство, а также определить размер кластера.
Для этого нам нужны следующие параметры, описанные в boot секторе (будут указаны в виде смещения от начала сектора): размер сектора по смещению 0x0B — 0x200 (512 байт), количество секторов в кластере по смещению 0x0D — 0x08, размер кластера получается посредством перемножения размера сектора на количество секторов в кластере 0x08*0x0200=0x1000 (4096 байт), количество зарезервированных секторов до первой копии таблиц FAT — по смещению 0x0E=0x01FE (510 секторов), количество копий FAT — по смещению 0x10=0x02, размер одной копии FAT — по смещению 0x24=00000F01 (3841 секторов). Используя полученные параметры, произведем расчет положения начала области данных: 0x10000+0x01FE*200+0x00000F01*2*200=0x410000 (8320 сектор). Небольшой подвох от создателей FAT32 заключается в том, что на данный момент мы рассчитали начало области данных для раздела FAT32, но оно не является нулевой точкой отсчета, так как первые две записи в FAT таблице зарезервированы и не используются по прямому назначению, в связи с чем нулевой точкой принимается начало области данных за минусом 2 кластеров. В данном случае это будет 0x410000-0x1000*2=0x40E000 (8318 сектор).
Выполним проверку на предмет отсутствия записей в таблице размещения файлов и проведем процедуру сравнения копий на предмет разночтений.
Рис. 4
Сравнение копий FAT показало, что разночтения отсутствуют. Анализ содержимого одной из копий FAT показал, что согласно таблицы на разделе заполнен только один кластер.
Далее необходимо оценить корневой каталог на предмет удаленных записей. Позиция первого кластера корневого каталога указывается в boot сектор по смещению 0x2C=0x00000002. Для второго кластера в FAT указано FF FF FF 0F, что означает конец цепочки, то есть корневой каталог состоит из одного кластера.
рис. 5
По адресу, рассчитанному выше, мы видим корневую директорию (корневой каталог), в которой содержится единственная 32-байтная запись. По смещению 0x0B мы видим значение 0x08, которое указывает на тип записи – метка тома. Тот факт, что таблицы размещения файлов заполнены нулями, и в корневом каталоге нет намека на какие-либо иные записи, говорит о том, что данный раздел был отформатирован.
Для проверки предположения о том, что раздел не пересоздавался и все параметры файловой системы корректны, необходимо произвести поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20 (данное выражение признак начала директории FAT32).
рис. 6
При нахождении регулярного выражения необходимо удостовериться, что это действительно директория, по иным признакам, так как в некоторых случаях возможно совпадение и найденное регулярное выражение не является элементом директории. Согласно информации на рис. 6, можно сказать, что данная директория начиналась с 3 кластера (номер текущего кластера директории DWORD содержится в WORD по смещению 0x1A (младшая часть) и WORD по смещению 0x14 (старшая часть)) и описывалась в корневом каталоге, так как по смещениям 0x3A и 0x34 содержатся нули (начальный кластер родительской директории). Проверим, соответствует ли номер кластера данной директории нулевой точке отсчета файловой системы, созданной после форматирования. Для этого номер кластера директории умножим на размер текущего кластера и прибавим к нулевой точке 0x03*0x1000+0x40E000=0x411000. Как видим, расчетный адрес соответствует фактическому нахождению. Установить имя данной директории возможно только в случае, если ранее корневой каталог состоял более, чем из одного кластера, и ссылка на данную директорию была не в первом кластере, так как содержимое первого кластера при форматировании было полностью уничтожено вместе с таблицами размещения файлов.
Далее продолжим поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20.
рис. 7
Повторяем все проверки: 0x04*0x1000+0x40E000=0x412000. Снова видим соответствие положения директории параметрам текущей файловой системы. Но, кроме этого, видим, что есть номер кластера родительской директории 0x03, что говорит о том, что данная директория была вложенной, и взглянув на рис. 6, можно установить имя директории, которая изображена на рис. 7. Итак, согласно рис. 6, по смещению 0x4B видим значение 0x10 — это означает, что данная запись указывает на директорию, а по смещениям 0x5A и 0x54 число 0x00000004 – указатель на 4-й кластер. По смещению 0x40 – имя директории «BIN». Именно таким образом устанавливается взаимосвязь директорий в поврежденном FAT разделе. После выполнения еще некоторого числа проверок директорий в разных участках образа можно сделать окончательный вывод о том, что на данном накопителе состоялось форматирование в границах предшествующей файловой системы и параметры вновь созданной файловой системы унаследованы от предыдущей, то есть дальнейшие аналитические операции нужно проводить в рамках раздела, описанного в таблице разделов с учетом параметров текущей файловой системы.
Зная, что 1С база, состоящая из DBF файлов, должна содержать файл конфигурации 1CV7.MD, выполним поиск последовательности 0x31 0x43 0x56 0x37 0x20 0x20 0x20 0x20 0x4D 0x44. Для того, чтобы уменьшить количество заведомо ложных результатов, поиск лучше выполнять в рамках 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
Первоначально проводится оценка заголовка: проверяется его длина, указанная по смещению 0x08, приводит ли указанное в нем смещение на конечный маркер 0x0D. Записи полей базы, начиная со смещения 0x20, описываются 32-байтовыми записями, в которых по смещению 0x00 следует имя поля, по смещению 0x0B тип поля, по смещению 0x10 – размер поля. Сумма размеров полей +1 (один дополнительный байт для каждой записи в базе является статусом записи в DBF) должна равняться содержимому по смещению 0x0A (размер одной записи в базе). На рисунке DBF файлы мы видим следующие длины полей: 0x09+0x10+0x10+0x10+0x10+0x10+0x01=0x5A.
Проведем проверку корректности размера файла. Для этого выполняем умножение количества записей, которое указано в заголовке по смещению 0x04 на размер одной записи в базе по смещению 0x0A с последующим сложением с содержимым по смещению 0x08.
0x00000003*0x005A+0xE1=0x01EF. По полученному смещению должен находиться маркер окончания файла 0x1A.
Для контроля целостности содержимого полей можно использовать визуальный метод.
рис. 11
В таком вариант просмотра нужно пролистывать содержимое записей от начала и до конца. В случае если заполнение однородное, в каждом поле располагаются типы данных, характерные для описанного в заголовке и инородного содержимого нет, то по завершении просмотра DBF файла можно сделать вывод о корректности его содержимого.
При обнаружении содержимого, не соответствующего описанию поля в заголовке базы, необходимо установить точное место, с которого начинаются некорректные данные.
Рис. 12
Исходя из описания полей в заголовке и содержимого конкретного DBF файла, можно формировать предположительные ASCII последовательности, которые должны находиться по заданным смещениями в недостающих фрагментах. При отсутствии однотипных баз на одном из накопителей (в том числе и файловых копий одной и той же базы) такой метод позволит относительно быстро найти все недостающие фрагменты в образе накопителя. Отдельно отметим, что возникнут дополнительные сложности в стыковке фрагментов, если размер записи в DBF файле маленький или кратен 16. При наличии иных однотипных баз задача будет многократно усложнена (это утверждение справедливо на всех этапах работ, начиная с поиска фрагментов нужной директории).
Необходимо проверить целостность каждого DBF файла, коих в одной 1С базе несколько сотен. По прохождении всех проверок и сборов фрагментов файлов последует финальная проверка в конфигураторе 1С Предприятия.
рис. 13
В идеальном варианте по результатам тестирования должны пройти успешно все пункты, отмеченные в чекбоксах. Если обнаруживаются ошибки по первым двум пунктам, то необходимо проанализировать лог ошибок в конфигураторе и выяснить, в каких DBF файлах присутствуют инородные данные, которые не были обнаружены при проверках. Если обнаруживаются ошибки при проверке логической целостности, то опять же необходимо анализировать лог ошибок, чтобы выяснить, заключается ли проблема базы в качестве ее сбора, либо в ошибках, допущенных разработчиками конфигурации 1С.
Обратим внимание на тот факт, что если бы данная USB flash не была отформатирована, то после ее вычитки процедура восстановления данных была бы значительно более простой, что сильно бы отразилось на стоимости и сроке выполнения работ в меньшую сторону. В заключение, хотелось бы предостеречь всех пользователей и обслуживающий персонал от необдуманных действий в аварийных ситуациях, которые многократно усугубляют проблему, а также пожелать почаще выполнять операции резервного копирования.
Следующая публикация: Восстановление файлов после трояна-шифровальщика
Предыдущая публикация: Восстановление данных из поврежденного массива RAID 50
рис. 1
Как выяснилось, резервная копия данной базы у клиента более, чем годовой давности.
Первый этап в решении подобных задач – это создание поблочной копии оригинального накопителя (или как принято писать со времен, когда носителями были только накопители на гибких и жестких магнитных дисках – посекторной). При вычитывании обнаруживается нестабильная скорость чтения, что говорит о серьезном износе NAND памяти (многократное чтение NAND контроллером страниц NAND памяти и коррекция ошибок за счет избыточности кодов коррекции ошибок (ECC) весьма ресурсоемкая операции, что в итоге влияет на скорость чтения). При наличии непрочитанных участков необходимо заполнить их паттерном, который в дальнейшем нам поможет идентифицировать файлы, которые не были вычитаны целиком.
Далее приступаем к анализу. Необходимо установить, какая файловая система и в каких границах ранее была на USB flash. То есть, необходимо выполнить поиск регулярных выражений, характерных для различных метаданных файловых систем, но прежде, чем его начать, проверим простой вариант, который подразумевает, что границы разделов прежние. Для этого установим текущие параметры файловой системы.
Открываем LBA 0 (0x0 в файле образе) и проверяем там наличие таблицы разделов, либо наличие Boot сектора файловой системы.
рис. 2
В нашем случае видим по смещению 0x1C2 типа раздела 0x0B, означающее, что на данный момент на USB накопителе есть раздел FAT32, который начинается с 0x80 сектора (DWORD по смещению 0x1C6), длиной 0x003C2000 секторов (DWORD по смещению 0x1CA). Переходим к boot сектору описанного раздела в сектор 0x80 (в файле образа байтах 0x10000)
рис. 3
Необходимо вычислить начальную точку отсчета, то есть место нулевого кластера, относительно которого рассчитывается пространство, а также определить размер кластера.
Для этого нам нужны следующие параметры, описанные в boot секторе (будут указаны в виде смещения от начала сектора): размер сектора по смещению 0x0B — 0x200 (512 байт), количество секторов в кластере по смещению 0x0D — 0x08, размер кластера получается посредством перемножения размера сектора на количество секторов в кластере 0x08*0x0200=0x1000 (4096 байт), количество зарезервированных секторов до первой копии таблиц FAT — по смещению 0x0E=0x01FE (510 секторов), количество копий FAT — по смещению 0x10=0x02, размер одной копии FAT — по смещению 0x24=00000F01 (3841 секторов). Используя полученные параметры, произведем расчет положения начала области данных: 0x10000+0x01FE*200+0x00000F01*2*200=0x410000 (8320 сектор). Небольшой подвох от создателей FAT32 заключается в том, что на данный момент мы рассчитали начало области данных для раздела FAT32, но оно не является нулевой точкой отсчета, так как первые две записи в FAT таблице зарезервированы и не используются по прямому назначению, в связи с чем нулевой точкой принимается начало области данных за минусом 2 кластеров. В данном случае это будет 0x410000-0x1000*2=0x40E000 (8318 сектор).
Выполним проверку на предмет отсутствия записей в таблице размещения файлов и проведем процедуру сравнения копий на предмет разночтений.
Рис. 4
Сравнение копий FAT показало, что разночтения отсутствуют. Анализ содержимого одной из копий FAT показал, что согласно таблицы на разделе заполнен только один кластер.
Далее необходимо оценить корневой каталог на предмет удаленных записей. Позиция первого кластера корневого каталога указывается в boot сектор по смещению 0x2C=0x00000002. Для второго кластера в FAT указано FF FF FF 0F, что означает конец цепочки, то есть корневой каталог состоит из одного кластера.
рис. 5
По адресу, рассчитанному выше, мы видим корневую директорию (корневой каталог), в которой содержится единственная 32-байтная запись. По смещению 0x0B мы видим значение 0x08, которое указывает на тип записи – метка тома. Тот факт, что таблицы размещения файлов заполнены нулями, и в корневом каталоге нет намека на какие-либо иные записи, говорит о том, что данный раздел был отформатирован.
Для проверки предположения о том, что раздел не пересоздавался и все параметры файловой системы корректны, необходимо произвести поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20 (данное выражение признак начала директории FAT32).
рис. 6
При нахождении регулярного выражения необходимо удостовериться, что это действительно директория, по иным признакам, так как в некоторых случаях возможно совпадение и найденное регулярное выражение не является элементом директории. Согласно информации на рис. 6, можно сказать, что данная директория начиналась с 3 кластера (номер текущего кластера директории DWORD содержится в WORD по смещению 0x1A (младшая часть) и WORD по смещению 0x14 (старшая часть)) и описывалась в корневом каталоге, так как по смещениям 0x3A и 0x34 содержатся нули (начальный кластер родительской директории). Проверим, соответствует ли номер кластера данной директории нулевой точке отсчета файловой системы, созданной после форматирования. Для этого номер кластера директории умножим на размер текущего кластера и прибавим к нулевой точке 0x03*0x1000+0x40E000=0x411000. Как видим, расчетный адрес соответствует фактическому нахождению. Установить имя данной директории возможно только в случае, если ранее корневой каталог состоял более, чем из одного кластера, и ссылка на данную директорию была не в первом кластере, так как содержимое первого кластера при форматировании было полностью уничтожено вместе с таблицами размещения файлов.
Далее продолжим поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20.
рис. 7
Повторяем все проверки: 0x04*0x1000+0x40E000=0x412000. Снова видим соответствие положения директории параметрам текущей файловой системы. Но, кроме этого, видим, что есть номер кластера родительской директории 0x03, что говорит о том, что данная директория была вложенной, и взглянув на рис. 6, можно установить имя директории, которая изображена на рис. 7. Итак, согласно рис. 6, по смещению 0x4B видим значение 0x10 — это означает, что данная запись указывает на директорию, а по смещениям 0x5A и 0x54 число 0x00000004 – указатель на 4-й кластер. По смещению 0x40 – имя директории «BIN». Именно таким образом устанавливается взаимосвязь директорий в поврежденном FAT разделе. После выполнения еще некоторого числа проверок директорий в разных участках образа можно сделать окончательный вывод о том, что на данном накопителе состоялось форматирование в границах предшествующей файловой системы и параметры вновь созданной файловой системы унаследованы от предыдущей, то есть дальнейшие аналитические операции нужно проводить в рамках раздела, описанного в таблице разделов с учетом параметров текущей файловой системы.
Зная, что 1С база, состоящая из DBF файлов, должна содержать файл конфигурации 1CV7.MD, выполним поиск последовательности 0x31 0x43 0x56 0x37 0x20 0x20 0x20 0x20 0x4D 0x44. Для того, чтобы уменьшить количество заведомо ложных результатов, поиск лучше выполнять в рамках 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
Первоначально проводится оценка заголовка: проверяется его длина, указанная по смещению 0x08, приводит ли указанное в нем смещение на конечный маркер 0x0D. Записи полей базы, начиная со смещения 0x20, описываются 32-байтовыми записями, в которых по смещению 0x00 следует имя поля, по смещению 0x0B тип поля, по смещению 0x10 – размер поля. Сумма размеров полей +1 (один дополнительный байт для каждой записи в базе является статусом записи в DBF) должна равняться содержимому по смещению 0x0A (размер одной записи в базе). На рисунке DBF файлы мы видим следующие длины полей: 0x09+0x10+0x10+0x10+0x10+0x10+0x01=0x5A.
Проведем проверку корректности размера файла. Для этого выполняем умножение количества записей, которое указано в заголовке по смещению 0x04 на размер одной записи в базе по смещению 0x0A с последующим сложением с содержимым по смещению 0x08.
0x00000003*0x005A+0xE1=0x01EF. По полученному смещению должен находиться маркер окончания файла 0x1A.
Для контроля целостности содержимого полей можно использовать визуальный метод.
рис. 11
В таком вариант просмотра нужно пролистывать содержимое записей от начала и до конца. В случае если заполнение однородное, в каждом поле располагаются типы данных, характерные для описанного в заголовке и инородного содержимого нет, то по завершении просмотра DBF файла можно сделать вывод о корректности его содержимого.
При обнаружении содержимого, не соответствующего описанию поля в заголовке базы, необходимо установить точное место, с которого начинаются некорректные данные.
Рис. 12
Исходя из описания полей в заголовке и содержимого конкретного DBF файла, можно формировать предположительные ASCII последовательности, которые должны находиться по заданным смещениями в недостающих фрагментах. При отсутствии однотипных баз на одном из накопителей (в том числе и файловых копий одной и той же базы) такой метод позволит относительно быстро найти все недостающие фрагменты в образе накопителя. Отдельно отметим, что возникнут дополнительные сложности в стыковке фрагментов, если размер записи в DBF файле маленький или кратен 16. При наличии иных однотипных баз задача будет многократно усложнена (это утверждение справедливо на всех этапах работ, начиная с поиска фрагментов нужной директории).
Необходимо проверить целостность каждого DBF файла, коих в одной 1С базе несколько сотен. По прохождении всех проверок и сборов фрагментов файлов последует финальная проверка в конфигураторе 1С Предприятия.
рис. 13
В идеальном варианте по результатам тестирования должны пройти успешно все пункты, отмеченные в чекбоксах. Если обнаруживаются ошибки по первым двум пунктам, то необходимо проанализировать лог ошибок в конфигураторе и выяснить, в каких DBF файлах присутствуют инородные данные, которые не были обнаружены при проверках. Если обнаруживаются ошибки при проверке логической целостности, то опять же необходимо анализировать лог ошибок, чтобы выяснить, заключается ли проблема базы в качестве ее сбора, либо в ошибках, допущенных разработчиками конфигурации 1С.
Обратим внимание на тот факт, что если бы данная USB flash не была отформатирована, то после ее вычитки процедура восстановления данных была бы значительно более простой, что сильно бы отразилось на стоимости и сроке выполнения работ в меньшую сторону. В заключение, хотелось бы предостеречь всех пользователей и обслуживающий персонал от необдуманных действий в аварийных ситуациях, которые многократно усугубляют проблему, а также пожелать почаще выполнять операции резервного копирования.
Следующая публикация: Восстановление файлов после трояна-шифровальщика
Предыдущая публикация: Восстановление данных из поврежденного массива RAID 50
Поделиться с друзьями
Комментарии (24)
mikkisse
26.04.2017 16:27Спасибо! Как всегда очень интересно.
hddmasters
26.04.2017 17:48+1Пожалуйста. Если будут у читателей пожелания рассмотреть еще какие-то виды работ по восстановлению данных, то предлагайте темы будущей заметки.
mikkisse
26.04.2017 18:04Если есть что-то интересное про восстановление какой-нибудь продуктивной СХД, с 24+ дисками.
hddmasters
26.04.2017 18:18+1Количество дисков повлияет только на размер матрицы и рутинные операции по их вычитыванию и в случае 24+ дисков картинки в заметке будут неудобного формата. Лучше конкретизировать задачу с уровнем RAID 5, 5E, 5EE, 6, 10, 60, (50 рассматривался в прошлой заметке). И рассмотреть ее с меньшим числом дисков, чтобы легче воспринималась.
VJean
27.04.2017 12:10то предлагайте темы будущей заметки.
— SSD. Диагностика, восстановление прошивки и/или восстановление данных. С учетом разных контроллеров, работы TRIM и прочих внутренних процессов.
— Восстановление фоток котиков с нечитаемых/неопределяемых MicroSD/SDHC(SDXC). Учесть, что изначально карта памяти была отформатирована в фотоаппарате.hddmasters
27.04.2017 14:43— Восстановление фоток котиков с нечитаемых/неопределяемых MicroSD/SDHC(SDXC). Учесть, что изначально карта памяти была отформатирована в фотоаппарате.
несколько заготовок подобных заметок есть. Но встает вопрос будет ли прок от их публикации пользователям? Выполнение работ в таких случаях тесно привязано к профессиональным ПАК: Flash Extractor (Софтцентр), PC3000Flash (НПП АСЕ). Стороннего бесплатного инструмента для этих задач найти не удастся, разве что писать самостоятельно сортировщик блоков (страниц) для разных видов контроллеров. Но кроме сортировки требуется еще множество инструментов, аналогов которым также нет, учитывая специфичность операций.VJean
27.04.2017 15:28Прок однозначно будет. Кто-то почерпнет для себя новое, а обычные пользователи хоть немного поймут, что восстановить информацию с флешек/карт памяти — это не просто запустить какую-то утилитку и подождать.
hddmasters
27.04.2017 15:40Учту пожелание. Либо я, либо кто-то из моих коллег напишет что-то по этой теме.
fedor77
27.04.2017 13:54Из практики: те dbf файлы, которые содержат основные данные базы, с высокой вероятностью фрагментированы.
В статье прекрасно расписано как получить список файлов, но мало уделено внимания сборке фрагментированных файлов. Пожелание автору раскрыть этот момент, тем более у каждой таблицы есть описание полей и их типы. Какие методики применяются для получения однозначной сборки файлов.hddmasters
27.04.2017 14:12На практике в ручном режиме собирать одну сильно фрагментированную базу займет достаточно много времени. Так как поиск каждого фрагмента даже в рамках 2Гб flash будет отнимать время.
в свое время для собственных нужд я писал утилиту, которая копирует из образа диска в новый файл, только те кластеры, которые могут претендовать на то, что содержат внутри себя фрагменты 1С базы. Отсев заведомо негодных данных велся по принципу: наличие недопустимых символов. Учитывались кластеры содержащие в себе заголовки баз, также учитывались кластеры концовки файлов (оценка содержимого была до 0x1A).
Методик идентификации фрагментов достаточно много. Например, характер заполнения базы позволяет идентифицировать длину записи в базе. В случае 1С dbf можество справочников содержат даты в каждой записи. По цикличности повторения даты во фрагменте можно идентифицировать к какому именно справочнику имеет отношение данный фрагмент. Собрав все возможные фрагменты для каждого dbf можно анализировать в каком порядке их склеивать.
Как уже писал серьезную проблему будут представлять избыточные данные, то есть данные от такой же базы.
Dioxin
27.04.2017 14:17Сисадмина на мыло. Срочно.
hddmasters
27.04.2017 14:18+1Зачем требовать чьей-то крови? Лучше сделать выводы, чтобы не повторить чужих ошибок. Тем более в истории недостаточно данных, чтобы на 100% утверждать, что в этом есть вина администратора.
kxl
28.04.2017 19:24файловую 8-ку уже так просто не восстановить из фрагментов…
hddmasters
28.04.2017 20:42Сбор 1CD файла сравним по сложности с работой описанной в данной публикации. Для успешного сбора достаточно понимать устройство 1CD контейнера. И понимать как искать в нем объекты. В принципе задача будет похожа на сбор по фрагментам SQL базы (mdf). Контейнер 1CD относительно прост в своем внутреннем устройстве и его вполне можно изучить не имея документации на его устройство (что и было сделано много лет назад)
Areso
ССЗБ?
Germanets
Если бы все правильно делали бэкапы и их проверяли — индустрии восстановления данных не существовало бы, во всяком случае в том виде, и с тем распространением которая она получила сейчас)
hddmasters
Индустрия восстановления данных — громко сказано. Обычно это удел относительно небольших компаний. И не так много профильных компаний, как может показаться на первый взгляд.
vesper-bot
За это и заплатил.
izzholtik
Единственная копия работала с флэшки. Казалось бы, что могло пойти не так?
mihmig
Меня особо доставляет восклицание: «ну вчера же всё нормально работало!»
hddmasters
Ну а как еще реагировать людям далеким от понимания принципов работы вычислительной техники? Вполне естественные реакции.
hddmasters
Недостаточные знания пользователя, недостаточная оценка рисков, недоработка системного администратора и прочие факторы складываются воедино и в итоге имеем ситуацию в духе той, что описана в начале заметки.