최근에 정보를 외장 하드 드라이브에 백업하려고 했을 때 두 번째 내장 하드 드라이브에 문제가 있다는 사실을 발견했습니다. 2TB 중 1.4TB를 사용했습니다. 전송률이 0으로 떨어졌고 데이터를 가져오는 데 어려움을 겪었습니다. 가능한 문제를 찾기 시작했지만 아마도 내 하드 드라이브에 문제가 있는 것 같았습니다. SMART 스캔을 수행하기 위해 chkdsk를 사용해 보았지만 속도가 느려지고 약 30% 정도 중지되었습니다. Windows 데이터 복구 응용 프로그램을 사용하면 더 많은 손상을 초래할 수 있다는 내용을 반복해서 읽었기 때문에 gddrescue 시도로 전환했습니다. USB 드라이브용 Kali를 다운로드하고 SATA 케이블을 통해 기존 2TB Toshiba HDD를 연결하고 SATA 케이블을 통해 새 3TB WD HDD를 설치하여 전송을 시작했습니다.
이것이 스캔을 시작하는 데 사용되는 것입니다.
ddrescue -f /dev/sda /dev/sdb /root/Desktop/log1.log
첫 번째 패스에서 52%의 절약 효과를 얻었으며 아직 오류나 불량 섹터가 없습니다. 그래서 이것이 맞는지는 잘 모르겠지만 현재 시점에서는 전송 속도가 평균 10,000B/s에 불과합니다.
중지하고 역방향으로 스캔을 시작했습니다.
ddrescue -f -R /dev/sda /dev/sdb /root/Desktop/log1.log
여기부터는 처음에는 더 낮은 속도로 시작하여 평균 10,000B/s로 떨어집니다.
첫 번째 통과에서는 이것이 정상입니까? 다운로드가 너무 느린 경우 다른 섹터로 이동하여 먼저 다운로드한 다음 느린 섹터로 돌아가야 합니까(첫 번째 패스에서 손상된 경우)? 또한 데이터 복구 부분이 실제로 새 하드 드라이브에 복제됩니까, 아니면 해당 데이터를 하드 드라이브에 저장하기 전에 완전히 완료해야 합니까?
답변1
읽기 오류가 발생할 때의 동작은 ddrescue디스크 자체의 동작에 따라 달라집니다.
일부 디스크는 읽기 요청당 몇 번만 시도하고 디스크의 내부 논리가 결과가 올바르지 않을 가능성이 있음을 나타내는 경우 오류를 보고합니다. 이를 통해 ddrescue유사한 유틸리티는 요청된 모든 데이터가 올바르게 판독되었다는 통계적으로 높은 신뢰도를 얻을 수 있을 때까지 여러 번 시도하고 각 시도의 결과를 개별적으로 분석할 수 있습니다.
다른 디스크는 자체적으로 이 작업을 시도합니다. 오류가 포함된 데이터 블록을 읽으라는 단일 요청이 있을 때 디스크는 데이터 블록을 여러 번 읽으려고 시도하며 디스크의 내부 진단에서 오류가 있음을 나타내는 경우에만 데이터를 반환합니다. 읽기 시도가 매우 길어졌습니다. 성공할 수 있습니다. 디스크가 마침내 성공적으로 읽으면 오류를 보고할 필요 없이 데이터를 애플리케이션에 반환합니다. 물론 디스크 자체는 실패한 블록당 읽기 시도 횟수를 엄청나게 증가시키므로 디스크 액세스 속도가 매우 느려집니다.
실패한 디스크 블록을 불량으로 표시하는 것은 일반적으로 쓰기 작업 중에만 발생합니다. 읽기 작업에서 불량 블록도 감지하는 경우 이는 시스템이 기본적으로 특정 데이터 블록을 더 이상 복구할 수 없다고 판단하고 이를 모두 0인 예비 블록으로 교체한다는 의미입니다. 이로 인해 후속 데이터 복구 시도가 훨씬 더 어려워집니다. Take를 읽는 것보다 실제 불량 블록에서 데이터를 복구할 수 있는 또 다른 기회를 얻으려면 디스크 자체의 불량 블록 교체 논리를 재정의하는 특수 소프트웨어 또는 하드웨어가 필요합니다. 빈 교체 블록.