If the ZimaOS system SSD is beginning to fail, clone it only after you have protected the data you cannot recreate. A whole-disk clone can preserve the ZimaOS boot layout, system database, app paths, and RAID metadata references, but cloning a failing drive is not guaranteed to succeed and should not be your only recovery plan.
IceWhale staff confirmed in the source thread that a normal clone is possible and that the storage/RAID information stored in the ZimaOS database should clone with the system disk. The safe workflow is therefore: back up critical data first, clone the entire disk while the source is still readable, boot only from the new disk, then verify storage and apps before retiring the old drive.
First Decide Whether Cloning Is Still Safe
If the SSD merely has age-related warnings or occasional read errors, an offline clone may still be reasonable. If it is disappearing from BIOS, producing repeated I/O errors, or freezing during reads, every extra pass can reduce the chance of recovering useful data.
In a severely degraded case, prioritize image/recovery tools that tolerate read errors rather than repeatedly booting ZimaOS from the failing device.
Back Up User Data and App Data Before the Clone
Do not assume RAID data is protected just because the system database can be cloned. Your storage array and your system SSD solve different problems. Copy irreplaceable files to another destination first.
The current ZimaOS 3-2-1 backup guide explains why RAID is not a backup and how to keep separate local and offsite copies.
If Docker app data lives on the system disk, back that up as well. The backup planning guide provides a practical ZimaOS backup overview.
Clone the Entire Disk, Not Individual Folders
ZimaOS uses multiple boot and system partitions. A file-level copy of the visible data folder does not reproduce the bootloader, system slots, or the database state IceWhale referred to.
Use a whole-disk imaging tool such as Rescuezilla, Clonezilla, or another block-level cloning utility. Boot the cloning utility from separate media so the failing system disk is not being actively modified during the copy.
Use a Destination Drive at Least as Large as the Source
For the simplest recovery, the replacement SSD should be equal to or larger than the old disk. If the new disk is larger, first concentrate on getting a bootable, verified clone. Expanding free space is a separate step.
Do not resize partitions during an emergency recovery unless the cloning tool requires it. Every additional transformation makes diagnosis harder.
Disconnect the Old ZimaOS Drive Before First Boot
After cloning, shut the system down and remove the failing source drive. Boot only from the replacement disk.
This matters because cloned ZimaOS disks can contain identical partition identifiers and similar boot structures. Having both connected can produce ambiguous boot behavior. A later ZimaOS staff discussion also warned users not to leave multiple ZimaOS system disks attached during recovery or migration.
Verify ZimaOS Before Touching the RAID
After the new SSD boots, confirm:
- the dashboard loads;
- the expected ZimaOS version is shown;
- apps appear and start;
- the RAID or storage spaces are visible;
- shares mount correctly;
- important files can be read.
Do not recreate or format an existing RAID just because the system disk changed. If the array does not reappear, stop and collect evidence before doing anything destructive.
Why the ZimaOS Database Matters for Existing RAID
IceWhale staff said the RAID information is stored in the system database and should be preserved by a normal clone. That explains why cloning the full system disk is more complete than a clean reinstall when the goal is to preserve an already configured storage environment.
However, if the source SSD is too damaged to clone, a clean reinstall may require support or manual recovery of existing storage metadata. That is exactly why a separate backup of critical files remains essential.
Check the Dual-System-Slot State
The current ZimaOS system recovery guide documents the A/B system-slot architecture.
After the clone boots, use the normal system recovery/status tools to confirm the system is not repeatedly falling back between slots.
What If the Old SSD Is Too Damaged to Clone?
Install ZimaOS fresh on a healthy replacement SSD, keep the data drives untouched, and contact IceWhale support before recreating an array that contains needed data. If you have backups of AppData and user data, rebuilding applications becomes much safer.
The installation recovery checklist can help separate system-disk failure from data-disk failure.
FAQ
Will cloning the ZimaOS SSD preserve my RAID configuration?
IceWhale staff said the RAID information stored in the ZimaOS database should clone normally with a whole-disk copy. Verify the array before making changes.
Should I clone a failing SSD while ZimaOS is running?
Prefer an offline clone from separate rescue media. That reduces filesystem changes and gives the cloning tool direct access to the source disk.
Can I keep the old SSD connected as a backup?
Not for the first boot. Keep it physically disconnected until the new clone is verified. Reconnecting duplicate ZimaOS system disks can confuse boot selection.
Is cloning a substitute for backing up my RAID data?
No. A clone protects the system disk state. Critical user data still needs an independent backup.
