현재 상태를 사용하여 GNU ddrescue (1.18.1) 완료를위한 루프 / 시간을 추정하는 방법은 무엇입니까?


9

배경 / 컨텍스트 :

현재 가상 디스크 이미지를 disk2s1 파티션에 쓰는 동안 케이블 연결이 끊어진 USB에서 데이터를 복구하기 위해 GNU ddrescue 1.18.1을 실행하고 있습니다. 처음에 두 번째 파티션 (disk2s2)을 복구하고 있으며 세 번째 단계 (Splitting)에 도달했습니다. 이미지를 네트워크 저장소에 배치하고 있습니다.

질문:

이 단계가 반복되는 것을 알았습니다. 현재 상태 정보를 고려할 때 발생할 수있는 루프 수를 계산하는 방법이 있습니까 (두 개의 오류 만 표시됨)?

상태:

상태

업데이트 / 편집 :

그래서 ddrescue 도구를 사용하여 완료를위한 루프 / 시간을 어떻게 평가할 수 있는지에 여전히 관심이 많습니다. 의견에 따라 현재 실행중인 disk2s1 파티션의 로그 파일 평가를 추가하고 있습니다 (disk2s2는 14.5 시간 후에 완료되었으며 약 6 시간 동안 한 번의 사용자 중단이 발생했습니다).

part1-log

완료된 파티션 로그

방금 완료 한 파티션의 경우 로그 검사 결과입니다.

사진 기록

참조 (ddrescue 알고리즘 노트) :

4 알고리즘


GNU ddrescue는 dd의 파생물이 아니며 한 장치에서 다른 장치로 데이터를 복사하는 데 사용할 수 있다는 점을 제외하고는 어떤 식 으로든 dd와 관련이 없습니다. 가장 큰 차이점은 ddrescue는 정교한 알고리즘을 사용하여 고장난 드라이브에서 데이터를 복사하여 가능한 한 적은 추가 손상을 입히는 것입니다.

Ddrescue는 진행중인 구조의 상태를 효율적으로 관리하고 좋은 부품을 먼저 구출하여 나중에 불량 (또는 느린) 영역 내에서 읽기 예약을 시도합니다. 이는 고장난 드라이브에서 최종적으로 복구 될 수있는 데이터의 양을 최대화합니다.

표준 dd 유틸리티는 고장난 드라이브에서 데이터를 저장하는 데 사용할 수 있지만, 데이터가 순차적으로 읽히므로 오류가 드라이브 시작 부분에있는 경우 아무 것도 구하지 않고 드라이브가 마모 될 수 있습니다.

다른 프로그램은 데이터를 순차적으로 읽지 만 오류를 발견하면 작은 크기의 읽기로 전환합니다. 이것은 오류 영역에서 더 많은 시간을 보내고 표면, 헤드 및 드라이브 메커니즘을 가능한 한 빨리 벗어나지 않고 손상시키는 것을 의미하기 때문에 나쁜 생각입니다. 이 동작은 남아있는 양호한 데이터를 구할 가능성을 줄입니다.

ddrescue의 알고리즘은 다음과 같습니다 (사용자는 언제든지 프로세스를 중단 할 수 있지만 불량 드라이브는 커널이 포기할 때까지 ddrescue를 오랫동안 차단할 수 있음에 유의하십시오).

1) 선택적으로 다중 부품 또는 이전에 중단 된 구조의 상태를 설명하는 로그 파일을 읽습니다. 로그 파일이 지정되지 않았거나 비어 있거나 존재하지 않으면 모든 복구 도메인을 시도하지 않은 것으로 표시하십시오.

2) (첫 번째 단계; 복사) 입력 파일의 시도되지 않은 부분을 읽고 실패한 블록을 트림되지 않은 것으로 표시하고 넘어갑니다. 느린 지역을 넘어서도 건너 뛰십시오. 건너 뛴 영역은 나중에 두 번의 추가 패스 (트리밍 전)에서 시도되어 모든 복구 도메인이 시도 될 때까지 각 패스 후 방향을 되돌립니다. 세 번째 패스는 건너 뛰기가 비활성화 된 스위핑 패스입니다. (목적은 큰 오류를 빠르게 구분하고 로그 파일을 작게 유지하며 트리밍을위한 좋은 시작점을 생성하는 것입니다). 시도하지 않은 영역 만 큰 블록에서 읽습니다. 트리밍, 분할 및 재 시도는 섹터별로 수행됩니다. 각 섹터는 최대 두 번 시도됩니다. 이 단계의 첫 번째 (보통 큰 블록 읽기의 일부이지만 때로는 단일 섹터 읽기의 경우), 두 번째 단계는 단일 섹터 읽기의 두 번째 단계입니다.

3) (두 번째 단계; 트리밍) 가장 작은 트리밍되지 않은 블록의 선단에서 불량 섹터가 발견 될 때까지 한 번에 하나의 섹터를 읽습니다. 그런 다음 불량 섹터가 발견 될 때까지 동일한 블록의 끝에서 한 번에 한 섹터 씩 뒤로 읽습니다. 트리밍되지 않은 각 블록에 대해 불량 섹터로 표시된 불량 섹터를 표시하고 해당 블록의 나머지 부분을 읽으려고하지 않고 비 분할로 표시합니다. 트리밍되지 않은 블록이 더 이상 없을 때까지 반복하십시오. (대량의 트리밍되지 않은 블록은 작은 블록을 연결하여 생성되므로 가장자리에서 좋은 데이터의 비율이 더 작습니다).

4) (Third phase; Splitting) 불량 섹터가 발견 될 때까지 가장 큰 비분 할 블록의 중심에서 한 번에 한 섹터 씩 전달합니다. 그런 다음 발견 된 불량 섹터가 처음 시도 된 것이 아닌 경우 불량 블록이 발견 될 때까지 동일한 블록의 중심에서 한 번에 한 섹터 씩 뒤로 읽습니다. 로그 파일이 '--logfile-size'보다 큰 경우 로그 파일의 항목 수가 '--logfile-size'아래로 떨어질 때까지 가장 큰 비분 할 블록을 순차적으로 읽으십시오. 남아있는 모든 비분 할 블록이 7 개 미만의 섹터를 가질 때까지 반복하십시오. 그런 다음 나머지 비분 할 블록을 순차적으로 읽습니다.

5) (4 단계; 재시도) 선택적으로 지정된 재시도 횟수에 도달 할 때까지 불량 섹터를 다시 읽으십시오. 모든 불량 섹터는 각 패스에서 한 번만 시도됩니다. Ddrescue는 불량 섹터를 복구 할 수 없는지 또는 일부 재시도 후에 결국 읽을 것인지 알 수 없습니다.

6) 선택적으로 나중에 사용하기 위해 로그 파일을 작성하십시오.

총 오류 크기 ( 'errsize')는 트리밍되지 않은, 분할되지 않은 섹터 및 불량 섹터 블록의 크기 합계입니다. 복사 단계에서 증가하며 트리밍, 분할 및 재시도 중에 감소 할 수 있습니다. ddrescue가 실패한 블록을 분할하여 더 작게 만들면 전체 오류 크기는 줄어들고 오류 수는 증가 할 수 있습니다.

로그 파일은 ddrescue가 완료되거나 중단 될 때뿐만 아니라 디스크에 주기적으로 저장됩니다. 따라서 충돌이 발생하면 약간의 복사만으로 구조를 다시 시작할 수 있습니다. 저장 간격은 로그 파일 크기에 따라 30 초에서 5 분까지 다양합니다 (큰 로그 파일은 더 긴 간격으로 저장 됨).

또한 동일한 로그 파일을 사용하여 입력 파일의 다른 영역을 복사하는 여러 명령과 다른 하위 집합에 대한 여러 복구 시도를 수행 할 수 있습니다. 이 예제를보십시오 :

디스크의 가장 중요한 부분을 먼저 구하십시오. ddrescue -i0 -s50MiB / dev / hdc hdimage 로그 파일 ddrescue -i0 -s1MiB -d -r3 / dev / hdc hdimage 로그 파일

그런 다음 주요 디스크 영역을 구출하십시오. ddrescue -i30GiB -s10GiB / dev / hdc hdimage 로그 파일 ddrescue -i230GiB -s5GiB / dev / hdc hdimage 로그 파일

이제 나머지를 구하십시오 (이미 수행 된 내용을 다시 복사하지 않음). ddrescue / dev / hdc hdimage 로그 파일 ddrescue -d -r3 / dev / hdc hdimage 로그 파일


디스크가 여전히 동일한 장치 이름으로 연결되어 있습니까? 또한 ddrescue디스크에 불량 블록이있는 경우에만 필요 합니다. 이는 "케이블 연결 해제"로 인한 것이 아닙니다. 케이블에 문제가있는 경우 다른 케이블을 사용해보십시오.
frostschutz

@TommieC. ddrescuelog -t YourLog.txt다른 터미널에서 시도해 볼 수 있습니까?
Simply_Me

@Simply_Me 두 가지 결과를 반영한 ​​업데이트 된 질문을 참조하십시오.
Tommie C.

@frostschutz 자세한 내용은 업데이트 된 질문을 참조하십시오. 디스크를 쓰는 동안 케이블 연결이 끊어졌으며 파티션 테이블에 문제가 발생했습니다. 케이블 자체가 손상되지 않았습니다.
Tommie C.

케이블 분리는 일반적으로 논리적 오류 (예 : 디스크의 데이터가 100 % 유효하지 않음)를 유발하지만 동시에 떨어 뜨리지 않는 한 드라이브에 물리적 문제를 일으키지 않습니다 . ddrescue물리적 문제 만 복구하려고 시도 할 수 있으며 논리적 오류는 전혀 도움이되지 않습니다. 후자를 위해, fsck또는 비슷하게 시도하십시오 .
Udo G

답변:


6

10 개월 전에 질문을 했는데도 몇 가지 요인에 따라 복구주기가 계속 실행될 수 있기 때문에 답이 적절할 수 있습니다! 말장난이 없습니다.

그 이유는 시간 추정이 거의 불가능하지만 때로는 다음과 같이 대략적인 아이디어를 얻을 수 있기 때문입니다. 가장 명백한 이유 중 하나는 불량 섹터를 읽는 데 드라이브가 얼마나 오래 걸릴지 예측할 수없고 ddrescue가 모든 섹터를 읽고 다시 시도하려면 시간이 오래 걸릴 수 있다는 것입니다. 예를 들어, 저는 현재 2 주가 넘는 작은 500GB 드라이브에서 복구를 실행하고 있으며 며칠이 남아있을 수 있습니다. 그러나 드라이브가 암호화되어 아무것도 읽지 못하기 때문에 광산이 더 복잡한 상황입니다. 파티션 테이블, 부팅 섹터 및 기타 중요한 디스크 부분이있는 모든 섹터를 가져와야합니다. 나는 모든 불량 섹터에 대한 기회를 개선하기 위해 ddrescue 외에도 기술을 사용하고 있습니다. 아이오와,

"루프"를 추정하면 재시도 횟수를 의미하는 경우 사용하는 매개 변수로 결정합니다. "총 패스 수"를 의미하는 경우 여기에서 알고리즘을 읽어서 쉽게 확인할 수 있습니다. > man ddrescue </ 알고리즘 : ddrescue가 데이터를 복구하는 방법

제공 한 화면 캡처의 숫자에 대해 구체적으로 이야기하겠습니다. 다른 상황에는 다른 요인이 적용될 수 있으므로이 정보를 일반적인 지침으로 사용하십시오.

제공 한 샘플에서 ddrescue의 running status 화면을 살펴보십시오. 우리는 "errsize"를 통해 문제의 총 "추정"(구조 도메인)을 얻습니다. "아직 읽을 수없는"데이터의 양입니다. 샘플에서는 345GB입니다. 오른쪽 아래의 다음 줄은 "평균 비율"입니다. 샘플에서는 583kb / s입니다.

"평균 비율"이 꾸준히 유지된다면 7 일이 더 남을 것입니다. 345GB / (583kb * 60 * 60 * 24) = 7.18 그러나 문제는 583kb / s에 의존 할 수 없다는 것입니다. 실제로 복구에 더 깊이 들어가면 점점 더 힘든 영역을 읽고 더 많은 재 시도를 수행하므로 드라이브 속도가 느려집니다. 따라서 기하 급수적으로 완료하는 시간이 늘어납니다. 이 모든 것은 드라이브가 얼마나 심하게 손상되었는지에 달려 있습니다.

제공 한 샘플은 "성공적인 읽기"가 10 시간 전에 완료되었음을 보여줍니다. 그것은 실제로 10 시간 이상 드라이브에서 아무것도 얻지 못한다는 것을 말합니다. 이는 드라이브에 345GB 상당의 데이터 샷이있을 수 있음을 나타냅니다. 이것은 당신에게 매우 나쁜 소식입니다.

반대로, "SMART"오류가 발생하기 시작한 두 번째 500GB 드라이브는 디스크에 디스크로 복사되고 (다른 드라이브에 로그 파일이 있음) 전체 작업에는 약 8-9 시간이 걸렸습니다. 그것의 마지막 부분이 느려졌습니다. 그러나 여전히 견딜 수 있습니다. 위에서 언급했듯이 매우 나쁜 드라이브는 500GB에서 2 주가 넘었으며 여전히 복구 할 약 4-5 %가 남아 있습니다.

HTH와 YMMV

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.