일부 2TB 대형 하드 드라이브에서 데이터를 복구해야 하며 문제가 있는 하드 드라이브가 USB 3을 사용하여 연결되어 있고 VM이 필요한 크기의 가상 디스크를 로컬로 제공하는 일부 VM의 일부 Live-Linux에서 그렇게 하고 있습니다. 데이터를 수신합니다. 그런 다음 상황이 어떻게 진행되는지 확인하기 위해 다음 호출을 실행했습니다.
ddrescue -f /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
sdc는 USB에 있는 고장난 장치, sdb데이터를 수신하는 가상 디스크, sda1임시 저장용이며 Ext4를 사용하여 포맷됩니다.
작업이 빠르게 작동하기 시작했고 ddrescue몇 분 안에 최대 45GB의 데이터를 읽을 수 있었지만 며칠 동안 초당 몇 바이트만 읽는 속도로 속도가 크게 느려졌습니다. 그래서 장치는 분명히 이 부분에서 고장이 났고 나는 서로 다른 여러 호출을 사용하는 부분을 간단히 건너뛰려고 했습니다 --input-position=[...]GB. 점프한 위치에 따라 내용이 다시 빠르게 읽기 시작했고, 다시 느려지고 다른 호출을 사용하여 다시 점프했습니다. 주목해야 할 중요한 점은 에서 인쇄한 입력 및 출력 위치가 ddrescue항상 동기화되어 있다는 것입니다! 제공된 지도 파일의 어떤 것도 수동으로 변경하거나 삭제하지 않았습니다. 항상 하나의 동일한 파일이었고 ddrescue자체적으로만 관리되었습니다.
그 후 접근 방식을 약간 변경하고 --input-position더 이상 수동으로 사용하지 않고 대신 다음을 사용하기로 결정했습니다.
ddrescue -f --min-read-rate=1MB --skip-size=1MB /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
따라서 ddrescue느린 부분을 인식할 때마다 깨진 데이터 블록을 건너뛰고 계속해서 읽습니다. 이번에도 입력과 출력 위치가 동기화되었고 읽기 및 복구된 데이터의 카운터가 항상 증가했습니다. 현재까지 ddrescue완료되었으며 ~650GB의 데이터를 구했다고 합니다.
문제는 최종적으로 가상 디스크 파일 자체를 살펴보면 실제로 저장된 데이터는 160GB 정도밖에 안 되는 것 같다는 점이다. 또한 마지막 쓰기 타임스탬프가 며칠이 너무 오래되었습니다. 그래서 어떤 이유에서 ddrescue인지 많은 양의 데이터를 읽는다고 생각했지만 손상된 디스크에서 읽은 가상 디스크의 위치에 제대로 쓰지 않는 것 같습니다. 결국, 제가 이해한 바에 따르면, 가상 디스크는 적어도 ddrescue구출한 데이터의 양에 해당하는 크기를 가지고 있어야 했습니다.
ddrescue나는 그것이 말한 모든 데이터를 올바르게 읽었지만 후속 호출에서 이미 구출된 데이터를 단순히 덮어썼다는 느낌을 받았습니다 . 그래서 읽기로 인식한 것 같은데 --input-position, 타겟에서는 항상 0번 위치부터 다시 쓴 것 같습니다.
분명히 데이터를 쓸 시작 위치를 지정하지 않았지만문서그것은 필요하지 않으며 ddrescue어쨌든 항상 입력 및 출력 위치가 동일하도록 인쇄됩니다.
-o bytes
--output-position=bytes
Starting position of the image of the rescue domain in outfile, in bytes.
Defaults to '--input-position'. The bytes below bytes aren't touched if
they exist and truncation is not requested. Else they are set to 0.
물론 나는 자르기를 요청하지 않았습니다. 문서에 따르면 자르기는 기본적으로 활성화되어 있지 않으며 내가 지정한 대상 드라이브에서도 작동하지 않았을 것입니다.
-t
--truncate
Truncate outfile to zero size before writing to it. Only works for regular
files, not for drives or partitions.
그렇다면 무엇이 잘못되었을 수 있는지 아시나요? --input-position이미 잘못된 값을 가진 여러 호출이 있었습니까 ? 파티션이나 파일 대신 드라이브에 읽고 쓰는 것과 관련이 있습니까?
일부 가상 디스크에 쓰는 데 문제가 있을까요? 왜 이것이 어떤 차이를 가져오는지 알 수 없지만 일부 가상 디스크에 써야 하고 필요한 크기의 원시 장치 저장소를 제공할 수 없습니다.
감사해요!
답변1
--input-positionddrescue와 함께 여러 가지를 사용하는 것이 안전합니까 ?
이전에 해당 예를 놓친 것 같지만 실제로는 이것이 제가 수행한 작업이며 이는 내 접근 방식이 지원됨을 나타냅니다.
Example 5: While rescuing a partition in /dev/sda1 to the file hdimage, /dev/sda1 stops responding and begins returning read errors, causing ddrescue to mark the rest of the partition as non-scraped.
ddrescue -n /dev/sda1 hdimage mapfile <-- /dev/sda1 fails here
(restart /dev/sda or reboot computer)
ddrescue -n -A -i<pos> -O /dev/sda1 hdimage mapfile
(if /dev/sda1 fails again, restart /dev/sda or reboot computer and
then repeat the above command as many times as needed until it
succeeds. <pos> is the position where the drive stopped responding)
ddrescue -d -r3 /dev/sda1 hdimage mapfile
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Examples
두 번째 호출은 다른 위치에서 반복되도록 명확하게 문서화되어 있습니다. 맵 파일을 사용하는 방법과 관련하여 ddrescue이는 또한 해당 파일을 사용하여 이미 어떤 블록을 읽었는지 항상 알고 있기 때문에 의미가 있습니다.
따라서 제 경우에는 문제가 다를 가능성이 높은 것 같습니다. 특히 제가 인식한 것 같은 너무 오래된 타임스탬프가 이상합니다. 어쩌면 ddrescue어떤 이유로 실제 대상 장치에 쓰지 않는 메시지를 놓쳤을 수도 있습니다 . VM 자체는 다른 USB 드라이브에도 있었습니다. 런타임 중에 Live-Linux에서 장치를 놓칠 수 있는 연결 오류가 있었을 수도 있습니다. dmesg -T기록된 모든 읽기 오류로 인해 이러한 오류를 쉽게 놓칠 수 있었습니다 .
전체 과정을 반복해야 할 것 같습니다...
답변2
매뉴얼 을 읽었는데 ddrescue어디에도 다중 매개변수의 가능성에 대한 언급이 없습니다 input-position.
이 매개변수는 항상 "a" 또는 "the"로 언급되므로 고유해야 하는 것으로 보입니다.
문제의 원인은 설명서의 다음 문구일 수 있습니다.
원래 구조 실행의 '--input-position'과 '--output-position' 사이의 원래 오프셋을 유지해야 합니다.
이는 다음의 다른 단락과 일치하는 것 같습니다.
Ddrescue는 입력에서 불량 섹터를 발견할 때 출력에 0을 쓰지 않으며 요청되지 않은 경우 출력 파일을 자르지 않습니다. 따라서 동일한 출력 파일에서 실행할 때마다 이미 구출된 데이터를 지우지 않고 공백을 메우려고 시도합니다.
이는 ddrescue첫 번째 실행의 매개변수를 기억하므로 항상 동일한 매개변수를 유지해야 하거나 후속 실행에서 매개변수를 지정하지 않아야 함을 의미합니다(어느 것이 옳은지는 말할 수 없습니다). 일부 매개변수는 기억되고 다음 실행 시 새 매개변수가 무시될 가능성이 있습니다.
디스크의 메타 테이블 일부가 손상된 경우 이러한 부분이 포함된 파일이 없기 때문에 실제로 복구된 것보다 적은 양의 데이터가 표시될 수 있습니다.
복구할 수 없는 데이터는 ddrescue다른 복구 제품을 사용하여 복구해야 합니다. 이는 시간이 오래 걸릴 수 있으며 귀하가 처분할 수 있는 제품에 대해서는 불가능할 수도 있습니다. 데이터를 반드시 복구해야 하는 경우 전문 복구 회사가 원본 디스크에서 복구를 수행할 수도 있지만 이러한 서비스에는 비용이 많이 듭니다.
답변3
의 매뉴얼 페이지가 ddrescue길기 때문에 ddrescue목표와 사용자 수준에 따라 사용 방법이 매우 다릅니다. 기본적으로 Live Linux를 사용한다면 VM 대신 물리적 머신에서 실행하고, sATA/USB 어댑터 없이 디스크를 sATA에 연결하는 것이 좋습니다.
다른 기능 중에는 ddrescue커널 디스크 드라이버와 버퍼를 우회할 수 있으므로 불량 클러스터에 대한 쓸데없는 반복 읽기를 줄일 수 있습니다. 맵파일(이전에는 로그파일이라고 함)은 모든 읽기 실패/성공 클러스터에 대한 정보를 보관하므로 충돌이 발생한 단계를 간단히 반복할 수 있습니다. 작업을 시작하기 전에 맵 ddrescue파일을 찾아 생성하고, 존재하지 않는 경우 읽고, 사용 가능한 경우 읽고 마지막으로 기록된 위치에서 복구 작업을 계속 시작합니다. 프로그램이 충돌할 때마다 시작 위치를 손으로 이동할 필요가 없습니다!
다양한 옵션을 사용하여 구조 과정을 더 빠르고 안전하게 만들 수 있습니다. 또한 두 개 이상의 단계로 구조 프로세스를 수행할 수도 있으며 권장됩니다.
첫 번째 단계: 좋은 클러스터를 빠르게 읽고 나쁜 클러스터를 즉시 건너뜁니다.
두 번째 단계: 이전 단계에서 읽지 않은 클러스터를 처리하고 특수 옵션을 사용하여 한 번에 한 섹터를 읽어야 하는 디스크 기능(NCQ, 미리 읽기 ...)을 속입니다. 내가 사용하는 적절한 명령은 다음과 같습니다.
ddrescue -n -p -d -r1 /dev/sdd $IMGPATH/disk.img $IMGPATH/disk.log;
ddrescue -d -r3 -R /dev/sdd $IMGPATH/disk.img $IMGPATH/disk.log;
# | | | | |
# | | | | revers reading
# | | | retry read 1x (3x)
# | | direct access to disk (bypass the kernel)
# | preallocate diskspace
# nonscrap
디스크가 너무 많이 뜨거워지거나 많은 읽기 작업을 원하지 않는 경우 다음 옵션을 사용하여 읽기 속도를 늦출 수 있습니다.--max-read-rate=50M
따라서 이는 첫 번째 접촉일 뿐이지만 전문 클럽이나 포럼에서 에 관한 많은 조언을 찾을 수 있습니다 ddrescue.