오늘 NVMe 하나로 시작하고 나중에 RAID로 전환하는 것은 합리적인 홈 서버 계획이지만, 안전한 마이그레이션 경로는 “JBOD를 RAID로 변환”을 클릭하는 것이 아닙니다. 2026년 2월 원문 스레드에서는 ZimaOS가 기존 단일 디스크 스토리지를 제자리에서 변환할 수 있다고 가정하기보다, 통제된 백업 → 새 어레이 생성 → 복원 → 검증 워크플로를 권장했습니다.
해당 게시물 이후 현재 ZimaOS의 마이그레이션 도구는 개선되었습니다. 이제 설정 > 데이터 마이그레이션에서 Docker 이미지, Docker 애플리케이션 데이터, ZimaOS 사용자 데이터베이스를 스토리지 공간 간에 이동할 수 있습니다. 따라서 애플리케이션 상태 마이그레이션은 더 쉬워졌지만, 별도의 대상 어레이 없이 이미 사용 중인 단일 디스크를 중복성을 갖춘 RAID 1/5 레이아웃으로 변환해 주는 것은 아닙니다.
원문 사용자는 NVMe 하나와 USB 백업 디스크로 시작했습니다
이 시스템은 ZimaOS용 내장 eMMC, JBOD 스토리지로 구성된 NVMe SSD 하나, 백업용 USB HDD를 사용했습니다. 사용자는 나중에 NVMe 스토리지를 더 추가하고 모든 데이터를 RAID 1 또는 RAID 5로 옮기기를 원했습니다.
이 경우에는 검증된 독립 백업을 유지하는 것이 특히 중요합니다. 스토리지 토폴로지를 변경하려면 새 디스크를 초기화하고 결국 기존 단일 디스크 레이아웃을 삭제해야 할 수 있기 때문입니다.
단일 디스크 JBOD를 제자리에서 변환할 수 있다고 가정하지 마세요
커뮤니티 답변에 따르면 ZimaOS 스토리지 UI에는 단일 디스크 JBOD를 RAID로 변환하는 지원되는 워크플로가 제공되지 않았습니다. 대신 사용하지 않은 드라이브로 새 어레이를 구성할 것을 권장했습니다.
현재 공개된 스토리지 문서에서는 특정 기존 RAID 레이아웃, 특히 RAID 5 확장에 드라이브를 추가하는 기능을 지원합니다. 그러나 이는 비중복 단일 디스크 스토리지 공간을 제자리에서 RAID로 변환하는 것과는 다릅니다.
눈에 보이는 공유 폴더 외에도 백업하세요
스토리지를 변경하기 전에 다음 항목을 보호하세요.
- 일반 공유 파일
- Docker 애플리케이션 데이터
- 사용자 지정 바인드 마운트 폴더
- 애플리케이션 데이터베이스
- 사용자 지정 앱의 Compose/YAML 정의
- 자동으로 재생성되지 않는 중요한 구성
백업은 작업 상태가 완료로 표시되었는지만 확인하지 말고, 실제로 대표 파일을 열어 보거나 테스트 복원을 수행하여 검증해야 합니다.
기존 디스크를 삭제하기 전에 새 RAID를 생성하세요
가장 안전한 마이그레이션 구조는 새로 추가한 드라이브에 새 RAID를 생성하는 동안 기존 NVMe를 그대로 두는 것입니다. 이렇게 하면 새 어레이가 검증될 때까지 기존 스토리지를 또 다른 복구 원본으로 보존할 수 있습니다.
현재 ZimaOS에서는 설정 > 스토리지에서 어레이를 생성합니다. 과거의 수동 mdadm 절차를 재현하기보다 현재 ZimaOS 스토리지 설정 워크플로를 사용하세요.
드라이브 수와 확장 계획에 따라 RAID 1 또는 RAID 5를 선택하세요
RAID 1은 두 드라이브를 미러링하는 간단한 방식입니다. RAID 5는 최소 세 개의 드라이브로 시작하며, 단일 드라이브 장애를 허용하는 대신 드라이브 하나에 해당하는 용량을 사용합니다.
현재 ZimaOS 문서에서는 RAID 5를 확장되는 라이브러리에 적합한 옵션으로 소개하며, 시간이 지나면서 드라이브를 추가할 수 있다고 설명합니다. 초기 마이그레이션 후 풀을 확장할 계획이라면 RAID 5가 매력적인 선택이 될 수 있습니다.
현재 데이터 마이그레이션으로 관리되는 ZimaOS 데이터를 이동할 수 있습니다
현재 IceWhale 문서에 따르면 설정 > 데이터 마이그레이션에서는 다음 항목을 이동할 수 있습니다.
- Docker 이미지
- Docker 애플리케이션 데이터
- Gallery, Downloads, Documents, Media, Backup 등의 사용자 데이터베이스
대상 스토리지가 준비된 후 현재 ZimaOS 데이터 마이그레이션 워크플로를 사용하세요.
사용자 지정 바인드 마운트는 여전히 수동으로 확인해야 합니다
기본 제공되는 마이그레이션 범주가 모든 Compose 스택의 모든 사용자 지정 호스트 경로를 자동으로 다시 지정해 준다고 보장할 수는 없습니다. 표준 ZimaOS 관리 위치 외부의 특이한 폴더를 마운트하는 애플리케이션을 확인하세요.
마이그레이션 후 각 중요한 앱의 볼륨 매핑을 점검하고 호스트 측 폴더가 새 스토리지를 가리키는지 확인하세요.
기존 NVMe를 용도 변경하기 전에 새 RAID를 검증하세요
다음 항목을 확인하세요.
- RAID 상태가 정상으로 표시되는지
- 중요한 공유 폴더에 예상한 파일이 있는지
- Docker 앱이 시작되고 데이터베이스가 온전한지
- 일반 클라이언트에서 권한이 정상적으로 작동하는지
- 백업 작업이 의도한 원본과 대상 위치를 가리키는지
그 후에야 기존 단일 NVMe를 삭제하거나 재사용해야 합니다.
RAID로 전환한 후에도 USB 백업을 유지하세요
RAID는 구성 디스크 하나에 장애가 발생한 후에도 가용성을 유지해 줍니다. 하지만 실수로 인한 삭제, 랜섬웨어, 애플리케이션 손상, 도난 또는 서버 전체의 손실을 막아 주지는 않습니다.
원래 계획에 포함된 USB 백업은 RAID 마이그레이션 후에도 유용하며, 더 폭넓은 3-2-1 백업 전략의 일부로 활용할 수 있습니다.
JBOD에서 RAID로 전환할 때 자주 묻는 질문
현재 ZimaOS에서 스토리지 공간 간에 AppData를 이동할 수 있나요?
예. 현재 데이터 마이그레이션 도구에는 Docker 애플리케이션 데이터와 Docker 이미지가 포함되어 있습니다.
그렇다면 단일 JBOD 디스크를 제자리에서 RAID 1로 변환할 수 있다는 뜻인가요?
아니요. 데이터 이동과 스토리지 토폴로지 변경은 별개의 작업입니다.
기존 디스크는 언제 삭제해야 하나요?
새 어레이, 파일, 애플리케이션 상태, 권한 및 백업을 모두 검증한 후에만 삭제해야 합니다.
