This looks like a mount / metadata issue, not an instant data-loss event, especially given you’re on ZimaOS 1.5.3, where there are known RAID/BTRFS mount bugs.
Before attempting any rebuild or re-creation in the UI (which can destroy data), we need to confirm whether the RAID still exists at the kernel level and whether ZimaOS simply failed to mount or register it.
Please do not recreate or format anything yet.
First: verify whether the RAID is still present
If you have SSH access, please share the output of the following read-only commands:
lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
cat /proc/mdstat
These will tell us:
- Whether the disks are still visible
- Whether an md RAID device still exists
- Whether the issue is UI-level or kernel-level
Second: check storage logs
There should be mount or detection errors logged here:
/ZimaOS-HD/.log/casaos/local-storage.log
Please upload or paste the relevant section around boot or the time the RAID disappeared.
About the SQLite suggestion
If the local-storage.db path returned “No such file or directory”, that usually means:
- The path differs on your build, or
- The storage service failed early and never populated the DB
That again points to a mount failure, not erased data.
Known issue
There are reports on v1.5.3 where RAID/BTRFS volumes fail to mount due to identifier / case-sensitivity issues. This is reportedly addressed in v1.5.4, but we should confirm the current state before suggesting an upgrade.
Important
- RAID metadata lives on the disks themselves.
- If the disks were not reformatted or repartitioned, the array is very likely recoverable.
- Recreating the RAID in the UI before confirming metadata can permanently destroy the array.
Once you share the outputs above, we can advise the correct and safe next step (manual mount, metadata re-import, or upgrade path).