Чи є спосіб пришвидшити ddrescue?

У мене відбувся збій жорсткого диска на 500 ГБ близько 5 днів тому. Я використовував ddrescueна важливому розділі кілька днів тому, і він був на "Обрізання невдалих блоків" вже майже 2 дні.

Оригінальна команда:

ddrescue -n /dev/rdisk1s2 /Volumes/OSXBackup/rdisk1s2.img /Volumes/OSXBackup/rdisk1s2.log

Поточний вихід:

Initial status (read from logfile)
rescued:   248992 MB,  errsize:   1007 MB,  errors:   15867
Current status
rescued:   249021 MB,  errsize:    978 MB,  current rate:    17408 B/s
   ipos:    44405 MB,   errors:   15866,    average rate:     2784 B/s
   opos:    44405 MB,     time from last successful read:       0 s
Trimming failed blocks...

Оригінальна команда використовувала ddrescue -nпараметр, і я кілька разів перезапустив процес (і, здавалося, підбирався прямо там, де він щоразу припинявся).

Чи є спосіб прискорити цей процес?

Редагувати: Через шість годин це поточний статус:

rescued:   249079 MB,  errsize:    920 MB,  current rate:      409 B/s
   ipos:    39908 MB,   errors:   15851,    average rate:     2698 B/s
   opos:    39908 MB,     time from last successful read:       0 s
Trimming failed blocks...

Схоже, що під час "помилок" неприємно відлічується, ipos / opos відраховує, скільки даних має пройти, і, здається, працює зі швидкістю 750 Мб / годину. З цією швидкістю він завершиться через ~ 53 години. Yikes.

Редагування №2: Через два дні все ще працює. Однак є надія. Він перемістився, пройшовши частину "Обрізка невдалих блоків", і перейшов до наступної фази "Розбиття невдалих блоків". Якщо що-небудь, то, що слід відмовитися від перегляду цього питання, це те, що це, безумовно, займе багато часу, коли задіяно велику кількість даних / помилок. Єдина моя надія, що я можу успішно відновити деякі важливі дані, коли все буде сказано і зроблено.

rescued:   249311 MB,  errsize:    688 MB,  current rate:        0 B/s
ipos:    26727 MB,   errors:   15905,    average rate:     1331 B/s
opos:    26727 MB,     time from last successful read:      20 s
Splitting failed blocks...

Я помітив, що використання параметра -n(без розділення) разом із -r 1(повторити один раз) та встановлення -c(розмір кластера) на менше значення може допомогти.

Моє враження, що крок розщеплення дуже повільний, оскільки ddrescueрозщеплює і знову розщеплює пошкоджені ділянки. Це займає багато часу, оскільки ddrescueнамагається відновити дуже малі частини даних. Тому я вважаю за краще не використовувати -n(НЕ-спліт) разом з -c 64, -c 32, -c 16, Асо

Ймовірно, що -n(без розбиття) завжди слід використовувати один прохід вперед і назад. Здається, що чим більше даних розбито, тим повільніше клонування, хоча я не впевнений у цьому. Я припускаю, що більша кількість необроблених ділянок, найкраща при ddrescueповторному запуску , тому що більш клопотні сектори мають клонуватися.

Оскільки я використовую логінфайл, я не соромлюсь скасувати команду за допомогою Ctrl+, Cколи швидкість зчитування даних стане двома низькими.

Я також використовую -R(Зворотний) режим, і після першого проходу він часто дає мені швидкість читання назад, ніж вперед.

Мені незрозуміло, як уже повторені сектори ( -r N) обробляються при ddrescueповторному виконанні команди, особливо при чергуванні -Rкоманд клонування вперед (за замовчуванням) та зворотного ( ). Я не впевнений, чи кількість разів, яку вони намагалися зберігати, зберігається у лог-файлі, і, ймовірно, робота знову робиться марною.

Можливо, -iпрапор (позиція введення) може також допомогти пришвидшити справи.

Помітити прогрес може бути дуже важко ddrescue, але є ще одна команда, що називається ddrescuelog.

Проста команда ddrescuelog -t YourLog.txtвиведе ці приємні відомості:

current pos:     2016 GB,  current status: trimming
domain size:     3000 GB,  in    1 area(s)
rescued:     2998 GB,  in 12802 area(s)  ( 99.91%)
non-tried:         0 B,  in    0 area(s)  (  0%)

errsize:     2452 MB,  errors:   12801  (  0.08%)
non-trimmed:   178896 kB,  in 3395 area(s)  (  0.00%)
non-split:     2262 MB,  in 9803 area(s)  (  0.07%)
bad-sector:    10451 kB,  in 19613 area(s)  (  0.00%)

Ви навіть можете використовувати його під час ddrescueзапуску ...

Ще один спосіб контролювати хід ddrescue (принаймні на Linux) - це використання strace.

Спочатку знайдіть PID для процесу ddrescue за допомогою "ps aux | grep ddrescue"

root@mojo:~# ps aux | grep ddrescue
root     12083  0.2  0.0  15764  3248 pts/1    D+   17:15   0:04 ddrescue --direct -d -r0 /dev/sdb1 test.img test.logfile
root     12637  0.0  0.0  13588   940 pts/4    S+   17:46   0:00 grep --color=auto ddrescue

Потім запустіть "strace" проти цього процесу. Ви побачите щось на кшталт:

root@mojo:~# strace -p 12083
Process 12083 attached - interrupt to quit
lseek(4, 1702220261888, SEEK_SET)       = 1702220261888
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET)       = 1702220261376
read(3, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET)       = 1702220261376
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
^C

...і так далі. Вихід швидкий і некрасивий, тому я передаваю його через "grep", щоб відфільтрувати речі, які мені цікаві:

root@mojo:/media/u02/salvage# nice strace -p 12083 2>&1|grep lseek
lseek(4, 1702212679168, SEEK_SET)       = 1702212679168
lseek(3, 1702212678656, SEEK_SET)       = 1702212678656
lseek(4, 1702212678656, SEEK_SET)       = 1702212678656
lseek(3, 1702212678144, SEEK_SET)       = 1702212678144
lseek(4, 1702212678144, SEEK_SET)       = 1702212678144
lseek(3, 1702212677632, SEEK_SET)       = 1702212677632
lseek(4, 1702212677632, SEEK_SET)       = 1702212677632
lseek(3, 1702212677120, SEEK_SET)       = 1702212677120
lseek(4, 1702212677120, SEEK_SET)       = 1702212677120
lseek(3, 1702212676608, SEEK_SET)       = 1702212676608
^C

У цьому прикладі "1702212676608" прирівнюється до "кількості даних, які ще потрібно обробити на тому 2 Тб диску, який ви намагаєтеся виправити". (Так. Ой.) Ddrescue виплюває аналогічне число - хоч як "1720 ГБ" - у своєму екрані.

strace дає МНОГО більш високий потік даних про деталізацію, який Ви зможете вивчити; це ще один спосіб оцінити швидкість ddrescue та визначити дату завершення.

Запускати його постійно - це, мабуть, поганий план, оскільки він би конкурував з ddrescue за час процесора. Я взяв трубку до "голови", щоб я міг схопити перші 10 значень:

root@mojo:~# strace -p 4073 2>&1 | grep lseek | head

Сподіваюся, що це комусь допоможе.

Якщо ваша мета - отримати більшу частину даних неушкодженими, ви можете прискорити її вилучення. Але якщо ви дійсно хочете врятувати якомога більше даних, тоді дозволяйте ddrecue гризти кожен і кожен - це маршрут, який потрібно пройти.

Я виявив, що граючи з параметром -K, ви можете прискорити роботу. З того, що я бачив, якщо ddrescue виявляє помилку під час роботи з опцією -n, намагається стрибнути фіксовану кількість секторів. Якщо він досі не вміє читати, він стрибає вдвічі більше. Якщо у вас великі пошкоджені ділянки, ви можете вказати велике значення K (наприклад, 100 М), і тому стрибок на помилку вперше буде більшим, і в першому минулому буде легше уникнути проблемних ділянок.

До речі, є чудовий графічний додаток для аналізу журналу.

http://sourceforge.net/projects/ddrescueview/

Яка файлова система жорсткого диска, на якій ви зберігаєте рятувальне зображення та журнал файлів? Я щойно переконався, що порятунок внутрішнього жорсткого диска потужністю 500 Гб (підключений через SATA) на ноутбуці під управлінням Linux Mint від USB Stick, зберігаючи рятувальне зображення та журнал файлів на exFatвідформатованому жорсткому диску USB, починався досить повільно (1-2 Мб / сек), але приблизно за 250 Гб він повзав лише зі швидкістю <100 КБ / сек. Здавалося, він стає повільніше, чим більший файл рятувального зображення зростав.

Потім я перемістив рятувальне зображення та файл реєстрації в інше тимчасове місце, переформатував жорсткий диск USB за допомогою ext4файлової системи, перемістив файли назад на нього та відновив процес ddrescue - і тепер він працює з 1-20 МБ / сек знову (коливається але в середньому близько 7 Мб / сек)!

Здається, exFatвін не дуже добре відтворює дуже великі файли (кілька сотень гігабайт).

Для більш швидкого та швидкого варіанта порятунку диска ви можете використовувати файл скрипту sh та запустити файл з "sh filename.sh". Він містить цей рядок, показаний, просто повторіть "sudo ddrescue" і "сон 3" ще кілька разів, сон використовується для того, щоб привід відпочив кілька секунд, це може бути корисно з деяких причин:

#! /bin/sh -e  
sudo ddrescue -d -r0 -e +0 -T 1s -n /dev/drivepartition file.img log.logfile 
sleep 3

-R0 не відповідає. -E +0 призначений для виходу з помилкою 1. -T 1s закінчується зчитуванням невдачі за 1 секунду. Існують варіанти, які можна використовувати як -d для прямого і -n без відколів, які можуть прискорити.

Ви можете використовувати -R після закінчення з опцією -А один раз, що скасує та видалить усі помилки та почнеться знову назад. Значить, вона буде читати помилки по-різному.

dd_rhelp - це скрипт оболонки, який використовує dd_rescue "[...] на всьому диску, Але НЕ намагатиметься зібрати максимально допустимі дані, перш ніж намагатись на віки на пучках значків"

він досить старий (2012), але все ще працює. ще не пробував ddrescue.