If ZimaOS Data Migration appears stuck at a low percentage while you are moving data onto a newly created RAID, check the RAID rebuild first and avoid interrupting the migration blindly. A migration UI can look frozen even while the storage layer is still resyncing in the background.
In the source case, the migration stayed at 6% and the web interface became difficult to use, but cat /proc/mdstat showed the RAID1 array was only about halfway through a very slow resync. That is a storage workload, not proof that the migration task itself has crashed.
Why Data Migration Can Appear Frozen During RAID Resync
Creating or rebuilding a RAID array causes sustained reads and writes across its member disks. If you start a large data migration at the same time, both operations compete for disk bandwidth and I/O latency.
The current ZimaOS Data Migration guide notes that migration takes over the interface while it runs and moves whole categories such as Docker images, Docker application data, and user folders. Large jobs can therefore take far longer than the UI estimate when the destination array is busy.
Step 1: Check RAID Rebuild Status from the Terminal
Run:
cat /proc/mdstatFor a Linux md RAID, look for terms such as resync, recovery, or a progress percentage. A healthy two-disk RAID1 commonly shows both members as [UU]. If a resync is active, note the percentage, estimated finish time, and speed.
What a very long ETA means
A large ETA can be caused by slow disks, USB/SATA link problems, competing workloads, or deliberately throttled md resync. It does not by itself mean the array is broken. Check again after 10–30 minutes and verify that the percentage is moving.
Step 2: Confirm the System Is Still Doing Useful Work
If /proc/mdstat advances over time, the storage layer is alive. You do not need to install iotop just to prove that. ZimaOS is an appliance-style OS, so adding host packages with conventional distro workflows is not the preferred troubleshooting path.
You can also check whether files remain accessible from another client. In the source case, data access from a computer and the phone app still worked even while the web migration screen remained at 6%.
Step 3: Do Not Stop Docker or Kill the Migration First
Stopping Docker can remove services that the ZimaOS web experience depends on, making the system look worse while leaving the storage operation unresolved. Killing a migration mid-copy can also leave some categories in the old location and others in the new one.
Wait for active RAID recovery to finish unless the array has stopped progressing entirely or the disks show clear hardware errors.
When Should You Suspect the Migration Is Really Stuck?
Investigate further if all of these remain true for an extended period:
- the migration percentage does not change;
-
/proc/mdstatshows no active rebuild or its percentage never advances; - disk activity is effectively absent;
- the destination has enough free space;
- there are no obvious network or power interruptions.
At that point, collect the exact ZimaOS version, source and destination storage types, migration category, RAID status, and any relevant logs before rebooting.
Use the Current Data Migration Workflow
Current ZimaOS places this feature under Settings → Data Migration. The tool can move Docker Images, Docker Application Data, and User Folders at the category level. If you need to move only one application, use the app-storage path workflow instead of migrating every app together.
The data migration guide explains how managed migration differs from manually moving folders.
How to Prevent the Same Problem Next Time
Let a newly created RAID finish synchronizing before starting a large app-data or user-data migration. Confirm the destination is healthy and has enough free space, then migrate one category at a time. This reduces competing I/O and makes failures easier to isolate.
Also keep a current backup of irreplaceable data. RAID synchronization and Data Migration are both storage operations; neither should be treated as a backup.
FAQ
Can I reboot ZimaOS if Data Migration is stuck at 6%?
Not as the first step. Check RAID and storage activity first. If the array is actively resyncing, allow it to finish unless there is a hardware or safety reason to stop.
Why does the migration estimate say minutes when it takes hours?
The estimate cannot fully account for a slow RAID rebuild, heavily loaded disks, or large numbers of small files. Measure actual progress instead of relying on the initial estimate.
Does [UU] mean RAID1 is healthy?
For a two-member md RAID1, [UU] means both expected members are present. It does not mean a resync has already completed, so also inspect the progress line.
Should I install iotop on ZimaOS?
Usually not for this diagnosis. /proc/mdstat already answers whether md RAID is rebuilding, and avoiding unnecessary host package modifications keeps troubleshooting simpler.
