Built-in Backup struggles

[scription]

Built-in Backup reports success while silently dropping ~36% of files — and the process itself won’t stop when told to

I’ve spent the better part of a day tracing a data-protection issue with the built-in Backup app on a fresh ZimaBoard 2 / ZimaOS install, and I think this deserves real attention from the dev team — not because it’s an edge case, but because the failure mode is specifically that the UI tells you everything is fine when it isn’t. That’s the worst kind of bug for a backup tool to have.

Posting this in detail so it’s reproducible, not just “it’s broken.”

Setup

• ZimaBoard 2, fresh ZimaOS installation (not migrated from another system)

• Source: a BTRFS RAID1 pool (2× 2TB SSD) mounted at /media/ZIMASSD, used as the AppData/storage pool for several self-hosted apps including Nextcloud

• Destination: a Synology NAS, connected via CIFS/SMB (vers=3.1.1), configured through the Backup app’s UI

• [ZimaOS version — check Settings > About and fill in before posting]

Issue 1: The source file count is wrong by ~36%

The Backup UI reported the source (Van) as 225,105 files. Running a live count on the actual source directory told a different story:

$ find /media/ZIMASSD -type f 2>/dev/null | wc -l
351334

That’s 126,229 files — over a third of the actual data — that the tool never even counted as needing backup, let alone attempted to copy. This wasn’t a mid-scan snapshot difference; the UI figure stayed fixed at 225,105 across multiple checks over more than an hour.

This almost certainly explains a second symptom I noticed independently before digging into the numbers: specific folders (in my case, my Nextcloud data directory and its own backup-archive folder) appeared completely absent from the destination, despite normal read permissions and no errors shown anywhere. If the initial source scan never counted their contents in the first place, of course they’d never show up on the far side — there’d be no error to show, because as far as the job’s file list was concerned, those files simply didn’t exist.

Issue 2: The backup process doesn’t stop when it finishes — and keeps running indefinitely

At one point the UI showed a completed run (Laatste [timestamp], matching file counts on both source and destination). Independently checking the actual process told a different story:

$ ps -p 1672 -o pid,etime,pcpu,cmd
    PID     ELAPSED %CPU CMD
   1672    03:25:39 13.8 /usr/bin/icewhale-files-backup

Still running, 3.5 hours after the UI’s own recorded completion time, still consuming CPU. Checking actual I/O activity confirmed it wasn’t doing a second useful pass either — it had simply stopped moving data and never exited:

$ sudo cat /proc/1672/io | grep bytes
read_bytes: 326670520320
write_bytes: 265061490688
[... 10 seconds later, identical numbers ...]

Zero I/O change over 10+ seconds. Fully stalled, indefinitely, while the UI displayed a normal “completed” state throughout — worse, the task menu still showed a Start button rather than any indication something was still active, so there was no visual cue anything was wrong at all.

Issue 3: The UI’s own Stop button doesn’t actually stop the process

On a later run, I clicked Stop from the task’s context menu. Checked the process immediately after:

$ ps aux | grep -i files-backup
root      679753 29.2  0.2 2211336 48116 ?       Ssl  12:08   3:54 /usr/bin/icewhale-files-backup

Still alive, still actively burning CPU, well after clicking Stop. The only way to actually terminate it was going around the UI entirely:

$ sudo systemctl stop icewhale-files-backup

That worked immediately and cleanly. So the underlying service is controllable — the UI control just isn’t wired to it reliably, or isn’t working at all.

Issue 4: Progress indicators are unreliable mid-run

During one run, the displayed transfer speed simply disappeared from the UI, and the file/size counters appeared to reset toward zero rather than continuing from where they were. I couldn’t get a clean explanation for this behavior from the UI itself — no error, no status change, just a discontinuity in what was being displayed.

Why this matters

Individually, any one of these might be dismissed as cosmetic. Together, they add up to: a backup tool that reports success on runs that didn’t finish, undercounts what it’s protecting by a third, can’t be stopped through its own controls, and gives no trustworthy live signal of what it’s actually doing. For a feature whose entire job is “tell me my data is safe,” that’s a serious gap — someone relying on the green checkmark here could go a long time without realizing a third of their data was never being backed up at all.

Related reports already on GitHub

This doesn’t appear to be an isolated case — several existing issues describe overlapping symptoms on the same icewhale-files-backup component:

• #259 — backup process hangs and pins CPU after being removed from the UI, requiring manual cleanup via SSH

• #326 — similar stuck-process behavior after deleting a backup task, requiring a manual service restart

• #338 — hidden folders silently excluded from a backup with no warning

• #435 — nested dot-folders silently skipped unless selected directly

• #442 — stale destination data when a directory is replaced by a file of the same name

• #458 — UI shows “complete” while a backup is still actively transferring in the background

Given the pattern, I’d guess several of these — and what I’ve found here — trace back to the same underlying scan/tracking logic in icewhale-files-backup rather than being unrelated bugs.

What I’d ask the team to look at

1. Make the source file count a live, verified scan rather than a value that can go stale relative to what’s actually on disk

2. Make sure the process actually exits when a run completes, and add a watchdog/timeout so a stalled run doesn’t sit indefinitely

3. Fix the Stop control so it actually signals the running process, not just updates UI state

4. Surface real errors (permission denied, skipped items, scan mismatches) instead of silently omitting files from a run

5. Consider consolidating the existing open issues above, since they look like symptoms of the same root cause

Happy to provide further logs or reproduce steps if anyone from the team wants more detail — I have journalctl output, /proc/<pid>/io snapshots, and screenshots from the full investigation.

[sergii]

I tried creating a backup using the 3.2.1 method, and the same problem occurred. I performed a clean install of ZimaOS 1.7.0 beta1, then updated to 1.7.0 beta2 on ZimaBoard2. I waited about three hours, the CPU was fully loaded, but got no results. It was difficult to stop the process. I had to manually delete it from all three sources. I no longer want to create backups using the built-in backup service.

[scription]

@scription

Built-in Backup reports success while silently dropping ~36% of files — and the process itself won’t stop when told to

Update — new findings, and the number is worse than I first reported

Following up on my own report with what I’ve since confirmed while building a replacement backup. Two things worth adding.

1. The real gap wasn’t ~36% — it was closer to ~80%.

My original figure (225,105 backed up vs ~351k “real”) came from a file count I ran as a normal user. When I re-counted as root, the actual number of files on the pool was ~1.2 million, not ~351k. The difference is permissions: a large part of my data (notably the Nextcloud data directory, owned by www-data with restrictive permissions) can’t even be traversed by a non-root process — so both my original count and, I strongly suspect, the built-in Backup app itself silently couldn’t see into those folders.

That reframes the core bug: it’s not just “skips some files,” it’s “backs up only what the backup process happens to have read permission for, and reports success regardless.” For anyone running Nextcloud, databases, or anything with restrictive ownership on their pool, that could mean the majority of their actual data is being silently skipped while the UI shows a green checkmark.

2. Confirmation of the hang/stop behaviour, with the mechanism.

I can confirm the “process won’t stop” behaviour from multiple angles now:

• The task would report done while the underlying icewhale-files-backup process kept running for hours afterward, pinned at ~14% CPU, doing no actual I/O (verified via /proc/<pid>/io — the byte counters were frozen).

• The UI Stop and Delete buttons did not reliably terminate it; only systemctl stop icewhale-files-backup actually killed it.

• The source file count shown in the UI never updated to reflect reality — it stayed fixed at the wrong number across many checks, which suggests it’s a cached figure, not a live scan. That’s likely why the “done” status can’t be trusted: it’s measuring completion against a wrong denominator.

Why this matters more than any single bug: every one of these was invisible at the “it said success” level. I only found them because I checked the actual file counts, process state, and I/O by hand. A backup tool that can’t be independently verified — and that reports success while dropping the majority of a user’s data — is genuinely dangerous, because it replaces “no backup” (a known risk you’d act on) with “a backup you falsely believe is complete.”

I’ve since moved to a transparent rsync-based setup where I can verify every run on disk. Happy to share details if it’s useful to anyone hitting the same wall — but the core ask to the team stands, and is if anything more urgent given the ~80% figure: the source scan needs to be live and permission-aware, the process needs to actually exit and be stoppable, and failures/skips need to surface instead of being swallowed.