If icewhale-files-backup grows to several gigabytes of RAM and repeatedly triggers the OOM killer on ZimaOS 1.7.0, update to ZimaOS 1.7.1 or newer first. IceWhale's 1.7.1 release notes explicitly fix abnormal memory usage in certain file-operation scenarios and backup failures/interruption issues.
The source thread documented a severe 1.7.0 regression: memory grew from roughly 3.5GB to more than 10GB, the kernel killed Backup, Restart=always brought it back, and the cycle destabilized the server. Masking the service stopped the loop but was only an emergency workaround.
Recognize the OOM Loop
journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -hIf the Backup process repeatedly returns as the top memory consumer, the restart loop can starve Docker and other services.
Update to 1.7.1 or Newer
The official ZimaOS 1.7.1 release notes lists fixes for abnormal memory usage and backup tasks that could fail or be interrupted.
Emergency Recovery on 1.7.0
sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.serviceMasking was necessary because normal stopping/disabling did not always prevent relaunch under the service's restart policy.
Understand What Masking Breaks
Masking disables built-in Backup. Use it only to stabilize an unusable host long enough to update or recover data.
Unmask After Updating
sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.serviceThen run a small controlled backup while monitoring RAM and swap.
USB Backup Workloads Were a Common Trigger
Multiple users reported similar behavior with USB backup targets. That helps reproduce the bug but does not prove the enclosure itself caused it.
Verify Backup Completeness
Compare source and destination file counts and perform a restore test. The backup verification guide helps reduce dependence on one job.
Check Whether Docker Was Damaged by Memory Starvation
In the thread, prolonged memory pressure eventually made Docker applications unavailable. After the host is stable, verify docker ps, the Docker daemon, and critical containers before restarting a large backup workload.
Start with a Small Backup After Updating
Do not immediately rerun the multi-terabyte or USB job that triggered the failure. Create a small test task, monitor memory for 10–20 minutes, then gradually increase file count and total size. This makes it easier to see whether the fixed service remains bounded.
File Count Matters as Much as Bytes
Hundreds of thousands of small files can create much more metadata work than a few large media files. When filing a support report, include both total bytes and approximate file count.
Keep an Independent Backup Path While Testing
If built-in Backup was previously incomplete or unstable, maintain another known-good copy with a separate tool or destination until a restore test confirms the current ZimaOS job is trustworthy.
Keep Logs from Before and After the Fix
Save the OOM messages, top memory processes, ZimaOS version, and backup target type before updating. Then repeat the same controlled workload after 1.7.1+ and compare memory growth. This gives you evidence that the regression is resolved instead of relying only on “the server feels stable.”
If memory still grows without bound on the fixed release, stop the task and submit those before/after measurements to support.
FAQ
Was the memory leak confirmed by multiple users?
Yes. Several users reported the same 1.7.0 behavior.
Did 1.7.1 address this class of problem?
Yes. The official changelog includes memory and backup fixes that directly overlap it.
Should I roll back to 1.6.2?
That was a temporary pre-1.7.1 workaround. Current users should prefer the fixed stable release.
How do I know the fix worked?
Run a controlled backup while monitoring memory, swap, logs, and destination completeness.
