USB 케이스로 ddrescue

Question

로그 파일(매핑된 파일)은 어디에 쓰나요? [...] 새 대상 디스크에도 쓸 수 있나요?

대상 디스크에 파일 시스템을 생성하고 이를 마운트한 다음 ddrescue장치에 쓰는 대신 파일 시스템의 일반 파일에 쓰도록 지시합니다( /dev/sdc명령에서). 지도 파일을 보자다른동일한 파일 시스템의 일반 파일(현명한 아이디어: 동일한 디렉토리에 있음)

이는 대상 디스크가 소스 디스크보다 큰 경우에 잘 작동하므로 파일 시스템이 구조상 일부 공간을 차지하더라도 이미지(소스 디스크 크기) 및 맵 파일을 위한 충분한 공간이 있을 것입니다. 그러나 대상 디스크가 크지 않더라도 압축 및/또는 -S/ --sparse옵션이 있는 파일 시스템 ddrescue이면 이미지를 파일 시스템으로 압축하는 데 충분할 수 있습니다. 그러나 데이터가 충분히 압축/희소화될 수 있는지 미리 알 수 있는 쉬운 방법은 없습니다. 원본 드라이브가 정상이면 다음을 수행할 수 있습니다.하드 드라이브에서 사용 중인 공간만 복제. 그러나 드라이브가 고장난 경우에는 이 방법을 권장하지 않습니다.

운 좋게도 귀하는 "대상 드라이브가 실패한 드라이브 크기의 두 배입니다"라고 (댓글에서) 말씀하셨습니다. 압축하지 않고도 이미지와 맵 파일이 들어갈 수 있는 대상 드라이브에 파일 시스템을 만듭니다. 파일 시스템은 /dev/sdc1파티션( )에 위치할 수도 있고 /dev/sdc전체 장치( )에 위치할 수도 있습니다. 보다단일 파티션 디스크 구성의 목적. 그러나 결정을 내리기 전에 현재 답변 전체를 읽어보십시오.

압축이 필요하지 않더라도 Btrfs는 Btrfs를 지원하므로 Btrfs를 사용합니다.쓰기 중 복사. 완료되면 ddrescue이미지에서 쓰기 권한을 제거하고 복사본( cp --reflink=always …)을 생성합니다. 처음에는 추가 공간을 거의 차지하지 않습니다. 이미지를 수정하는 모든 작업(예: fsck)은 복사본에서 수행됩니다. 문제가 발생하더라도 원본 파일은 그대로 유지되므로 언제든지 다시 시작할 수 있습니다. 나는 ZFS도 똑같이 유용할 것이라고 생각하지만, 그것을 사용해 본 경험은 없습니다.

전체 디스크의 이미지를 일반 파일로 사용하면 .또는 이와 유사한 명령( ddrescue읽을 수 있다고 가정)을 사용하여 파티션 테이블(있는 경우)을 확인할 수 있습니다. gdisk -l /path/to/image여기에서 파일 시스템을 마운트할 수 있습니다( ddrescue파일 시스템을 마운트할 수 있도록 충분한 데이터를 읽었다고 가정). 유용한 명령: losetup, kpartx또는 그냥 mount -o offset=…. 그러면 파일을 읽을 수 있습니다. 이미지를 저장한 동일한 파일 시스템에 복사할 수 있습니다.

/dev/sdc직접 복사하는 것이 합리적인 상황은 최소한 두 가지입니다 .

실패한 디스크에서 부팅하는 것처럼 복사본에서 부팅해야 합니다.
일반 파일에서는 작동하지 않는 도구(예: 복구 도구)를 사용하고 싶은 경우, 실제 디스크에 고정되는 도구를 사용합니다. 이러한 제한은 Unix-y 설계에 따른 것이 아닙니다. 도구는 Windows 도구일 수도 있고 Windows 자체일 수도 있습니다.

로그 파일의 크기는 일반적으로 얼마나 됩니까?

지도 파일헤더 등(~350바이트)과 데이터 블록 목록으로 구성됩니다. 동일한 상태를 유지하는 연속 섹터 블록당 한 줄(~30바이트)입니다. 더 나쁜 상황은 드라이브의 각 물리적 섹터가 인접 섹터와 다른 상태에 있는 경우입니다. 그러면 물리적 섹터당 한 줄이 있습니다. 즉, 소스 디스크의 512바이트 또는 4096바이트마다 약 30바이트의 맵 파일이 있으므로 맵 파일의 크기는 소스 디스크 크기의 6% 또는 1%를 초과해서는 안 됩니다.

따라서 이론적으로는 기가바이트가 가능하지만 해당 크기(즉, 테스트 드라이브의 다른 모든 섹터가 손상된 섹터)에 도달하는 데는 오랜 시간이 걸립니다. 실제로는 잘못된 섹터를 배치하는 것이 더 운이 좋을 것으로 예상됩니다. 매핑 파일은 몇 킬로바이트, 어쩌면 몇 메가바이트 정도 걸릴 것으로 예상됩니다.

위에서 언급한 파일 시스템이 아닌 원본 디스크를 대상 디스크에 직접 복사해야 하거나 선택하고 대상 디스크가 훨씬 큰 경우 매핑된 파일을 대상 드라이브에 저장할 수 있습니다. . 한 가지 가능한 접근 방식은 다음과 같습니다.

ddrescue대상 디스크의 맨 처음부터 시작하여 큰 조각(소스 디스크 크기)을 덮어쓰더라도 파티션의 내용이 변경되지 않도록 대상 드라이브에서 충분히 멀리 시작하는 파티션을 만듭니다 . 예상 크기의 매핑된 파일을 수용할 수 있는 파일 시스템을 수용할 수 있을 만큼 파티션을 크게 만듭니다. 하지만 필요한 경우를 대비해 디스크 끝에 공간을 남겨두세요(1MiB이면 충분합니다).GPT. 파티션에 파일 시스템을 만듭니다.
mount -o offset=… /dev/sdc …(주위가 아닌 ) 을 사용하여 파일 시스템을 마운트할 수 있는지 확인하십시오 mount /dev/sdc1 …. 설치된 채로 둡니다. 종이에 오프셋을 기록해 두십시오.
실행 ddrescue하고 쓰도록 /dev/sdc하되 맵 파일을 마운트된 파일 시스템에 넣습니다. 이는 sdc파티션 테이블을 덮어쓰지만 오프셋을 알고 있으므로 매핑된 파일이 포함된 파일 시스템을 계속 마운트할 수 있습니다.
작업이 완료된 후 ddrescue(여러 세션에 걸쳐) 의 파티션 테이블을 확인하세요 /dev/sdc. MBR 또는 기본 GPT의 DOS 파티션 테이블은 소스 디스크에서 시작됩니다( ddrescue이 부분을 읽을 수 없는 경우 제외).

(참고: 논리 섹터 크기에 문제가 있을 수 있으며 나중에 다루겠습니다. 지금은 문제가 없다고 가정하고 조치를 취하기 전에 전체 답변을 읽어보시기 바랍니다.)

복사된 파티션 테이블이 MBR의 DOS 파티션 테이블이라면 문제가 없습니다.

GPT인 경우 보조 GPT를 수정해야 합니다. 이제 원본 디스크의 보조 GPT 복사본은 대상 디스크 중간에 있습니다. 일반적으로 끝에 있어야 합니다. 어딘가에 하나쯤은 있을 수도 있겠지오래된보조 GPT는 /dev/sdc사본과 관련이 없습니다. gdisk /dev/sdc차이점이 감지되어야 하며 기본 GPT에 대해 보조 GPT를 수정하는 옵션이 제공되어야 합니다(수동 방법: r복구 옵션의 경우 d백업을 다시 작성합니다. "수동 복구 프로세스" 참조)여기).
매핑된 파일이 포함된 파일 시스템을 계속 마운트할 수 있지만( 사용 offset=…) 디스크의 이 부분은 이제 파티션 테이블에 따라 사용되지 않습니다. 파일 시스템에 더 쉽게 액세스하기 위해 파티션 테이블에 항목을 만들 수 있습니다(비교내 대답) 또는 존재하지 않았던 것처럼 파일 시스템을 확장합니다.

하드 드라이브를 USB 인클로저에 연결하는 것은 좋은 생각이 아니라는 글을 읽었습니다. SATA 연결만 있는 경우 어떤 옵션이 있습니까?

네트워크의 다른 컴퓨터는

대상 디스크를 마운트하고 NFS 또는 유사한 프로토콜을 통해 파일을 생성할 수 있습니다.
사용할 대상 디스크를 노출하세요.블록 장치로.

그러나 USB 인클로저는 괜찮을 수 있습니다. 가능한 문제를 처리하는 방법을 알고 있다면(우리는 그것에 대해 알아볼 것입니다) 아마도 괜찮을 것입니다.

꼭 선택해야 한다면 새 드라이브를 SATA 포트에 넣고 고장난 드라이브를 케이스에 넣는 것이 좋을까요, 아니면 그 반대일까요?

인클로저는 내부 디스크에 장애가 발생할 경우 오작동하거나 예상치 못한 동작을 일으킬 수 있는 추가 계층입니다. 그래서 건강한 대상 디스크와 함께 사용하는 것을 선호합니다. 그러나 다른 측면도 있습니다(주로 특이한 점을 다루겠습니다).

이것을 실행하기 전에 드라이브가 마운트되지 않았는지 확인해야 합니까 ddrescue?

원본 드라이브를 변경하면 안 됩니다. 데이터를 한꺼번에 읽을 수는 없지만 덩어리 단위로 읽을 수 있습니다. 읽는 사이에 내용이 변경되면 연결되지 않은 이미지가 나타날 수 있습니다. 비교하다"파노라마 실패"사진에서는 이미지의 여러 부분이 서로 다른 순간에 촬영되며 세계(출처)는 완전히 정적이지 않습니다.

원본 드라이브는 읽기 전용으로 마운트할 수 있습니다. 그러나 드라이브에 결함이 있으므로 읽으면 상태가 악화될 수 있으므로 불필요하게 읽지 않는 것이 가장 좋습니다. 소스를 제거된 상태로 둡니다.

ddrescue대상 드라이브의 파일 시스템에 있는 일반 파일에 쓰려면 파일 시스템을 마운트해야 합니다 . 대상 드라이브에 쓰 려면 ddrescue변경하려는 조각을 설치하면 안 되지만 합당한 이유가 있는 경우(예: 위 프로세스에서 맵 파일을 저장하는 경우) 더 진행할 수 있습니다.

디스크 섹터 크기가 동일한지 확인하고 ddrescue다른 경우 매개변수를 전달해야 합니까?

네, 꼭 확인하셔야 합니다. 하지만 아니요, ddrescue소스 디스크의 물리적 섹터 크기에 맞게 조정할 수 있는 매개변수가 있지만 자체적으로 작동해야 합니다(섹터가 다르기 때문은 아닙니다). 다른 섹터 크기는 나중에 문제가 될 수 있습니다.

또한 일부 USB 인클로저에는 간섭을 일으킬 수 있는 이상한 현상이 발생합니다.

먼저 "물리적 섹터 크기"와 "논리적 섹터 크기"의 개념을 숙지하세요. 유용한 링크:

즉, 논리 섹터를 사용하여 드라이브와 통신하지만 내부적으로는 물리적 섹터를 사용하여 데이터를 읽고 씁니다. 운영 체제는 하나의 논리 섹터만 요청할 수 있지만 물리 섹터 크기보다 작은 경우 전체 물리 섹터를 읽지만 그 중 일부(요청한 논리 섹터)만 반환됩니다.

호출되면 ddrescue섹터 크기(바이트 단위 -b, 기본값 512)와 클러스터 크기( -c한 번에 복사되는 섹터, 기본값 128)를 지정할 수 있습니다. 먼저(복사 단계) 도구는 전체 클러스터를 한 번에 여러 섹터를 읽지만 나중에(트림, 스크랩 단계) 개별 섹터를 한 번에 하나씩 읽습니다. 글쎄, "부서"가 아니라 "부서"라고 생각합니다.

장치의 실제 물리 섹터 크기보다 작은 크기를 지정하면 -b읽기 오류가 발생하는 경우 ddrescue물리 섹터의 일부를 읽으려고 시도하고 다시 시도하게 됩니다. 내부적으로 드라이브는 매번 전체 물리적 섹터를 읽으려고 시도합니다. 만약 성공한다면 인접한 ddrescue가 이미지의 섹터로 간주하는 부분을 채울 수 있다는 사실에도 불구하고 일부 데이터는 어쨌든 삭제됩니다. 인접한 각 조각에는 자체 시도가 필요합니다. 디스크에 오류가 발생하는 경우 추가 작업으로 인해 드라이브가 더 손상될 수 있으므로 가능한 한 적은 수의 읽기로 최대한 많은 데이터를 얻고 싶을 것입니다 -b.

장치의 실제 물리적 섹터 크기보다 큰 크기를 지정하면 -b읽기 오류가 발생하는 경우 ddrescue한 번에 여러 물리적 섹터를 읽으려고 시도하고 다시 시도하게 됩니다. 성공하지 못하면 물리적 섹터보다 큰 간격이 이미지에 남게 됩니다. 도구가 보다 적절한 섹터 크기를 사용한 경우 문제 없이 이러한 조각 중 일부를 읽을 수 있습니다.

511완전히 미친 섹터 크기(예 : 513또는 ) 를 지정 4444하면 어떤 일이 발생하는지 모르겠습니다. 나는 그것을 테스트하지도 않았습니다.

-b기본값은 입니다 512. 이는 4096바이트 물리적 섹터 크기를 사용하는 드라이브에 대한 최선의 선택이 아닙니다. 이는 두 디스크 간의 섹터 크기가 다른지 여부에 관계없이 조정해야 하는 매개변수입니다.

건강한 대상의 섹터 크기는 중요하지 않다고 생각합니다. ddrescue검색 가능한 파일(일반 파일 또는 블록 장치)에 쓰기만 하면 됩니다.

그러면 쉘이 방해할 수 있습니다. 결함이 있는 디스크와 함께 사용하기로 결정했다고 가정해 보겠습니다. 일부 껍질논리 섹터 크기 변경물리적 섹터 크기를 알고 있다면 이는 중요하지 않습니다. 하지만 나는 어댑터를 가지고 있었는데 그것은 나에게 거짓말을 했습니다.물리적섹터 크기! 512실제 디스크 사용량을 보고합니다 4096. 제가 사용한 것은 결함이 있는 디스크였고 ddrescue -b 512 …모든 불량 섹터가 8개 그룹으로 나타났습니다. 이로 인해 생각이 들었습니다. 4096SATA를 통해 연결한 후 실제 값을 보고했습니다. 이 과정에서 디스크가 손상되었는데, -b 4096처음부터 디스크를 사용했다면 더 많은 데이터를 복구할 수 있었을지 의문입니다.

앞서 저는 "건강한 대상 디스크가 있는 섀시를 사용하고 싶습니다"라고 썼습니다. 이는 사실이지만 저장 장치가 논리 섹터 크기를 변경할 수 있는 경우 이를 대상 디스크와 함께 사용하면 가능합니다.

파티션에 파일 시스템을 생성한 다음 이미지를 일반 파일에 쓰기로 결정했습니다. 모든 작품. 그런 다음 오류가 발생한 디스크는 폐기되고 대상 디스크는 섀시에서 SATA 연결로 이동됩니다. 논리 섹터 크기가 변경되고 다음과 같은 상황이 발생합니다.파일 시스템 유형이 잘못되어 드라이브를 마운트할 수 없습니다..
장치에 쓰기로 결정했지만 복사본의 파티션 테이블이 대상 디스크에서 사용하는 논리 섹터 크기와 일치하지 않습니다.

후자의 상황은 케이스 없이도 발생할 수 있으며, 케이스를 사용하면 문제가 해결될 수도 있습니다(사용 중인 경우). 이는 두 디스크의 논리 섹터 크기와 섀시가 간섭하는 방식(있는 경우)에 따라 달라집니다.

좋은 소식: mount -o offset=…파티션 테이블이 적합하지 않더라도 파일 시스템을 마운트할 수 있어야 합니다. 마지막 링크를 클릭하시면 제 답변에 자세한 내용이 설명되어 있습니다.

그러나 부팅하기 위해 대상 장치에 복사했고 이제 논리 섹터 크기가 다르기 때문에 파티션 테이블이 유효하지 않은 경우 파티션 테이블을 복구해야 합니다. 수리가 가능할 수도 있고 불가능할 수도 있습니다.

Answer 1