☰

ddrescue가 매우 느림, NTFS에 쓰기 - 지금 Ext4로 변환할 가치가 있습니까?

tag-icon • tag-icon ntfs hard-drive-recovery ddrescue
ddrescue가 매우 느림, NTFS에 쓰기 - 지금 Ext4로 변환할 가치가 있습니까?

이틀 전 저는 대부분을 저렴한 가격에 구할 수 있기를 바라며 나에게 건네준 1TB 고장난 HDD의 복구를 시작했습니다.

처음에는 비정상적으로 작동하여 갑자기 연결이 끊어지고 무서운 소음을 내는 경우가 많았으며 복사 속도는 초당 몇 KB에서 초당 약 50MB 사이였습니다(더운 날이었는데 노트북 냉각 패드로 과열을 방지하려고 노력했습니다). 아래에는 냉각 블록이 있고 그 위에 냉각 블록이 있는데 매 시간마다 교체했습니다.) 그러다가 첫날 저녁에는 좀 더 안정되었으나, 평균 복사 속도가 3~4MB/s 정도로 크게 떨어졌습니다. 이제 250GB를 복구한 후 평균 약 400KB/s로 떨어졌는데, 이는 고통스러울 정도로 느립니다(적어도 더 이상 감소하지는 않는 것 같습니다).

그래서 내 질문은 다음과 같습니다

  • 저는 NTFS 파티션으로 복구를 수행하고 있습니다. 프로세스 후반에 읽은 내용에 따르면(이 프랑스어 가이드), 복구 속도가 상당히 느려질 수 있으므로 권장되지 않습니다. 그것이 (여전히) 사실인가요? 그렇다면 왜 그렇습니까?
    • 아니면 Linux용 NTFS 드라이버가 충분히 성숙되지 않은 과거의 일입니까? (저는 최신 Knoppix 라이브 DVD를 사용하고 있는데 DVD-RW에서 성공적으로 부팅되지 않아 메모리 카드에 복사했습니다.)
  • 이 단계에서 파티션을 Ext4와 같은 기본 Linux 형식으로 변환하는 데 어려움을 겪을 가치가 있습니까? 내 말은, 복사 속도가 크게 향상될까요?
    • 아니면 대부분의 "정상" 섹터가 이미 복구된 첫 번째 단계 이후 드라이브 오류로 인해 이러한 속도 저하가 발생하는 것이 정상입니까? (SMART 매개변수가 악화되고, '종합 건강 자체 평가 테스트 결과'가 'PASSED'에서 'FAILED'로 바뀌고, 재할당된 섹터 수가 144개에서 1360개로 변경되었습니다.)
  • 복구율 및/또는 복구 속도를 향상시키기 위해 할 수 있는 다른 방법이 있습니까?
  • ddrescue실제적인 이점을 얻을 수 있는 옵션이 있습니까 ?

다음 명령을 사용하여 첫 번째 실행을 수행했습니다.

ddrescue -n -N -a500000 -K1048576 -u /dev/sdc /media/sda1/Hitachi1TB /media/sda1/Hitachi1TB.log

( -n& -N스위치는 스크래핑 및 트리밍 단계를 우회하는 것으로 추정됩니다. 프로세스의 어느 시점에서 프로그램이 이러한 작업을 시도하는지, 실제로 이를 우회하는 데 유용한지는 확실하지 않습니다. 그런 다음 최소 복사 속도를 500000으로 지정했습니다. 초당 바이트 수, "읽기 오류 시 건너뛸 초기 크기" 값은 1MB로, 여전히 정상이거나 액세스하기 쉬운 영역을 최대한 빨리 복사하려고 시도합니다. 이는 -u"단방향"을 위한 것입니다. 스위치를 사용하여 역방향으로 복사하는 또 다른 HDD는 -R문제를 개선하는 것처럼 보였지만 이 HDD를 사용하면 큰 혼란을 야기하는 것으로 보이며 해당 스위치를 사용하면 분명히 더 안정적입니다.)

이제 한 번의 패스가 완료된 후 이러한 매개변수 대부분을 제거하고 -u. 어느 시점에서 스위치를 시도했지만 -d("직접 디스크 액세스 사용") 아무 것도 복사되지 않았고 "오류 크기"가 매우 빠르게 커졌습니다.

답변1

위의 의견을 완성하려면(공식적으로 불편을 끼쳐드려 죄송합니다.) 이유를 잘 이해하지 못하더라도 그만한 가치가 있다고 말하고 싶습니다. Ext4 파티션으로 복구하는 두 번째 시도에서는 처음에 복사 속도가 훨씬 더 높았습니다(평균 약 90MB/s인 반면, NTFS 파티션으로 복구한 첫 번째 시도에서는 기껏해야 약 50MB/s에 불과했습니다). , 오류나 속도 저하도 없습니다. 그런데 약 165GB(이전보다 훨씬 이전)를 복사한 후 매우 불안정해지며 크롤링 속도로 느려지고 다시 딸깍 소리와 윙윙거리는 소음이 발생했습니다(아주 더운 기간이어서 도움이 되지 않았습니다. 냉각하려고 노력했습니다). 아래에 노트북 냉각 패드를 놓고 그 위에 냉동 팩을 사용하여 가능한 한 많이 내려 놓고 매 시간마다 교체) ; 계속해서 시도했지만(가끔 몇 초 동안 120MB/s 속도로 돌아왔다가 다시 0으로 돌아옴) 잠시 후에 포기해야 했습니다.

ddrescueview첫 번째 복구 지도 는 다음과 같습니다 .
ddrescueview 첫 번째 시도 NTFS 파티션

쉽게 복구된 데이터 스트라이프가 매우 느리거나 읽을 수 없는 데이터와 번갈아 나타나는 흥미로운 패턴이 있습니다.[내가 아는 바로는 헤드가 플래터에 닿아 표면이 손상되고 자성 먼지가 방출되어 원심력에 의해 퍼지는 것으로 보입니다. 그리고 서보 트랙(시동 프로세스에 대한 필수 정보가 포함되어 있음)이 하드 드라이브(3.5" Hitachi 1TB)의 바깥쪽 가장자리에 있기 때문에 먼지 중 일부가 여기에 도달하여 접근하기 어려울 수 있습니다. 시작 시 자주 발생하는 클릭 소음을 설명할 수 있습니다.](틀렸다면 정정해주세요.) => [EDIT 20200501] 틀렸습니다. 실제로 이 패턴은 일반적으로 드라이브의 한 헤드가 완전히 고장나서 더 이상 아무것도 읽지 않는다는 것을 나타냅니다. 플래터의 데이터는 여전히 읽을 수 있을 수 있습니다. 이 시점에서는 헤드 스택 어셈블리를 교체해야 하며 전문 데이터 복구 연구소에서만 안전하게 수행할 수 있습니다.

ddrescueview두 번째 회복 지도는 다음과 같습니다 .
ddrescueview 두 번째 시도 Ext4 파티션

그래서 165GB 정도 지나면 하드디스크가 매우 불안정해지고 복구도 점점 어려워지는데, 그 전에는 건너뛰는 부분 없이 복사율이 일관되게 높았습니다. 나중에 ddru_ntfsbitmap마지막 시도에서 이 방법을 사용했기 때문에 할당되지 않은 공간은 대부분 건너뛰었습니다.

ddrescueview다음은 로 생성된 로그 파일의 맵 입니다 ddru_ntfsbitmap. 실제 데이터가 포함된 하드 드라이브 영역은 녹색으로, 여유 공간은 회색으로 표시됩니다.
ddrescueview ddru_ntfsbitmap 로그 파일

다행히 실제 데이터의 대부분은 1분기에 위치하여 성공적으로 복구되었습니다. 이제 나는 아직 두 이미지의 좋은 부분을 결합하고 아마도 R-Studio(내가 시도한 최고의 데이터 복구 소프트웨어)를 사용하여 실제 파일을 추출하지 않았습니다.

처음 질문과 관련하여 나중에 발견한 흥미롭고 특이한 점 중 하나(공식 규칙에 따라 이 내용을 주석으로 넣었어야 했지만 너무 길어져서 스크린샷을 제공할 수 없었을 것입니다) .

이미지 1에서 누락된 Ext4 파티션의 이미지 2의 복구된 영역을 NTFS 파티션 {1} 의 해당 이미지 1에 복사하려고 했습니다 . 이 작업은 매우 빠른 속도로 수행되어야 했습니다(입력 및 출력). 건강한 2TB HDD를 사용 중), 평균 속도는 660KB/s에 불과했습니다. 따라서 처음에 이 질문을 할 만큼 걱정이 되었을 때 이후 단계의 초기 복구 속도에 매우 가깝습니다. ..

사용된 명령(도메인 로그 파일로 사용되는 이미지 2의 로그 파일):

ddrescue -m [image2.log] [image2] [image1] [image1.log]

스크린샷:
ddrescue 복사 구조 영역 이미지 2를 이미지 1로

그래서 저는 멈추고 그 반대로 했습니다. 이미지 2(Ext4)에서 누락된 이미지 1(NTFS)의 복구된 영역을 해당 이미지 2에 복사했습니다. 이제 복사 속도는 약 43000KB/s 또는 43MB/s였습니다. 평균적으로(최대 쓰기 속도가 200MB/s에 가까운 Seagate 2TB의 경우 동일한 HDD에 복사할 때 예상되는 것보다 약간 느릴 수 있으므로 한 번에 약 100MB/s에 도달할 수 있어야 함) 한 파티션에서 다른 파티션으로 복사하지만 여전히 첫 번째 시도보다 거의 100배 더 좋습니다. 이렇게 엄청난 불일치에 대한 설명은 무엇입니까?

사용된 명령(도메인 로그 파일로 사용되는 이미지 1의 로그 파일):

ddrescue -m [image1.log] [image1] [image2] [image2.log]

스크린샷:
ddrescue 복사 구조 영역 이미지 1 ~ 이미지 2

 두 파티션의 이미지 파일에는 실제로 기록된 데이터 양에 해당하는 "디스크 상의 크기" {2} 가 있다는 것을 알았습니다. 실제로 기록하지 않았음에도 불구하고 전체 크기(1TB 또는 931.5GB)와는 매우 거리가 멀었습니다. 스위치 를 사용하지 마십시오 -S("출력 파일에 스파스 쓰기 사용"). 이미지 2(이미지 1에서 추가 복구 영역이 완성된 후)의 "디스크 크기"는 308.5GB이고, 이미지 1의 "디스크 크기"는 259.8GB입니다. Linux NTFS 드라이버가 희박한 쓰기를 처리하는 데 문제가 있는 경우 느린 복사 속도와 관련이 있을 수 있습니까? 그리고 해당 스위치를 사용하지 않았는데 마지막 섹터가 기록되자마자 전체 크기가 할당되지 않은 이유는 무엇입니까 -S?

나는 프로세스 초기에 스위치(“사전 할당”)를 사용하려고 했는데 -p, 그것이 “더 깨끗”하고, 더 간단하고, 문제가 발생할 경우(복구를 복구해야 하는 경우) 처리하기 더 쉬울 것이라고 생각했습니다. ..), 하지만 너무 길어서 최대한 빨리 시작하고 싶었기 때문에 중지해야 했습니다(분명히 단순히 필요한 섹터를 할당하는 대신 실제로 빈 데이터를 작성합니다). 그런 다음 -R일시적으로 스위치("역방향")를 사용하면 출력 파일에 가장 마지막 섹터를 기록하여 의도한 대로 전체 크기를 할당할 수 있다는 것을 알았습니다 . 결과적으로 출력 파일의 크기가 931.5GB로 늘어났지만 "디스크의 크기"는 실제로 훨씬 더 낮았습니다(나중에 Windows에서 해당 복구에 사용된 HDD에 액세스하여 비정상적으로 많은 여유 공간을 볼 때 이를 발견했습니다). 공간).
________________
{1} 그 동안 HDD의 상태가 저하되었음에도 불구하고 어떻게 두 번째 복구 시도가 처음 100GB 정도에 대해 훨씬 더 나은 결과를 얻을 수 있는지 이해가 되지 않습니다. [EDIT 20200501] => a500000처음에 사용된 매개변수 때문에 읽기 속도가 500KB/s 임계값 미만인 영역을 건너뛰었기 때문일 수 있습니다 . 해당 옵션이 없으면 두 번째로 느린 영역을 즉시 읽습니다. 실제로 이러한 느린 영역은 약한 헤드와 연관되어 있으므로 이 실패한 헤드가 이미 오작동의 징후를 보였지만 두 번째로 많은 데이터를 얻을 수 있었다는 것은 여전히 ​​수수께끼입니다. 아직 배우는 중이에요...

{2} 그런데 "디스크"가 아닌 데이터 저장 장치가 있기 때문에 Windows 및 Linux 시스템 모두에서 "디스크"라는 단어를 바꿔야 합니다.

답변2

  1. 먼저 디스크 이미지를 복사하고 싶을 수도 있습니다.dd명령

    sudo dd bs=[block_size] 개수=[NofBlocks] if=[in_file] of=[out_file]

어디

[in_file] - 손상된 디스크일 수 있습니다(예: /dev/sdd2)

[out_file] - 출력 이미지 파일의 위치입니다.

  1. 이미지를 마운트하고 복구해 보십시오.

관련 정보