ZimaOS Backup is intentionally not a mirror: deleting a file from the source does not mean the backup copy should disappear immediately. The built-in Backup app is designed to preserve recovery points and protect against accidental deletion, while sync software is designed to propagate changes—including deletions.
This distinction was the core of the 2025 forum debate. IceWhale explicitly pushed back on deletion mirroring because removing a file from the backup destination as soon as it disappears from the source weakens the safety of a backup. Current 2026 ZimaOS documentation now states the same principle directly: cloud sync mirrors deletions, while backup keeps versions and restore points.
Why Deleted Source Files Can Remain in a Backup
A backup exists so you can recover from mistakes, corruption, ransomware, or unwanted changes. If deleting a source file instantly deletes every backup copy, accidental deletion propagates into the very location meant to rescue you.
The current ZimaOS 3-2-1 Backup guide explicitly says backup keeps versions and writes forward rather than behaving like a cloud mirror.
Backup, One-Way Sync, and Two-Way Sync Are Different
| Mode | What happens when the source file is deleted? | Best use |
|---|---|---|
| Backup | Older copies or versions can remain for recovery | Protection from loss and mistakes |
| One-way mirror/sync | Deletion can be propagated to the destination | Keeping an exact secondary working copy |
| Two-way sync | Deletion usually propagates between both sides | Keeping active folders aligned across devices |
The 2025 user asking for destination deletions was really asking for a mirror/sync policy, even though the task had been created in Backup.
Why an Ever-Growing Backup Can Still Be a Real Problem
The user's concern is valid: if every deleted file is retained forever, destination storage can grow indefinitely. A mature backup system therefore needs retention controls—such as number of versions, age-based expiry, or storage quotas—rather than simply mirroring deletions.
When configuring current ZimaOS Backup, check task retention and restore behavior for the destination you use. If the UI does not expose the retention policy you need, size the destination with headroom and monitor growth.
Use Sync When You Truly Want an Exact Mirror
If your goal is “destination should look exactly like source,” use a synchronization tool designed to propagate file creation, modification, rename, and deletion. Syncthing, rsync-based workflows, or another purpose-built sync tool may fit better than a backup task.
Do not rename a mirror workflow “backup” and assume it protects against deletion. A mirror can faithfully reproduce the mistake you were hoping to recover from.
Use Backup for Work, Photos, and Irreplaceable Documents
For work files, family photos, tax records, creative projects, and application data, keep at least one destination that does not immediately delete the last recoverable copy.
The backup strategy overview helps separate fast copies from true recovery copies.
Combine Backup and Sync Instead of Forcing One Mode to Do Both
A strong home-server design can use:
- a sync job for active working folders;
- a scheduled backup for versions and restore points;
- an offsite backup for disaster recovery.
This gives you the convenience of synchronized files without sacrificing historical recovery.
How to Test Your Backup Policy
Create a small test file, let the backup run, edit it, run backup again, then delete the source. Open the restore interface and check whether the older copy remains available. That tells you how the current version actually behaves before you trust it with production data.
What If You Need Automatic Cleanup?
Look for retention or version-pruning settings rather than deleting destination files manually. Manual cleanup can break restore history or remove the only good copy.
If your backup destination is running out of space, add capacity, shorten retention where supported, or move older archives to another tier rather than converting the only backup into a sync mirror.
FAQ
Why does a deleted source file remain in ZimaOS Backup?
Because backup is meant to preserve recovery points. Current ZimaOS documentation explicitly distinguishes backup from sync that mirrors deletions.
Is this a bug in ZimaOS 1.5?
The forum discussion shows the behavior was intentional from a backup-safety perspective, not simply an unexplained deletion bug.
How do I keep the destination identical to the source?
Use a one-way mirror or synchronization workflow rather than relying on a backup task whose purpose is retention.
Won't retained deleted files fill my backup disk?
They can if retention is unlimited. Manage versions, age, quotas, or archive tiers rather than deleting your only recovery history.
