У меня есть ПК с Windows 10, и один из моих жестких дисков полностью сломался (то есть не распознается BIOS, издает странные звуки и не может быть использован). Это был не системный диск, а в основном содержал личные данные. Я точно не помню, что было на диске, и в этом проблема. Чтобы оценить потерю (и оценить, стоят ли того дальнейшие процедуры восстановления данных на жестком диске), я хотел бы получить все возможные подсказки о том, что было на диске (имена файлов, возможно, с именами папок было бы достаточно).
Я подумал, что, возможно, поисковая система Windows с ее индексацией файлов может хранить какую-то информацию о том, что находится на диске, и эту информацию, пусть даже частичную, можно как-то извлечь.
Можно ли получить доступ к базе данных поиска Windows и получить список файлов с путями с утерянного диска, и если да, то как?
Обратите внимание, что этот вопрос касается не восстановления данных с поврежденного жесткого диска, а того, какую информацию хранит Windows о файлах, которые были на жестких дисках (но сейчас их там нет). Индекс поиска файлов Windows кажется потенциальным местом, где может храниться такая информация.
решение1
С помощью комментарияДокторМойше ПиппикМне удалось получить доступ к базе данных поиска Windows.
Контент поиска по умолчанию сохраняется по адресу
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb
Это довольно большой файл (1 ГБ в моем случае) и обычно его нельзя скопировать куда-то еще, потому что он используется поиском Windows. Просто откройте диспетчер задач, найдите "Microsoft Windows Search Indexer" и завершите процесс "Windows search". Затем скопируйте файл Windows.edb в безопасное место.
Информация о формате файла поисковой базы данных приведена, например, в этом документеГовард Чиверс, который используетwdsCarveпрограммное обеспечение, которое, похоже, недоступно для скачивания. Также естьэтотиЭта статьяИоахим Метц. Иоахим Метц также, кажется, внес основной вклад вlibesedbна Github, который, однако, не имеет бинарных релизов для Windows и помечен как экспериментальный.
Короче говоря, база данных поиска Windows, по-видимому, основана на формате файла базы данных (EDB) Extensible Storage Engine (ESE), фирменном недокументированном формате файлов Windows с дополнительными элементами обфускации и сжатия.
Наконец, я нашел проектЧонхён Кимс 2018 года называетсяWinSearchDBAnalyzer, систочники(дополнительная зависимостьWinforms) на Github. Согласно блогу, он бесплатный (для использования), доступны двоичные файлы для Windows, и, кроме того, с помощью Microsoft Visual Studio Community edition я мог бы легко собрать программу самостоятельно.
Использование простое, можно выбрать местоположение файла Windows.edb, а затем проверить некоторые флаги для того, что искать. Затем это заняло некоторое время (~5 минут), а затем представило около 100 тыс. записей в таблице. Сортировка по местоположению файла проста, и для каждого файла представлены метаданные.
Однако, возвращаясь к моему первоначальному намерению, количество файлов на потерянном жестком диске, все еще присутствующих в базе данных поиска Windows, было разочаровывающе малым. Из сотен тысяч файлов на этом жестком диске содержалось только максимум 1/10 или меньше (на самом деле то, что я все еще помню), так что в итоге это оказалось гораздо менее полезным, чем я думал. Тем не менее, это жизнеспособный способ получить доступ хотя бы к некоторой метаинформации о содержимом жестких дисков, которые больше не присутствуют и не доступны.
решение2
Этот ответ соотносится с ответом Трилариона на его собственный вопрос.
Интересный документ, на который ссылается доктор Мойше Пиппик, описывает область индексации. Это может объяснить низкий процент индексированных файлов.
Кроме того, вы можете проверить, что произойдет, если вы предоставите индексатору файл со случайным содержимым. Появится ли этот файл в базе данных или нет?
Неизвестный формат файла не может быть прочитан индексатором. Насколько мне известно, в более старой версии Windows индексатор можно было расширить, предоставив скомпилированный код, который позволял индексатору читать созданный формат файла.
Может случиться так, что файлы, которые технически не могут быть проиндексированы, не появятся в индексе.
решение3
Первое — быть очень точным и ориентированным на детали. Вы сказали «как будто недоступен вообще». Это что, обычная английская грамматика? Следующее — «недоступен вообще» неточно. Многие скажут, что если буква диска все еще на месте, а содержимое помечено как необработанное, то их диск «недоступен вообще».
Мое определение таково: если диск включается без сбоев, но любая попытка чтения, предпринятая компьютером для диска, терпит неудачу, то его следует считать «вообще недоступным».
Это совершенно разное понимание одного и того же выражения.
Первое, что вы можете сделать, очень просто. Предпочтительно используя машину Linux, вы подключаете диск и проверяете его наличие с помощью команды lsblk. Затем вы создаете файл журнала с помощью smartmontools и анализируете его. Следующим шагом будет - если содержимое файла журнала не возражает - попытаться сделать дубликат диска с помощью ddrescue и его функции файла журнала. Это предоставит вам, как мы надеемся, почти полную копию на исправном диске и список отсутствующих областей, которые не были скопированы.
Будучи параноиком, вы бы быстро дублировали дубликат и работали над второй копией. В зависимости от вашего бюджета вы бы запускали различные продукты восстановления для второй копии. Бесплатная и открытая программа-специалист по дактилоскопии, такая как Photorec, выдала бы результаты без метаданных, таких как структуры каталогов и файлов, но полезный вывод Photorec вернул бы вашу память в нужное русло, что вы в ней хранили.
Этот анализ можно сделать без вреда на машине Windows, используя вторую копию. Если собранной информации недостаточно, ваша работа начнется.
Сначала вам следует изучить, как работают наиболее часто используемые схемы разделов, такие как старая Intel/MBR, а также изучить GPT. Бесплатное и открытое программное обеспечение Testdisk — это хороший инструмент, который вам поможет.
Зная файловую систему, используемую при форматировании диска, вам затем нужно будет изучить формат рассматриваемой файловой системы, например, NTFS. Поскольку NTFS немного сложна для начала, вам лучше попрактиковаться с файловыми системами FAT. Как только вы освоитесь, вы можете попробовать перезаписать часть или всю FAT (таблицу(ы) размещения файлов) файловой системы FAT. Затем потребуется немного программирования для поиска ее остатков. Затем вы должны узнать, как дефрагментация влияет на ваш успех.
После понимания простой реализации файловой системы вы бы добрались до (предположительно) NTFS. Ваше единственное преимущество перед программой восстановления заключается в том, что вы можете использовать оставшуюся память содержимого вашего диска в своих интересах.
Это может принести успех, но нет никаких гарантий.
В 2001 году я исследовал отказавший системный диск XP, все еще использовавший файловую систему FAT. Единственное, что я восстановил (что имело хоть какое-то значение), был список приглашений (xls-файл) на его свадьбу с уже разосланными приглашениями. Не было возможности автоматически восстановить файл — мне пришлось просматривать различные последующие кластеры. Поскольку это был xls-файл, он не был сжат. Я просто увидел второй кластер файла, и он не был следующим в линейном порядке. Сегодня я бы никогда не справился с этой задачей в отношении сжатия, используемого в файлах Excel типа xlsx.