Linux ищет весь жесткий диск шестнадцатеричных байтов для строки байтов и список всех файлов, к которым принадлежит данные? [закрыто]

Извинения за титул. Чтобы быть более конкретным, я помню, как я читал это где-то в прошлом году, когда пытался восстановить повреждение данных на жестком диске.

У меня есть жесткий диск Windows XP, который потерпел крушение головы и вызвал неустранимый плохой секторов в определенных файлах. Я клонирую диск на дубликат диска и заменяю файлы, которые были повреждены, используя резервную копию, которую я использовал давно.

То, что я уже сделал, - это ... Я загрузился в Parted Magic из Ultimate Boot CD и использовала инструменты ddrescue для клонирования поврежденного диска в образ диска, а затем использовали файл logfile.txt для записи DEADBEEF во все сектора, которые он не мог прочитать / клонировать в файл образа диска и сделать полное изображение. Я, как я полагаю, использовал одну из команд linux grep, чтобы попытаться выполнить поиск всей файловой системы для строки DEADBEEF и перечислить все файлы, содержащие эту строку, хотя некоторые проблемы с ней оставляют часы в поиске из-за некоторой нечетной ошибки.

Я также вручную исправил ошибки $ MFT (Master File Table), за исключением данных одного файла с картинками, которые неважны, чтобы я мог правильно сканировать всю файловую систему и видеть все файлы (некоторые из них не были показывая из-за повреждения).

Мне нужно сделать следующее:

Я хочу полностью отсканировать весь диск до уровня байта (как если бы он смотрел на образ диска в шестнадцатеричном редакторе), для каждого сектора, для строки DEADBEEF, затем перечислите все файлы, к которым плохой сектор переписывается с DEADBEEF, в соответствии с файловой системой. Я помню, что читал об этом где-то, имея возможность сканировать диск, и как только он находит строку, он перечисляет смещение / местоположение / сектор строки DEADBEEF и какой файл владеет данными в этом секторе. Это, или каждый плохой сектор, и перечисляет, к какому файлу принадлежит плохой сектор.

В журнале ddrescue перечислены все сектора, которые были обнаружены как нечитаемые (около 1000 200-байтовых секторов), где он написал DEADBEEF. Если я знаю, какие файлы имеют эти плохие сектора, я могу их заменить, используя мою старую резервную копию.

Прежде чем вы спросите, я не могу просто использовать старую резервную копию, потому что ей около 3 лет. Старая резервная копия на самом деле является исходным диском с этого компьютера, который я клонировал на этом диске, который я пытаюсь спасти. Большинство поврежденных секторов от сбоя жесткого диска находились в составе диска, в котором были только файлы, которые присутствовали на оригинальном диске. Я могу легко скопировать эти файлы с оригинала на новый диск, чтобы исправить все поврежденные секторы DEADBEEF, но мне нужно знать, к какому файлу принадлежат эти плохие секторы.

Опять же, я помню, что читал что-то о сканировании всех секторов диска и наличии списка всех файлов, к которым принадлежал определенный сектор. Итак, как мне это сделать из Parted Magic? Я должен установить его там, чтобы он был установлен как только для чтения.

0
задан 14 April 2017 в 07:26

3 ответа

Вы можете сделать, как полезный комментарий от steeldriver говорит и использовать ddrutility

Он, похоже, не находится в репозиториях Ubuntu, но это главная страница steeldriver В частности, используйте его инструмент ddru_findbad. Вот клип со своей вики-страницы:

ddru_findbad Это сценарий bash, который попытается найти, какие файлы связаны с плохими секторами в файле журнала ddrescue. Он полагается на сторонние утилиты для своих функций. Он может не работать на всех системах. Он может быть медленным и может быть очень медленным, если не непригодным, если в списке много неприятных секторов (это плохо работает с большим размером ошибки).

У меня возникает соблазн забыть о номерах сектора и просто монтировать клонированное изображение & amp; искать все файлы для "DEADBEEF", с помощью find, xargs & amp; grep в Ubuntu (или Xubuntu, Lubuntu или Debian, большинство Linux).

Легче или быстрее, чем пытаться ddru_findbad или нет, возможно, зависит от того, насколько велика & amp; Быстрое изображение вашего диска.

find /mnt/x -type f -print0 | xargs -0 grep --files-with-matches "DEADBEEF" >> list

Если изображение установлено на /mnt/x. Тогда список файлов имеет все имена файлов, которые соответствуют. Любое свободное пространство с DEADBEEF игнорируется.

1
ответ дан 18 July 2018 в 15:00

Вы можете сделать, как полезный комментарий от steeldriver говорит и использовать ddrutility

Он, похоже, не находится в репозиториях Ubuntu, но это главная страница steeldriver В частности, используйте его инструмент ddru_findbad. Вот клип со своей вики-страницы:

ddru_findbad Это сценарий bash, который попытается найти, какие файлы связаны с плохими секторами в файле журнала ddrescue. Он полагается на сторонние утилиты для своих функций. Он может не работать на всех системах. Он может быть медленным и может быть очень медленным, если не непригодным, если в списке много неприятных секторов (это плохо работает с большим размером ошибки).

У меня возникает соблазн забыть о номерах сектора и просто монтировать клонированное изображение & amp; искать все файлы для "DEADBEEF", с помощью find, xargs & amp; grep в Ubuntu (или Xubuntu, Lubuntu или Debian, большинство Linux).

Легче или быстрее, чем пытаться ddru_findbad или нет, возможно, зависит от того, насколько велика & amp; Быстрое изображение вашего диска.

find /mnt/x -type f -print0 | xargs -0 grep --files-with-matches "DEADBEEF" >> list

Если изображение установлено на /mnt/x. Тогда список файлов имеет все имена файлов, которые соответствуют. Любое свободное пространство с DEADBEEF игнорируется.

1
ответ дан 24 July 2018 в 20:32
  • 1
    Я попробую. В прошлый раз, когда я работал над этим, я получил помощь от кого-то, у кого я попробовал это: [[& quot; для i в find . -type d -maxdepth 3; do echo & quot; Глядя в $ i ... & quot ;; grep -r -l DEADBEEFDEADBEEF & quot; $ i & quot; 2 & GT; & амп; 1; эхо ", выполненное с помощью $ i"; эхо-сигнал "; сделано | tee greplog.txt & quot; ]] ... но это не позволило мне «найти: пути должны предшествовать выражению: 3». ..... Есть 2 `в этом коде перед поиском и после maxdepth 3. (как я могу сделать это правильно разрыв строки, он не работает) – DCX 15 April 2017 в 21:06
  • 2
    Да, этот код, который вы пробовали, кажется, тоже обрабатывает вывод find, который, вероятно, не будет работать с именами с новыми символами и amp; возможно, даже пробелы - find -print0 и xargs -0 заботятся об этом, а также делают ненужным цикл. Вы действительно хотите, чтобы сообщение о том, какой файл в настоящее время искали, и когда это делается? Может быть 50 000 + бесполезных сообщений, и я думаю, что grep может выводить имена файлов с не-совпадениями тоже. На самом деле grep's -r также рекурсивно читает и под каталогом, чтобы 3 раза искать папки. И все в тесте? Запись на поврежденные fs? Странно, не делай этого ;-) – Xen2050 15 April 2017 в 22:36
  • 3
    Я не могу вспомнить, почему это было настроено таким образом, но я помню, что хотел посмотреть, как это скажет мне, что в настоящее время проводится обыск, чтобы я мог сказать, работает ли это бег или нет. Я думаю, что в прошлые разы, которые я пробовал, он был заморожен на 10 часов в одночасье, и я даже не знал, что он перестает работать, потому что не было никакой линии, указывающей на это. Я думаю, что я также хотел, чтобы это было, когда он попал в файл проблемы, так как было 2 файла, которые таинственно терпели неудачу, без причины, которые я мог найти, но очень раздражающий, пытаясь сделать первоначальный поиск по 2-3 часа каждый раз. Похоже, ddrutility делает то, что мне нужно. – DCX 16 April 2017 в 03:50
  • 4
    Теперь, когда я думаю об этом, возможно, это было бы так, что он не прекратил поиск, если бы он попал в файл проблемы. Как я уже сказал, это было крайне неприятно, делая поиск в течение 2-3 часов, а затем оставив его незавершенным, по какой-то неизвестной причине говоря о файле, с которым у него возникла проблема, и я остался, не зная, какие файлы и каталоги уже были сканируется на DEADBEEF. Я не хочу просто удалять файлы. Из того, что я мог сказать, с ними не было никакой реальной проблемы. Я просмотрел их в шестнадцатеричном редакторе, без каких-либо плохих секторов или чего-то еще, & amp; Я мог бы скопировать и прочитать файл в порядке. – DCX 16 April 2017 в 03:53
  • 5
    Понимаю. Я бы использовал системный монитор, чтобы проверить, не происходит ли чтение диска, но это не говорит о том, что было обыскано, какой-то тип ведения журнала помог бы там, но с пространством имен файлов & amp; Сумасшедшие вещи, такие как новые строки, разрешали анализировать списки файлов, могут быть сложными. Это не на самом поврежденном диске? Хорошая скопированная информация не должна иметь ошибок чтения (после fsck), и попытка поиска неисправного диска вряд ли сделает его более здоровым (больше похоже на неудачу с каждым чтением). – Xen2050 16 April 2017 в 04:13

Вы можете сделать, как полезный комментарий от steeldriver говорит и использовать ddrutility

Он, похоже, не находится в репозиториях Ubuntu, но это главная страница steeldriver В частности, используйте его инструмент ddru_findbad. Вот клип со своей вики-страницы:

ddru_findbad Это сценарий bash, который попытается найти, какие файлы связаны с плохими секторами в файле журнала ddrescue. Он полагается на сторонние утилиты для своих функций. Он может не работать на всех системах. Он может быть медленным и может быть очень медленным, если не непригодным, если в списке много неприятных секторов (это плохо работает с большим размером ошибки).

У меня возникает соблазн забыть о номерах сектора и просто монтировать клонированное изображение & amp; искать все файлы для "DEADBEEF", с помощью find, xargs & amp; grep в Ubuntu (или Xubuntu, Lubuntu или Debian, большинство Linux).

Легче или быстрее, чем пытаться ddru_findbad или нет, возможно, зависит от того, насколько велика & amp; Быстрое изображение вашего диска.

find /mnt/x -type f -print0 | xargs -0 grep --files-with-matches "DEADBEEF" >> list

Если изображение установлено на /mnt/x. Тогда список файлов имеет все имена файлов, которые соответствуют. Любое свободное пространство с DEADBEEF игнорируется.

1
ответ дан 31 July 2018 в 23:34
  • 1
    Я попробую. В прошлый раз, когда я работал над этим, я получил помощь от кого-то, у кого я попробовал это: [[& quot; для i в find . -type d -maxdepth 3; do echo & quot; Глядя в $ i ... & quot ;; grep -r -l DEADBEEFDEADBEEF & quot; $ i & quot; 2 & GT; & амп; 1; эхо ", выполненное с помощью $ i"; эхо-сигнал "; сделано | tee greplog.txt & quot; ]] ... но это не позволило мне «найти: пути должны предшествовать выражению: 3». ..... Есть 2 `в этом коде перед поиском и после maxdepth 3. (как я могу сделать это правильно разрыв строки, он не работает) – DCX 15 April 2017 в 21:06
  • 2
    Да, этот код, который вы пробовали, кажется, тоже обрабатывает вывод find, который, вероятно, не будет работать с именами с новыми символами и amp; возможно, даже пробелы - find -print0 и xargs -0 заботятся об этом, а также делают ненужным цикл. Вы действительно хотите, чтобы сообщение о том, какой файл в настоящее время искали, и когда это делается? Может быть 50 000 + бесполезных сообщений, и я думаю, что grep может выводить имена файлов с не-совпадениями тоже. На самом деле grep's -r также рекурсивно читает и под каталогом, чтобы 3 раза искать папки. И все в тесте? Запись на поврежденные fs? Странно, не делай этого ;-) – Xen2050 15 April 2017 в 22:36
  • 3
    Я не могу вспомнить, почему это было настроено таким образом, но я помню, что хотел посмотреть, как это скажет мне, что в настоящее время проводится обыск, чтобы я мог сказать, работает ли это бег или нет. Я думаю, что в прошлые разы, которые я пробовал, он был заморожен на 10 часов в одночасье, и я даже не знал, что он перестает работать, потому что не было никакой линии, указывающей на это. Я думаю, что я также хотел, чтобы это было, когда он попал в файл проблемы, так как было 2 файла, которые таинственно терпели неудачу, без причины, которые я мог найти, но очень раздражающий, пытаясь сделать первоначальный поиск по 2-3 часа каждый раз. Похоже, ddrutility делает то, что мне нужно. – DCX 16 April 2017 в 03:50
  • 4
    Теперь, когда я думаю об этом, возможно, это было бы так, что он не прекратил поиск, если бы он попал в файл проблемы. Как я уже сказал, это было крайне неприятно, делая поиск в течение 2-3 часов, а затем оставив его незавершенным, по какой-то неизвестной причине говоря о файле, с которым у него возникла проблема, и я остался, не зная, какие файлы и каталоги уже были сканируется на DEADBEEF. Я не хочу просто удалять файлы. Из того, что я мог сказать, с ними не было никакой реальной проблемы. Я просмотрел их в шестнадцатеричном редакторе, без каких-либо плохих секторов или чего-то еще, & amp; Я мог бы скопировать и прочитать файл в порядке. – DCX 16 April 2017 в 03:53
  • 5
    Я вижу. Я бы использовать системный монитор, чтобы увидеть, если там был любой диск читает происходит, но что бы не сказал, что ищет какой-то тип в области лесозаготовок бы помочь, но с именем пространства и сумасшедшие вещи, как переводы строк допускается извлечение файла списков может быть сложно. Это было не на сам поврежденный диск правильно? Хорошие скопировать информация не должны иметь никаких ошибок чтения (после fsck), и попытки поиска неисправного накопителя скорее всего, не сделает его здоровее (больше похоже на провал с каждым читать). – Xen2050 16 April 2017 в 04:13

Другие вопросы по тегам:

Похожие вопросы: