약 5일 전에 500GB 드라이브 HDD 충돌이 발생했습니다. ddrescue며칠 전에 중요한 파티션을 사용했는데 지금은 거의 이틀 동안 "실패한 블록 트리밍"에 있었습니다.
원래 명령:
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시간 내에 완료됩니다. 좋아요.
편집 #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...
답변1
-n(분할 없음) 옵션을 -r 1(한 번 다시 시도) 와 함께 사용하고 -c(클러스터 크기)를 더 작은 값으로 설정하는 것이 도움이 될 수 있다는 것을 확인했습니다 .
ddrescue내 생각에는 손상된 부분을 쪼개고 다시 쪼개기 때문에 분할 단계가 매우 느리다는 것입니다 . ddrescue아주 작은 부분의 데이터를 복원하려고 하기 때문에 시간이 많이 걸립니다 . 그래서 나는 (no-split)을 , , , aso -n와 함께 사용하는 것을 선호합니다.-c 64-c 32-c 16
아마도 -n(분할 없음)은 정방향 및 역방향의 첫 번째 패스에 항상 사용해야 합니다. 데이터가 많이 분할될수록 복제 속도가 느려지는 것 같지만 확실하지는 않습니다. 처리되지 않은 영역이 클수록 ddrescue다시 실행할 때 가장 좋다고 가정합니다. 더 많은 연속 섹터가 복제되기 때문입니다.
저는 로그파일을 사용하고 있기 때문에 데이터 읽기 속도가 2배 느려지면 주저하지 않고 Ctrl+ 로 명령을 취소합니다.C
나는 또한 -R(역방향) 모드를 사용하는데 첫 번째 패스 후에는 앞으로 읽는 것보다 뒤로 읽는 속도가 더 빠른 경우가 많습니다.
명령을 다시 실행할 때, 특히 정방향(기본값) 및 역방향( ) 복제 명령을 번갈아 사용할 때 이미 재시도된 섹터( -r N)가 어떻게 처리되는지 명확하지 않습니다 . 시도한 횟수가 로그 파일에 저장되어 있는지 확실하지 않으며 아마도 작업이 다시 쓸모 없게 수행되었을 것입니다.ddrescue-R
아마도 -i(입력 위치) 플래그도 작업 속도를 높이는 데 도움이 될 수 있습니다.
답변2
의 진행 상황을 확인하는 것은 매우 어려울 수 있지만 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실행 중에도 사용할 수 있습니다 .
답변3
-K 매개변수를 사용하면 작업 속도를 높일 수 있다는 것을 알았습니다. -n 옵션을 사용하여 실행할 때 ddrescue가 고정된 양의 섹터를 점프하려고 시도할 때 오류를 발견한 경우 내가 본 것입니다. 여전히 읽을 수 없으면 크기가 두 배로 늘어납니다. 손상된 영역이 큰 경우 큰 K 값(예: 100M)을 표시할 수 있으므로 처음에는 오류로 인한 점프가 더 커지고 처음에는 문제가 있는 영역을 빠르게 피하는 것이 더 쉬울 것입니다.
그건 그렇고, 로그를 분석하는 훌륭한 그래픽 응용 프로그램이 있습니다.
답변4
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
이것이 누군가에게 도움이 되기를 바랍니다.