The source recovery was straightforward and user-verified: a four-disk RAID 5 had one drive marked Damaged. The owner powered the ZimaCube down, replaced that disk, powered the system back on, followed ZimaOS's storage prompts, and reported that the rebuild started with an estimated 13.5 hours remaining.
Current ZimaOS documentation now describes this same managed workflow more explicitly: when a RAID disk fails, the array becomes degraded, the data remains accessible, and after the failed disk is replaced ZimaOS guides the user through the rebuild. The old source also reported that another RAID 0 array became read-only at the same time; current docs do not describe that as the normal permanent behavior for every unrelated array.
Confirm Which Physical Disk Actually Failed
Before pulling anything, match the ZimaOS Storage status to the physical bay/serial number. In a degraded RAID 5, removing the wrong healthy member can turn a single-drive failure into a much more dangerous multi-drive outage.
Copy Critical Data Before Rebuild If the Array Is Still Accessible
RAID 5 survives one member failure, but the rebuild reads heavily from every surviving disk. If another disk has marginal SMART health or unreadable sectors, the rebuild is the moment those weaknesses matter most.
If the array is accessible and the data is irreplaceable, copy the most important files to independent storage before starting a long rebuild whenever practical.
The Source Replaced the Disk While Powered Off
The OP shut the ZimaCube down before swapping the damaged disk. That is the safest default when you are not explicitly relying on a documented hot-swap workflow.
After installing the replacement drive, power on and let ZimaOS detect the degraded array and the new eligible disk.
Use the ZimaOS Rebuild Prompt
The source user did not post a manual mdadm repair command. They followed the storage UI prompts, and the rebuild began successfully.
Current IceWhale storage guidance says the same thing: replace the failed drive and let ZimaOS guide the rebuild.
Use the current ZimaOS storage recovery workflow.
Use an Equal-or-Larger Replacement Disk
A replacement drive must be large enough to satisfy the RAID member geometry. Two drives marketed at the same nominal capacity can differ slightly in usable sector count, so matching model/capacity where possible reduces surprises.
Monitor Rebuild Progress and Disk Health
ZimaOS 1.3.2 and later added clearer progress display for RAID rebuild/parity operations. During the rebuild, avoid unnecessary shutdowns, monitor temperatures/SMART health, and keep heavy workloads lower if possible.
Verify the Array After Recovery
When rebuild finishes, confirm:
- RAID status returns to healthy;
- all expected members are active;
- shares and apps can read/write normally;
- important files open correctly;
- your independent backup is current.
The Source's Second RAID 0 Being Read-Only Was a Separate Symptom
The user reported both arrays were placed read-only even though only RAID 5 had the damaged disk. The thread did not document why the unrelated RAID 0 was protected that way or what exact action restored its write access.
Do not assume a current ZimaOS system will always make every array read-only after one RAID failure.
RAID 5 Recovery FAQ
Did the source user successfully start the RAID5 rebuild?
Yes. After replacing the failed disk and following the prompts, the array entered recovery with about 13.5 hours estimated.
Should I manually run mdadm commands first?
Not for the source-confirmed workflow. Use the managed ZimaOS rebuild path unless IceWhale support gives version-specific CLI instructions.
Is RAID 5 a backup?
No. RAID maintains availability through one disk failure; it does not protect against accidental deletion, corruption, theft, or another failure during rebuild.
