동일한 오류가 발생한 다른 사람을 찾는 데 어려움을 겪고 있으며 앞으로 최선의 길을 찾으려고 노력하고 있습니다.
내 하드 드라이브가 사용할 수 없을 정도로 느려지고 부팅이 중지됩니다. Clonezilla 복제가 실패했고 Clonezilla Live CD에 포함된 GNU 복구 도구를 사용하여 ddrescue를 시작했습니다. 2TB 드라이브의 경우 평균 약 400kBps로 엄청나게 느린 속도이므로 약 4개월 정도 걸릴 것으로 예상됩니다! 이 지점에서. 안타깝게도 마지막 백업이 2년 전이어서 백업에서 많은 사진을 삭제하고 싶습니다. 놀랍게도 3일이 걸렸음에도 불구하고 현재까지 오류 없이 약 50GB 정도의 공간이 절약되었습니다. 앞으로 나아갈 최선의 길과 오류 없이 왜 그렇게 오래 걸리는지에 대해 몇 가지 질문이 있습니다.
드라이브가 성공적으로 읽는 데 오랜 시간이 걸리지만 실제로는 실패하지 않아 복사 시간이 느려지나요? 하드 자체는 괜찮은데, 컨트롤 보드에 문제가 있거나 그런 게 있는 걸까요?
로그 파일이 어디로 갈지 매우 걱정됩니다. 나는 내 컴퓨터가 4개월 동안 안정적으로 유지되고 명령이 잘못되지 않을 것이라고 기대할 수 없습니다. 몇 주 동안이라도 실행되도록 하려는 경우 해당 로그 파일을 플래시 드라이브에 저장하고 싶습니다. 처음에는 더 큰 새 하드 드라이브에 저장될 것이라고 생각했지만 이제 clonezilla_live가 사용하는 RAM 드라이브에 저장될 수 있다는 것을 깨달았습니다. 포맷된 USB 드라이브를 삽입하고 마운트하고 로그 파일을 복사한 다음 ddrescue를 다시 시작해도 안전합니까? Clonezilla 셸은 시작할 때 존재하지 않았던 USB 스틱을 삽입한 것을 인식하여 설치할 수 있습니까?
sudo fdisk -l디스크를 나열한 다음 디렉토리를 생성해 볼까 ? sudo mkdir /logfile/usb그럼 설치해볼까? sudo mount /dev/sdb1 /media/usb, 복사하시겠습니까?
어떤 피드백이라도 감사하겠습니다. 나는 Unix 셸에서 z-pool raid를 설정하면서 장난을 쳤지만 항상 간단한 버전은 물론 Linux가 아닌 내가 무엇을 하고 있는지 정확히 알고 있었습니다.
답변1
누군가 관심이 있거나 수년에 걸쳐 이것의 보관된 버전을 발견한 경우를 대비해. 복제를 재개하기 위한 로그 파일을 만드는데 두 달을 기다렸습니다. 두 번(컴퓨터를 다시 시작할 때까지) 읽기 오류가 발생하기 시작했고 한 번은 전원이 꺼졌습니다. 몇 달 동안 복사한 후 USB 어댑터를 통해 백업을 다른 노트북에 연결했는데 7.5MB 중 ~2TB 정도가 복사되지 않았습니다(-r3(3회 재시도) 후에도 여전히 오류가 발생함). 읽을 수 없었지만 다음 지침에 따라 파티션 테이블을 다시 작성했습니다.https://perrohunter.com/repair-a-mac-os-x-hfs-partition-table/ - 이 드라이브는 이전 드라이브보다 훨씬 크기 때문에 블록 크기를 변경해야 했습니다.
그런 다음 거의 완벽하게 작동했습니다. 디스크 유틸리티에서 디스크 검증과 복구, 권한 복구를 했더니 정상적으로 부팅이 되었습니다.
진짜 교훈은? 저는 매우 중요한 파일(사진 및 문서)과 라이브 이미지 부팅 가능한 백업에 backblaze를 사용합니다.
답변2
ddrescue는 두 번째 단계에 도달할 때까지 불량 섹터를 표시하지 않습니다. https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html
(2단계; 가지치기) 가지치기는 한번에 끝납니다. 잘리지 않은 각 블록에 대해 불량 섹터가 발견될 때까지 블록의 앞쪽 가장자리부터 시작하여 한 번에 한 섹터씩 앞으로 읽습니다. 그런 다음 불량 섹터가 발견될 때까지 블록의 뒤쪽 가장자리부터 한 섹터 뒤로 읽습니다. 발견된 불량 섹터(있는 경우)는 불량 섹터로 표시되고 블록의 나머지 부분은 읽으려는 시도 없이 지워지지 않은 것으로 표시됩니다.
문제는 이 단계가 시작되는 데 오랜 시간이 걸릴 수 있다는 것입니다. 세 가지 채널로 나누어져 있습니다.
- 앞으로 복사하고 시간 초과 등에 따라 청크를
rescued,non-trimmed및 으로 표시합니다.non-tried - 뒤로 복사하고 모든
non-tried블록을 읽습니다. - 건너뛰지 않고 앞으로 복사, 가지치기로 큰 오류에 대비
불행하게도 이 단계에 걸리는 시간은 오류 수(귀하의 경우에는 몇 시간, 며칠, 몇 주 또는 몇 달)에 따라 달라지므로 누구도 예측할 수 없습니다.
참고: --retry-passes=n( r) 플래그는 네 번째 단계에서만 중요합니다.
(4단계; 재시도) 지정된 재시도 횟수에 도달할 때까지 불량 섹터 읽기를 다시 시도하는 옵션이 있습니다.
따라서 재시도 횟수를 줄여서 첫 번째 단계의 속도를 높이지는 않습니다.
그러나 ddrescue 로그 파일에서 특정 블록을 "구출됨"으로 표시하는지 확인할 수 있으므로 드라이브 데이터의 일부 또는 전체를 복구할 수 있기를 바랍니다. 예는 다음과 같습니다.
# pos size status
0x00000000 0x00117000 +
0x00117000 0x00000200 -
0x00117200 0x00001000 /
0x00118200 0x00007E00 *
0x00120000 0x00048000 ?
로그 파일에 +-status가 포함된 행이 있으면 희망이 있습니다. '구출되다'라는 뜻이다. 하지만 ?(미시도)와 (미손질) 만 포함되어 있다면 *포기하셔도 될 것 같아요. 물론 처음부터 드라이브에 단순히 결함이 있었을 가능성도 있지만 그럴 가능성은 희박하다고 생각합니다. 그러나 두 번째 컴퓨터에서 ddrescue를 실행할 수 있는 경우 데이터의 중요도에 따라 이를 시도해야 합니다. 마지막 희망은 헤드/전자 장치를 교체하는 것일 수 있지만 이는 비용이 많이 들 수 있습니다.
로그를 분석하는 또 다른 방법은 ddrescue 로그 뷰어를 사용하는 것입니다. https://sourceforge.net/projects/ddrescueview/
나는 사용한다이별의 마법ddrescue GUI와 ddrescue 로그 뷰어가 포함되어 있기 때문입니다.
여기에서 1단계 2단계 중급 뷰어의 스크린샷을 볼 수 있습니다(뒤로 복사됨).
화살표는 현재 위치를 나타냅니다. 보시다시피 드라이브의 중간에 불량 섹터가 많을 가능성이 있으므로(이 단계에서는 "트리밍되지 않음"으로 표시됨) 이것이 제가 포기한 이유입니다.
답변3
데이터가 계속 복사되고 있는지 확인하세요. 출력 파일을 확인하고 크기가 늘어나고 있는지 확인하세요. 고장난 하드 드라이브에서 대량의 데이터를 한 번에 복사하려고 하면 고장난 하드 드라이브가 정지될 가능성이 높습니다.
아무것도 하지 않는 것처럼 보이면 중지하고 돌아가서 디렉터리를 한 번에 하나씩 복사하여 같은 일이 다시 발생하더라도 최소한 완전한 디렉터리를 갖게 되는 것이 좋습니다. 효과가 있으면 하루나 이틀 더 보관할 수 있습니다. 예상 시간은 매우 잘못된 경우가 많지만, 한 달 정도는 걸리지 않습니다!
저는 ddrescue에 대해 잘 알지는 못하지만, 직장에서 Data Rescue를 많이 사용하는데, 하루 안에 완성되지 않은 전체 하드 드라이브 이미지를 본 적이 없습니다. 즉, 응용 프로그램을 다시 설치하고 설정을 재구성할 수 있지만 문서와 사진을 교체할 수는 없으므로 필요한 디렉터리(아마도 /home)만 복사하는 것이 가장 좋습니다.
로그 파일의 경우 데이터 복구 유틸리티가 실행되는 동안에는 해당 파일을 건드리지 않습니다.