Hyper Backup stuck in a scan loop over live LXC subvolumes

My Synology Hyper Backup job to Google Drive kept restarting and never finishing. It would run for hours, get most of the way through the scan, then bail and start over. Backup destination kept growing because new index files were being written each pass without the data ever syncing.

What was happening

The backup task covered a /backup share with a dozen subpaths — MariaDB dumps, container exports, Nextcloud archives, repos, and an LXC subvolume replica directory the Proxmox host writes into.

In Hyper Backup's UI, the job would say "Backing up" for hours, then "Detecting changes" again with no progress message. Logs were unhelpful — no errors, just restart events.

What I found

The LXC subvolume replica directory was the problem. About 30 LXC subvolume snapshots that Proxmox was actively writing to as part of the replica schedule. Hyper Backup's scan pass takes a directory snapshot, computes diffs against the last run, and starts uploading. If a file changes mid-scan it can recover — but if hundreds of files in dozens of subvolumes change during every scan, the inconsistency detector trips and restarts the entire run.

In other words: backup was scanning a moving target, and the target moved faster than the scan could complete. The "safe" paths under the same share — write-once dumps and tarballs — were getting starved because the scan never made it to the upload phase.

The fix

Two pieces. First, exclude the actively-replicated path from this backup task entirely. Hyper Backup has per-task file filters; adding the LXC replica directory pattern there stopped it from being scanned. The replicas are already redundant — that's what they're for — so they don't need to be in this offsite job.

File Filter > Exclude:
  containers/zfs-tank/**

Second, getting Hyper Backup to actually accept that change required canceling the in-progress run. The documented DSM API endpoint for that returned error 4400 and was useless. The GUI cancel button worked. Restarted the task and it completed in under an hour for the first time in weeks.

What I'd do differently

The backup config and the replica config didn't know about each other. Either I needed to point the backup at an explicit list of stable subpaths instead of "everything under this share," or I needed to land replicas somewhere the backup wasn't scanning. I chose the second — the replicas now go to a separate share that has no backup task pointing at it. Two systems, two responsibilities, no overlap.

Side note: I also found 54 nightly MariaDB dumps in that share with no rotation, going back to mid-March. A two-line cron entry on the host that runs the dumps takes care of that: find /backup/dumps -mtime +14 -delete.