고장난 USB 하드 드라이브에서 데이터를 복구하기 위해 ddrescue를 사용하려고 합니다. 4일 정도 ddrescue를 실행했더니 드디어 1단계가 완료되었습니다. 2단계가 시작된 후 어느 시점에서 노트북과 하드 드라이브가 따뜻해지기 때문에 휴식을 주기 위해 프로세스를 중단했습니다. ddrescue를 다시 시작했을 때 중단된 부분부터 다시 시작되었지만 2단계(카운트다운) 대신 1단계가 다시 증가하는 것을 발견했습니다. 게다가 두 번째 패스는 고통스러울 정도로 느려서 다음 이틀 동안 5GB만 처리했습니다. 현재 상태는 오류 0개, errsize는 0B, 저장된 크기는 769755MB로 제가 기억하는 드라이브의 데이터 양 정도입니다. 제 질문은, ddrescue가 복구할 데이터를 복구했다고 가정할 수 있는지, 그리고 이미지 파일의 내용을 다른 USB 드라이브에 안전하게 추출할 수 있는지입니다. 아니면 나머지 두 번에도 ddrescue를 실행해야 합니까?
"지정되지 않은 오류가 발생했습니다"라는 메시지와 함께 USB 하드 드라이브에서 PS Chkdsk가 실패합니다. 새 하드 드라이브에 이미지 파일을 추출하고 chkdsk를 다시 실행하여 문제를 해결할 수 있는지 확인하고 싶습니다. Linux에서 이미지 파일을 탑재하려고 하면 누락된 NTFS 서명이 반환됩니다.
답변1
로그/매핑 파일을 에 제공했습니까 ddrescue? 예를 들어:
# ddrescue /dev/sdc file.img map.txt
지도 파일을 제공하는 경우 ddrescue중단한 부분부터 계속해야 합니다. 이는 원래 복구된 모든 데이터를 다시 저장하려고 시도하지 않고 잘못된 비트만 다시 저장하려고 시도한다는 것을 의미합니다. 그러나 제가 아는 한 통과는 재부팅과 아무런 관련이 없습니다. 매핑 파일을 사용하면 ddrescue어떤 데이터가 포함되었는지, 어디에서 문제가 발생했는지, 현재 알고리즘의 어느 단계가 실행되고 있는지 알 수 있습니다. 다만, 패스는 스테이지가 디스크를 통과한 횟수만 카운트할 뿐 ddrescue, 맵파일에는 기록되지 않는 것 같습니다. "패스 2" 중간에 중단한 다음 다시 실행하면 "패스 1"이라고 하는 완전히 새로운 "패스 3"이 효과적으로 실행되지만 패스 1에서 이미 수행한 작업은 다시 실행되지 않습니다. 또는 부분적으로 패스 2에 포함됩니다. 이 경우 처리량이 더 낮을 것으로 예상됩니다. 원래 패스 1을 제외한 모든 항목은 실패 지점까지 읽으려고 시도합니다. ddrescue먼저 드라이브에서 쉽게 읽을 수 있는 모든 비트를 가능한 한 빨리 복구하려고 시도한 다음 돌아가서 읽을 수 없는 부분을 다시 시도하는 방식으로 작동합니다. 다시 시작한 후에는 "rescued" 값이 마지막으로 실행했을 때 중지되었을 때의 값과 동일한 것을 확인해야 합니다.
매핑 파일을 제공하지 않으면 중단한 부분에서 다시 시작할 방법이 없습니다. 중지 ddrescue하고 다시 시작하는 것은 기본적으로 처음부터 시작하는 것과 동일합니다. 어떤 데이터가 있는지 또는 처리되지 않았는지 알 수 없기 때문입니다. 실패한 디스크에서 데이터를 복구할 때는 항상 맵 파일을 사용해야 합니다.
전체적으로 ddrescue드라이브의 100% 복구가 완료되거나 데이터 복구 시도를 포기하면 종료됩니다. ddrescue아직 읽지 않은 나머지 데이터를 삭제하려는 경우가 아니면 실행이 완료되도록 해야 합니다 . 항상 하나 이상의 완전한 패스가 완료되도록 허용해야 합니다. 그렇지 않으면 완벽한 데이터가 누락됩니다(첫 번째 패스가 완료되도록 허용하면 덮어쓰게 됩니다). 복구된 데이터 양은 드라이브에 있는 실제 파일 양이 아니라 드라이브의 전체 크기와 관련이 있습니다. 따라서 1000000MB 드라이브에서 769755MB를 복구하면 ddrescue드라이브에 있는 전체 섹터/블록의 약 77%가 복구되었음을 의미합니다. 드라이브를 사용하지만 이 77%가 사용 중인 블록에 해당하는지 아니면 사용 가능한 블록에 해당하는지 알 수 없습니다. 드라이브가 77% 차면 가장 좋은 경우는 데이터와 파일 시스템 구조를 100% 복구한 것입니다(운이 좋지 않은 경우). 최악의 시나리오에서는 드라이브의 사용되지 않은 23%(즉, 빈 공간)와 드라이브 데이터의 또 다른 77-23=54%를 모두 복구했습니다. 드라이브가 77% 차면 0.54/.77 = 약 70% 데이터입니다. 평균적으로 복구된 데이터 부분이 무작위인 경우 데이터의 약 77%를 갖게 됩니다. 운이 좋지 않으면 중요한 파일 시스템 구조가 누락되어 나머지 데이터를 복구하기 어려울 수 있습니다.
답변2
ddrescue파일 대신 블록에서 작동합니다. 60Gb 데이터가 포함된 100Gb 드라이브에서는 블록을 60Gb로 복원할 수 있지만 이렇게 하면 20Gb의 데이터만 복원됩니다. 60Gb 블록이 데이터를 완전히 덮을 가능성은 희박합니다.
제 생각에는 ddrescue실행되도록 놔두는 것이 좋습니다(백업과 충돌 사이에 발생한 몇 시간의 데이터 변경 사항이 손실되더라도 백업에서 복원하는 것이 더 비용 효과적인지 다시 고려하면서).