디스크 오류로 인해 읽기 전용 스냅샷이 손상되지 않았는지 어떻게 확인할 수 있습니까?
체크섬을 서로 계산하고 추가 검사를 위해 저장하는 유일한 방법입니까, 아니면 BTRFS가 자체적으로 처리합니까?
이론적 해석
혹시라도 발생할 수 있는 디스크 장애를 예방하기 위해 정기적으로 스냅샷을 백업하고 있습니다. 며칠 전에는 btrfs send | btrfs receive특정 스냅샷을 만들 수 없었습니다 . 삭제하면 나머지 작업은 정상적으로 진행되었습니다. 게다가 btrfs scrub수정 불가능한 오류가 몇 가지 있다고 하더군요. 이로 인해 기본 디스크의 스냅샷을 외부 디스크에 백업하기 전에 손상되었을 수 있다는 생각이 들었습니다. 이를 인식하지 못하면 외부 디스크의 백업이 이미 손상되었을 것입니다.
그런 일이 일어나지 않도록 방지하고 싶습니다. 스냅샷을 백업할 수 있다면 스냅샷이 손상되지 않았는지 확인하고 싶습니다.
답변1
'디스크 오류로 인해 손상됨'의 의미에 따라 두 가지 대답이 가능합니다.
단순한 미사용 데이터 손상을 의미하는 경우
BTRFS는 이를 사용자에게 투명하게 처리합니다. 내부적으로 스냅샷의 데이터를 포함한 모든 것을 체크섬한 다음 각 블록을 읽을 때 체크섬을 확인합니다. 하지만 여기에는 몇 가지 예외가 있습니다.
nodatasum또는 옵션을 사용하여 볼륨을 마운트하면nodatacow데이터 블록의 체크섬이 수행되지 않습니다. 대부분의 경우 이러한 옵션을 사용하여 마운트하면 안 되므로 문제가 되지 않습니다.NOCOW속성이 설정된( 명령C출력에서 ) 모든 파일lsattr도 검사되지 않습니다. 이 속성이 설정된 정말 중요한 파일이 없을 가능성이 높습니다(시스템 저널 파일에는 이 속성이 설정되어 있지만 수동으로 설정하지 않는 한 그게 전부입니다).
너무 많은 장치의 손실로 인해 볼륨의 데이터가 심각하게 파괴되는 것을 의미하는 경우
어딘가에 데이터의 또 다른 복사본을 두는 것 외에는 이를 방지할 수 없습니다. 볼륨에 대한 스토리지 프로필이 허용할 수 있는 것보다 더 많은 장치를 분실한 경우 데이터는 모두 사라지며 백업에서 복원하지 않는 이상 데이터를 복구할 수 있는 방법이 없습니다.
귀하의 특정 사례와 관련하여
보내기/받기와 관련하여 이야기하고 있는 문제는 아마도 스크럽에서 보고된 수정할 수 없는 오류의 부작용일 것입니다. BTRFS가 오류를 투명하게 수정할 수 없는 경우(일반적으로 단일 또는 raid0과 같이 복구를 수행할 수 없는 프로필을 사용하여 블록이 저장되기 때문에) I/O 오류를 반환하므로 전송 작업이 실패하게 됩니다. 따라서 보내기/받기를 사용하는 경우 이미 손상된 백업으로 끝나지 않을 것입니다(그리고 실제로 대부분의 다른 도구도 사용하지 않습니다. 좋은 백업 소프트웨어라면 파일을 읽을 수 없으면 오류가 발생합니다) ).
이 경우 수정할 수 없는 오류는 전적으로 스냅샷 전용 데이터에 있거나 스냅샷이 생성되지 않는 데이터에 있는 것처럼 들립니다. 소스 볼륨을 어딘가에 마운트하고 마운트된 위치에서 다음 명령을 실행하면 어떤 파일에 문제가 있는지 쉽게(매우 빠르지는 않지만) 파악할 수 있습니다.
find . -exec cat '{}' \; > /dev/null
그러면 볼륨의 모든 파일을 읽으려고 시도하며 오류 메시지에 파일 이름과 함께 읽기 오류가 콘솔에 표시됩니다. 이는 잠재적으로 매우 느릴 수 있으므로 볼륨이 큰 경우 병렬화하는 것이 좋습니다.
해당 파일을 찾아서 처리한 후에는 더 이상 문제가 발생하지 않습니다. 문제를 해결한 후 가까운 시일 내에 이러한 문제가 다시 발생하는 경우 하드웨어를 확인해야 합니다.무엇조용히 데이터를 손상시키고 있습니다.