Ця команда ddrescue робить щось?

Під час спроби відновити дані з несправного жорсткого диска , я запускаю команду 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. Щоб обійтись навколо 500000 MB, знадобилося 9 днів , який розмір несправного дискового накопичувача. Коли він потрапив туди, однак потім відкинувся назад 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

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

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -d, що вказує ddrescue використовувати прямий доступ до диска,
• - сила, яка повідомляє ddrescue насильно використовувати та читати / записувати у ваш файл реєстрації у випадку, якщо він скаржиться, що не може використовувати його для цілей читання / запису
• -R (так, з CAPITAL R), який повідомляє ddrescueвиконувати операції відновлення в зворотному порядку, а не зчитувати з ладу жорсткий диск у режимі перемотки. Іноді читання в зворотному порядку допомагає, коли пошкодження значні, оскільки це обходить кеш-пам’ять жорсткого диска у випадку, якщо там є проблеми.

В даний час я використовую ці команди (за винятком того, що я не використовую 3команду, оскільки я не хочу [ТАК] ddrescueповторювати погані сектори, я залишаю це останньою, після того, як буде зроблено перше зачитування, і я маю великий успіх врятування дані з мого невдалого жорсткого диска Seagate 1 Тб, де я ВИПУСКЮ, можливо, я маю кілька біткойнів, які я, можливо, видобував ще в 2009 - 2010 роках. Можливо, я знайшов від 1 до 3 блоків по 50 BTC кожен, сподіваюся, це на цьому жорсткому диску мені знадобиться понад 15 днів, щоб завершити операцію зі швидкістю зчитування в середньому 634 кбіт / с.

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

Крім того, не будьте жадібними намагатися отримати більш швидку швидкість зчитування даних, оскільки моя спроба спробувати багато параметрів і різних розмірів блоку майже не залишила мене повністю мертвою жорсткою річкою, яка перестане працювати більше 1 секунди після того, як потужність перемикає її (це було 5 днів тому), але, на щастя, він лише почав ще раз показувати ознаки життя, спочатку читав зі швидкістю 2000 Bs (так, BYTES в секунду) трохи менше 2kbps, я був дуже розчарований, але після скасуванняddrescueз CTRL + C і просто перезапустити його ще раз (у зворотному порядку з -R) додано параметр, потім швидкість повернулася до 630, перш ніж я читав вперед 930 кбіт / с, принаймні, я вмію, що я роблю 630 кбіт / с у зворотному напрямку і не потрібно відкладати 2 кбіт / с, тому якщо ви отримаєте успіх на будь-якій швидкості читання, як, наприклад, в діапазоні 500 кбіт / с, і не намагайтеся нічого піднімати швидкість вище, це може бути вашою останньою успішною спробою отримати будь-яка швидкість читання.

Крім того, якщо вам ddrescueце не приносить користі, оскільки ви не можете нічого прочитати, незалежно від параметрів, які ви намагаєтеся, ви можете розглянути можливість заміни логічної плати на жорсткому диску, оскільки 90% часу це логічна плата йде погано, але спочатку зніміть логічну плату та очистіть усі контакти, що створюють контакти із штифтами жорсткого диска, інколи ці контакти отримують у ній чорнушку гую суміш, розриваючи контакт, яка може стати джерелом вашої невдачі. Але майте на увазі, що якщо вам доведеться замінити логічну плату вашого жорсткого диска, вам доведеться отримати одну і ту ж марку, серійний номер (близький до), номер моделі, номер редакції, оскільки він повинен бути таким же близьким, як оригінал для донорська рада працювати.

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

Що ваш файл зображень все ще малий, можливо, це не стосується того, що блоки ще не були успішно отримані з диска. Однак це було б поганим результатом після закінчення цього часу. Якщо припустити, що на пристрої є лише кілька поганих блоків, і що вони ще не на початку, ваш статус перших записів буде +. IIRC ddrescueпочинає читати, поки не знайде помилку, а потім починає розбивати решту диска. Здається, ваш диск вийшов з ладу з самого початку.

Якщо +в журналі немає (декількох) записів і розмір вашого файлу все ще буде, 0я не думаю, що ddrescueце неправильно. Нічого не +означає, що з вашого накопичувача нічого не було відновлено. Це може означати смажену електроніку або погану голову, оскільки у випадку несправності лише декількох секторів ви мали б результати швидше.

Що стосується чогось іншого. Я припускаю, що ви вже спробували прочитати кілька блоків із звичайним дд. Ви подивилися на системний журнал на основі цього і гуглили будь-які повідомлення, які ви знайшли там?

Пошук "Результат: hostbyte = недійсний драйвер = DRIVER_SENSE" приводить до кількох цікавих читань (частково німецькою мовою) та ще декілька пропозицій:

• Спробуйте підключитися через USB 1.1 замість 2.0
• Привід може нагрітися, тому загорніть його в пластик і поставте в холодильник на 10 хвилин, це дає деякий час для читання, перш ніж накопичувач знову нагріється.
• перемикач SMART в BIOS (і підключення до SATA).
• Переконайтесь, що USB-накопичувач має достатню потужність (додаткове джерело живлення)
• Якщо через деякий час зчитування через USB не вдається, скористайтесь дистанційно керованим USB-концентратором, де програмуйте енергію з USB-концентратора на накопичувач протягом декількох секунд.

Окрім охолодження нечитабельного диска (за допомогою охолоджуючого спрею), я жодного з них не пробував.