For a planned ZimaOS system-drive upgrade, clone the entire old disk to the larger SSD, boot with the old system disk disconnected, verify every app and VM path, and only then expand usable capacity. This preserves more state than copying files manually and gives you a rollback because the original drive can remain untouched.
The 2026 source thread is community advice rather than an IceWhale staff procedure, so treat full-disk cloning as a practical migration methodโnot a formally supported one-click ZimaOS feature. The highest-risk part is not the copy itself; it is booting two duplicate system disks at once or resizing partitions before you know the clone works.
When Cloning Is Better Than Reinstalling
Cloning is attractive when:
- apps are already configured;
- VM paths and storage mappings are working;
- the source SSD is healthy;
- you want to preserve the current system exactly.
A clean reinstall can be better if the old installation has accumulated errors or most persistent app data already lives on separate storage.
Back Up VMs and App Data First
Even a planned clone can fail through a wrong disk selection, power loss, or bad destination SSD. Export or back up important VM data and persistent Docker folders before touching the system drive.
The backup planning guide provides a broader backup path.
Step 1: Clone the Whole Disk Offline
Use Rescuezilla, Clonezilla, or another disk-imaging tool from separate boot media. Copy the entire old SSD to the larger replacement SSD.
Do not copy only the visible storage partition. ZimaOS uses multiple boot/system partitions and a dual-slot architecture.
Step 2: Keep the Old Drive Untouched
After the clone completes, shut down. Remove the original SSD and store it safely. Do not format it yet.
If the clone fails to boot or an app path breaks, the untouched old SSD gives you a clean rollback.
Step 3: Boot and Verify Before Expanding
Confirm:
- ZimaOS boots normally;
- the dashboard version is correct;
- Apps appear;
- Docker workloads start;
- ZVM guests can see their disks;
- shares and mounts retain the expected paths.
Only after this verification should you think about the additional SSD capacity.
Step 4: Inspect the Cloned Partition Layout
Run:
lsblk
lsblk -f
df -hA sector clone normally preserves the original partition sizes. The extra capacity may appear as unallocated space rather than immediately increasing the writable data partition.
Do Not Resize ZimaOS System Partitions Blindly
ZimaOS uses multiple small partitions for boot and A/B system recovery. Expanding the wrong partition can make future updates or recovery fail.
If your real goal is more application/data capacity rather than a larger system partition, it can be cleaner to add a separate SSD and use ZimaOS Data Migration or App Storage Paths.
The current ZimaOS storage setup guide recommends separating fast app data and larger storage according to workload.
Alternative: Move App Data Instead of Enlarging the System Disk
If the 32GB/64GB system disk is working and the problem is only AppData growth, moving persistent application data to a larger storage space can solve the capacity problem without cloning the OS.
This reduces the blast radius of future system reinstalls and keeps user data away from the smallest disk.
What About ZimaOS Plus Activation?
Other IceWhale discussions have noted that changing the boot disk can affect ZimaOS Plus authorization and may require rebinding through support. If you use Plus, record the current activation state before migration.
FAQ
Will a full-disk clone preserve Docker paths and VM paths?
That is the main advantage of whole-disk cloning. The 2026 community recommendation specifically favored a full-disk clone to preserve the existing working paths.
Can I clone directly while ZimaOS is running?
Prefer an offline clone from rescue media so filesystem state is not changing during the copy.
Will the larger SSD automatically show its full capacity?
Not necessarily. A raw clone can leave additional space unallocated until the correct writable area is safely expanded or used separately.
When should I choose a clean reinstall instead?
Choose reinstall when the current system is unstable or when persistent data already lives safely on separate storage and rebuilding apps is straightforward.
