Анализ выделенного пространства в разделе Ext4 для повышения эффективности восстановления данных

Анализ выделенного пространства в разделе Ext4 для повышения эффективности восстановления данных

Я пытаюсь использовать Lubuntu, чтобы восстановить как можно больше данных с неисправного жесткого диска объемом 4 ТБ.

Согласно GParted, основной раздел, отформатированный в Ext4, содержит всего 553 ГБ данных. Я попытался сделать полный клон с помощьюHDDSuperClone, программное обеспечение с графическим интерфейсом для Linux, похожее на командную строку ddrescueпо назначению и функционалу. Сначала оно работало хорошо, с небольшим количеством ошибок/пропущенных секторов и хорошей средней скоростью копирования (~60 МБ/с). Но где-то в середине у него начались более серьезные проблемы, некоторые области вообще не считывались, образуя узор из чередующихся полос хорошего и плохого чтения, что обычно указывает на то, что одна головка неисправна. В этот момент я остановил восстановление.

Я восстановил около 1,7 ТБ, и он довольно долго копировал только 00, поэтому я думал, что все соответствующие данные уже будут сохранены на диске восстановления. Но оказалось, что основной раздел не может быть смонтирован (хотя его все еще можно смонтировать на исходном диске, хотя и с трудом), и известное программное обеспечение для восстановления данных (R-Studio, DMDE) не может восстановить исходную структуру каталогов или получить исходные имена файлов. И при открытии диска восстановления в WinHex я вижу, что он полностью пуст за пределами 438 ГБ, что означает, что около 115 ГБ отсутствуют — хотя я не понимаю, как это возможно, поскольку файловые системы должны записывать данные в самые внешние доступные области, где скорость чтения/записи лучше, чтобы оптимизировать производительность жестких дисков.

Теперь, чтобы максимально использовать то, что осталось, учитывая, что состояние диска может быстро ухудшиться при следующей серьезной попытке восстановления, я ищу любой метод, который мог бы анализировать структуры метаданных и сообщать о выделенном/невыделенном пространстве, чтобы я мог нацелить восстановление на эти соответствующие области, а не тратить драгоценное время на чтение гигабайт нулей. Небольшая программа командной строки, разработанная несколько лет назад автором HDDSuperClone ddru_ntfsbitmap(часть ddr_utility), может делать это автоматически с разделами NTFS: она анализирует $Bitmapфайл и генерирует «файл карты», для ddrescueкоторого фактически ограничивает копирование секторами, помеченными как выделенные (при условии, что этот системный файл может быть прочитан целиком); она также может генерировать «файл карты» для восстановления первого $MFT, что чрезвычайно полезно (MFT содержит все метаданные файлов и информацию о структуре каталогов, если он поврежден или утерян, возможно только восстановление типа «raw file cutting»). Но даже этот высококвалифицированный человек не знает, как сделать то же самое с разделами Linux, как он ответил наэта тема HDDGuru.

Итак, даже если это не полностью автоматизировано, мне нужна процедура, которая могла бы быстро и эффективно проанализировать раздел Ext4, чтобы не изнашивать диск еще больше в процессе, и сообщить эту информацию либо в виде текстового журнала, либо в виде графического представления. Возможно, программа дефрагментации справится с этой задачей?

И вообще, где находятся важные структуры метаданных («иноды», если я не ошибаюсь) на разделе Linux? Есть ли единый файл, эквивалентный NTFS $Bitmap, или информация о распределении файлов/секторов определяется с помощью более сложного анализа? (Если это имеет значение, диск находился в сетевом корпусе WDMyCloud, настроенном на заводе и работающем с операционной системой Linux.)

Анализ исходного диска с помощью GParted.

Примерно на 47% восстановления начинают проявляться серьезные проблемы: чередующиеся полосы хороших показаний (зеленые) и плохих показаний (серые) указывают на то, что одна головка вышла из строя.

Связанный контент