[I’ve searched “RAID” and didn’t see an answer so here goes]
I have two identical NVMe drives (2TB each, same brand etc). Initially I added them both thinking I might use the space (4TB) but nah, I think 2TB of RAID 1 will be better. So I disabled the drive that has nothing on it, then went to create RAID 1, but it says it will format both drives (!).
Is there a way to simply mirror nvme0 to nvme1 as RAID 1?
If not, I can backup nvme0 to an external drive, create the RAID, then copy back, but it seems kinda clunky.
TIA
Yeah unfortunately the current RAID creation flow in ZimaOS is still “create from scratch”, not a true live mirror conversion like Synology’s SHR migration or mdadm grow/migrate workflows.
So the warning you’re seeing is expected right now, even if only one disk actually contains data.
Since both disks get added into a brand new RAID1 array, ZimaOS treats them both as needing initialization and formatting first.
Your backup → create RAID1 → restore approach is honestly the safest and cleanest method at the moment, even if it feels a bit clunky.
The important thing is:
RAID1 is not a backup anyway, so having that external backup before starting is actually a very good idea regardless.
Personally, I would avoid trying to force a manual mdadm mirror conversion underneath ZimaOS unless you’re very comfortable with Linux RAID internals, because ZimaOS also tracks storage metadata/UI state and you could easily end up with mismatched mounts or unmanaged arrays in the interface.
So in your situation I’d probably do:
- Backup nvme0 externally
- Create fresh RAID1 in ZimaOS
- Restore data back onto the new RAID volume
Bit slower, but much lower risk.
Well that didn’t work. I disabled nvme1 because the “create RAID’“ option was available until I did, then I initiated the RAID option but it fails with:
failed to delete RAID info: mdadm: Couldn’t open /dev/nvme0n1 for write - not zeroing
Huh? Neither NVMe drive is currently mounted and the warning message said it would be reformatted so why isn’t it just nuking it?
TIA, m
A reboot fixed that 
but now I need to work out why docker still points to the old directory (it’s not a symlink from /DATA like everything else). I’ll try to migrate again.
That error makes me wonder whether ZimaOS still has the disk in use somewhere, even though it isn’t mounted in the Storage UI.
The key part is:
mdadm: Couldn't open /dev/nvme0n1 for write - not zeroing
which normally means the device is busy, read-only, or still being referenced by another process rather than a RAID creation problem itself.
Before doing anything destructive, I’d check whether ZimaOS still sees the drive as mounted or being used somewhere. Could you post the output of:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
mount | grep nvme
cat /proc/mdstat
That should tell us whether the disk is still attached to a filesystem, already contains RAID metadata, or is being held by something in the background.
It wasn’t mounted (as I mentioned) but it recovered with a reboot.
Everything seems to be OK though it was much more painful than it should be, since /DATA/AppData etc were still pointing to the old /media/nvme0 drive, and changing the symlinks didn’t work, there must be some config file/database that stores them that needs the UI to fix (yeah, I know, you’ve said this before 
). So I moved each directory set back to /media/nvme0 and used the UI to migrate them to the RAID drive [the root partition, where /media/nvme0 was after the RAID creation, didn’t have room for everything, hence the piecemeal approach].
Everything seems OK now (docker and VMs start ok at least) so fingers crossed
Glad to hear you got it working in the end.
The reboot fixing the mdadm error does suggest something still had the device open in the background, even though it wasn’t actively mounted. Those are always the frustrating ones because the UI looks clean but the kernel disagrees.
What you ran into afterwards with /DATA/AppData and the old /media/nvme0 paths is exactly the part that tends to catch people out. There are still references maintained internally by ZimaOS beyond the filesystem symlinks themselves, which is why manually changing links often doesn’t fully update what Docker, VMs, and the UI expect to see.
Your workaround of moving the data back temporarily and then using the Storage Manager migration through the UI was probably the safest recovery path. It lets ZimaOS update all of its internal references rather than leaving you chasing hidden configuration entries.
If Docker containers and VMs are all starting normally now, that’s a very good sign. I’d still keep an eye on it for a few days and make sure any scheduled backups, SMB shares, and app updates behave as expected, but it sounds like you’ve successfully made the transition to RAID1.
Thanks for posting the outcome too. It will definitely help the next person who tries to convert two existing NVMe drives into a RAID1 volume.
