저장소 무결성 검사는 통과했는데 파일 하나가 여전히 복원되지 않는 이유는 무엇인가요?

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

저장소 검사가 통과했는데도 특정 파일 하나만 복원에 실패할 수 있습니다. 검사에서 정확한 복구 경로가 아니라 메타데이터나 샘플링된 데이터만 검증했을 수 있기 때문입니다.

백업 검증은 하나의 보편적인 작업이 아닙니다. 일부 검사는 모든 저장 바이트를 읽지 않고 저장소 구조, 인덱스, 매니페스트 및 참조된 청크를 확인합니다. 다른 검사는 데이터를 샘플링하거나, 백업되지 않은 파일을 건너뛰거나, 대상 파일 시스템의 이름, 권한, ACL, 레이블, 여유 공간 및 애플리케이션 잠금에 대해서는 아무것도 알려 주지 않습니다. 실패한 파일을 스냅샷 선택부터 저장된 객체를 거쳐 대상 위치에 파일을 생성하는 과정까지 하나의 경로로 취급하세요.

통과한 검사가 정확히 무엇을 검증했는지 확인하기

검사 명령, 옵션, 백업 도구 버전, 저장소 백엔드, 스냅샷 ID 및 최종 로그를 저장하세요. 저장소 구조, 아카이브 메타데이터, 참조된 청크, 저장된 데이터 또는 실제 추출 중 무엇을 검사했는지 확인합니다.

Borg는 표준 아카이브 검사가 기본적으로 파일 데이터는 읽지 않고 메타데이터를 읽는다고 설명합니다. 데이터 검증을 명시적으로 요청한 경우는 예외입니다.

따라서 녹색 결과는 참조가 내부적으로 일관된다는 점만 증명할 수 있으며, 일부 페이로드 청크는 읽지 않은 상태로 남아 있을 수 있습니다. 대표 파일을 추출하기 전까지는 저장소가 완전히 복원 가능하다고 판단하지 마세요.

파일의 저장 데이터가 실제로 읽혔는지 확인하기

의도한 스냅샷에서 파일을 찾고, 파일을 재구성하는 데 필요한 팩, 청크 또는 객체를 식별하세요. 실패한 복원과 저장소 검사가 데이터를 읽은 범위를 비교합니다.

Restic은 read-data 및 read-data-subset 검사를 문서화하고 있으며, 일반적인 구조 검사와 전체 페이로드 읽기가 서로 다른 검증 수준임을 보여 줍니다.

일부만 읽었다면 실패한 파일이 검사되지 않은 팩에 의존할 수 있습니다. 복구를 시도하기 전에 지원되는 방식으로 대상 데이터 검사 또는 전체 데이터 검사를 실행하세요.

파일이 해당 스냅샷에 포함되었는지 확인하기

선택한 스냅샷에서 정확한 상대 경로를 나열하세요. 필터, 제외 항목, 읽을 수 없는 원본에 대한 경고, 심볼릭 링크 규칙, 마운트 경계 및 복원 UI에서 다른 버전을 선택했는지 확인합니다.

Kopia는 무시 정책이 일치하는 경로를 제외한다고 경고합니다. 따라서 원하는 파일이 애초에 캡처되지 않았더라도 저장소 일관성 검사는 통과할 수 있습니다.

자리 표시자 경로나 상위 디렉터리 항목만으로는 파일 페이로드가 존재한다는 증거가 되지 않습니다. 스냅샷 인벤토리, 크기, 해시 및 타임스탬프를 예상 원본 기록과 비교하세요.

대상 파일 이름 및 경로 제약 확인하기

같은 파일을 짧고 비어 있는 로컬 경로에 간단한 이름으로 복원하세요. 사용할 수 없는 문자, 예약된 이름, 대소문자 충돌, 후행 공백, 경로 길이 및 유니코드 정규화를 비교합니다.

Microsoft의 파일 이름 지정 지침은 Windows 파일 이름 및 경로 제한을 설명합니다. 이 제한으로 인해 저장소 자체는 정상이어도 특정 복원 경로가 거부될 수 있습니다.

파일이 임시 짧은 경로로 복원된다면 저장된 콘텐츠를 사용할 수 있다는 뜻입니다. 저장소를 복구하는 대신 대상 레이아웃이나 이름 변경 매핑을 수정하세요.

ACL, 확장 속성 및 소유권 복원 확인하기

일회용 대상에서만 메타데이터 보존을 비활성화한 상태로 복원을 반복한 다음, 일반적인 메타데이터 인식 복원과 비교하세요. 처음 실패한 속성을 기록합니다.

GNU tar는 ACL 및 확장 속성 복원을 별도로 문서화하고 있습니다. 이를 통해 파일 데이터를 읽을 수 있어도 메타데이터 적용은 실패할 수 있음을 알 수 있습니다.

애플리케이션이 ACL, 소유권, 스파스 범위 또는 xattr에 의존한다면 메타데이터를 제외한 복원을 운영 환경의 해결책으로 받아들이지 마세요. 실패한 계층을 식별하는 용도로만 사용하세요.

보안 레이블 및 대상 정책 확인하기

SELinux 레이블, 바이러스 백신 또는 엔드포인트 보호, 랜섬웨어 방지 제어, 불변 플래그, 공유 권한 및 복원 대상의 애플리케이션 잠금을 확인하세요.

Red Hat은 파일이 누락되었거나 부적절한 레이블과 함께 도착했을 때 기본 보안 컨텍스트 복원을 문서화합니다.

파일이 추출되었지만 열리지 않는다면 저장소 문제가 아니라 대상 정책 문제일 수 있습니다. 복원된 파일이 필요한 동일한 사용자와 애플리케이션을 통해 테스트하세요.

복구 전에 격리된 복원을 수행하기

실패한 파일, 상위 디렉터리의 메타데이터 및 주변의 여러 파일을 비어 있는 데이터셋이나 임시 디렉터리로 복원하세요. 복구 명령을 실행하기 전에 해시, 로그 및 저장소 상태를 저장합니다.

ZimaSpace의 체크섬 및 메타데이터 검증 가이드는 저장된 콘텐츠 무결성과 실제로 사용할 수 있는 애플리케이션 복구의 차이를 함께 설명합니다.

선택한 파일이 의도한 스냅샷에서 복원되고, 예상 콘텐츠와 일치하며, 필요한 메타데이터가 적용되고, 운영 애플리케이션 경로를 통해 열릴 때 문제가 해결된 것입니다.

자주 묻는 질문

저장소 검사가 통과하면 모든 파일을 복원할 수 있다는 뜻인가요?

아니요. 검사에서 저장된 모든 데이터를 읽었는지, 그리고 대상 위치에서 각 경로와 메타데이터를 재생성할 수 있는지에 따라 달라집니다.

복원 한 번이 실패하면 즉시 복구를 실행해야 하나요?

아니요. 먼저 다른 대상에서 테스트하고, 스냅샷에 파일이 존재하는지 확인한 다음, 지원되는 데이터 검사를 실행하세요. 복구 작업으로 손상된 메타데이터나 객체가 제거될 수 있습니다.

성공적인 테스트 복원이 검증 보고서보다 더 강력한가요?

테스트한 복구 경로에 대해서는 그렇습니다. 해당 샘플에 대해 선택, 복호화, 페이로드 읽기, 대상 생성 및 메타데이터 처리가 모두 이루어졌음을 증명합니다.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.