ddrescue를 사용하여 손상된 드라이브를 복구합니다. 실행이 완료되기 전에 진행 상황을 확인할 수 있나요?

Question

이론적으로는 종료( ctrl+ C) ddrescue하고 나중에 동일한 로그 파일로 실행하여 다시 시작하는 대신 계속할 수 있습니다. 나는 이 방법이 항상 작동하지 않는다고 주장하는 일부 게시물을 보았습니다. 이 경우 ddrescue이전 작업을 무시하고 알 수 없는 이유로 처음부터 시작했습니다.

대상 파티션을 읽기 전용으로 마운트해 보십시오:

sudo mount -o ro /dev/sdc2 /mnt/foo

읽기 전용이므로 ddrescue작업에 방해가 되어서는 안 됩니다. 파일 시스템에 중요한 데이터가 아직 복구되지 않을 위험이 있으며, 이 경우 mount실패할 수 있습니다. 운이 좋으면 마운트한 다음 필요한 파일을 읽을 수 있지만 mount및 (예:) 에서 오류가 발생하지 않더라도 파일이 손상될 수 있습니다 cp. 그것들이나 그 사본을 검사하십시오. ddrescue파일이 유효하고 내부에 복구되지 않은/혼란된 조각이 없는지 확인하지 않는 한 종료하지 마십시오 .

문제가 발생할 경우 ddrescue더 많은 데이터가 복구될 때까지 기다릴 수 있습니다(있는 경우). 시스템이 메타데이터나 파일 자체 등을 캐시할 수 있기 때문에 손상되지 않은 파일이 마운트 지점 아래에 나타날 때까지 기다리지 않을 것입니다. umount더 많은 데이터가 복구될 때까지 기다렸다가 mount파일을 다시 확인하십시오.

편집: 추가 질문에 답변합니다.

ddrescue에 특정 폴더를 지정하도록 지시하는 방법이 있습니까?

아니요. 이 도구는 블록 수준에서 작동합니다. 파일 시스템과 파일에 대해서는 아무것도 모릅니다. "ddrescuelog에 내 파일의 99.73%가 복구되었다고 나와 있습니다"라는 진술에는 "블록의 99.73%"가 나와야 합니다.

그리고 99.73% 복구됐다고 하는데 파일로 인식하기에는 너무 손상이 심해서 데이터가 복구됐을 가능성도 있나요? 이런 경우에는 손상된 파일을 볼 수 있는 프로그램이 있으면 일부 파일을 수동으로 복구할 수도 있습니다.

가능한 시나리오: 파일 내용은 복구되었지만 해당 파일 시스템 항목은 복구되지 않았습니다(참고: 일반적으로 그 반대도 가능하지만 분명히 귀하의 경우는 아닙니다). 폴더 전체가 사라졌다고 하더군요. 일부 파일은 lost+found이후 에 나타날 수 있다고 생각합니다 fsck(또는 파일 시스템에 따라 비슷한 방식으로 – 그것이 무엇인지 모르겠습니다).

자세한 내용은 여기를 참조하세요:Linux 및 Unix에서 Lost+found 폴더의 목적은 무엇입니까?

이 작업은 읽기 전용이 아니므로 작업 fsck중에는 수행하면 안 됩니다 . ddrescue종료하고 ddrescue, 실행 fsck하고, 다시 시작하는 ddrescue것도 나쁜 일입니다. ddrescue끝날 때 까지 기다리는 것이 좋습니다 . 시간이 좀 걸릴 수 있습니다 – 읽어보세요이것그리고이것.

일반적으로 fsck복구된 데이터의 복사본에 대해(또는 기타 읽기 전용이 아닌 도구) 작업을 수행해야 합니다. 나중에 참고할 수 있도록 좋은 방법입니다.

장치가 아닌 파일에 씁니다. 다음과 함께 파일 시스템을 사용하십시오.COW(기록 중 복사)특징.
을 만들다암소으로 복사하세요 cp --reflink=always. ddrescue작동 중에 이 작업을 수행할 수 있습니다 . 이 복사본은 대상 파일의 스냅샷과 같습니다.
읽기 전용이 아닌 도구를 포함하여 복사본에 있는 모든 도구를 사용하십시오.
오류가 발생한 경우 ddrescue다른 대상 파일로 다시 시작할 수 있는 원래 대상 파일(아직 실행 중인 경우 더 많은 데이터가 복구되었을 수 있음)이 남아 있습니다.암소복사합니다(아마도 다른 도구를 사용하여).

삭제된 파일을 검색하여 삭제 취소를 시도할 수도 있습니다. 도구 선택은 파일 시스템에 따라 다릅니다.

또 다른 힌트: 소프트웨어가 파일 시스템 계층 구조의 다른 곳에서 임시 파일을 사용하고 있었을 수도 있습니다. 확인하다 /tmp/, /var/tmp/.

편집하여 추가 질문에 답변합니다.

ddrescuelog에 블록의 99.73%가 복구되었다고 표시되는 경우 이는 정확히 무엇을 의미합니까? 빈집 운전이 아닌 어떤 결과를 기대해야 할 것 같습니다.

참고: 아래 예는 모든 파일 시스템 문제 및 시나리오를 다루거나 디스크 섹터를 파일 시스템 할당 단위와 구별하기 위한 것이 아닙니다. 질문에만 대답하는 것입니다.

귀하의 파티션이 줄거리가 있는 소설이 아니라 백과사전인 책이라고 상상해 보십시오. 파일은 내의 기사입니다. 디스크 블록(또는 섹터)은 책의 한 페이지와 같습니다. 파일 시스템은 페이지에 기사를 배치하는 일반적인 방법입니다. 일부 페이지에는목차(ToC)이는 우리 그림의 파일 시스템 문제이며 다음과 같이 보일 수 있습니다.

기사 #289: 페이지 2076, 2077, 2078, 402, 403.

이 기사는 파일로 분할되어 있을 수 있다는 점에 유의하세요. 다른 페이지에 있지만 여전히 안에 있습니다.목차폴더 구조와 같은 것이 있습니다.

…
people/: 보다목차43페이지에 있습니다.
…
(43페이지)
mathematicians/: 참조목차80페이지에 있습니다
famous Poles/. : 참조목차82페이지
Adam and Eve. : 기사 #14를 참조하세요.
…
(80페이지)
Euclid: 기사 #289를 참조하세요.
Banach Stefan: 기사 #4380을 참조하세요.
…
(82페이지)
Banach Stefan: 기사 #4380을 참조하세요.
Kościuszko Tadeusz: 기사 #2208을 참조하세요.
…

이 구조는 하드링크된 파일의 예입니다. 단일 기사를 가리키는 최소 두 개의 경로( ./people/mathematicians/Banach Stefan및 ) 가 있습니다 ./people/famous Poles/Banach Stefan. 여기서는 내 예가 의도적으로 정보를 숨기기 때문에 각 경로의 시작 부분에 점을 표시했습니다. people/섹션은 어떤 섹션에 속합니까? ( /people/또는 /full articles/people/또는 /stubs/people/또는 일 수도 있습니다 /foo/bar/people/).

그만큼목차다음과 같은 섹션이 있을 수도 있습니다.

"빈" 페이지: 567, 568, 569, 2070, 2071…

주어진 페이지에는 한 번에 존재하는 어떤 기사에도 속하지 않더라도 텍스트(예: 데이터)가 있습니다. 이는 기사 삭제 프로세스가 다음에만 영향을 미치기 때문입니다.목차. 그만큼목차이는 주어진 페이지가 기사에 속하는지, 어떤 기사에 속하는지, 아니면 비어 있고 덮어쓴 것으로 처리될 수 있는지를 알려주는 유일한 확실한 방법입니다. 더욱이: 없이는 "빈 페이지"를 발견할 방법이 없습니다.목차. 기사의 일부가 되기 위해 빈 페이지가 있는 백과사전에서는 이상하게 느껴지지만, 0s나 공백 등으로 가득 찬 섹터는 파일의 일부가 될 수 있습니다. 모든 것에 관한 것입니다목차.

일부 페이지(블록)가 (아직) 복구되지 않았습니다. 그 중 하나는 기사 데이터가 있는 페이지일 수 있습니다.목차-메타데이터. 가능성:

누락된 블록은 데이터 블록입니다(예: 2078 페이지). 당신은 유클리드에 관한 기사의 경로와 그것이 어느 페이지에 있는지 알고 있지만, 비어 있어서는 안되는 페이지 중 하나가 비어 있습니다. 기사가 잘못되었습니다.
누락된 블록은 메타데이터 블록입니다. 일부 시나리오:
- 여유 공간에 대한 정보를 잃어버렸습니다.
- 경로 가 있다는 것을 알고 있지만 ./people/mathematicians/Euclid기사가 어느 페이지에 있는지에 대한 정보가 부족합니다. 기사에 대해 이미 알고 있지 않은 한 기사를 찾는 것은 불가능합니다(예: 사람에 대한 항목에는 "born"이라는 단어가 있을 가능성이 높습니다. PDF 파일은 "%PDF"로 시작합니다).
- 이런저런 페이지에 하나의 기사가 있지만 완전한 경로는 없다는 것을 알고 있습니다. 이 경우 아래에 배치하면 lost+found그렇게 fsck됩니다. 우리 그림에는 다음과 같은 가능성이 있습니다.
  - 80페이지 누락: 43페이지에서 섹션(폴더)이 있다는 것을 알고 있지만 mathematicians기사 #289가 "Euclid"라는 이름 아래에 있어야 한다는 것을 모릅니다.
  - 43페이지 누락: 아담과 이브에 관한 기사 #14도 있어야 하고, 수학자나 유명한 폴란드인도 포함된 섹션이 있어야 한다는 것을 모르실 겁니다. 그러나 Euclid와 Banach에 관한 기사가 포함된 섹션이 있고 Banach와 Kościuszko에 대한 기사가 포함된 다른 섹션(82페이지)이 있다는 것을 볼 수 있습니다(80페이지).이것이 귀하의 /home.기사(파일)가 거기에 있고 유효할 수도 있습니다. 경로가 없기 때문에 경로로 접근할 수 없습니다.목차당신의 /home.
복구되지 않은 블록이 여러 개인 경우 위의 문제가 복합적으로 발생할 수 있습니다.
누락된 블록은 비어 있는 것으로 표시될 수 있습니다. 이 경우 아무것도 잃지 않습니다.

Answer 1

이론적으로는 종료( ctrl+ C) ddrescue하고 나중에 동일한 로그 파일로 실행하여 다시 시작하는 대신 계속할 수 있습니다. 나는 이 방법이 항상 작동하지 않는다고 주장하는 일부 게시물을 보았습니다. 이 경우 ddrescue이전 작업을 무시하고 알 수 없는 이유로 처음부터 시작했습니다.

대상 파티션을 읽기 전용으로 마운트해 보십시오:

sudo mount -o ro /dev/sdc2 /mnt/foo

읽기 전용이므로 ddrescue작업에 방해가 되어서는 안 됩니다. 파일 시스템에 중요한 데이터가 아직 복구되지 않을 위험이 있으며, 이 경우 mount실패할 수 있습니다. 운이 좋으면 마운트한 다음 필요한 파일을 읽을 수 있지만 mount및 (예:) 에서 오류가 발생하지 않더라도 파일이 손상될 수 있습니다 cp. 그것들이나 그 사본을 검사하십시오. ddrescue파일이 유효하고 내부에 복구되지 않은/혼란된 조각이 없는지 확인하지 않는 한 종료하지 마십시오 .

문제가 발생할 경우 ddrescue더 많은 데이터가 복구될 때까지 기다릴 수 있습니다(있는 경우). 시스템이 메타데이터나 파일 자체 등을 캐시할 수 있기 때문에 손상되지 않은 파일이 마운트 지점 아래에 나타날 때까지 기다리지 않을 것입니다. umount더 많은 데이터가 복구될 때까지 기다렸다가 mount파일을 다시 확인하십시오.

편집: 추가 질문에 답변합니다.

ddrescue에 특정 폴더를 지정하도록 지시하는 방법이 있습니까?

아니요. 이 도구는 블록 수준에서 작동합니다. 파일 시스템과 파일에 대해서는 아무것도 모릅니다. "ddrescuelog에 내 파일의 99.73%가 복구되었다고 나와 있습니다"라는 진술에는 "블록의 99.73%"가 나와야 합니다.

그리고 99.73% 복구됐다고 하는데 파일로 인식하기에는 너무 손상이 심해서 데이터가 복구됐을 가능성도 있나요? 이런 경우에는 손상된 파일을 볼 수 있는 프로그램이 있으면 일부 파일을 수동으로 복구할 수도 있습니다.

가능한 시나리오: 파일 내용은 복구되었지만 해당 파일 시스템 항목은 복구되지 않았습니다(참고: 일반적으로 그 반대도 가능하지만 분명히 귀하의 경우는 아닙니다). 폴더 전체가 사라졌다고 하더군요. 일부 파일은 lost+found이후 에 나타날 수 있다고 생각합니다 fsck(또는 파일 시스템에 따라 비슷한 방식으로 – 그것이 무엇인지 모르겠습니다).

자세한 내용은 여기를 참조하세요:Linux 및 Unix에서 Lost+found 폴더의 목적은 무엇입니까?

이 작업은 읽기 전용이 아니므로 작업 fsck중에는 수행하면 안 됩니다 . ddrescue종료하고 ddrescue, 실행 fsck하고, 다시 시작하는 ddrescue것도 나쁜 일입니다. ddrescue끝날 때 까지 기다리는 것이 좋습니다 . 시간이 좀 걸릴 수 있습니다 – 읽어보세요이것그리고이것.

일반적으로 fsck복구된 데이터의 복사본에 대해(또는 기타 읽기 전용이 아닌 도구) 작업을 수행해야 합니다. 나중에 참고할 수 있도록 좋은 방법입니다.

장치가 아닌 파일에 씁니다. 다음과 함께 파일 시스템을 사용하십시오.COW(기록 중 복사)특징.
을 만들다암소으로 복사하세요 cp --reflink=always. ddrescue작동 중에 이 작업을 수행할 수 있습니다 . 이 복사본은 대상 파일의 스냅샷과 같습니다.
읽기 전용이 아닌 도구를 포함하여 복사본에 있는 모든 도구를 사용하십시오.
오류가 발생한 경우 ddrescue다른 대상 파일로 다시 시작할 수 있는 원래 대상 파일(아직 실행 중인 경우 더 많은 데이터가 복구되었을 수 있음)이 남아 있습니다.암소복사합니다(아마도 다른 도구를 사용하여).

삭제된 파일을 검색하여 삭제 취소를 시도할 수도 있습니다. 도구 선택은 파일 시스템에 따라 다릅니다.

또 다른 힌트: 소프트웨어가 파일 시스템 계층 구조의 다른 곳에서 임시 파일을 사용하고 있었을 수도 있습니다. 확인하다 /tmp/, /var/tmp/.

편집하여 추가 질문에 답변합니다.

ddrescuelog에 블록의 99.73%가 복구되었다고 표시되는 경우 이는 정확히 무엇을 의미합니까? 빈집 운전이 아닌 어떤 결과를 기대해야 할 것 같습니다.

참고: 아래 예는 모든 파일 시스템 문제 및 시나리오를 다루거나 디스크 섹터를 파일 시스템 할당 단위와 구별하기 위한 것이 아닙니다. 질문에만 대답하는 것입니다.

귀하의 파티션이 줄거리가 있는 소설이 아니라 백과사전인 책이라고 상상해 보십시오. 파일은 내의 기사입니다. 디스크 블록(또는 섹터)은 책의 한 페이지와 같습니다. 파일 시스템은 페이지에 기사를 배치하는 일반적인 방법입니다. 일부 페이지에는목차(ToC)이는 우리 그림의 파일 시스템 문제이며 다음과 같이 보일 수 있습니다.

기사 #289: 페이지 2076, 2077, 2078, 402, 403.

이 기사는 파일로 분할되어 있을 수 있다는 점에 유의하세요. 다른 페이지에 있지만 여전히 안에 있습니다.목차폴더 구조와 같은 것이 있습니다.

…
people/: 보다목차43페이지에 있습니다.
…
(43페이지)
mathematicians/: 참조목차80페이지에 있습니다
famous Poles/. : 참조목차82페이지
Adam and Eve. : 기사 #14를 참조하세요.
…
(80페이지)
Euclid: 기사 #289를 참조하세요.
Banach Stefan: 기사 #4380을 참조하세요.
…
(82페이지)
Banach Stefan: 기사 #4380을 참조하세요.
Kościuszko Tadeusz: 기사 #2208을 참조하세요.
…

이 구조는 하드링크된 파일의 예입니다. 단일 기사를 가리키는 최소 두 개의 경로( ./people/mathematicians/Banach Stefan및 ) 가 있습니다 ./people/famous Poles/Banach Stefan. 여기서는 내 예가 의도적으로 정보를 숨기기 때문에 각 경로의 시작 부분에 점을 표시했습니다. people/섹션은 어떤 섹션에 속합니까? ( /people/또는 /full articles/people/또는 /stubs/people/또는 일 수도 있습니다 /foo/bar/people/).

그만큼목차다음과 같은 섹션이 있을 수도 있습니다.

"빈" 페이지: 567, 568, 569, 2070, 2071…

주어진 페이지에는 한 번에 존재하는 어떤 기사에도 속하지 않더라도 텍스트(예: 데이터)가 있습니다. 이는 기사 삭제 프로세스가 다음에만 영향을 미치기 때문입니다.목차. 그만큼목차이는 주어진 페이지가 기사에 속하는지, 어떤 기사에 속하는지, 아니면 비어 있고 덮어쓴 것으로 처리될 수 있는지를 알려주는 유일한 확실한 방법입니다. 더욱이: 없이는 "빈 페이지"를 발견할 방법이 없습니다.목차. 기사의 일부가 되기 위해 빈 페이지가 있는 백과사전에서는 이상하게 느껴지지만, 0s나 공백 등으로 가득 찬 섹터는 파일의 일부가 될 수 있습니다. 모든 것에 관한 것입니다목차.

일부 페이지(블록)가 (아직) 복구되지 않았습니다. 그 중 하나는 기사 데이터가 있는 페이지일 수 있습니다.목차-메타데이터. 가능성:

누락된 블록은 데이터 블록입니다(예: 2078 페이지). 당신은 유클리드에 관한 기사의 경로와 그것이 어느 페이지에 있는지 알고 있지만, 비어 있어서는 안되는 페이지 중 하나가 비어 있습니다. 기사가 잘못되었습니다.
누락된 블록은 메타데이터 블록입니다. 일부 시나리오:
- 여유 공간에 대한 정보를 잃어버렸습니다.
- 경로 가 있다는 것을 알고 있지만 ./people/mathematicians/Euclid기사가 어느 페이지에 있는지에 대한 정보가 부족합니다. 기사에 대해 이미 알고 있지 않은 한 기사를 찾는 것은 불가능합니다(예: 사람에 대한 항목에는 "born"이라는 단어가 있을 가능성이 높습니다. PDF 파일은 "%PDF"로 시작합니다).
- 이런저런 페이지에 하나의 기사가 있지만 완전한 경로는 없다는 것을 알고 있습니다. 이 경우 아래에 배치하면 lost+found그렇게 fsck됩니다. 우리 그림에는 다음과 같은 가능성이 있습니다.
  - 80페이지 누락: 43페이지에서 섹션(폴더)이 있다는 것을 알고 있지만 mathematicians기사 #289가 "Euclid"라는 이름 아래에 있어야 한다는 것을 모릅니다.
  - 43페이지 누락: 아담과 이브에 관한 기사 #14도 있어야 하고, 수학자나 유명한 폴란드인도 포함된 섹션이 있어야 한다는 것을 모르실 겁니다. 그러나 Euclid와 Banach에 관한 기사가 포함된 섹션이 있고 Banach와 Kościuszko에 대한 기사가 포함된 다른 섹션(82페이지)이 있다는 것을 볼 수 있습니다(80페이지).이것이 귀하의 /home.기사(파일)가 거기에 있고 유효할 수도 있습니다. 경로가 없기 때문에 경로로 접근할 수 없습니다.목차당신의 /home.
복구되지 않은 블록이 여러 개인 경우 위의 문제가 복합적으로 발생할 수 있습니다.
누락된 블록은 비어 있는 것으로 표시될 수 있습니다. 이 경우 아무것도 잃지 않습니다.

ddrescue를 사용하여 손상된 드라이브를 복구합니다. 실행이 완료되기 전에 진행 상황을 확인할 수 있나요?

답변1

편집: 추가 질문에 답변합니다.

편집하여 추가 질문에 답변합니다.

관련 정보