Bottom Line: Do Not Plan on an In-Place RAID 1 to RAID 0 Conversion
If your real goal is one ~44 TB RAID 0 volume from two 22 TB drives, plan for backup → destroy/recreate → restore. That is the clean, verifiable path. A RAID 1 mirror and a RAID 0 stripe have different layouts; changing the storage goal is not just “turning off redundancy.”
Do Not Rely on the Forum Claim That One Disk Will Definitely Be Preserved
The thread suggested a possible path where one mirror member keeps its data while the other becomes standalone storage. The current public ZimaOS storage documentation does not define that behavior as a supported promise. If the UI says formatting is involved and the data matters, stop and back up first.
Back Up and Verify Before Any Destructive Storage Change
The current ZimaOS 3-2-1 backup guide makes the core rule explicit: RAID is not backup, and a backup should be restore-tested. If the array contains anything you care about, copy it elsewhere and open restored files before breaking the mirror.
If You Need Recovery Rather Than Reconfiguration, Use a Different Playbook
Do not confuse “I want more usable capacity” with “my RAID metadata is missing after reinstall.” The ZimaOS RAID 1 recovery guide is deliberately conservative about destructive commands and disk identification.
The Linux kernel MD software RAID documentation provides lower-level background on Linux RAID arrays; it does not override the supported ZimaOS UI workflow.
Advanced RAID Commands Are Not a Shortcut
Linux mdadm can inspect and manage software RAID, but destructive flags can erase array metadata. Review the mdadm manual before using any CLI path, and do not use --zero-superblock as a casual experiment.
If you are planning a larger multi-drive layout from scratch, the ZimaCube 2 multi-drive NAS page gives the current hardware context for capacity-focused builds.
