Восстановление раздела HFS+. Случай из практики

Клиент обратился в сервис восстановления данных. Пропали тридцать гигабайт фотографий и видеозаписей с диска, который использовался в компьютере Apple. Больше никаких подробностей нет.

Решение задачи оказалось не самым тривиальным, мы перепробовали несколько гипотез, в том числе ошибочных. Восстанавливая данные, мы использовали несколько приемов анализа и восстановления данных. Эта статья — описание полного пути со всеми неудачами.

Первый взгляд

1-empty-tree

Пустая файловая система

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

Сбой файловой системы?

Первое предположение — данные пользователя удалены или произошел сбой файловой системы, который мешает штатным образом показать полное дерево каталогов и файлов. Поэтому первым делом запустили режим «сканирование Catalog File», который часто помогает справиться с такими проблемами.

2-scan-catalog-file

Меню запуска сканирования Catalog File на файловой системе

Catalog File — область метаданных HFS+, которая хранит информацию об иерархии каталогов и файлов — имена, размеры, даты создания и прочее. Также там хранится часть информации о размещении файлов. Если файл состоит из более чем 8 фрагментов, то дополнительно используется Extents File.

Режим «сканирование Catalog File» анализирует содержимое этих файлов и пытается построить дерево каталогов и файлов, даже если штатная иерархия нарушена. Этот режим похож на “сканирование MFT”.

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

3-scan-result

Виртуальная файловая система — результат сканирования Catalog File

Раздел переформатирован?

Сканирование Catalog File выполнилось за несколько секнуд. Это подозрительно, т. к. у долго живущей файловой системы этот файл большой и читается дольше. Так возникло следующее предположение — раздел переформатирован, т. е. создана новая (пустая) файловая система на месте старой (с данными). Поэтому Catalog File такой маленький и сканирование не дает нужного результата.

Чтобы дополнительно проверить это предположение, мы построили карту занятого пространства. И она оказалась слишком маленькой — 600 мегабайт, а это примерный размер всех служебных файлов (Catalog, Extent, Allocation и Attributes). Второе предположение похоже на правду.

Меню построения карты занятых секторов

Когда файловая система работает ей приходится постоянно выделять место для сохранения новых файлов и освобождать его, если файл удален. Чтобы упростить эту задачу HFS+ использует битовую карту, в которой отмечены занятые и свободные блоки. Data Extractor умеет пользоваться этой информацией и показывать занятые или свободные сектора (по мнению файловой системы!).

Мы предположили, что пользователь создал новую файловую систему на том же месте, где находилась старая и с тем же размером. Если это так, то должны остаться старые метаданные — участки старых Catalog и Extents file. Однако не известно, где они лежат. Надо сканировать или весь раздел, или только незанятое пространство, чтобы чтобы старые метаданные не перепутались с новыми.

5-scan-unused

Запуск сканирования по незанятому пространству

Не у всех файловых систем занятое пространство является переписанным. Например, Ext4 при создании резервирует (отмечает как «занятые») под свои нужды намного больше секторов, чем реально переписывает. А вот HFS+ напротив, достаточно «честная».

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

6-unused-scan-result

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

У раздела другое смещение?

После анализа получили «хорошее» дерево каталогов и файлов, это значит, что старые метаданные всё еще хранятся на диске и Data Extractor’у удалось их найти и разобрать. Но ни один из файлов не попал на место, такое бывает, когда у раздела неправильно задано начало. Так появилось новое предположение — что новая и старая файловые системы начинается в разных местах. Переформатирован не раздел, а весь диск — созданы новые MBR+GPT на месте старых структур, создана новая файловая система с другим началом. Из-за этого старый раздел теперь потерян.

Если предположение правильное, то можно попробовать найти старый раздел. Один из способов — найти в черновом восстановлении HFS+ Volume Header’ы старого раздела и воспользоваться методом добавления виртуального раздела.

В разделе HFS+ должно быть минимум 2 Volume Header’а:

  • основной по смещению 1024 байта от начала раздела;
  • копия по смещению 1024 байта от конца раздела;
  • помимо них может быть много версий Volume Header’а в журнале файловой системы;
  • журнал хранится внутри раздела, т. е. положение Volume Header’ов  не фиксировано и с их помощью нельзя определить начало раздела.

Мы просканировали около миллиона секторов в начале диска и в конце.

7-old-and-new-volhdrs-edt

Результаты чернового восстановления

Результаты чернового восстановления сказали многое о ситуации :

  • нашлось 2 группы Volume Header’ов, они описывают файловые системы разного размера (размер вычисляется из полей Total Blocks и Block Size);
  • в каждой группе несколько десятков Volume Header’ов, значит это файловые системы с журналом;
  • одна из групп относится к новой файловой системе. Первый и последний Volume Header расположены в правильных местах — в начале и в конце нового раздела;
  • делаем вывод, что вторая группа — Volume Header’ы старого раздела;
  • старые Volume Header’ы находятся раньше начала нового раздела (имеют меньший LBA). Делаем вывод, что старый раздел начинается раньше;
  • старый раздел занимал примерно такой же объем, значит в конце диска должна быть копия Volume Header, но она не найдена — значит она перезаписана;
  • начало старого раздела все еще можно узнать по основной копии Volume Header, она должна быть раньше всех остальных копий из журнала. Берем первый из старых Volume Header’ов и пытаем добавить раздел. Data Extractor должен автоматически определить начало и размер раздела, но попытка заканчивается неудачей. Data Extractor предлагает ввести начало раздела вручную;

    8-add-virt-part

    Data Exctractor не смог автоматически определить начало раздело, поэтому предложил указать его вручную

  • замечаем, что все старые Volume Header’ы расположены плотной группой — разница между соседними несколько сотен секторов. Это характерно для версий из журнала. Делаем вывод, что все старые Volume Header’ы из журнала.

Гипотеза о смещении подтвердилась. Стало известно, что старая файловая система начиналась раньше. Но добавить старый раздел мы не смогли, т. к. все еще не знаем точное начало.

Определяем сдвиг

У нас есть виртуальная файловая система — результат анализа по незанятому пространству. Она похожа на то, что нужно клиенту. Если гипотеза о сдвиге верна, то все файлы в ней сдвинуты на одинаковое количество секторов. Поэтому они не открываются.

untitled-drawing

Виртуальное и реальное размещение файлов на диске не совпадают

Как определить сдвиг? Надо найти реальное положение любого файла из результата анализа. Разница между тем, где файл начинается в виртуальной файловой системе (виртуальное начало) и тем, где он находится на диске (реальное начало) — это и есть сдвиг.

Но как найти «тот самый файл» на диске? Найти его можно с помощью чернового восстановления, надо только суметь отличить этот файл от остальных.

Например:

  • в файловой системе только один файл базы данных 1C, в черновом восстановлении с помощью GREP нашелся только один файл такого типа — пара «реальный-виртуальный» найдена;
  • в виртуальной файловой системе только один .zip файл с размером 1 234 567 байт. Черновое умеет искать .zip файлы и определять их точный размер. Режим нашел только два .zip файла с размером 1 234 567 байт — пробуем оба файла, начинаем с того, который ближе к файлу из виртуальной ФС;
  • в файловой системе 20 .bmp файлов с размером 456 789 байт, 5 из них расположены в первой половине диска, только один файл называется «dog.bmp». Черновое восстановление нашло 40 .bmp файлов, 10 из них в первой половине диска и только внутри одного рисунок с собакой. Пара найдена;
  • если не получилось найти пару сразу — попробуйте другой файл.

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

Мы выбрали один файл из виртуальной файловой системы. Его виртуальное начало LBA= 23 111 520, размер 48 076 байт.

9-jpegs

Файлы .jpeg в результате сканирования по незанятому пространству

Новый раздел начинается с LBA = 409 640. Старый раздел по нашей гипотезе сдвинут назад. Сдвиг не может быть больше 409 640 секторов, иначе уйдем за начало диска. Таким образом, реальный файл должен лежать в интервале [22 701 880 .. 23 111 519].

Мы таких точных расчетов не делали, а прикинули, что начинать можно с LBA = 22 500 000. И подождали пока режим преодолеет отметку 23 500 000. Среди результатов нашелся только один .jpeg с размером 48 076 байт, на LBA = 22 701 882.

10-raw-res

Результаты чернового восстановления

Теперь можно посчитать разницу между реальным и виртуальным положением:

Сдвиг = реальный LBA - виртуальный LBA = 
Сдвиг = 22 701 882 – 23 111 520 = -409 638.

Старый раздел начинается на 409 638 секторов раньше виртуального, виртуальный начинается там же где и новая файловая система — LBA 409 640. Это значит, что начало старого раздела — LBA = 2.

Добавляем виртуальный раздел

Мы знаем начало раздела и у нас есть много версий Volume Header’а. Любую из них можно использовать для добавления виртуального раздела. Какую выбрать? Мы отсортировали их по дате обновления (update date) и взяли самую свежую.

11-select-volume-header

HFS+ Volume Header’ы в черновом восстановлении, упорядочены по дате обновления

Начало раздела надо указать самостоятельно — LBA = 2.

12-add-part

Вручную указываем начало раздела

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

13-old-fs

Добавленный раздел открылся штатным способом

Что дальше?

В конце стало понятно, что произошло:

  • был раздел HFS+ с данными клиента. Начинался с LBA=2. Возможно использовался MBR, т. к. для GPT нужно больше места в начале диска;
  • диск переформатировали стандартной утилитой MacOS, она создала GPT и новую пустую файловую систему HFS+.

Это означает, что данные или метаданные старой файловой системы могут быть переписаны. Если в дереве каталогов и файлов мы видим все что нужно клиенту — можно сохранять данные. Если нет, то можно выполнить сканирование Catalog File. Либо сканирвоание всего раздела, чтобы получить максимальный результат — найти то, что было удалено или не отображается штатным образом.

В этой задаче примерно известно, что было переписано — это сектора в карте занятого в новом разделе. Используя возможности работы с картам можно проверить переписаны или нет конкретные файлы пользователя или наиболее важные метаданные HFS+ (Catalog, Extents и Allocation File).

Update: Вышла новая статья «Отделяем хорошие файлы от плохих или работа со снимками файловых систем«, в которой разобрано как отделить перезаписанные файлы от не перезаписанных.

Другие способы

У этой задачи есть и более быстрые способы решения. Если посчитать размер старого раздела в секторах, то легко увидеть, что его начало лежит в интервале от 0 до 7 LBA, иначе он выйдет за границы диска. Все 8 вариантов легко проверить перебором. Но столь короткое решение на дает показать всего того, что встретилось на длинном пути.

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (2 голосов, средний: 3,00)
Loading...Loading...

Об авторе Александр Леоненко

Разработчик Data Extractor и Data Extractor RAID Edition
Запись опубликована в рубрике Data Extractor с метками , , , , , . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>