The Reinstall Did Not Automatically Mean the RAID Data Was Gone
A user reinstalled ZimaOS from USB onto the same eMMC after the built-in backup had filled the system drive. The existing RAID 5 no longer appeared through a clear import or reattach flow, creating the impression that the array might have been lost.
Community replies explained that reinstalling the operating system does not necessarily erase RAID metadata stored on the member disks. The critical condition was that the user had not reformatted, initialized, or rebuilt those disks. The author powered the NAS off and stopped making changes while asking for guidance.
Do Not Create a New Array or Format the Member Disks
The strongest safety instruction in the thread was to pause disk operations. A missing array in the user interface is not proof that its data no longer exists. Creating a replacement pool or accepting a format prompt can overwrite the metadata and content needed for recovery.
The discussion linked a related community RAID 5 recovery discussion, but participants still avoided publishing generic assembly commands because disk order, array condition, RAID level, and version history can differ.
ZimaOS Did Not Offer a Clear Import Flow in This Case
The replies described a gap between technical recoverability and the ZimaOS interface available at the time. The disks could retain the array while the freshly installed system failed to guide the user through reattaching it. A community feature request for attaching an existing array was also referenced.
The author later located the array and contacted the Zima Community team. After receiving case-specific help, they reported that the issue was fully resolved and their applications were running as before. They deliberately withheld the exact recovery procedure because applying one RAID sequence to a different disk state could cause damage.
Application Data Required a Separate Restoration Step
The user had previously migrated ZimaOS AppData to the RAID. After the array was restored, temporary migration paths had to be renamed while migration was configured again. The apps were then reinstalled from the store and resumed using their retained data.
This outcome depends on the application data still being present and its paths being restored correctly. Reinstalling an app is not the same as recreating its data, and changing migration paths without understanding the existing layout can disconnect an app from its volumes.
When to Stop and Ask for Case-Specific Help
Stop if the interface offers to initialize disks, if any member is missing, if the array was degraded before the reinstall, or if the correct device order and metadata state are unknown. The resolved user and the community reply both recommended contacting community@icewhale.org rather than guessing with live data.
Version Boundary
The system had originally been on a 1.4.x release and was running ZimaOS 1.5.3 after the reinstall and upgrade. The thread documents one resolved recovery case, not a guarantee that every array or later ZimaOS release behaves identically.
FAQ
Does reinstalling ZimaOS erase a RAID automatically?
Not in this case. The array survived because the member disks were not reformatted or reinitialized. The author later recovered it with community assistance.
Should I create a new RAID with the same disks to make it appear?
No. The thread explicitly warns against creating a new array or formatting the disks, because those actions can destroy recoverable data.
Why are exact recovery commands omitted?
RAID states differ, and a command that is appropriate for one array may damage another. The resolved user intentionally recommended case-specific support.
