Bottom Line: Missing From Files After Reboot Is Not Enough Evidence to Recreate the RAID
The logs show ZimaOS attempting to mount /dev/md0 and failing when it uses the stored filesystem type BTRFS. That points to a mount/metadata path worth investigating. It does not, by itself, prove the data is gone or prove the filesystem is healthy.
Run Read-Only Identification Checks First
lsblk -f
cat /proc/mdstat
sudo mdadm --detail /dev/md0
sudo blkid /dev/md0You want four answers: are both member disks present, is the md array assembled, what state does mdadm report, and what filesystem signature does the assembled device expose? The mdadm manual documents array inspection, while the Btrfs documentation is the upstream reference for filesystem checks.
Do Not Format, Recreate or Zero RAID Metadata While the Old Array May Be Recoverable
A fresh “Create RAID” action can turn a mount problem into data loss. The ZimaOS RAID recovery guide makes the same safety distinction: first preserve and identify the existing array, then decide whether recovery or rebuild is required.
Why /etc/fstab Is Not the First Fix
ZimaOS manages storage through its own storage service and metadata. A manual mount can prove that a filesystem is readable, but an fstab entry does not necessarily repair the state that the ZimaOS Files UI expects. The current ZimaOS storage guide is the supported baseline.
When to Escalate the Case
If /proc/mdstat and mdadm --detail show a healthy assembled array but ZimaOS still refuses to mount it, preserve the logs and the four read-only outputs above before rebooting or experimenting. That evidence tells support whether the failure is array assembly, filesystem recognition or ZimaOS mount management.
The ZimaOS data-migration guide is relevant only after the storage is healthy and visible; migration is not a substitute for RAID recovery.
