이 글은 고급 스토리지 마이그레이션 실패 보고서이며, 지원되는 가져오기 방법을 설명하는 글이 아닙니다. 소스 배열은 Linux 커널 수준에서 구성되었지만 ZimaOS의 Storage 계층이 이를 정상적으로 인식하지 못했고, 사용자는 지속적인 UI 오류를 겪었습니다.
커널 수준의 배열 감지는 ZimaOS 관리와 다릅니다
Linux 시스템은 RAID 메타데이터나 파일 시스템을 인식할 수 있지만, 어플라이언스형 스토리지 관리자는 해당 풀을 안전하게 관리하는 데 필요한 수명 주기 상태를 갖추지 못할 수 있습니다. RAID 복구 워크플로는 ZimaOS가 이미 이해하는 배열에 대해 더 안전한 원칙을 보여 줍니다. 기존 RAID 메타데이터를 보존하고, 첫 단계로 배열을 재생성하지 않는 것입니다.
OpenZFS에는 명확한 내보내기 및 가져오기 수명 주기가 있습니다
공식 OpenZFS 풀 내보내기 문서에 따르면, 풀을 내보내면 데이터 세트가 마운트 해제되고 장치가 내보낸 상태로 표시되어 나중에 이동하고 가져올 수 있습니다. OpenZFS 풀 가져오기 문서에서는 다른 호스트가 사용 가능한 풀을 검색하고 가져오는 방법을 설명합니다.
현재 ZimaOS 개발자 문서에도 zpool export를 포함한 ZFS CLI 작업이 안내되어 있습니다. 그러나 이는 임의의 mdadm+Btrfs, 네이티브 Btrfs, ZFS 풀을 가져오는 범용 GUI 마법사와는 다릅니다.
현재 공개 문서에는 범용 외부 풀 마법사가 안내되어 있지 않습니다
현재 Storage 마법사는 ZimaOS 스토리지를 생성하고 관리하는 데 초점을 두며, 공개 ZFS 개발자 가이드에서는 수동 ZFS 작업을 설명합니다. 외부 배열을 도입하는 것이 아니라 관리되는 ZimaOS 데이터를 새 스토리지로 옮기려는 것이 실제 목적이라면, ZimaOS 데이터 마이그레이션이 현재로서는 더 안전한 방법입니다. 파괴적인 스토리지 작업을 시작하기 전에 ZimaOS 백업 워크플로를 계획에 포함해야 합니다.
유일한 데이터 사본에 강제 가져오기 복구 플래그를 사용하지 마세요
OpenZFS는 강제 가져오기 또는 복구 가져오기를 수행하면 최근 트랜잭션이 삭제되거나 그 밖의 위험이 발생할 수 있다고 경고합니다. 중요한 데이터의 유일한 사본에 복구 플래그를 사용하거나 파괴적인 재포맷을 시도하지 마세요.
결론
1.6.1 커뮤니티 실패 사례는 커널이 인식하는 외부 배열이 ZimaOS가 관리하는 풀과 자동으로 동일하지 않다는 점을 보여 줍니다. ZFS에는 정의된 내보내기/가져오기 수명 주기가 있지만, 현재 공개된 ZimaOS 문서에는 모든 외부 RAID/파일 시스템 조합을 도입할 수 있는 하나의 범용 GUI 워크플로가 안내되어 있지 않습니다.
