ZFS 데이터셋이 성공적으로 마운트된 후 비어 있는 것처럼 보이는 원인은 무엇인가요?

ZFS 데이터셋은 마운트된 것으로 표시되지만, 예상한 데이터가 하위 데이터셋이나 숨겨진 마운트 지점 또는 다른 가져오기 루트에 있으면 비어 있는 것처럼 보일 수 있습니다.

마운트 플래그는 하나의 데이터셋이 하나의 경로에 연결되어 있다는 사실만 증명합니다. 해당 경로가 애플리케이션이나 사용자가 예상하는 경로인지, 하위 데이터셋이 그 아래에 마운트되었는지, 암호화된 하위 데이터셋이 잠금 해제되었는지는 증명하지 않습니다. 빈 상위 데이터셋도 실제 파일이 모두 하위 데이터셋에 있다면 완전히 정상일 수 있습니다. 데이터를 복사하거나 풀 구조를 변경하기 전에 데이터셋 속성, 참조 공간, 마운트 테이블 및 디렉터리 보기를 비교하는 것부터 시작하세요.

데이터셋 공간과 연 디렉터리 비교

데이터셋 이름과 USED, REFER, AVAIL, MOUNTPOINT, MOUNTED 값을 기록하세요. 그런 다음 사용자 또는 애플리케이션에 표시된 정확한 디렉터리를 나열하세요.

데이터셋에 참조된 데이터가 거의 없다고 표시되면 파일이 하위 데이터셋, 스냅샷, 클론 또는 이름이 비슷한 다른 데이터셋에 속해 있을 수 있습니다. FreeBSD ZFS 핸드북은 데이터셋을 별도로 관리되는 파일 시스템으로 설명하므로, 풀 수준의 사용량과 특정 디렉터리에서 연 내용이 반드시 동일한 데이터셋을 나타내지는 않습니다.

그래픽 파일 브라우저만 보고 데이터 손실을 추정하지 마세요. ZFS 속성 보기, 운영 체제의 마운트 테이블, 컨테이너나 제한된 애플리케이션 네임스페이스 밖에 있는 로컬 root 셸을 서로 비교하세요.

mountpoint, mounted, canmount를 함께 확인

데이터셋의 마운트 지점이 명시적인지 상속된 것인지, 실제로 해당 경로에 마운트되어 있는지, canmount가 on, off, noauto 중 무엇인지 확인하세요.

Oracle의 ZFS 속성 안내에 따르면 mountpoint와 canmount는 데이터셋이 자동으로 마운트되는지, 요청할 때만 마운트되는지, 또는 하위 데이터셋에 속성만 전달하는 데 사용되는지를 결정합니다.

데이터셋은 하위 데이터셋에 상속 속성을 제공하면서도 의도적으로 직접 마운트되지 않을 수 있습니다. 반대로 legacy 마운트 지점을 사용하는 데이터셋은 ZFS 속성상 정상으로 보여도 별도의 시스템 마운트 항목에 의존하며, 해당 항목이 실행되지 않았을 수 있습니다.

상위 및 하위 데이터셋 마운트 검사

풀 아래의 전체 데이터셋 트리를 나열하고 마운트 지점 기준으로 정렬하세요. 상위 데이터셋과 사용자 파일, 애플리케이션 데이터, 백업 또는 미디어를 저장해야 하는 모든 하위 데이터셋을 비교하세요.

빈 상위 데이터셋은 속성과 마운트 지점을 구성하는 용도로만 존재할 때 흔히 발생합니다. FreeBSD의 ZFS 데이터셋 네임스페이스에서는 각 하위를 자체적으로 관리되는 데이터셋으로 취급하므로, pool/data는 비어 있어도 pool/data/photos에 실제 파일이 있을 수 있습니다.

상위 데이터셋은 마운트되었지만 하위 데이터셋이 마운트되지 않았다면 하위 데이터셋을 별도로 진단하세요. canmount, 암호화 키, 충돌하는 마운트 지점, 가져오기 실패 여부 및 하위 데이터셋 마운트가 완료되기 전에 서비스가 시작되었는지를 확인하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

마운트가 디렉터리에 이미 있던 파일을 숨겼는지 확인

데이터셋이 마운트되기 전에 일반 디렉터리에 파일이 존재할 수 있습니다. ZFS 데이터셋이 해당 경로에 마운트되면 기본 파일 시스템에 여전히 남아 있더라도 그 아래의 파일은 경로에서 숨겨집니다.

데이터셋을 마운트 해제하는 작업은 통제된 유지 관리 시간에만 수행하고, 호스트에서 기본 디렉터리를 검사하세요. Linux 마운트 매뉴얼은 마운트된 파일 시스템이 해당 경로를 차지하는 동안 기존 마운트 지점의 내용이 보이지 않게 된다고 설명합니다.

반대쪽 오류도 발생할 수 있습니다. 예상한 ZFS 마운트가 실패하면 비어 있는 기본 디렉터리가 사용자와 컨테이너에 표시됩니다. 이 경우 정상적인 데이터셋이 단순히 서비스되는 경로에 연결되지 않았을 뿐인데도 비어 있는 것처럼 보일 수 있습니다.

대체 루트 및 legacy 마운트 동작 배제

풀이 대체 루트, 복구 옵션, 임시 마운트 경로 또는 다른 풀 이름으로 가져와졌는지 확인하세요. 데이터셋이 일반적인 운영 위치가 아니라 접두사가 붙은 복구 경로 아래에 정상적으로 마운트되었을 수 있습니다.

대체 루트를 사용해 풀을 가져오면 해당 임시 루트를 기준으로 데이터셋 마운트 위치가 다시 지정됩니다. Ubuntu의 zpool import 참고 문서에 따르면 -R은 altroot을 설정하며, -N은 파일 시스템을 마운트하지 않고 풀을 가져올 수 있습니다.

마운트 지점이 legacy인 데이터셋도 검사하세요. 이 모드에서는 ZFS가 마운트를 자동으로 관리하지 않으므로 운영 체제의 마운트 설정이 기준이 됩니다.

암호화된 하위 데이터셋 및 컨테이너 마운트 네임스페이스 확인

상위 데이터셋이 마운트된 후에도 암호화된 하위 데이터셋의 키가 로드되지 않았거나 하위 데이터셋 마운트가 실패하면 해당 하위 데이터셋을 사용할 수 없습니다. 그러면 풀이 온라인 상태여도 상위 디렉터리가 비어 있거나 불완전하게 보입니다.

암호화된 모든 하위 데이터셋의 키 상태와 마운트 상태를 확인한 다음, 호스트 경로와 컨테이너에 표시되는 경로를 비교하세요. Canonical의 LXD 문서에 따르면 컨테이너 디스크 장치는 호스트 소스를 별도의 인스턴스 경로에 매핑하므로, 호스트에서 보이는 하위 데이터셋이 오래된 컨테이너 마운트에는 없을 수 있습니다.

호스트에서는 데이터가 보이지만 컨테이너에서는 보이지 않는다면 컨테이너의 바인드 소스와 마운트 전파를 검사하세요. ZFS 하위 데이터셋이 마운트되기 전에 생성된 컨테이너는 서비스가 다시 생성되거나 마운트가 올바르게 전파될 때까지 기본 디렉터리의 빈 내용을 계속 볼 수 있습니다.

데이터셋을 복사하지 않고 올바른 보기 복원

확인된 가장 작은 범위의 속성 또는 경로만 수정하세요. 누락된 하위 데이터셋을 마운트하거나, 상속된 마운트 지점을 수정하거나, 의도하지 않은 대체 루트를 제거하거나, legacy 마운트 항목을 복구하거나, 암호화 키를 로드하거나, 올바른 바인드 소스로 컨테이너를 다시 생성하면 됩니다.

ZimaSpace 홈 서버 복구 체크리스트도 같은 원칙을 제시합니다. 복구 도구를 실행하거나 데이터를 복원하기 전에 저장소 계층과 마운트 상태를 확인하세요.

예상한 데이터셋과 하위 데이터셋 마운트가 의도한 경로에 나타나고, 참조 공간이 보이는 파일과 일치하며, 애플리케이션이 호스트와 동일한 트리를 보고, 내보내기, 가져오기, 서비스 재시작 및 재부팅 후에도 구성이 유지되면 진단이 완료된 것입니다.