Bottom Line: The High CPU Was the Backup Job, Not a Persistent ZimaOS CPU Regression
The NAS jumped from roughly 3% CPU to 45–60% after installing 1.7.0 Beta 2, and temperature rose from about 32–36°C to 58°C. The key follow-up solved it: the upgrade had triggered previously configured Backup processes. After stopping those jobs and restarting ZimaOS, CPU returned to normal.
Check Workload Before Rolling Back the OS
When CPU spikes immediately after an update, first ask what resumed: backup, indexing, media scans, checksum work, app pulls or container restarts. Use top or ps for host processes and docker stats for containers. Docker documents live CPU/memory reporting in docker stats.
Use a Simple Confirmation Test
Pause the suspected job. If CPU falls promptly and rises again when the job resumes, you have a workload cause rather than a vague “beta is hot” theory. In this case, the user did exactly that and the system returned to its previous behavior.
Backup Activity Can Legitimately Be CPU and I/O Heavy
Backup work can include file enumeration, hashing, compression, encryption and large reads/writes. The current ZimaOS 3-2-1 backup guide explains scheduled tasks and why verification matters. The backup hardware planning guide is useful when jobs are large enough to affect normal NAS activity.
For host-side process diagnosis, the top manual explains the CPU and process fields used to identify the actual workload.
When It Is Still an OS Problem
If CPU remains high with Backup stopped, identify the process that owns the load and capture logs before rebooting. A stable NAS with full share access but high utilization is not enough evidence by itself to call the operating system defective.
For version context, see the ZimaOS 1.6/1.7 upgrade context page and the current ZimaOS page.
