Starting with one NVMe today and moving to RAID later is a reasonable home-server plan, but the safe migration path is not “click Convert JBOD to RAID.” The February 2026 source thread recommended a controlled backup → create new array → restore → verify workflow rather than assuming ZimaOS could transform the existing single-disk storage in place.
Current ZimaOS has improved migration tooling since that post. Settings > Data Migration can now move Docker Images, Docker Application Data, and ZimaOS user databases between storage spaces. That makes application-state migration easier, but it still does not turn an already-used single disk into a redundant RAID 1/5 layout without a separate destination array.
The Source User Started with One NVMe and a USB Backup Disk
The system used built-in eMMC for ZimaOS, one NVMe SSD configured as JBOD storage, and a USB HDD for backup. The user wanted to add more NVMe storage later and move everything into RAID 1 or RAID 5.
This is exactly the situation where preserving a verified independent backup matters, because changing the storage topology can involve initializing new disks and eventually erasing the old single-disk layout.
Do Not Assume a Single-Disk JBOD Can Be Converted In Place
The community reply stated that the ZimaOS Storage UI did not expose a supported single-disk JBOD → RAID conversion workflow. It recommended building a fresh array from unused drives instead.
Current public Storage documentation now supports adding drives to certain existing RAID layouts, especially RAID 5 expansion, but that is different from converting a non-redundant single-disk storage space into RAID in place.
Back Up More Than the Obvious Share Folders
Before changing storage, protect:
- ordinary shared files;
- Docker application data;
- custom bind-mounted folders;
- application databases;
- Compose/YAML definitions for custom apps;
- important configuration that is not recreated automatically.
A backup should be verified by actually opening representative files or performing a test restore, not merely by seeing a completed task status.
Create the New RAID Before Erasing the Old Disk
The safest migration architecture is to leave the original NVMe untouched while the new RAID is created on newly added drives. That preserves the original storage as another recovery source until the new array has been validated.
Current ZimaOS handles array creation through Settings > Storage. Use the current ZimaOS Storage setup workflow rather than reproducing old manual mdadm procedures.
Choose RAID 1 or RAID 5 Based on Drive Count and Growth
RAID 1 is the straightforward two-drive mirror. RAID 5 starts at three drives and trades one drive's worth of capacity for single-drive-failure tolerance.
Current ZimaOS documentation positions RAID 5 as a growing-library option and says drives can be added over time. That can make RAID 5 attractive if the user expects the pool to expand after the initial migration.
Current Data Migration Can Move Managed ZimaOS Data
Current IceWhale documentation says Settings > Data Migration can move:
- Docker Images;
- Docker Application Data;
- User Databases such as Gallery, Downloads, Documents, Media, and Backup.
Use the current ZimaOS Data Migration workflow after the target storage exists.
Custom Bind Mounts Still Need Manual Verification
Built-in migration categories do not guarantee that every custom host path in every Compose stack will be rewritten automatically. Check applications that mount unusual folders outside standard ZimaOS-managed locations.
After migration, inspect each important app's volume mapping and confirm that the host-side folder points to the new storage.
Verify the New RAID Before Repurposing the Original NVMe
Confirm:
- the RAID reports healthy;
- important shares contain the expected files;
- Docker apps start and their databases are intact;
- permissions work from normal clients;
- backup jobs point at the intended source and destination.
Only then should the original single NVMe be wiped or reused.
Keep the USB Backup After Moving to RAID
RAID protects availability after a member-disk failure. It does not protect against accidental deletion, ransomware, application corruption, theft, or loss of the entire server.
The USB backup from the source plan remains useful after RAID migration and can become part of a wider 3-2-1 strategy.
JBOD to RAID FAQ
Can current ZimaOS move AppData between storage spaces?
Yes. The current Data Migration tool includes Docker Application Data and Docker Images.
Does that mean a single JBOD disk can be converted to RAID 1 in place?
No. Moving data and changing storage topology are separate operations.
When should the original disk be erased?
Only after the new array, files, application state, permissions, and backups have been verified.
