가능하지만 먼저 적절한 테스트를 거쳐야 합니다.

Question 1

오프라인 수정 불가능 섹터

게시하신 이미지와 텍스트를 보면 이미 읽을 수 없거나 쓸 수 없는 섹터가 16개 있습니다.

과거에 데이터 복구 작업자로서 다음을 사용하는 것이 좋습니다.ddrescue(맨 페이지)가능한 한 빨리 디스크의 나머지 부분을 외부 미디어에 복사하십시오.

이 시점에서는 SMART와 POH를 통한 여부는 중요하지 않습니다.

이제 사용 ddrescue하고 실제로 문제가 있음을 확인할 수 있으므로, 또 다른 문제는 어떤 파일이 영향을 받는지 파악하는 것이며 ddrescue의 로그 파일에서 해당 파일을 찾을 수 없습니다.

다음과 같이 ddrescue 이미지를 성공적으로 마운트해야 합니다 root.

mount -o ro,loop,offset=$(( sector size, usually 512 * an actual offset )) /path/to/ddrescue/image /mnt/point/

오류=영향을 받은 파일 찾기:

cp -PRv /mnt/point/ /path/to/extracted/files/ 2>>/path/to/extracted/files/ERRORS.txt

이것은 단지 예일 뿐입니다. 항상 경로를 다시 확인하고 복사하여 붙여넣지 마세요.

Answer

오프라인 수정 불가능 섹터

게시하신 이미지와 텍스트를 보면 이미 읽을 수 없거나 쓸 수 없는 섹터가 16개 있습니다.

과거에 데이터 복구 작업자로서 다음을 사용하는 것이 좋습니다.ddrescue(맨 페이지)가능한 한 빨리 디스크의 나머지 부분을 외부 미디어에 복사하십시오.

이 시점에서는 SMART와 POH를 통한 여부는 중요하지 않습니다.

이제 사용 ddrescue하고 실제로 문제가 있음을 확인할 수 있으므로, 또 다른 문제는 어떤 파일이 영향을 받는지 파악하는 것이며 ddrescue의 로그 파일에서 해당 파일을 찾을 수 없습니다.

다음과 같이 ddrescue 이미지를 성공적으로 마운트해야 합니다 root.

mount -o ro,loop,offset=$(( sector size, usually 512 * an actual offset )) /path/to/ddrescue/image /mnt/point/

오류=영향을 받은 파일 찾기:

cp -PRv /mnt/point/ /path/to/extracted/files/ 2>>/path/to/extracted/files/ERRORS.txt

이것은 단지 예일 뿐입니다. 항상 경로를 다시 확인하고 복사하여 붙여넣지 마세요.

Question 2

드라이브 자체는 날짜를 알지 못하며 날짜를 설정할 방법도 없습니다. 이는 단순히 충전 시간 단위로 계산되며, 드라이브가 한 번에 몇 분 동안만 작동하는 경우 해당 카운터도 거칠고 올바르게 계산되지 않을 수 있습니다.

현재 전원 켜짐 시간은 11853이므로 이 시스템이 매일 실행되는 평균 시간을 기준으로 날짜를 추정할 수 있습니다. 또는 다른 곳에 전원 켜기 시간 값을 기록하여 더 정확한 날짜를 추론할 수도 있습니다.

드라이브에 읽을 수 없는(보류 중이거나 수정할 수 없는) 섹터가 있으므로 일부 데이터가 손실되었을 수 있습니다. 비교할 수 있는 백업이나 확인할 수 있는 체크섬이 있습니까?

개인적으로는 먼저 (읽기 오류 처리를 위해) 교체 ddrescue한 다음 더 철저하게 테스트하겠습니다. SMART가 보고하는 오류 카운터는 항상 의도적으로 문제를 찾지 않고 드라이브에서 발생한 최소값입니다.

따라서 현재 보고되지 않은 버그가 더 있을 수 있습니다.

앞으로는 장기간 자체 테스트(또는선택적 자가평가) 짧은 테스트는 읽기 오류를 감지할 만큼 충분히 신뢰할 수 없기 때문입니다.

Answer

드라이브 자체는 날짜를 알지 못하며 날짜를 설정할 방법도 없습니다. 이는 단순히 충전 시간 단위로 계산되며, 드라이브가 한 번에 몇 분 동안만 작동하는 경우 해당 카운터도 거칠고 올바르게 계산되지 않을 수 있습니다.

현재 전원 켜짐 시간은 11853이므로 이 시스템이 매일 실행되는 평균 시간을 기준으로 날짜를 추정할 수 있습니다. 또는 다른 곳에 전원 켜기 시간 값을 기록하여 더 정확한 날짜를 추론할 수도 있습니다.

드라이브에 읽을 수 없는(보류 중이거나 수정할 수 없는) 섹터가 있으므로 일부 데이터가 손실되었을 수 있습니다. 비교할 수 있는 백업이나 확인할 수 있는 체크섬이 있습니까?

개인적으로는 먼저 (읽기 오류 처리를 위해) 교체 ddrescue한 다음 더 철저하게 테스트하겠습니다. SMART가 보고하는 오류 카운터는 항상 의도적으로 문제를 찾지 않고 드라이브에서 발생한 최소값입니다.

따라서 현재 보고되지 않은 버그가 더 있을 수 있습니다.

앞으로는 장기간 자체 테스트(또는선택적 자가평가) 짧은 테스트는 읽기 오류를 감지할 만큼 충분히 신뢰할 수 없기 때문입니다.

Question 3

나는 특히 이것에 대해 걱정할 것입니다:

  7 Seek_Error_Rate         POSR-K   082   060   030    -    4473742513

탐색 오류율이 높습니다(예전에는 더 나빴습니다).

블록에는 본질적으로 걱정할 필요가 없는 수정 불가능한 오류가 있을 수 있으며 16개의 보류 중인 오류가 있을 수도 있지만 검색 오류율을 기준으로 해당 드라이브를 신뢰하지 않을 것이며 이러한 드라이브가 실패하면 일반적으로 실패합니다. 신속하게, 그리고 놀랄 만큼.

불량 블록 검사를 실행하고 장기간 자체 테스트를 실행한 후 결과에 따라 수행할 작업을 결정합니다. 디스크는 시스템 파일(또는 쉽게 복원할 수 있는 기타 파일)을 저장하는 데 적합할 수 있지만 아마도 중요한 데이터를 디스크에 저장하지는 않을 것입니다.

어떤 호스트의 시스템 로그가 참조됩니까? /var/log/syslog?

예. 내부 로그에 동일한 오류(예: LBA 0x00a03a40에서 수정 불가능한 READ DMA EXT)가 표시될 수 있습니다.

내 SSHD의 실제 수명주기를 찾고 있습니다.

  9 Power_On_Hours          -O--CK   087   087   000    -    11853

SMART 값은 100으로 정규화되며(낮을수록 더 나쁨) 드라이브가 표시된 임계값 아래로 떨어지면 "실패"한 것으로 간주됩니다. 이것이 귀하의 드라이브가 여전히 통과하는 이유입니다. 모든 값이 임계값보다 높습니다.

여전히 작동하고 있으며 일부 불량 블록(발생할 수 있음)이 있으며 일단 해당 블록을 재할당하면 꽤 오랫동안 괜찮을 것입니다. 따라서 계속 사용할 수 있지만 제가 쓴 것처럼 오류가 발생하면 높은 검색 오류율이 이미 일부 문제(아마도 기계적)를 나타내기 때문에 갑자기 실패할 수 있습니다.

Answer

나는 특히 이것에 대해 걱정할 것입니다:

  7 Seek_Error_Rate         POSR-K   082   060   030    -    4473742513

탐색 오류율이 높습니다(예전에는 더 나빴습니다).

블록에는 본질적으로 걱정할 필요가 없는 수정 불가능한 오류가 있을 수 있으며 16개의 보류 중인 오류가 있을 수도 있지만 검색 오류율을 기준으로 해당 드라이브를 신뢰하지 않을 것이며 이러한 드라이브가 실패하면 일반적으로 실패합니다. 신속하게, 그리고 놀랄 만큼.

불량 블록 검사를 실행하고 장기간 자체 테스트를 실행한 후 결과에 따라 수행할 작업을 결정합니다. 디스크는 시스템 파일(또는 쉽게 복원할 수 있는 기타 파일)을 저장하는 데 적합할 수 있지만 아마도 중요한 데이터를 디스크에 저장하지는 않을 것입니다.

어떤 호스트의 시스템 로그가 참조됩니까? /var/log/syslog?

예. 내부 로그에 동일한 오류(예: LBA 0x00a03a40에서 수정 불가능한 READ DMA EXT)가 표시될 수 있습니다.

내 SSHD의 실제 수명주기를 찾고 있습니다.

  9 Power_On_Hours          -O--CK   087   087   000    -    11853

SMART 값은 100으로 정규화되며(낮을수록 더 나쁨) 드라이브가 표시된 임계값 아래로 떨어지면 "실패"한 것으로 간주됩니다. 이것이 귀하의 드라이브가 여전히 통과하는 이유입니다. 모든 값이 임계값보다 높습니다.

여전히 작동하고 있으며 일부 불량 블록(발생할 수 있음)이 있으며 일단 해당 블록을 재할당하면 꽤 오랫동안 괜찮을 것입니다. 따라서 계속 사용할 수 있지만 제가 쓴 것처럼 오류가 발생하면 높은 검색 오류율이 이미 일부 문제(아마도 기계적)를 나타내기 때문에 갑자기 실패할 수 있습니다.

Question 4

가능하지만 먼저 적절한 테스트를 거쳐야 합니다.

특히 디스크에 대해 장기간 자체 테스트를 수행해야 합니다. smartctl -t long /dev/sda터미널(드라이브가 있다고 가정)에서 루트로 이 작업을 수행 /dev/sda한 다음 약 1시간 40분 후에 돌아와서 GSmartControl의 출력을 다시 확인하십시오.

이렇게 하면 디스크 펌웨어가 자체 내부 테스트 모음을 실행하게 됩니다.~해야 한다GSmartControl의 출력에 일부 변경이 발생합니다. 특히, 귀하는 다음 중 하나를 찾고 있습니다:

"SMART 종합건강 자가평가 결과"가 다른 내용으로 변경되었습니다 PASSED.
증가날것의속성 5, 196, 197 또는 198 중 하나의 값입니다.
출력의 SMART 확장 포괄적 오류 로그 부분에 하나 이상의 다른 오류가 있습니다.
SMART 확장 자체 테스트 로그 섹션의 새 항목 -에는 LBA_of_first_error.

확장 자체 테스트를 실행한 후 이러한 조건 중 하나라도 발견되면 즉시 드라이브 교체를 고려해야 합니다.

확장 자체 테스트를 실행한 후에도 이러한 조건이 표시되지 않으면 드라이브 교체를 고려할 수 있지만 그렇지 않을 수도 있습니다.~처럼긴급한. 그래도 계속해서 모니터링하세요.

하지만 기록된 오류는 어떻습니까?

드라이브의 전원을 켜는 데 11853시간이 걸렸으므로(SMART 확장 자체 테스트 로그에서도 유추할 수 있는 속성 9의 원래 값) 오류가 오래 전에 발생했으므로 무시해도 됩니다.

약간의 배경 지식으로 시스템이 숫자를 정확한 날짜에 매핑할 수 없기 때문에 날짜가 나열되어 있지 않습니다. 드라이브에는 내부 시계가 없으므로 날짜 자체를 추적할 수 없으며 시스템 자체는 드라이브가 얼마나 많은 시간을 소비했는지 알 수 없습니다.정전(이렇게 하려면 전원을 켜는 데 걸리는 시간을 플로팅해야 합니다.존재하다특정 날짜 및 시간까지).

오프라인으로 수정할 수 없는 섹터/현재 보류 중인 섹터는 어떻습니까?

이러한 지표는 실제로 SMART의 큰 문제를 강조합니다. 과거 데이터가 아닌 현재 값의 특정 시점 스냅샷만 가져오기 때문에그리고카운터의 마지막 변경이 발생한 시점에 대한 타임스탬프가 없으면 먼 과거의 이벤트와 최근의 이벤트를 구별하거나 급격한 변화와 꾸준한 증가를 구분할 방법이 없습니다.

이러한 특정 지표는 이러한 차별화가 실제로 중요한 부분입니다. 이러한 숫자(또는 재할당된 섹터 수) 중 하나라도 갑자기 예기치 않게 급증하거나 지속적으로 증가하는 경우 이러한 상황은 우려됩니다. 수백 시간 동안 한두 번만 얻고 대부분이 동일하게 유지된다면 그다지 큰 문제는 아닙니다(여전히 주의를 기울일 가치가 있지만 아기를 먹지는 않을 것입니다).

특별한 경우에는 숫자가 계속 변경되거나 갑자기 다시 점프하지 않는 한 괜찮을 것입니다(재할당을 위한 백업 섹터로 사용할 수 있는 일반적인 드라이브 근처에는 없습니다).

모든 것이 괜찮다면 교체를 권장하는 이유는 무엇입니까?

하지만, 여기에 포함될 수 있는 다른 사항이 있습니다. 제가 발견한 가장 큰 문제는 검색 오류율이 특히 높다는 것입니다(속성 7). 이는 거의 0이 되지 않을 것이지만 정규화된 속성 값이 약 90 이하로 떨어지는 것이 이례적일 만큼 충분히 높습니다. 대부분의 경우 이는 드라이브 자체 내의 기계적 문제를 나타내며 이는 곧 임박한 오류를 나타내는 매우 신뢰할 수 있는 지표입니다. 또한 고속 쓰기 수가 0이 아닙니다(이는 일반적으로 기계적 문제를 나타냄).

이를 감안할 때 적어도 해당 드라이브 교체 계획을 진지하게 고려할 것입니다. 가능하다면 SSD를 사용하면 노트북에서 기존 하드 드라이브를 사용할 때 발생하는 대부분의 문제를 해결하고 속도를 높일 수 있습니다.그리고배터리 수명이 약간 연장됩니다). 너전적으로그러나 고장이 나기 전에 교체하려는 경우 하드 드라이브의 기계적 고장은 거의 항상 갑작스럽고 재앙적이며 나중에 데이터를 실제로 복구하는 것이 불가능한 경우가 많습니다.

Answer

가능하지만 먼저 적절한 테스트를 거쳐야 합니다.

특히 디스크에 대해 장기간 자체 테스트를 수행해야 합니다. smartctl -t long /dev/sda터미널(드라이브가 있다고 가정)에서 루트로 이 작업을 수행 /dev/sda한 다음 약 1시간 40분 후에 돌아와서 GSmartControl의 출력을 다시 확인하십시오.

이렇게 하면 디스크 펌웨어가 자체 내부 테스트 모음을 실행하게 됩니다.~해야 한다GSmartControl의 출력에 일부 변경이 발생합니다. 특히, 귀하는 다음 중 하나를 찾고 있습니다:

"SMART 종합건강 자가평가 결과"가 다른 내용으로 변경되었습니다 PASSED.
증가날것의속성 5, 196, 197 또는 198 중 하나의 값입니다.
출력의 SMART 확장 포괄적 오류 로그 부분에 하나 이상의 다른 오류가 있습니다.
SMART 확장 자체 테스트 로그 섹션의 새 항목 -에는 LBA_of_first_error.

확장 자체 테스트를 실행한 후 이러한 조건 중 하나라도 발견되면 즉시 드라이브 교체를 고려해야 합니다.

확장 자체 테스트를 실행한 후에도 이러한 조건이 표시되지 않으면 드라이브 교체를 고려할 수 있지만 그렇지 않을 수도 있습니다.~처럼긴급한. 그래도 계속해서 모니터링하세요.

하지만 기록된 오류는 어떻습니까?

드라이브의 전원을 켜는 데 11853시간이 걸렸으므로(SMART 확장 자체 테스트 로그에서도 유추할 수 있는 속성 9의 원래 값) 오류가 오래 전에 발생했으므로 무시해도 됩니다.

약간의 배경 지식으로 시스템이 숫자를 정확한 날짜에 매핑할 수 없기 때문에 날짜가 나열되어 있지 않습니다. 드라이브에는 내부 시계가 없으므로 날짜 자체를 추적할 수 없으며 시스템 자체는 드라이브가 얼마나 많은 시간을 소비했는지 알 수 없습니다.정전(이렇게 하려면 전원을 켜는 데 걸리는 시간을 플로팅해야 합니다.존재하다특정 날짜 및 시간까지).

오프라인으로 수정할 수 없는 섹터/현재 보류 중인 섹터는 어떻습니까?

이러한 지표는 실제로 SMART의 큰 문제를 강조합니다. 과거 데이터가 아닌 현재 값의 특정 시점 스냅샷만 가져오기 때문에그리고카운터의 마지막 변경이 발생한 시점에 대한 타임스탬프가 없으면 먼 과거의 이벤트와 최근의 이벤트를 구별하거나 급격한 변화와 꾸준한 증가를 구분할 방법이 없습니다.

이러한 특정 지표는 이러한 차별화가 실제로 중요한 부분입니다. 이러한 숫자(또는 재할당된 섹터 수) 중 하나라도 갑자기 예기치 않게 급증하거나 지속적으로 증가하는 경우 이러한 상황은 우려됩니다. 수백 시간 동안 한두 번만 얻고 대부분이 동일하게 유지된다면 그다지 큰 문제는 아닙니다(여전히 주의를 기울일 가치가 있지만 아기를 먹지는 않을 것입니다).

특별한 경우에는 숫자가 계속 변경되거나 갑자기 다시 점프하지 않는 한 괜찮을 것입니다(재할당을 위한 백업 섹터로 사용할 수 있는 일반적인 드라이브 근처에는 없습니다).

모든 것이 괜찮다면 교체를 권장하는 이유는 무엇입니까?

하지만, 여기에 포함될 수 있는 다른 사항이 있습니다. 제가 발견한 가장 큰 문제는 검색 오류율이 특히 높다는 것입니다(속성 7). 이는 거의 0이 되지 않을 것이지만 정규화된 속성 값이 약 90 이하로 떨어지는 것이 이례적일 만큼 충분히 높습니다. 대부분의 경우 이는 드라이브 자체 내의 기계적 문제를 나타내며 이는 곧 임박한 오류를 나타내는 매우 신뢰할 수 있는 지표입니다. 또한 고속 쓰기 수가 0이 아닙니다(이는 일반적으로 기계적 문제를 나타냄).

이를 감안할 때 적어도 해당 드라이브 교체 계획을 진지하게 고려할 것입니다. 가능하다면 SSD를 사용하면 노트북에서 기존 하드 드라이브를 사용할 때 발생하는 대부분의 문제를 해결하고 속도를 높일 수 있습니다.그리고배터리 수명이 약간 연장됩니다). 너전적으로그러나 고장이 나기 전에 교체하려는 경우 하드 드라이브의 기계적 고장은 거의 항상 갑작스럽고 재앙적이며 나중에 데이터를 실제로 복구하는 것이 불가능한 경우가 많습니다.

가능하지만 먼저 적절한 테스트를 거쳐야 합니다.

답변1

오프라인 수정 불가능 섹터

답변2

답변3

답변4

가능하지만 먼저 적절한 테스트를 거쳐야 합니다.

하지만 기록된 오류는 어떻습니까?

오프라인으로 수정할 수 없는 섹터/현재 보류 중인 섹터는 어떻습니까?

모든 것이 괜찮다면 교체를 권장하는 이유는 무엇입니까?

관련 정보