Docker 볼륨을 복원하면 파일 내용은 복원되지만 확장 속성은 사라지는 이유는 무엇인가요?

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

Docker 볼륨을 복원하면 모든 파일 바이트를 그대로 재생성할 수 있지만, 백업 형식, 옵션, 권한 또는 대상 환경에서 확장 속성을 보존할 수 없으면 확장 속성이 손실될 수 있습니다.

확장 속성은 일반적인 파일 내용, 소유권, 모드 비트 및 타임스탬프 외부에 저장되는 메타데이터 이름-값 쌍입니다. 여기에는 ACL 데이터, SELinux 레이블, Linux 기능, 애플리케이션 마커 또는 Samba 메타데이터가 포함될 수 있습니다. 간단한 tar 기반 볼륨 백업은 완전해 보이는 디렉터리를 복원할 수 있지만, 아카이브에 xattr이 기록되지 않았거나 복원 프로세스가 보호된 네임스페이스에 쓸 수 없으면 애플리케이션이 다르게 동작할 수 있습니다.

복원을 반복하기 전에 원본 속성 목록 작성

대표 파일을 선택하고 해시, 소유자, 모드, ACL, 모든 확장 속성의 이름과 값을 기록하세요. 복원 후 애플리케이션에서 오류가 발생하는 파일도 포함하세요.

Linux의 xattr 모델은 user, system, security, trusted 네임스페이스를 구분하며, 각각 접근 권한과 권한 요구 사항이 다릅니다.

원본에 xattr이 없다면 복원 과정에서 xattr이 손실된 것이 아닙니다. 하나의 네임스페이스만 사라졌다면 아카이브의 파일 내용 계층보다 권한, 보안 정책 또는 대상 환경의 지원 여부를 먼저 확인하세요.

Docker 백업 명령이 실제로 무엇을 아카이브했는지 확인

백업 컨테이너에서 사용한 정확한 이미지, 명령어, 작업 디렉터리, 아카이브 형식, 사용자, 마운트된 원본 및 마운트된 백업 대상 경로를 저장하세요.

Docker의 볼륨 백업 예제는 보조 컨테이너 내부에서 tar를 사용하지만, 메타데이터 보존 여부는 선택한 tar 구현과 옵션에 따라 달라집니다.

아카이브 파일이 성공적으로 생성되었다고 해서 디렉터리 항목과 데이터가 읽혔다는 것만 증명할 뿐, 모든 xattr 네임스페이스가 포함되었다는 뜻은 아닙니다. 생성에 사용한 것과 동일한 도구로 아카이브를 검사하세요.

아카이브 생성 및 추출 중 확장 속성 활성화

백업과 복원에 사용한 tar 옵션을 비교하세요. 양방향에서 xattr이 활성화되었는지, 포함 또는 제외 패턴이 필요한 네임스페이스를 제거하지 않았는지 확인하세요.

GNU tar는 --xattrs 옵션이 확장 속성을 저장하고 복원한다고 설명합니다.

추출할 때만 이 옵션을 추가하면 저장되지 않은 속성을 복구할 수 없습니다. 알려진 테스트 xattr이 설정된 원본 파일에서 새 소형 아카이브를 만들고, 운영 백업을 변경하기 전에 이를 검사하세요.

파일 기반 백업에 올바른 Rsync 메타데이터 옵션 사용

볼륨 백업에 Rsync를 사용하는 경우 송신 측과 수신 측의 아카이브, ACL, xattr, 숫자 ID, fake-super 및 권한 옵션을 확인하세요.

공식 Rsync 매뉴얼은 확장 속성 보존을 위한 -X 옵션을 설명하며, 권한 있는 메타데이터를 직접 적용할 수 없을 때 fake-super 저장 방식도 설명합니다.

일반적인 -a 아카이브 옵션이 모든 ACL 및 xattr 요구 사항을 자동으로 포함하는 것은 아닙니다. 실제 원본 및 대상 파일 시스템에서 정확한 명령어를 테스트하세요.

대상 파일 시스템 및 마운트 지원 확인

복원된 볼륨에 직접 임시 파일을 만들고 사용자 xattr 하나를 설정, 조회 및 삭제해 보세요. 호스트를 통해서도, 백업 컨테이너를 통해서도 반복하세요.

호스트와 복원 컨테이너 양쪽에서 속성 조회 도구를 사용해 대상 환경이 백업 아카이브와 별개로 xattr을 허용하고 반환하는지 확인하세요.

직접 xattr을 만들 수 없다면 파일 시스템 유형, 마운트 옵션, 네트워크 프로토콜, 볼륨 드라이버 및 스토리지 장비의 지원 여부를 확인하세요. 대상 환경이 표현할 수 없는 메타데이터는 어떤 아카이브 옵션으로도 복원할 수 없습니다.

Security 및 Trusted 네임스페이스 권한 확인

복원 컨테이너 사용자, 기능, 사용자 네임스페이스, 루트리스 모드, SELinux 정책 및 볼륨 경로가 호스트에서 바인드 마운트되었는지 기록하세요.

Red Hat은 파일을 복사하거나 다시 생성한 후 SELinux 레이블을 정책에 맞게 복원해야 할 수 있다고 설명합니다.

백업 컨테이너에 광범위한 호스트 권한을 영구적으로 부여하지 마세요. 통제된 복원 환경을 사용하거나, 먼저 일반 데이터를 복원한 뒤 지원되는 도구로 정책이 관리하는 레이블을 다시 적용하세요.

ACL, 기능 및 애플리케이션별 Xattr 구분

POSIX ACL 항목, Linux 파일 기능, SELinux 레이블, 사용자 xattr, Samba 또는 macOS 메타데이터를 각각 비교하세요. 각각 다른 원인으로 문제가 발생할 수 있습니다.

Samba의 xattr_tdb 모듈은 기반 파일 시스템과 별도로 xattr을 저장할 수 있습니다.

따라서 파일 수준의 볼륨 아카이브는 겉으로 보이는 파일 트리를 보존하더라도 별도의 Samba 메타데이터 데이터베이스는 보존하지 못할 수 있습니다. 모든 종속 메타데이터 저장소를 포함하거나 애플리케이션이 지원하는 절차를 통해 다시 생성하세요.

테스트 파일 하나를 복원하고 애플리케이션 검증

콘텐츠 해시, ACL, 사용자 xattr 및 필요한 애플리케이션 메타데이터가 포함된 알려진 원본 파일을 만드세요. 이를 백업한 다음 임시 볼륨에 복원하세요.

ZimaSpace의 NAS 권한 및 메타데이터 변경에 관한 문서에서는 더 넓은 범위의 마이그레이션 동작을 다룹니다. 이 문서에서는 Docker 볼륨 백업 및 복원에만 초점을 맞춥니다.

두 번째로 통제된 백업 및 복원을 수행한 후 콘텐츠 해시, 필요한 xattr 이름과 값, ACL, 보안 레이블 및 애플리케이션 동작이 모두 일치하면 문제가 해결된 것입니다.

자주 묻는 질문

확장 속성은 ACL과 같은 것인가요?

아닙니다. 일부 파일 시스템에서는 ACL이 system xattr을 사용해 구현될 수 있지만, xattr에는 보안 레이블, 기능, 사용자 메타데이터 및 애플리케이션별 값도 저장됩니다.

tar는 기본적으로 확장 속성을 보존하나요?

그렇다고 가정하지 마세요. GNU tar는 명시적인 xattr 옵션을 제공하며, 추출 과정에서 복원하려면 아카이브 생성 단계에서 속성이 저장되어 있어야 합니다.

root로 실행해도 복원 과정에서 xattr이 손실될 수 있나요?

예. 아카이브에 xattr이 포함되지 않았거나, 대상 환경이 xattr을 지원하지 않거나, 보안 정책이 적용을 거부하거나, 메타데이터가 별도의 애플리케이션 데이터베이스에 저장되어 있을 수 있습니다.

지원 및 팁

더 읽어보기

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.