The original ZimaOS 1.5.3 “Always” schedule really did say LAN/cloud backup sources should be checked daily at 1:00 AM, but multiple users reported that the jobs did not start automatically. Manual runs worked, which narrowed the issue to scheduling/service behavior rather than basic source or destination access.
The workaround of restarting icewhale-files-backup.service forced jobs to run for some users, but the original poster explicitly called that approach unreliable. It should remain a diagnostic workaround, not the recommended normal scheduler.
What the 1.5.3 UI Promised
For Zima/USB sources, “Always” meant reacting to file changes. For cloud or LAN sources, the tooltip described a once-daily check at 1:00 AM device time.
Manual Success Does Not Prove the Scheduler Works
If “Run now” succeeds, source credentials, path access and destination writes are probably functional. The next checks are device timezone, task schedule state and the backup service around the expected trigger time.
The Service-Restart Workaround Was Community-Verified but Not Ideal
One user found that restarting icewhale-files-backup.service caused jobs to run, then scheduled that restart with cron. Another user used Zima Cron for the same idea. The source poster noted that a normal crontab could be erased by ZimaOS updates.
The current current ZimaOS Backup guide now describes independently scheduled tasks rather than relying on that old service-restart pattern.
Later Versions Showed a Different Backup Failure
After upgrading to 1.6.1, a user reported jobs that appeared to run but moved no files. That is not the same symptom as “the 1 AM trigger never fired,” so the two should be diagnosed separately.
Use the Current Backup App Before Keeping an Old Workaround
Recreate the task on the current stable ZimaOS, set an explicit schedule, verify the device timezone, and restore a test file after the first successful run. The ZimaOS backup overview provides the present product model.
Bottom Line
The 1.5.3 thread documents a real scheduler problem with LAN/NAS backup sources, but restarting the service every night was only a workaround. On current ZimaOS, reproduce the task with the modern scheduler, verify timezone and logs, and treat “job did not start” separately from “job started but transferred nothing.”
