ddrescue: перечитанные только хорошие секторы?
Файловые системы Unix/Linux не полагаются на расширения путем, окна делают. Вам не должно быть нужно .py в конце файла для выполнения его.
Можно петлять любым вызовом его с интерпретатором:
python ScriptFile
Или путем маркировки его исполняемый файл и определения интерпретатора на первой строке (например. #!/usr/bin/python).
Если Вы не можете выполнить файл с:
/Path/to/ScriptFile
проверьте полномочия с
ls -l ScriptFile
Вы, возможно, должны добавить исполняемый флаг и chmod это так это выполнится для Вас.
При использовании пользовательских сценариев регулярно, можно хотеть удостовериться каталог, Вы храните их, добавляется к PATH переменная среды.
Полностью перечитанный ddrescue руководство и узнанный следующая опция:
-m file
--domain-logfile=fileОграничьте спасательный домен блоками, отмеченными, как закончено в файле файла журнала. Это полезно, если конечный диск перестал работать во время спасения.
Так вызов ddrescue выглядел бы примерно так:
# ddrescue -d -b 4096 -m sda1.log /dev/sda1 /mnt/sda1.img logfile2.log
Быстрое редактирование 2018:
Я использую ddrescue иногда, от несколько лет назад, для спасения жесткого диска.
Что-то более быстрое, чем dd на HDD с действительно поврежденными поверхностями.
Но dd действительно безопасно, и мое первое сообщение остаются верными.
Исходное сообщение
Это - очень плохая идея!
Я говорю о Прежде, чем отобразить поврежденную файловую систему в файл на другом жестком диске...
Как тогда, когда дисковод становится поврежденным, повреждение обычно растут каждый раз, когда Вы пытаетесь получить доступ к своему диску.
Таким образом, хороший способ спасти поврежденный диск состоит в том, чтобы сделать изображение путем копирования целого диска с, начинают заканчиваться в одной непрерывной операции!. После этого: отключите дисковод и сохраните их бесшумно. Как: меньше Вы касаетесь поврежденного диска, больше шанса, необходимо восстановить что-то.
Как каждый раз, когда доступ механического устройства к отходам мог сделать еще некоторые убытки, журнал, Вами становятся от Вашей последней операции, не является ссылкой для знания, какой блок повреждены теперь.
Я лично, не использовать ddrescue. Я использую dd от некоторое время и этот инструмент делают все, в чем я нуждаюсь:
dd bs=512 if=/dev/sdX of=/backuprepo/sdXBroken.img conv=noerror,sync
И, я позволяю ему работать терпеливо.
-
1
-
2"повредил файловую систему" - если он удачлив, у него только есть проблема программного обеспечения, не аппаратная проблема :) – PythoNic 17.11.2016, 18:53
Зная, что делает ddrecue, вы не должны использовать его для записи в / dev / null при восстановлении данных со сломанного диска, а для получения «хоть чего-нибудь» с помощью записи в файл реального образа.
Запись в / dev / null имеет смысл, например, если вы хотите узнать, стоит ли возвращать новый диск в магазин.
В этом случае я бы не использовал файл журнала из "/ dev / null try", а использовал бы пустой / новый файл, а затем пытался бы в конечном итоге еще несколько раз, в зависимости от того, как это происходит ...
{{ 1}}