ddrescue 속도를 높일 수있는 방법이 있습니까?

약 5 일 전에 500GB 드라이브 HDD 충돌이 발생했습니다. 내가 사용 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매개 변수를 사용했으며 필요에 따라 프로세스를 몇 번 다시 시작했습니다 (매번 중단 된 곳에서 바로 선택하는 것처럼 보였습니다).

이 프로세스 속도를 높일 수있는 방법이 있습니까?

편집 : 6 시간 후 현재 상태입니다.

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는 이탈해야하는 데이터의 양을 카운트 다운하며 시간당 750MB의 속도로 작동하는 것으로 보입니다. 이 속도로 ~ 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더 연속적인 섹터가 복제되어야하기 때문에 비 처리 영역이 클수록 다시 실행할 때 최고라고 가정합니다 .

로그 파일을 사용함에 따라 데이터 읽기 속도가 2가 될 때 Ctrl+로 명령을 취소하는 것을 망설이지 않습니다 C.

또한 -R(Reverse) 모드를 사용 하며 첫 번째 패스 후에는 종종 앞쪽보다 뒤로 읽는 속도가 더 빠릅니다.

명령을 다시 -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를 사용하는 것입니다.

먼저 "ps aux | grep ddrescue"를 사용하여 ddrescue 프로세스의 PID를 찾으십시오.

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"은 "구제하려는 2TB 디스크에서 여전히 처리해야하는 데이터의 양"과 같습니다. (예, 아야) ddrescue는 화면 출력에서 ​​"1720GB"와 비슷한 숫자를 내고 있습니다.

strace는 검사 할 수 있도록 훨씬 더 세분화 된 데이터 스트림을 제공합니다. ddrescue의 속도를 평가하고 완료 날짜를 추정하는 또 다른 방법입니다.

CPU 시간 동안 ddrescue와 경쟁하기 때문에 지속적으로 실행하는 것은 나쁜 계획 일 것입니다. 처음 10 개 값을 가져올 수 있도록 "헤드"로 파이핑했습니다.

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

이것이 누군가를 돕기를 바랍니다.

대량의 데이터를 그대로 유지하는 것이 목표라면 추출 속도를 높일 수 있습니다. 그러나 가능한 한 많은 데이터를 구하고 싶다면 ddrecue가 각각 니블 링하도록하는 것이 좋습니다.

-K 매개 변수를 사용하면 속도를 높일 수 있습니다. -n 옵션으로 실행할 때 ddrescue가 오류를 발견하면 내가 본 것에서 고정 된 양의 섹터를 점프하려고합니다. 여전히 읽을 수 없으면 크기가 두 배로 늘어납니다. 손상된 영역이 큰 경우 큰 K 값 (예 : 100M)을 표시 할 수 있으므로 오류에 대한 점프가 처음에 더 커져서 과거에 문제가있는 영역을 빨리 피하는 것이 더 쉬울 것입니다.

그건 그렇고, 로그를 분석하는 멋진 그래픽 응용 프로그램이 있습니다.

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

복구 이미지와 로그 파일을 저장하는 하드 디스크의 파일 시스템은 무엇입니까? 방금 USB 스틱에서 Linux Mint를 실행하는 랩톱에서 500GB 내장 하드 드라이브 (SATA를 통해 연결됨)를 구출하여 exFat포맷 된 USB 하드 드라이브 에 구조 이미지와 로그 파일을 저장하는 것이 다소 느리게 시작되는 경험을했습니다 (1-2MB / 초) 그러나 약 250GB 후에는 초당 100KB로 크롤링되었습니다. 복구 이미지 파일이 커질수록 속도가 느려지는 것 같습니다.

그런 다음 복구 이미지와 로그 파일을 다른 임시 위치 ext4로 이동하고 파일 시스템으로 USB 하드 드라이브를 다시 포맷 하고 파일을 다시 이동 한 다음 ddrescue 프로세스를 다시 시작했습니다. 이제 1-20MB / sec로 다시 실행됩니다. 그러나 평균 약 7MB / sec)!

exFat매우 큰 파일 (수백 기가 바이트)에서는 잘 재생되지 않는 것 같습니다 .

디스크를 구출하는 더 빠르고 빠른 옵션을 사용하려면 sh 스크립트 파일을 사용하고 "sh filename.sh"로 파일을 실행할 수 있습니다. 여기에 표시된이 줄이 포함되어 있습니다. "sudo ddrescue"와 "sleep 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 1은 1 초의 페일 읽기로 종료됩니다. 속도가 빠른 스크랩이없는 경우 직접 -d 및 -n으로 사용할 수있는 옵션이 있습니다.

-A 옵션을 사용하여 완료 후 -R을 사용하면 모든 오류를 되돌리고 제거하고 거꾸로 다시 시작할 수 있습니다. 오류가 다르게 읽히는 것을 의미합니다.

dd_rhelp 는 전체 디스크에서 dd_rescue "[...]를 사용하는 쉘 스크립트입니다. 그러나 여러 불량 섹터에서 연령대를 시도하기 전에 최대 유효 데이터를 수집하려고 시도합니다."

꽤 오래되었지만 (2012) 여전히 작동합니다. 아직 ddrescue를 시도하지 않았습니다.