Эта команда ddrescue что-то делает?


9

В ходе попытки восстановить данные с неисправного жесткого диска я запускаю команду ddrescue.

Команда выполнялась в течение 9 дней, и я подумал по звуку дисковой активности, что, возможно, она что-то делает. Все это время вывод командной строки выглядел более или менее статичным:

$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:         0 B,  errsize:    500 GB,  current rate:        0 B/s
   ipos:     2539 MB,   errors:       1,    average rate:        0 B/s
   opos:     2539 MB,     time from last successful read:     9.7 d
Splitting failed blocks... 

Одна часть, которая менялась, это где говорится iposи opos. Потребовалось 9 дней, чтобы приблизиться 500000 MB, что является размером неисправного диска. Однако когда он туда попал, он снова упал 0и снова начал подниматься. Когда я пишу это, это примерно так 2580 MBи считается.

Размер создаваемого файла изображения составляет 0 байт.

Файл журнала имеет размер около 3 МБ и выглядит следующим образом:

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
# current_pos  current_status
0x975C3000     /
#      pos        size  status
0x00000000  0x00862000  -
0x00862000  0x00014800  /
0x00876800  0x00800400  -
~~~~~~edited for brevity ~~~~~~~~
0x74702CCE00  0x00320000  -
0x74705ECE00  0x00025800  /
0x7470612600  0x005F3A00  -

Я начинаю беспокоиться, что это просто пустая трата времени, и никакие данные не восстанавливаются вообще.

Есть ли какие-либо указания на этот вывод, что происходит что-то полезное?

Есть ли какая-либо причина, чтобы позволить ddrescueкоманде продолжать работу, как есть, или я должен остановить ее и сделать что-то еще?


Это самое последнее содержание /var/log/syslog

Jun 10 07:29:17 homebase-i3 kernel: [568470.316436] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.316443] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.316450] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Jun 10 07:29:17 homebase-i3 kernel: [568470.316465] end_request: critical target error, dev sdb, sector 301925016
Jun 10 07:29:17 homebase-i3 kernel: [568470.346640] sd 5:0:0:0: [sdb] Unhandled sense code
Jun 10 07:29:17 homebase-i3 kernel: [568470.346646] sd 5:0:0:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jun 10 07:29:17 homebase-i3 kernel: [568470.346651] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.346656] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.346662] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00

Ответы:


8

Я не знаю, пытаетесь ли вы извлечь данные с этого жесткого диска или уже добились успеха, но в случае, если вы не добились успеха и хотели бы попробовать, возможно, вы сможете восстановить потерянные, возможно, потерянные Биткойны или что-то еще, я сделал несколько изменений в параметрах вашей ddrescueкомандной строки, я добавил следующее:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R
  • -d, который говорит ddrescue использовать прямой доступ к диску,
  • --force, который указывает ddrescue принудительно использовать и читать / писать в ваш файл журнала в случае, если он жалуется, что не может использовать его для чтения / записи
  • -R (да, с CAPITAL R), который указывает ddrescueвыполнять операции восстановления в обратном порядке, а не считывать неисправный жесткий диск в режиме пересылки. Иногда чтение в обратном направлении помогает, когда ущерб является значительным, поскольку это позволяет обойти кеш жесткого диска в случае возникновения проблем.

В настоящее время я использую эти команды (за исключением того, что я не использую 3команду, так как я не хочу, чтобы [YET] ddrescueповторял плохие сектора, я оставлю это напоследок, после того, как мой первый цикл будет завершен, и я добиваюсь большого успеха, спасая данные с моего неисправного жесткого диска Seagate емкостью 1 ТБ, на котором, как я предполагаю, находилось несколько биткойнов, которые я мог добывать еще в 2009–2010 годах, возможно, я обнаружил от 1 до 3 блоков по 50 BTC каждый, надеюсь, это на этом жестком диске, В общей сложности мне потребуется более 15 дней, чтобы выполнить операцию со средней скоростью чтения 634 кбит / с.

Кроме того, я хотел бы добавить, что вы можете и, скорее всего, основываясь на своем предыдущем послужном списке более чем 9 ДНЕЙ «последнего чтения», вы столкнетесь с ситуацией, когда жесткий диск просто откажется читать дальше, в этом В этой ситуации просто нажмите CTRL + C, чтобы отменить, поскольку вы используете файл журнала, отсоедините кабель SATA от неисправного жесткого диска, но не от контроллера USB от порта USB (да, вместо подключения к SATA используйте контроллер USB SATA). материнская плата, чтобы она не блокировала весь компьютер, что привело к принудительной перезагрузке, а затем снова включите питание SATA, чтобы перезагрузить жесткий диск, подождите 10 секунд, а затем нажмите стрелку вверх или вниз, чтобы перезагрузить предыдущий терминал. команда и перезапуститеddrescueОперация, благодаря вашему предыдущему журналу, она будет продолжаться с того места, где она в последний раз остановилась, и будет выполняться чтение, а «последнее успешное чтение» всегда должно оставаться на «0 с» (ноль секунд), где это должно быть, что указывает ddrescueна успешность в чтение с жесткого диска, и если вы когда-нибудь заметите, что «последнее чтение с» начинает считать секунды, просто снова завершите ddrescueс помощью CTRL+ C, выключите и снова включите питание жесткого диска и перезапуститеddrescueнет смысла ждать, чтобы увидеть, перезапустится ли «последнее чтение из» обратно в ноль самостоятельно, исходя из моего опыта, этого никогда не произойдет, вы будете ждать вечность. Мне пришлось выключить и выключить мой жесткий диск объемом 1 ТБ примерно в 20 раз, прошло около 7 дней, и я очень близок к достижению восстановленной отметки в 500 ГБ, на полпути до сих пор, надеюсь, я не столкнусь с какими-либо серьезными сбоями, так как Я близок к 100%, так как он работает безупречно в течение последних 3 дней, снова со скоростью более 634 кбит / с.

Кроме того, не жадничайте при попытке получить более высокую скорость чтения данных, так как моя попытка попробовать много параметров и блоков разных размеров почти оставила меня с совершенно мертвым жестким диском, который перестанет работать через 1 секунду после включения / выключения питания. (это было 5 дней назад), но, к счастью, это только начало снова показывать признаки жизни, первоначально читая со скоростью 2000 б.с. (да, БАЙТОВ в секунду) чуть меньше 2 Кбит / с, я был очень разочарован, но после отменыddrescueс CTRL + C и просто перезапустить его еще раз (в обратном направлении с добавленным параметром -R), затем скорость вернулась к 630, прежде чем я начал читать вперед со скоростью 930 кбит / с, по крайней мере, я доволен, что я делаю 630 кбит / с наоборот и не нужно откладывать с 2kbps, так что если вы добьетесь успеха на любой скорости чтения, как в случае с палкой диапазона 500 kbps, и не пытаетесь что-либо увеличить скорость, это может быть вашей последней успешной попыткой получить любая скорость чтения.

В качестве альтернативы, если ddrescueэто вам не подходит, потому что вы ничего не можете прочитать, независимо от того, какие параметры вы пытаетесь использовать, вы можете рассмотреть вопрос о замене логической платы с жесткого диска, поскольку 90% времени идет на работу логической платы. Плохо, но сначала снимите плату логики и почистите все контакты, которые соприкасаются со штырьками жесткого диска, иногда эти контакты получают черноватую клейкую смесь, разрывая контакт, который может стать причиной вашей неисправности. Но имейте в виду, что если вам придется заменить логическую плату вашего жесткого диска, вам нужно будет получить одну из той же марки, серийный номер (рядом с), номер модели, номер редакции, потому что она должна быть такой же, как оригинал для донорская доска для работы.


2
Возможно, вы захотите немного отредактировать эту стену текста.
СЛМ

4
На самом деле я подумал, что это один из самых конструктивных и подробных постов, которые я видел по этому вопросу. Надеюсь, вы не возражаете, я только что добавил похожий вопрос unix.stackexchange.com/q/219365/125662, в котором упоминается ваш действительно полезный вклад
baroquedub

1
Из руководства GNU ddrescue: "--force Принудительная перезапись outfile. Необходима, когда outfile - это не обычный файл, а устройство или раздел. Этот параметр является лишь защитой от случайного уничтожения разделов и игнорируется для обычных файлов. «. Это не о mapfile / logfile.
Arch Linux Tux

Пожалуйста, исправьте описание --forceопции, это не правильно
эндолит

5

Вы должны быть в состоянии остановиться, ddrescueпоскольку он использует файл журнала, чтобы иметь возможность перезапустить свою работу (закрыть) с того места, где он остался. Однако я бы проверил, был ли недавно обновлен файл журнала, посмотрев на отметку времени или выполнив tail -f /home/dave/recovery_usb500.logfile.

То, что ваш файл изображения все еще настолько мал, может быть связано с тем, что еще не были успешно извлечены блоки с диска. Это, однако, было бы плохим результатом после всего этого времени работы. Предполагая, что на устройстве всего несколько плохих блоков, и что они не находятся в начале, ваш статус первых записей будет +. IIRC ddrescueначинает чтение до тех пор, пока не обнаружит ошибку, а затем начнет разделять оставшуюся часть диска. Ваш диск, кажется, выходит из строя с самого начала.

Если +в журнале нет (несколько) записей и размер вашего файла все равно будет, 0я не думаю, что ddrescueэто неправильно. Нет, +значит, что с вашего диска ничего не удалось восстановить. Это может означать перегоревшую электронику или плохую голову, так как в случае неисправности нескольких секторов вы получите результаты намного быстрее.

Что касается еще чего-то. Я предполагаю, что вы уже пытались прочитать несколько блоков с нормальным дд. Вы смотрели на системный журнал на основе этого и погуглили все найденные там сообщения?


Поиск «Result: hostbyte = invalid driverbyte = DRIVER_SENSE» приводит к нескольким интересным прочтениям (частично по-немецки) с еще несколькими предложениями:

  • Попробуйте подключиться через USB 1.1 вместо 2.0
  • Дисковод может нагреться, поэтому оберните его пластиком и поместите в холодильник на 10 минут, что дает некоторое время для чтения, прежде чем диск снова нагреется.
  • Переключатель SMART в BIOS (и подключение с SATA).
  • Убедитесь, что на USB-накопителе достаточно энергии (дополнительный источник питания)
  • Если через какое-то время чтение через USB не удается, используйте USB-концентратор с дистанционным управлением, где вы программно переключаете питание с USB-концентратора на накопитель на несколько секунд.

Помимо охлаждения нечитаемого диска (с охлаждающим спреем) я не пробовал ничего из этого сам.


Спасибо за ответ. Я не пробовал "нормальный" dd, так как я не знаю, что это такое. Мне кажется, что большая часть диска и данных не повреждена, но есть некоторая неисправность в некоторой критической области диска, где происходит индексация или просмотр файлов.
Вопрос

Вы можете считать ddrescueэто производной от ddэтого не останавливается, когда возникает ошибка. Вы проверяли на +признаки?
Anthon

В лог-файле нет никаких +признаков. Есть только -и \ знаки.
Вопрос

Это означает, что ничего еще не восстановлено, и я думаю, что вряд ли это ddrescueначнется после всего этого времени. Если вы хотите, мы можем поболтать (ссылка вверху этой страницы) об этом
Anthon

Я добавил содержание /var/log/syslogк вопросу.
Вопрос
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.