A finished ZimaOS Backup task should not need to be recreated simply because an external USB drive was unplugged for a few days. The backup files themselves do not disappear when the drive is disconnected, and current Backup is designed around persistent tasks, schedules, resume, and fault tolerance.
The 2026 forum thread documented two users whose manual USB backup tasks vanished from the task list. IceWhale support asked about the USB filesystem and safe disconnection but did not post a final root cause, so this should be treated as an abnormal task-persistence problem rather than normal behavior.
Update to the Current Stable ZimaOS First
ZimaOS 1.4.1 already included a fix for backup tasks disappearing or not being displayed in time. The current ZimaOS 1.4.1 release notes documents that earlier fix.
Current Backup Tasks Are Meant to Persist
The current current ZimaOS Backup guide describes reusable tasks with independent schedules and resumable transfers.
Record the USB Drive Identity
lsblk -f
blkidRecord the drive model, filesystem, label, and UUID before unplugging it. After reconnecting, compare them to confirm ZimaOS is seeing the same filesystem identity.
Safely Disconnect the USB Drive
Wait for the backup job to finish, make sure no Files or app process is using the drive, then use the supported eject/disconnect workflow before physically unplugging it.
What Should Happen When the Drive Is Missing?
The task may show failed, paused, unavailable, or wait for the destination—but the task definition should not silently vanish. If it disappears completely, capture the Backup page before recreating it.
Check Whether the Drive Format Matters
One reporting user used exFAT. That does not prove exFAT caused the problem, but filesystem type is useful evidence because removable-drive mount behavior can differ between formats.
Do Not Recreate the Task Immediately Every Time
Recreating it destroys evidence about the previous task ID/state. First reconnect the disk, refresh the page, reboot once if needed, and collect logs/screenshots showing that the task is genuinely missing.
Test Scheduled Reconnect Behavior
Create a small test backup, let it finish, safely disconnect the drive, wait/reboot, reconnect it, and confirm whether the same task returns. This controlled test is much easier for support to reproduce than a multi-terabyte production job.
The backup verification guide helps avoid relying on one unstable workflow.
Separate a Missing Task from a Missing Destination
If the USB drive is unplugged, the destination can be unavailable while the task still exists. Take a screenshot of the task list before disconnecting and compare it after reconnecting so you can prove whether the task object disappeared or only the drive went offline.
Check the Same Drive After Reconnect
A changed UUID, different partition, or reformatted filesystem can make ZimaOS see a destination as a different device. Compare lsblk -f output before and after reconnecting instead of relying on the drive's physical enclosure name.
Keep a Second Backup While the Bug Is Unresolved
If you cannot trust the task to remain registered, use another local/cloud copy for important data until the behavior is reproducible and fixed. The USB drive may still contain valid files, but automation that silently disappears is not reliable enough to be your only backup workflow.
FAQ
Do backup files disappear when the USB drive is unplugged?
No. IceWhale support explicitly clarified that the existing backed-up files remain on the drive.
Is a disappearing backup task normal?
No. Current Backup is built around persistent reusable tasks and schedules.
Should the USB drive stay connected all the time?
Not necessarily, but safely disconnect it after jobs finish and verify task behavior when it returns.
Does exFAT cause the bug?
The thread does not prove that. Record the filesystem as diagnostic evidence, not as a confirmed root cause.
