# Changelog

All notable changes to the Vault plugin will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/), and this project uses date-based versioning (`YYYY.MM.PATCH`).

## [Unreleased]

### Added

- **VM backup jobs now detect raw vs qcow2 disks and only offer supported backup types** (closes #163). Vault reads each VM's disk format at discovery time and exposes it (`disk_format`, `supports_incremental`) on `GET /api/v1/vms`. Because libvirt checkpoint-based incremental/differential backups require qcow2 disks, the job wizard now hides those options — and falls back to Full — when a selected VM uses raw or mixed disks, with an inline note naming the affected VM. This surfaces up front the constraint the engine previously enforced silently by downgrading raw-disk VMs to full backups.
- **Pre/post-backup scripts now receive job context as environment variables** (part of #187). The job editor has long promised `VAULT_JOB_NAME` and `VAULT_STATUS` to hook scripts, but they were never actually set. Vault now exports `VAULT_JOB_NAME`, `VAULT_STATUS` (`starting` for pre-scripts, the run's final status for post-scripts), `VAULT_JOB_ID`, and `VAULT_RUN_ID` into every pre/post-backup script's environment — enabling, for example, an Immich `pg_dump` pre-script that targets the right job.
- **Container exclusion presets can now carry advisory notes and warnings** (part of #187). `GET /api/v1/presets/exclusions` returns optional `notes`/`warnings` for apps that need a caveat, and the job wizard shows them inline beneath the container's exclusions.
- **Docker named volumes are now backed up, not silently skipped.** Vault previously only backed up bind mounts, so containers that store their data in named `docker volume`s (many compose stacks — the single most-reported gap for the old appdata.backup plugin) were archived empty. Vault now backs up named volume mounts too — a volume's data lives at a real host path (`/var/lib/docker/volumes/<name>/_data`), handled exactly like a bind mount — across the classic, dedup and restore paths, and reattaches them on restore via the container's bind spec. The job wizard's mount editor lists them tagged "named volume" so you can include or exclude each one. Anonymous volumes (a random 64-hex id) are deliberately skipped because they can't be reliably reattached on restore; tmpfs/npipe and other non-data mounts are skipped as before.
- **Compression level is now configurable per job** (fastest / default / better / best). The job wizard exposes a level next to the compression algorithm, mapped to the zstd/gzip encoder levels, so you can trade backup time for archive size. The default level is unchanged, so existing jobs and their archives are byte-for-byte identical.
- **Jobs that would back up into their own source are now rejected up front.** Saving a job whose local destination path sits inside (or contains) one of its folder/flash source trees now returns a clear error instead of silently archiving each run into the next run's source — the old plugin's "backing itself up" footgun. Remote destinations are unaffected.
- **Sparse files that could stall a backup are now flagged.** Vault logs a warning when a large file's logical size vastly exceeds its on-disk size (e.g. a Meilisearch/LMDB store reporting terabytes but occupying kilobytes), so a slow backup reading the full logical extent is no longer a silent mystery — the exact trap behind the old plugin's multi-hour stalls.
- **Containers that route their network through another container are flagged.** When a container uses `network_mode: container:<other>` (a Gluetun/VPN-sidecar setup), Vault now logs a note reminding you to include the provider in the same job and order it to start first, so the dependent doesn't lose its network when restarted after backup.

### Fixed

- **Backups no longer fail when the Recycle Bin plugin is installed** (closes #204). The Unraid Recycle Bin plugin creates a `/mnt/RecycleBin` view directory (symlinks/subfolders, not a real pool) that it rebuilds periodically. Vault's staging-pool discovery treated it as a normal pool and staged backups there, so a docker or flash backup could fail mid-run with `open /mnt/RecycleBin/.vault-stage/…: no such file or directory` when the plugin regenerated the view. `/mnt/RecycleBin` (and any dot-prefixed `/mnt` entry such as a stray `.Recycle.Bin`) is now excluded from staging-pool candidates.
- **Flash and folder backups now honour path exclusions** (closes #204). The classic tar backup path used for flash/folder items on non-dedup destinations ignored `exclude_paths` entirely, and the job wizard offered no way to set them. Folder items (including the Flash Drive preset) now have an "Exclude paths" editor in the wizard's advanced step, and the engine applies those exclusions on the classic path just as it already did for deduplicated backups — so you can, for example, exclude a share's `.Recycle.Bin` folder from a flash backup.
- **The Recycle Bin plugin's trash folder is auto-excluded from the Flash Drive backup when detected** (closes #204). Vault now detects the installed Recycle Bin plugin (via its `/boot/config/plugins/recycle.bin.plg` marker) and, when present, pre-fills `.Recycle.Bin` as a recommended exclusion for the Flash Drive backup in the job wizard — so deleted files held in the trash aren't backed up. The pre-filled exclusion is shown in the editor and can be changed or removed.

### Changed

- **Rate limiting on the encryption-verify and API-key endpoints now uses an explicit client-IP key.** Migrated off `httprate`'s `LimitByIP`, which a recent dependency bump deprecated (tripping the lint/build gate), to `LimitBy` with a documented key function. Behaviour is unchanged — requests are still bucketed by the connecting TCP peer address — the trust model is just stated explicitly now.
- **Anomaly messages are now plain-English sentences** (closes #192). Every detector now describes what happened versus what was expected in friendly language — e.g. _"This backup took 4m 23s, about 1.2× its usual 3m 40s"_ instead of _"backup duration anomaly: 4m 23s (1.2x median)"_ — across the dashboard, the anomalies page, notifications, the API, and MCP. Notifications also replace the raw JSON blob (`{"z_score":11.06,...}`) with a short context line such as _"Based on the last 10 samples"_, while the precise statistics remain available in the structured `details` field for programmatic consumers.
- **Tdarr container backups now drop stray log files and are covered by tests** (closes #188). The Tdarr exclusion preset already skipped the transcode cache (`/temp`) and log directory (`/app/logs`); it now also excludes stray `*.log` files, while deliberately keeping `/app/server` (the DB2 database, plugins and samples) and `/app/configs` so Tdarr settings and statistics restore cleanly. Both the combined `tdarr` image and the `tdarr_node` image are recognised, now with regression tests to keep detection working.
- **Immich container backups are now correct for both image variants** (closes #187). The exclusion preset previously only covered the imagegenius fork's `/photos` layout; it now also covers the official `immich-app` image's `/data` layout, excluding only regeneratable thumbnails and re-encoded video while always keeping the original `upload`/`library`/`profile` assets and Immich's built-in `backups/` database dumps. The wizard now also surfaces a warning that Immich's PostgreSQL database runs in a separate container and must be captured via Immich's built-in database backup, a dedicated Postgres backup job, or a `pg_dump` pre-script — see the Backup Jobs guide in the documentation for the recommended setup.

## [2026.07.01] - 2026-07-04

### Added

- **Documentation link in Settings → Reference** (closes #189). A new Documentation card at the top of the Reference tab links directly to the online manual at [ruaan-deysel.github.io/vault](https://ruaan-deysel.github.io/vault/), so users can reach the guides and settings reference without leaving the plugin.
- **Optional "Backups" quick link in the Unraid top navigation** (closes #162). Enable it under Settings → Utilities → Vault → Quick Access to get a one-click **Backups** entry in the Unraid top bar that opens the Vault web UI embedded in the Unraid interface. Off by default. Unlike the community add-on that inspired it, this uses Unraid's supported plugin menu extension point — no core files are patched and no background watchdog is needed; the embedded view also refreshes its session token automatically when you return to a long-idle tab.

### Fixed

- **Anomaly baselines no longer report a 100% failure rate for every job** (closes #181). The baseline refresher counted a run as failed unless its status was `success` — a value the runner never writes (successes are `completed`) — so every job's stored failure rate was a meaningless constant 1.0. Failures are now counted the same way the reliability detector counts them (`failed` status or failed items), producing real rates.
- **Database snapshots are now written atomically** (closes #182). The pool snapshot and USB safety-net copy were written directly over the previous good file, so a crash, power loss, or full disk mid-save corrupted the very copy the daemon needs for disaster recovery. Snapshots are now written to a temp file and renamed into place only after completing successfully — and if the primary snapshot is ever unreadable at startup, the daemon now also tries the rotated snapshot copies (newest first) before falling back to the USB copy or a fresh database.
- **Post-backup health checks show container names again after a container was recreated** (closes #178). In stop-all mode, the health check after restarting containers looked names up by the stored container ID — but when a container had been recreated (update, compose recreate) the runner works with the re-resolved ID, so the check reported the raw 64-character ID instead of the name. Names now resolve through the re-resolved IDs too.
- **Filename validation now rejects single backslashes** (closes #179). The path-separator guard in restore-name validation checked for a double backslash due to an escaping mistake, letting a single `\` through this specific check (harmless on Linux, but the guard didn't do what it said). It now rejects both `/` and `\`.
- **Replication sync results are now honest about failures** (closes #177). A sync whose jobs all failed to copy still recorded "success" and announced a completed sync — a false safety signal for an off-site-copy feature. Sync status is now `success` only when every job synced, `partial` when some failed, and `failed` when nothing synced, with the failure count shown on the Replication page (which previously showed failed syncs as "Pending").
- **Replicated restore-point metadata can no longer be silently corrupted** (closes #176). The replication origin marker was spliced into restore-point metadata by string concatenation, so a source name containing quotes/backslashes — or metadata like `{ }` — produced invalid JSON, silently stripping checksums and dedup manifest references from every replicated restore point. The metadata is now rebuilt through the JSON encoder and is always valid.
- **Restoring over an existing installation no longer fails on pre-existing symlinks** (closes #175). Regular files are overwritten during restore, but symlink and hardlink entries were created without replacing what was already on disk — so restoring a container/folder backup onto a live appdata tree aborted with "file exists" at the first pre-existing link (version symlinks, certificate links, node_modules/.bin). Links are now replaced like files; directories are never silently removed.
- **Deduplicated backups no longer fail outright on a single unreadable file** (closes #174). Classic backups skip inaccessible files with a log line, but the deduplicated (chunked) path aborted the entire item on the first permission-denied or vanished file — so the same job succeeded on a classic destination and hard-failed on a dedup one. The chunked walk now skips-and-logs identically, reporting the number of skipped paths in the log and progress message.
- **Automatic database backups are now pruned instead of accumulating forever** (closes #184). After every successful run Vault copies its own database to the destination's `_vault/` directory, but old copies were never removed — one server had accumulated 136 copies (477 MB) in six weeks, and on quota-limited remotes this growth eventually crowds out real backups. Vault now keeps the newest 14 timestamped copies per destination (plus the `vault.db.latest` recovery pointer, which is always kept) and deletes older ones after each write.
- **Deleting the last dedup job on a destination no longer destroys the daemon's database backups stored there** (closes #183). The dedup chunk repository and the automatic `vault.db` recovery copies share the `_vault` directory on every destination; the cleanup that removes an orphaned dedup repo deleted the entire directory — including every database backup. Cleanup now removes only the dedup-owned paths (`repo.json`, `packs/`, `index/`) and leaves the database copies untouched.
- **Replication syncs no longer leak storage connections** (closes #173). Each replication sync opened the local storage destination but never closed it; for SFTP destinations that leaked up to four SSH connections per scheduled sync (and orphaned NFS mounts), accumulating until daemon restart. The adapter is now released when the sync completes.
- **Daemon shutdown now waits for in-flight restores** (closes #172). A planned restart (plugin update, `rc.vault restart`) drained active backups but was blind to restores: shutdown could kill a restore mid-write, leaving half-restored appdata or VM disks. Restores now participate in the same drain protocol as backups — shutdown waits for them, and a draining daemon refuses to start new ones.
- **Cancelling a VM backup or restore now takes effect immediately** (closes #171). VM operations ignored cancellation entirely: pressing Cancel (or the stall watchdog firing) had no effect until the libvirt backup job finished or its 2-hour timeout expired, and the hypervisor kept writing disk data into a staging directory the runner had already torn down. Cancellation is now honoured within seconds across every VM stage — the in-flight libvirt backup job is aborted (`DomainAbortJob`), multi-GB disk/NVRAM copies stop at the next 1 MiB chunk, and all shutdown/startup/readiness waits exit early — while VM teardown (restarting a cold-backed-up VM, tearing down the paused backup session) still always completes so a cancelled run never leaves a VM in the wrong power state.
- **Backups of imported jobs no longer crash when a container's stored ID is missing** (closes #170). Jobs imported from existing backups (native manifests without per-item IDs, or appdata.backup imports) store containers with an empty ID; when such a job ran while a container with that name existed, the ID-change log line sliced the empty ID and panicked, failing the run with an opaque "Internal error (panic)" on every attempt. ID truncation is now bounds-checked everywhere.
- **SMB capacity probes no longer leak a connection on every check** (closes #169). The scheduled capacity probe (and the Storage page's refresh button) opened an SMB session for the space query but never logged it off, leaking one authenticated session plus its TCP connection per probe until the NAS started refusing new SMB connections. The probe now releases the session like every other SMB operation.
- **Empty directories left behind by deleted backups are now actually cleaned up** (closes #168). Deleting restore points (retention, manual deletion) removed the files but the sweep that prunes the now-empty parent directories never ran: the storage middleware chain didn't pass the directory-removal capability through to the underlying adapter, so the sweep silently did nothing on every destination. Local, SFTP, SMB, and NFS destinations now prune emptied parent directories again; object stores (S3) and WebDAV, which have no safe "remove if empty" primitive, are skipped cleanly.
- **ZFS incremental and differential chains now record and use the correct parent snapshot** (closes #180). The snapshot created by each ZFS backup was never persisted into the restore point, so chained runs silently fell back to sending against whatever vault snapshot happened to be newest on the dataset — a "differential" was really an incremental against the previous run, and snapshot cleanup then destroyed the last full's snapshot (the chain anchor). The result: differential restore chains could not be received (`zfs recv: most recent snapshot does not match incremental source`). Each backup now records its snapshot per item in the restore point (`zfs_snapshots`), the next chain run resolves its `-i` parent from there (falling back to a full backup with a clear warning when the parent is missing or was deleted — including for restore points created before this fix), and cleanup preserves the chain-anchor snapshot alongside the newest one.
- **Automatic retries now actually fire for pre-flight failures and stall-cancelled runs** (closes #167). When a run was skipped because its destination failed the pre-flight check (DNS blip, unmounted share), or cancelled by the no-progress stall watchdog, Vault scheduled a retry — but the retry watcher only ever dispatched retries for runs whose status was `failed`, so those scheduled retries sat in the database forever and never ran. The watcher now claims due retries for `failed`, `skipped`, and `cancelled` runs alike, matching the outcomes retries are scheduled for.
- **Truncated archives can no longer be reported as successful backups** (closes #166). When finalising a container-volume, folder, or plugin archive, errors from the tar footer flush, the gzip/zstd trailer, and the final write to disk were silently discarded — so a disk that filled up during the last flush, or a file that shrank while being archived, produced a corrupt/truncated archive that the run reported (and even checksum-verified) as success, discovered only at restore time. All three finalisation steps now fail the backup with a clear error (`closing tar writer: …`, `finalising compression: …`, `closing archive file: …`).
- **Deduplication garbage collection can no longer run while a backup is writing to the same destination** (closes #165). Starting a GC (Storage → Run GC, or the automatic reclaim after deleting a dedup job) while a dedup backup was in flight could delete the chunk packs that backup had just written — its restore point only becomes visible to GC at the very end of the run — silently corrupting the new backup so it would fail at restore time. GC now waits for the active backup/restore to finish before it scans (and backups queue behind a running GC), refuses to start during daemon shutdown, and shutdown in turn waits for an in-progress GC to complete.
- **S3 backup verification no longer aborts (and deletes the upload) on large archives** (closes #164). S3 `Read`/`ReadRange` bound the streamed response body to the same 5-minute deadline used for quick metadata calls, so verifying any archive that takes longer than 5 minutes to stream back failed with `context deadline exceeded` — and the runner then removed the files it had just successfully uploaded, leaving the run failed and the destination empty. Streamed S3 reads now carry no wall-clock deadline (matching SFTP/WebDAV/local): closing the reader releases the connection, waiting for a dead endpoint's response headers is still bounded (5 minutes), and genuinely hung transfers are cancelled by the stall watchdog. Deep verify and restores from S3 destinations benefit the same way.

## [2026.07.00] - 2026-07-02

### Fixed

- **VM backups now honour the job's compression setting.** Container, folder, and plugin backups compress their archives in the engine, but VM backups stage raw artifacts (disk images, `domain.xml`, `vm_meta.json`, NVRAM) and the upload layer never applied a codec — so jobs configured for gzip or Zstandard still landed full-size, uncompressed `qcow2`/`img` files on the destination. VM uploads are now compressed in transit with the configured codec (stored as `.gz`/`.zst`, compressed before encryption) and transparently decompressed on restore; existing uncompressed backups keep restoring unchanged. A 10 GiB Fedora test disk dropped from 2.7 GB to 1.1 GB on the destination with zstd.
- **VM backups no longer fail with `backup job ended unexpectedly: DomainJobNone`** (closes #160). When a libvirt push-backup job finished, Vault asked libvirt for the completed-job record to decide success or failure. On hosts where that record is unavailable at poll time (libvirt reports "no completed job" as a normal reply, not an error — e.g. another tool consumed the record or libvirtd reloaded), Vault misread the reply as a failure even though every byte had been copied, so backups that ran to completion (44+ minutes of real work) were reported as failed on every attempt. Vault now treats a missing completion record as "no verdict" and confirms success from the backup artifacts on disk (logging that it did so); a job that vanishes without producing its files still fails, now with an error naming the missing files instead of looping for 2 hours.
- **`restoring domain state: Failed to terminate process … with SIGKILL: Device or resource busy` after VM backups** (#160). After pushing tens of GB through the page cache (typical on fuse-backed Unraid shares), the temporary paused backup session's qemu process can sit in uninterruptible IO, so libvirt's single kill attempt timed out, failed the whole backup, and could leave a cold-backed-up VM powered off. Teardown of the backup session (and the forced stop before a cold backup) now retries the destroy for up to 5 minutes until the flush completes, then restarts the VM as before.
- **qcow2 disks in `.img` files are now backed up and restored in their real format** (#160). Disk format was inferred from the file extension, but Unraid names most vdisks `vdisk1.img` regardless of format. A qcow2-formatted `.img` (like the Windows VM in the report) was written out as a raw image and restored as raw while the domain XML still said qcow2 — an unbootable restore. The format now comes from the domain XML's `<driver type=…>` (extension only as fallback), which also makes qcow2-in-`.img` VMs eligible for incremental backups for the first time.
- **VM restore-chain assembly no longer assumes every chain layer ends in `.qcow2`.** Restoring an incremental chain resolves each step's disk files from the `vm_meta.json` the backup recorded (with the old filename scan as fallback for pre-existing backups), so chains whose full backup is a `.img` file flatten correctly; a chain whose disks cannot be resolved now fails loudly instead of silently restoring only the newest increment. `qemu-img` calls also honour restore cancellation, and layer/metadata filenames are validated before use.
- **A VM whose disks are all skipped (e.g. block-passthrough only) now fails its backup with a clear error** instead of "succeeding" with no disk data. The per-VM disk inventory (eligible disks, formats, and skipped disks with the reason) plus the exact backup job submitted to libvirt are now logged, so future reports like #160 carry the root cause in `vault.log`.
- **Restore wizard no longer shows `no tar index sidecar found for this item` for VMs.** The per-file restore picker only applies to tar-based backups (containers, folders, plugins); for VM and ZFS items the wizard showed a red sidecar-lookup error that looked like a broken restore point. Those items now show a plain "Restored in full" row, and the disabled **Start Restore** button explains that the pre-flight checks must be run first.

## [2026.06.07] - 2026-06-25

### Changed

- **Modals no longer close when you click the background** (closes #148). Clicking the dimmed backdrop behind a dialog – or releasing a text selection whose drag ended outside the dialog – used to dismiss the modal and discard any in-progress work, such as a half-filled backup job. Backdrop click-to-close has been removed from every modal: the job and storage wizards, confirmation dialogs, the command palette, and the path and script browsers. Modals are still dismissed the deliberate ways – the close (×) button, Cancel, or the Escape key – all unchanged.

### Fixed

- **Creating a backup job now validates its input instead of saving a broken job or returning a 500.** `POST`/`PUT /api/v1/jobs` previously performed no validation: a request with no name (or a whitespace-only name) was saved as an unusable job, and a request with an invalid cron expression was saved as a job that silently never ran. The job create/update endpoints now reject an empty name with `400 name is required` and an unparsable schedule with `400 invalid schedule: …` (an empty schedule is still allowed — that means a manual-only job), matching the validation the storage and replication endpoints already had. Last-day-of-month schedules (`0 2 L * *`) and `@`-descriptors remain valid.
- **Duplicate names now return a clear 409 instead of a generic 500.** Creating or renaming a job, storage destination, or replication source to a name that already exists tripped the underlying `UNIQUE` constraint and surfaced as `500 internal server error`. These now return `409 Conflict` with an actionable message (e.g. _"a job with this name already exists"_) so the UI and API clients can show the real reason.
- **Container appdata on Unassigned Devices is no longer auto-excluded from backups** (closes #152). Bind mounts under `/mnt/disks/` (the Unassigned Devices mount point) were wrongly flagged as a "direct disk volume" and shown greyed-out in the job wizard's **Container Mounts & Exclusions** step, so appdata kept on an Unassigned Devices SSD (e.g. a container's `/config` at `/mnt/disks/<device>/appdata/<app>`) could not be included in a backup. The direct-disk rule now matches only real array disks (`/mnt/disk1`, `/mnt/disk2`, …) and no longer catches the plural `/mnt/disks/`, so those mounts are backed up by default and are tickable like any other path.

## [2026.06.06] - 2026-06-22

### Added

- **Richer Discord notifications: bot identity and role pings** (#146). The **Settings → Notifications → Discord** card now lets you override the **Bot Username** and **Bot Avatar URL** the webhook posts under, and ping a **Mention Role ID** on alerts with a **Mention On** control (Never / Failures only / All backups). Pings are deliberately safe — only the role you specify is mentioned (`allowed_mentions` is locked down, so a stray mention can never `@everyone`), the role ID is validated as a numeric snowflake before use, and the **Test** button now reflects your configured bot name/avatar. By default nothing pings (Mention On = Never), so existing setups are unchanged.

### Fixed

- **You can now choose to be notified on successful backups, not just failures** (closes #146). The per-job notification preference (`notify_on`) was already honoured by the backend and submitted by the job form, but the job wizard never rendered a control to change it, so it was stuck at its `failure`-only default and there was no way to opt into success notifications. The job wizard's **Step 5 → Advanced** now has a dedicated **Notifications** section (split out from Scripts for clarity) with a **Notify On** dropdown — **All backups (success & failure)** / **Failures only** / **Never** — and a tooltip noting that the global notifications toggle in Settings must be on and that Discord is configured separately. No backend, database, or API changes were required.

## [2026.06.05] - 2026-06-20

### Added

- **Configurable history retention.** A new **Settings → General → History Retention** control (30 days / 90 days / 6 months / 1 year / 2 years / Keep everything; default 1 year) caps how long backup/restore run history is kept, so the database doesn't grow without bound. The purge (which runs during the daemon's maintenance pass) is deliberately safe: it only removes run-history rows that are both older than the chosen period **and** no longer back a restore point – recoverable backups are governed solely by each job's own backup retention and are never deleted by this setting.
- **Selectable backup-size trend window.** The History page's "Backup Size Trend" chart now has a period selector – **7d / 30d / 90d / 6m / 1y** (default 30d) – instead of a fixed last-30-runs view. Long ranges are aggregated server-side into readable buckets (per run for 7d, per day for 30d/90d, per week for 6m/1y) and the bars are stacked by backup type (containers / VMs / folders / flash). Backed by a new `GET /api/v1/history/trend` endpoint.
- **Capacity trend and runway forecast on storage destinations.** Each destination's capacity block now shows a sparkline of usage over the last 90 days (the samples Vault already collects) plus a plain-language runway estimate – "~N days until full at current growth", "Usage stable or shrinking", or "Not enough history yet" – computed from a linear fit of recent samples. The trend and runway colour-shift to amber/red as the destination nears full. Quota-less providers (S3, generic WebDAV) show the usage trend without a percentage or runway.
- **Dedup savings bar.** Deduplicated destinations now show a visual savings bar beside the existing ratio text: how much of the logical data is physically stored versus how much deduplication avoided writing (e.g. "Stored 29% · Saved 70.6 GB").
- **Search, filter, and sort your backup jobs.** The Jobs page now has a toolbar above the list: a **search** box (matches name and description), a **status** filter (All / Enabled / Disabled), a **storage** filter (any destination), and a **sort** control (Name A–Z, Next run, Recently created). A "Showing X of Y" counter and a **Clear filters** link appear when a filter is active, and the existing **Select all** plus bulk actions (enable / disable / run / delete) now operate on the _filtered_ set – so you can, for example, filter to Disabled and bulk-enable just those. All client-side over the already-loaded list, so there is no extra loading. Useful once you have more than a handful of jobs.
- **Pre-flight checks before a restore.** The restore wizard's final step now runs a quick go/no-go check before you commit: **Storage reachable** (the destination answers), **Backup present on storage** (the restore point's data is actually there), **Decryptable** (the supplied passphrase matches, for age-encrypted jobs – skipped otherwise), and **Free space** (the staging/destination volume has room for the restore point). **Start Restore** stays disabled until the checks pass, so a doomed restore fails in a second instead of part-way through. Changing the passphrase or destination re-arms the checks ("Inputs changed since the last check"); when checks fail you can still **Restore anyway** behind a confirm. Backed by a new `POST /api/v1/jobs/{id}/restore-points/{rpid}/preflight` endpoint.
- **Restore points now show as a visual timeline.** The restore wizard's version-selection step replaces the flat card list with a day-grouped timeline plus a density overview (one bar per day, sized by backup volume) so you can see at a glance what you can recover and from when. Each point shows its time, type (full/incremental/differential dot), size, and the trust signals Vault already computes – **Recommended** (newest), **Verified**, and chain health (broken / chain depth / retained). Calm, keyboard-navigable, and responsive.
- **The 3-2-1 Backup Rule panel is now goal-aware.** Instead of always scoring against the full rule (which left a deliberately simple setup permanently red), you pick a backup goal that matches your intent and the panel scores against that: **Local only** (at least one copy), **Local + offsite** (a local copy plus a remote/replicated copy), or **Full 3-2-1** (3 copies, 2 media types, 1 offsite). It turns green when the chosen goal is met and only suggests the steps relevant to that goal. The goal is a segmented control in the panel; when unset it auto-selects the highest tier your current setup already meets. Persisted in a `backup_rule_goal` UI setting (frontend-only). Works alongside the show/hide toggle.
- **The 3-2-1 Backup Rule panel can now be hidden.** The Dashboard's 3-2-1 compliance panel is useful guidance, but for an intentionally simple setup (e.g. a single server backing up locally) it stays permanently red, which reads as a failure rather than a choice. A new **×** on the panel hides it instantly, and a **Settings → Dashboard → Show 3-2-1 Backup Rule** toggle re-enables it. It remains shown by default, so the best-practice nudge is still there for anyone who wants it. No scoring changes.
- **Per-mount include/exclude toggles for container backups** (closes #143). The job wizard's container section (now **Container Mounts & Exclusions**) lists every bind mount of each selected container with a checkbox – uncheck a mount to keep its data out of the backup (e.g. a media or downloads share mapped into Sonarr/Radarr/Plex). This replaces the slow, error-prone workflow of hand-typing each container path per container. Mounts Vault already auto-skips (device/virtual paths and known shared-data shares) are shown disabled with the reason, so it's clear what will and won't be backed up. A new `GET /api/v1/containers/{name}/mounts` endpoint exposes the mount list with each mount's auto-skip verdict. The free-text exclusion box is preserved below as **Additional path exclusions** for subpaths and glob patterns (e.g. `/config/Cache`, `*.log`); a checkbox and an exact whole-mount text exclusion stay in sync, so pre-existing exclusions (such as a `/rootfs` entry on Telegraf/Glances) correctly show their mount as unchecked.

### Fixed

- **The History "Purge" button now warns it deletes restore points.** Purging run history runs a cascade that also removes the restore points those runs produced – the recoverable backups Vault tracks – leaving their files orphaned on storage. The confirmation dialog previously said only "delete all job run history records"; it now spells out that restore points go too and that this cannot be undone, so it isn't triggered by surprise.
- **Adding an item to a job no longer claims it's already backed up.** When you added a container or VM to an existing job, it immediately showed as **protected** on the Dashboard and appeared in the Restore tab with the job's whole backup history (e.g. "backed up today, 5 restore points") — even though that backup had not run yet, and trying to restore it returned **"internal server error"**. The cause: protection and restore-point listing keyed off _job membership_ rather than what each backup actually captured. Vault already records exactly which items each restore point contains, so it now uses that: such an item shows as **"Pending first backup"** (a distinct amber state, not green-protected) until a backup really captures it; the Restore tab only lists restore points that contain the selected item; and browsing or restoring an item a restore point never captured now returns a clear message instead of a 500. The health ring's protection figure is likewise based on real per-item membership. _(Items backed up before this metadata existed are treated as before.)_
- **The Dashboard's Backup Health card no longer contradicts itself.** The ring (operational health: backup success plus protection of the items you've put in jobs) could read a green **100%** while its own subtitle said "Attention needed – 12 items unprotected" – because the subtitle was secretly using a different metric (whole-server coverage, e.g. 8/20). The subtitle now describes the same thing the ring does ("All backups healthy"), and overall coverage is shown as a calm, non-alarming hint ("12 items not in any backup job · see Protection Status") that points at the Protection Status panel, which owns that metric. A deliberately partial setup (backing up only some containers) now stays green instead of looking broken.
- **Consistent save buttons across Settings.** Every primary action button now behaves the same while working: it shows an inline spinner next to its label (previously only some did – the encryption, API-key, retry-policy, compaction, and staging/snapshot "Apply" buttons just swapped text or did nothing visible). Also fixed seven Settings buttons that used an undefined `hover` colour and so had **no hover effect at all**, normalised two others that used a different hover shade, and standardised the busy-label punctuation (`Saving…` rather than a mix of `Saving...` and `Saving…`) and font weight.
- **Storage destination cards no longer look uneven.** Within a row, the cards already stretched to equal height, but each card's footer (timestamp · job count · health · Test) floated at a different vertical position, leaving a large empty gap under shorter cards. The footer is now pinned to the bottom of every card so the rows line up.

- **Disabling anomaly detection now hides it on backup jobs too.** With anomaly detection turned off in Settings, the **Learning baseline** badge (and the per-job anomaly badge and the job editor's anomaly-sensitivity override) still appeared on backup jobs. The Jobs page now gates all anomaly UI on the global toggle, matching the Dashboard and the Anomalies page, so disabling anomaly detection hides it everywhere until it is re-enabled.
- **Selecting a specific NIC bind address now works end-to-end** (closes #139). Cycling the **Bind Address** to a detected interface IP (e.g. `192.168.20.21`) left the daemon showing **STOPPED** and made the Vault UI unreachable – only `127.0.0.1` and `0.0.0.0` worked. Two causes are fixed: (1) `rc.vault` validated the address with a bare `ip` command, but the service/php-fpm execution context often lacks `/usr/sbin` in `PATH` (the same gap fixed for `apply.sh` in #136), so a valid NIC address silently failed validation and was reset to `127.0.0.1` _in memory_ – the daemon bound loopback while the UI health probe targeted the NIC IP. `rc.vault` now resolves the `ip` binary to an absolute path and, when `ip` is unavailable, accepts the configured address rather than rejecting it. (2) Once bound to a NIC IP, every request from the co-located Unraid PHP proxy arrived from a non-loopback source and was rejected with **401 "valid API key required"** when an API key was configured – breaking the _entire_ proxied UI, not just the status check. The daemon now exempts requests originating from the host itself (loopback **or** any local interface address), so the local proxy is trusted on any bind address while genuine remote LAN clients still require a key.
- **The service status no longer shows a false STOPPED right after applying a configuration change.** A restart that takes the hybrid database-restore path can need ~15–20 s to bind and serve health; the post-Apply status poll gave up too early and reported STOPPED until a manual refresh. The poll window now extends to ~36 s.
- **Deleting jobs no longer makes the daemon appear to hang** (issue #143). After any configuration change (job/storage/settings CRUD) the daemon flushes its database to the USB flash drive; this flush ran **synchronously on the request**, so deleting several jobs in a row serialised multiple multi-second flash writes and the UI froze (often mistaken for a crash). The flush is now scheduled off the request path and **coalesced**, so a burst of deletes triggers a single flush and each delete returns immediately. Shutdown durability is unchanged – a synchronous flush still runs before the daemon exits.
- **"Delete all files" cleanup no longer fails when a backup directory is already gone** (issue #143). Removing a job or restore point with _delete files_ could report **"failed – files may remain on storage"** purely because a directory it tried to list no longer existed (e.g. a WebDAV `PROPFIND` returning `404` for an already-removed or never-written path). A missing directory now counts as already-clean instead of aborting the whole cleanup.
- **Deleting a job on a deduplicated destination now reclaims its storage** (issue #143). Dedup backups share a single content-addressed repository (`_vault/`) across every job on a destination, so deleting one job previously left its now-orphaned chunks behind. Deleting a job now runs garbage collection to free the chunks no longer referenced by any surviving job, and when the **last** dedup job on a destination is removed the entire `_vault` repository (and its index) is deleted outright.
- **WebDAV backups no longer fail with a transient `423 Locked` while creating folders.** Some WebDAV servers (notably Koofr) briefly lock a directory during `MKCOL` – especially right after a failed upload's partial files are cleaned up – so the very next `MkdirAll` returned `423` and failed the whole item (e.g. _"writing config.json to storage: … MkdirAll …/telegraf/: 423"_). Directory creation now retries transient WebDAV errors (`423`, `409`, `429`, `5xx`, network blips) with the same backoff already used for chunk uploads, so a momentary lock clears and the backup proceeds. Verified end-to-end against a live Koofr destination.

### Changed

- **Dashboard VMs card reads "Virtual Machines" instead of "libvirt".** The stat card's subtitle showed the implementation name (`libvirt`); it now uses the friendlier "Virtual Machines" label.
- **Item picker empty states follow Unraid's service naming.** When adding items to a job and the relevant service is off, the message now reads "Docker service not available" / "Virtual Machine service not available" instead of "Docker is not available" / "libvirt is not available".
- **Configuration form on the Unraid plugin settings page is now left-aligned.** The **Daemon Port** and **Bind Address** labels and fields previously sat in an indented, right-aligned column (Unraid's default `dl/dt` styling); they now sit flush left in a clean label/field layout, matching the Unraid Management Agent plugin's Configuration page.
- **Em dashes replaced with en dashes throughout the UI.** Swept the Svelte/JS web UI, the Unraid plugin settings page (including the Bind Address options), and these release notes (which render in the in-app View Changelog modal) to use en dashes instead of em dashes for a cleaner, more consistent look.
- **Bind Address dropdown is grouped and no longer stretches across the screen.** The list is organised into labelled sections – _Local only (recommended)_, _All interfaces_, and _Network interfaces_ (detected NICs shown as `<ip> – <iface>`) – and the control is given a fixed, compact width so the Configuration form stays left-aligned instead of spanning the full width of wide displays.
- **Applying a configuration change reports its result inline instead of as raw script output near the footer.** Previously the Apply form streamed `rc.vault`'s raw output (e.g. "Stopping Vault daemon…") into Unraid's progress area just above the **Array Started** system-status bar. That output is now suppressed and replaced with a co-located "Applying configuration – restarting daemon…" note next to the form that resolves to the live RUNNING/STOPPED status – keeping the daemon's feedback in-component rather than in Unraid's reserved system-status area, consistent with Unraid plugin conventions and the official Unraid API plugin.
- **The Dashboard's Protection Status panel grows to fit its contents** (issue #143). Each category column (Containers, VMs, Folders, Flash Drive) was capped at a fixed height with an inner scrollbar, so servers with many containers had to scroll within a small box. The columns now size to the number of items, showing every container/VM at a glance without a nested scrollbar.

### Removed

- **The API Endpoints list was removed from Settings → Reference.** It enumerated every REST route in the UI, which added clutter without real value for operators (no comparable backup tool surfaces its API inside the app), so it has been dropped. The Reference tab keeps its Compression Guide and Backup Type Guide. Only the in-UI list was removed – the REST endpoints themselves are unaffected, and integrations that call `/api/v1/...` continue to work.

## [2026.06.04] - 2026-06-13

### Added

- **Network auto-discovery via mDNS/zeroconf** (closes #137). The daemon now advertises itself on the local network as a `_vault._tcp` service (with `version` and `tls` TXT records), so integrations such as the Home Assistant Vault integration can auto-discover a running Vault instance instead of requiring a manually entered address. Discovery is automatically **disabled** when the daemon is bound to a loopback address (the local-only default) – a `127.0.0.1`/`::1` bind is never advertised – and enabled for all-interfaces (`:24085`, `0.0.0.0`, `::`) or specific-NIC binds. Pure-Go and Avahi-compatible; advertisement failures are non-fatal and never block backups.
- **Hide unused services for a cleaner interface.** Anomaly Detection and Replication can now be toggled off from **Settings**. Disabling a feature removes it from the sidebar (and the Dashboard, for Anomaly Detection) and halts its backend work – anomaly evaluation already stops, and scheduled replication syncs are now paused while disabled. Replication defaults to visible only when replication sources are already configured, so existing setups are unaffected and fresh installs stay uncluttered. Replication is always shown on replica instances (it is core there). Re-enabling a feature restores its page and resumes its backend work immediately, without a daemon restart.

### Fixed

- **Backup jobs now fail when all of their targets are missing** (closes #138). When every container/VM/folder/plugin/dataset configured for a job no longer exists on the server, the run previously reported **completed** with zero items backed up, masking the fact that nothing was protected. The runner now records a **failed** run with a clear error listing the missing targets (and counts them as failed items) so the failure is visible in the UI, notifications, and the reliability detector. Because a missing target is a configuration problem rather than a transient/destination fault, this does not schedule a retry or trip the destination circuit breaker. A safety net also fails any run that ends with zero items processed despite items being configured.
- **The Dashboard's Recent Activity now shows the real failure reason instead of "expand for details"** (follow-up to #138). The failure-reason helper only surfaced plain-text log lines containing the words "error"/"fail", so messages that contained neither (such as the all-targets-missing message) fell through to a generic "Backup failed – expand for details" – misleading on the Dashboard, which has no expand affordance. It now surfaces the first meaningful line of any plain-text log, and the remaining placeholder reads "see Logs for details". The Recent Activity failure line also now **wraps** (up to three lines, full text on hover) instead of truncating to a single cut-off line.
- **Settings "Save" buttons no longer balloon and show "Loading…" while saving.** The Anomaly Detection, Storage Logging, and Discord Save buttons (and the Discord Test / diagnostics buttons) embedded the full-section loading spinner – which carries large padding and a "Loading…" label – directly inside the button. They now use a small inline spinner that keeps the button's shape and colour.

## [2026.06.03] - 2026-06-12

### Changed

- **S3 key sanitization is no longer silent.** When a job or item name contains characters that must be replaced for S3-compatible gateway signing (e.g. spaces – `QA S3 verify` is stored as `QA_S3_verify`), the daemon now logs the original → stored mapping once per session, so operators browsing the bucket can connect what they see to their job names instead of discovering the rename by accident.

### Fixed

- **The Unraid Plugins page now shows "Vault" with a proper description.** The plugin list previously showed a lowercase **vault** with no description because Unraid's plugin manager renders `/usr/local/emhttp/plugins/<name>/README.md` for the title and description, falling back to the raw lowercase plugin name when that file is missing. The plugin package (and the dev deploy) now ship that README – title-cased name plus a one-paragraph summary – matching how other plugins present themselves.
- **The Unraid Plugins page now shows "Vault" with a proper description.** The plugin list previously showed a lowercase **vault** with no description because Unraid's plugin manager renders `/usr/local/emhttp/plugins/<name>/README.md` for the title and description, falling back to the raw lowercase plugin name when that file is missing. The plugin package (and the dev deploy) now ship that README – title-cased name plus a one-paragraph summary – matching how other plugins present themselves.
- **Importing backups now skips manifests written by a newer Vault version with a clear log message.** Previously a manifest with an unrecognised (future) schema version was silently parsed as a legacy manifest, which could import a backup with wrong or missing settings. Scan and import now check the manifest version and skip too-new manifests with an explicit "upgrade Vault to import this backup" log line; current and legacy manifests import unchanged.
- **Bind Address dropdown now lists detected NIC addresses** (closes #136). The per-interface addresses (e.g. `192.168.20.21 (br0)`) never appeared because PHP silently casts the numeric-string `'4'`/`'6'` array keys in `vault_get_local_ips()` to integers, so the strict family comparison never matched and every detected address was filtered out. The keys are now non-numeric (`v4`/`v6`), and the `ip` binary is resolved to an absolute path (`/usr/sbin/ip`, fallback `/sbin/ip`) since the webgui's php-fpm PATH may not include `/usr/sbin`. The loopback and wildcard options (`127.0.0.1`, `::1`, `0.0.0.0`, `::`) are always present regardless of detection. The Apply-time bind-address validation in `apply.sh` uses the same absolute-path resolution and no longer resets a valid NIC address to `127.0.0.1` when the `ip` binary cannot be found.
- **Activity Log and Replication pages no longer flicker every few seconds** (closes #135). When the UI runs through the Unraid plugin proxy it refreshes by polling (5 s on Logs, 10 s on Replication), and every poll swapped the whole list out for a loading spinner and back – a visible jitter/flicker on each tick. Background refreshes now update the list in place; the spinner only shows on first load and explicit user actions (filter change, Refresh). A failed background poll also keeps the current list on screen instead of flashing an error panel, and on Replication it no longer raises an error toast every tick.
- **Restoring a chunked WebDAV backup no longer fails with a 404.** Restore downloads stream every object through ranged reads (the resumable reader introduced with resilient restores), but the WebDAV adapter's ranged read did not understand chunked (sidecar-manifest) uploads – and a chunked upload has no object at its logical path at all – so restoring any WebDAV backup larger than the chunk size (default 50 MiB) failed immediately. Ranged reads now detect the chunk manifest and serve the requested byte window from only the chunks that overlap it, restoring both the sequential resumable path and the parallel ranged-download path for chunked objects. Plain objects (including dedup pack files) are unaffected and keep their single-request fast path.
- **Background backup-file cleanup now reports its outcome** (follow-up to #111). Deleting a job or restore point with its backup files returns immediately while the remote sweep runs in the background, but a failed sweep was only visible in the daemon log. A failure is now recorded in the Activity Log (with the storage error) so it is durably visible, and the Jobs page shows a toast when the sweep for a deleted job completes or fails.
- **Timed-out finalization steps are now cancelled instead of leaking** (follow-up to #112). When a post-backup finalization step (manifest write, database backup, retention sweep) exceeded its hard timeout, the runner moved on – correct – but the hung step's goroutine kept running forever, holding its storage connection open. Each step now receives a context that is cancelled on timeout: in-flight storage I/O is aborted by closing the step's adapter, and the retention and database-backup sweeps stop between items, so the abandoned goroutine exits promptly. A cancelled retention sweep simply resumes on the job's next run.
- **Dedup backups can no longer be falsely cancelled by the stall watchdog during long pack uploads** (follow-up to #110). The dedup (chunked) backup path only refreshed the no-progress watchdog once per completed file, so a single very large file uploading packs to a slow remote for over two hours could be cancelled mid-transfer. Pack uploads now heartbeat the watchdog on every chunk of bytes written, matching the classic upload path.

## [2026.06.02] - 2026-06-10

### Fixed

- **Copy API key works on plain-HTTP (non-secure) origins** (closes #129). The **Copy** button under Settings → API Key failed with `Failed to copy – clipboard access denied` in Safari and Chrome because the modern Clipboard API is only available in secure (HTTPS) contexts, and the Unraid web GUI is typically served over plain HTTP on the LAN. Copying now falls back to the legacy `execCommand('copy')` path via a shared clipboard helper when the Clipboard API is unavailable or denied. The Activity Log's per-entry copy button uses the same fallback.
- **Changing the Bind Address (or Port) now reliably restarts the daemon when Apply is clicked** (closes #130). The plugin's `apply.sh` only restarted the daemon when the PID file was present and valid – a stale or missing PID file silently skipped the restart, leaving the daemon on the old address until a manual restart. It now falls back to `pidof` (the same process lookup `rc.vault` uses), prints an explicit `Restarting Vault daemon...` line in the Apply progress window, and probes the post-restart health check against the actual configured bind address (previously hardcoded to `127.0.0.1`, which could not confirm a daemon bound to a specific NIC address).

### Changed

- **VM and folder backup progress now shows human-readable sizes** (closes #133). Live progress messages such as `backup in progress: 6453198848/34359738368 bytes` now read `backup in progress: 6 GB/32 GB`. The same formatting applies to VM disk restore, NVRAM copy, stale block-job wait, and the folder-backup manifest completion message.
- **Anomaly detail values are now human-friendly** (closes #134). Anomaly details stored and shown in notifications, the API, and the UI previously carried full float precision (e.g. `Z Score: -16.76413455138884`, `Growth Factor: 0.5766537578335602`). New anomalies are rounded at the source (z-score and growth factor to 2 decimals, capacity ETA to 1 decimal, slope/intercept to whole bytes, free-space percentage to 1 decimal), and the Activity Log formats these fields at display time so entries recorded before this change read cleanly too.

## [2026.06.01] - 2026-06-08

### Changed

- **Renamed "Grandfather-Father-Son (GFS)" retention to "Long-Term Retention (LTR)"** across the UI, code, and docs (closes #125). LTR is the industry-standard enterprise term for keeping weekly/monthly/yearly recovery points (as used by Veeam, Druva, and others) and reads far more clearly than the legacy tape-rotation name. This is a **terminology-only** change – no database, API, or behaviour changes: the `keep_latest`/`keep_daily`/`keep_weekly`/`keep_monthly`/`keep_yearly` job fields and the `GET /jobs/{id}/retention-preview` endpoint are unchanged.
- **Collapsible API reference** (closes #126). The API Endpoints list under Settings → Reference is now split into collapsible sections (Health & Realtime, Jobs, Storage Destinations, Deduplication, and so on), each showing its endpoint count and collapsed by default, so the reference stays tidy and easy to scan as the API grows.
- **Clearer help tooltips.** Rewrote the tooltips for the more technical storage and settings options – WebDAV/S3 transfer tuning (chunk/part size, stall and request timeouts, path-style, bandwidth), dedup compaction threshold, database mode, and scheduled/backup verification – into plain language with a consistent _what it does → why it matters → recommended default_ structure. No behaviour change.

### Fixed

- **Changing the daemon port no longer silently breaks the web UI** (closes #124). Previously an invalid or already-in-use port was written straight to `vault.cfg` (the port field's `1024-65535` limit was enforced only client-side), the daemon failed to bind and exited, and the UI became unreachable with no feedback. The plugin's `apply.sh` now validates the port server-side – rejecting non-numeric or out-of-range values and resetting to the default `24085` – then verifies the daemon actually comes back up after the restart and prints a clear diagnostic (with the tail of the log) if it does not. `rc.vault` now re-checks the process for a few seconds after launch and dumps the last log lines on a failed start instead of leaving a stale PID file. The Settings page polls the daemon's real status after an Apply and shows a visible error (instead of only a transient progress frame) when the chosen port can't be bound.

## [2026.06.00] - 2026-06-07

### Fixed

- **Large backups no longer fail with `dedup: pack size … exceeds safety bound` when an item contains a very large number of files (#118).** Backup manifests (the per-item index of every file and its chunks) were stored as a single JSON blob; for a directory with an enormous number of files – e.g. a Plex appdata `/tmp` tree – that blob grew past the packer's 96 MiB safety bound and the whole backup aborted. Oversized manifests are now split through the same content-defined chunker used for file data and stored as ordered segments behind a small envelope, so no single chunk approaches the bound regardless of file count. The split is transparent on restore, existing (v1) single-blob manifests still read unchanged, and because near-identical manifests now mostly re-reference existing segments, manifest storage also deduplicates across snapshots. A clearer early error also replaces the opaque packer failure if any oversized chunk is ever stored.
- **Anomaly values are now human-readable, and the "Raw details" toggle works.** Anomaly summaries and the detail panel showed raw numbers – e.g. `backup size anomaly: 4258918530 bytes`, `Observed: 4259532913`, `Deviation: -27.28833643436231` – and clicking **Raw details** did nothing. Values now adapt to friendly units (bytes → KB/MB/GB, seconds → `5m 26s`, ETA → days) on both the summary line and the Observed/Expected fields, and the deviation z-score is rounded to two decimals. The **Raw details** disclosure was a `<details>` nested inside the row's `<button>` (invalid HTML), so clicks collapsed the row instead of expanding; it is now a sibling of the row and expands correctly to show the raw detector JSON. Both the summary headline and the detail panel are reformatted at display time, so anomalies stored before this change are humanized too; newly-detected anomalies are additionally stored with friendly summaries (so Unraid/Discord notifications read the same way).
- **The VM backup mode (Live Snapshot vs Cold Backup) now saves and reloads correctly when editing a job (#116).** The job editor never persisted the choice: `saveJob()` stripped `vm_mode` from the API payload before sending it, and `openEdit()` hardcoded the selector back to **Live Snapshot** every time a job was opened – so picking **Cold Backup** appeared to work but silently reverted, and every VM backup ran in snapshot mode regardless of the setting. The editor now sends `vm_mode` on save and reads the saved value back on edit (defaulting to `snapshot` for jobs created before the field existed), so Cold Backup sticks. This matters because Cold Backup (shut down → copy → restart) is the reliable fallback when a live snapshot backup fails – e.g. on non-qcow2 disks or guests without a working dirty-bitmap path.
- **Failed-backup error messages are now visible at a glance on the History page (#116).** Previously the failure reason was clipped to ~120 characters and the inline summary was `truncate`d to one line, so the actual cause (e.g. a libvirt/QEMU or storage error behind a VM backup that fails partway) was effectively hidden – matching the "just seeing a message of failed, no log errors I can see" report. The inline reason now wraps (up to three lines, full text in the tooltip) and is no longer character-clipped, the most recent failed/partial runs auto-expand to show the per-item breakdown without a manual click, and `partial` runs (some items succeeded, some failed) now surface their first error too.
- **Remote backups are no longer cancelled mid-upload by the progress watchdog or a hidden total-job timeout (#110).** The per-job no-progress watchdog only advanced its timer during the _staging_ phase, so the actual remote upload – a single blocking `adapter.Write` – ran with a frozen timer and any upload exceeding 2 hours was killed even while data was transferring fine (worst with **Defer remote upload**, where the whole batch uploads with the timer frozen). The upload (and verify read-back) now heartbeat the watchdog on every chunk of bytes moved, so it only fires on a genuinely dead connection. Separately, the undocumented **4-hour total-job hard cap** that also cancelled large healthy backups has been removed: a job that is actively transferring is never killed by elapsed time. The no-progress stall watchdog (zero bytes for 2h) plus manual Cancel are now the only automatic cancellers, and a stall-cancel is logged and labelled distinctly from a user cancel (and still triggers a retry, unlike a user cancel).
- **Deleting a job or restore point with its backup files no longer times out the UI ("daemon unavailable") on slow remotes (#111).** Cleanup of a large backup on a remote target (e.g. ~30 GB on a Hetzner Storage Box) ran synchronously inside the HTTP handler and could take far longer than the browser/proxy would wait – surfacing as a spurious `vault daemon unavailable` even though the server kept working and eventually returned 204. The DB record is now deleted immediately and the remote file sweep runs in a background goroutine; the request returns **202 Accepted** and a `job_cleanup_complete` / `restore_point_cleanup_complete` (or `*_failed`) WebSocket event reports the outcome. Cleanup also no longer leaves empty WebDAV chunk sidecar directories behind: `Delete` now removes the `.chunks` directory after its chunk files, sweeping orphaned artifacts from partial/interrupted chunked uploads.
- **Storage destinations can now be deleted even when jobs or replication sources still reference them (#113).** Deleting a destination with dependent rows previously failed with an "internal error" because `jobs.storage_dest_id` and `replication_sources.storage_dest_id` are foreign keys with no `ON DELETE` rule, so the bare `DELETE` raised a `FOREIGN KEY constraint failed`. `DeleteStorageDestination` now runs in a single transaction that first **orphans** those dependents – setting the reference to `NULL` so the jobs survive but lose their destination (matching the delete dialog's warning that "those jobs will no longer have a storage destination and will fail to run") – then deletes the row. Job reads now `COALESCE(storage_dest_id, 0)` and job writes map the `0` sentinel back to SQL `NULL`, so an orphaned job lists, opens, and re-saves without re-triggering the constraint. Destinations referenced only through `ON DELETE CASCADE` tables (dedup packs/chunks/GC runs, capacity samples) continue to clean up automatically.
- **Dashboard no longer stays stuck "Backup in Progress" forever when a finalization step hangs (#112).** Three coordinated fixes: (1) The Unraid notify helper is now launched with a 30-second `context.WithTimeout` via `exec.CommandContext`; a wedged helper is killed and a clear error is logged rather than blocking forever. (2) The live run status (`currentRun`) is cleared immediately after the run is persisted to the database – the Dashboard reflects completion the moment data is safe, even if database-backup, USB flush, retention enforcement, or notification takes extra time. The existing deferred `setRunStatus(nil)` remains as an idempotent safety net. (3) Every blocking finalization step (`database-backup`, `snapshot-usb`, `retention`/`retention-gfs`, `notify`) is now wrapped in `runFinalizationStep` with a named hard timeout (5 min / 5 min / 10 min / 2 min). On timeout an `ERROR` log line names the step and the run continues, ensuring `r.mu` (the run-slot mutex) always releases and future jobs are never blocked indefinitely.

### Changed

- **In-app API Endpoint Reference (Settings → API Endpoints) now lists the anomaly-detection and stale-item remediation endpoints**, so the documented surface matches the daemon's actual routes (`/anomalies*`, `/jobs/{id}/baseline`, `/destinations/{id}/capacity-trajectory`, and the new `/jobs/{id}/stale-items*` + `/jobs/{id}/items/{itemId}`).
- **Storage layer rebuilt as a composable middleware chain for uniform reliability across all backends.** Every storage destination (local, SMB, NFS, SFTP, WebDAV, S3) is now a thin provider wrapped in a chain – throttle → retry → metrics → logging – so cross-cutting behaviour is identical everywhere instead of hand-rolled per provider. A single transient-error **retry layer** with jittered exponential backoff (5 attempts, 1s→30s, full jitter) now sits in front of **all** backends; it classifies timeouts, connection resets, broken pipes, unexpected EOF, and transient HTTP statuses (408/429/500/502/503/504) as retryable while failing fast on auth/permission, 4xx, and user cancellation. This replaces the previous WebDAV-only retry loop and gives S3 and SFTP automatic retry they never had. A new retry-aware `WriteFrom` write path re-opens the staged source per attempt so a partially-failed upload replays cleanly from the start.

### Added

- **Stale-item detection and one-click remediation for backup jobs (#119).** When a container, VM, folder, plugin, or ZFS dataset referenced by a job no longer exists on the server, the backup run now **skips** it instead of failing the whole job with confusing "missing item" errors, records it, and raises an Unraid notification. The Jobs page shows an amber **"N missing"** badge on affected jobs; clicking it opens a **Review missing items** dialog that lists each gone item with a per-item **Remove** button and a **Remove all** button. Vault never removes items automatically – you decide. Removal is re-validated server-side at click time (an item that has reappeared is left alone) and only drops the item from the job: **existing backups and restore points are preserved**, so you can still restore what was captured before the source disappeared. Detection degrades safely – if Docker or libvirt is temporarily unavailable, items of that type are treated as "unknown" (never flagged as missing) so a transient outage can't mark everything stale. New endpoints: `GET /api/v1/jobs/{id}/stale-items`, `POST /api/v1/jobs/{id}/stale-items/remove`, `DELETE /api/v1/jobs/{id}/items/{itemId}`; new WebSocket event `stale_items_detected`.
- **Resilient, parallel restores from remote storage.** Restore downloads now recover from transient mid-stream connection drops instead of restarting the whole object and failing the restore: a resumable reader reopens the transfer from the last byte received (built on ranged reads, so it works on every backend – local, SMB, NFS, SFTP, WebDAV, S3). Restores also download multiple files concurrently (bounded by the job's parallel-transfers setting), and a single large **plain** object (e.g. an unencrypted, uncompressed VM `qcow2`) is fetched via concurrent ranged GETs assembled on disk – turning a long single-stream download into a parallel one. Encrypted (`.age`) or compressed objects use the sequential resumable path so the decrypt/decompress pipeline stays correct; checksums are verified on both paths (a whole-file re-read for the parallel path, inline for the sequential path). Restores additionally gained the same no-progress **stall watchdog** the backup path has – a hung restore is now cancelled (and that cancellation reaches the engine restore phase) rather than blocking indefinitely.
- **Per-job parallel uploads.** Each job has a **Max parallel uploads** setting (1–16). A job's staged files now upload through a bounded worker pool of that size, sharing the destination's bandwidth cap. Existing jobs keep serial behaviour (1) on upgrade so nothing changes unexpectedly on fragile links; new jobs default to 3. Set it to 1 for a flaky or rate-limited remote, or higher for a fast link.
- **SFTP connection pooling.** The SFTP backend previously dialed a fresh SSH connection for every operation; it now reuses a small pool of healthy connections (and correctly closes both the SSH and SFTP clients on teardown, fixing a per-operation connection leak). This makes parallel SFTP uploads practical.
- **Storage observability.** Per-operation metrics (calls, errors, retries, latency) are tracked per destination, and an opt-in **Verbose storage logging** toggle (Settings → General, off by default) emits a redacted, structured trace line per storage operation for diagnosing slow or flaky remotes.
- **Empty-directory cleanup.** Deleting the last backup under a directory on filesystem-style and SFTP backends now sweeps the now-empty parent directories, so destinations don't accumulate empty folders over time.

- **Anomaly detection and insights (Pillar A).** A new `internal/anomaly` engine watches four signals per job/destination – size drift, duration drift, reliability/verify regressions, and destination capacity trajectory – and surfaces anomalies across every Vault surface. Detectors use robust statistics (median + MAD with the Iglewicz–Hoaglin modified z-score) plus pragmatic secondary rules (a 5× median-multiplier growth rule and a 0.5× asymmetric-shrinkage rule for suspiciously small backups). Each job and destination exposes a **Strict / Balanced / Permissive** sensitivity knob (Settings → General sets the global default; per-job overrides on the job edit form). Detection runs asynchronously off the backup runner via a bounded, non-blocking evaluator goroutine – a completed run enqueues an evaluation, and a 5-minute trend ticker drives the capacity detector. Anomalies surface live on a new dashboard card, as inline severity badges on job and run-history rows, on a new `/anomalies` page (filters, keyset pagination, bulk-acknowledge), via Unraid + Discord notifications (severity-gated; default: critical only, with `notified_at` de-duplication and per-job `anomaly:*` `notify_on` overrides), and as three MCP tools (`list_anomalies`, `get_anomaly`, `acknowledge_anomaly`) for AI assistants. Lifecycle is hybrid: soft (info/warning) anomalies auto-resolve on a clean run, criticals persist until acknowledged, and a **Mark as expected** action raises the baseline floor so deliberate growth stops re-alerting. New endpoints under `/api/v1/anomalies`, `/api/v1/jobs/{id}/baseline`, and `/api/v1/destinations/{id}/capacity-trajectory`; new WebSocket events `anomaly.raised`, `anomaly.updated`, `anomaly.bulk_resolved`, `anomaly.bulk_acked`, and `baseline.updated`. Detection is opt-out (`anomaly_detection_enabled`, defaults to `true`) and learns a per-job baseline over the first 10 runs (the UI shows a "Learning baseline (N/10)" label until then). Storage adapters gained a `Usage()` method (free/total bytes) – implemented for local, SFTP, SMB, NFS, and quota-capable WebDAV; S3 reports unsupported. Terminal anomalies older than 90 days are pruned automatically.

### Security

- **SFTP private-key file path is now validated before it is read** (CodeQL `go/path-injection`). The admin-configured key-file path is rejected if it contains any `..` traversal component (checked both before and after normalisation) and resolved to a clean absolute path before `os.ReadFile`, mirroring the existing snapshot-path sanitiser. Static-analysis false positives on the parameterised bulk job-item queries (`DELETE/UPDATE … WHERE id IN (?, …)`) and the anomaly-list filter query were annotated as safe – every value is bound, never interpolated.

## [v2026.05.04] - 2026-05-28

### Fixed

- **Vault configuration no longer disappears after an Unraid upgrade or restart (closes #108).** Four root-cause-driven changes restore the persistence invariant end-to-end:

  1. **Non-hybrid USB-backup restoration fallback.** The previous startup path only ran the snapshot fallback chain when hybrid mode engaged. The first time the daemon ran in hybrid mode, the on-USB `vault.db` was renamed to `vault.db.backup` (the safety net). On any later boot where the pool drive failed to mount in time – exactly what happens after an Unraid upgrade restart, because Unraid launches plugin services before the array finishes mounting – `hybridMode` stayed false, `db.Open("/boot/.../vault.db")` saw a missing file and silently created a brand-new empty SQLite schema, and every saved job, destination, and setting became invisible. `internal/cli/daemon.go` now performs an explicit non-hybrid restoration step: if the primary DB is missing/empty but a USB safety-net backup exists, `vault.db.backup` is copied back into place (fsynced) _before_ the first `db.Open`. Operators get a clear log line (`Configuration restored from USB backup at …`) and, if neither file exists, an explicit warning that the daemon is starting fresh.
  2. **Pool-mount retry loop on startup.** `internal/cli/daemon.go` now polls `unraid.PreferredPool()` + `unraid.IsMountedPool()` up to 15 times with a 2 s interval (30 s window total) before declaring no pool. This catches the common case where the array comes up within a few seconds after the daemon launches and lets hybrid mode engage cleanly, instead of falling through to USB-direct mode for the entire daemon lifetime.
  3. **Pre-drain USB flush on SIGTERM.** `internal/api/server.go` `StartWithContext` now invokes a registered `preShutdownHook` _immediately_ on `ctx.Done()`, before the runner drain. The daemon registers `snapshotMgr.FlushToUSB()` as that hook (`internal/cli/daemon.go`). Previously the final snapshot + USB flush only happened after the (up to 30 s) runner drain returned and `srv.ListenAndServe` produced `ErrServerClosed`; if `rc.vault` escalated to `SIGKILL` mid-drain (which it did, given a 15 s wait), all in-RAM configuration was lost. A new log line `server shutdown: pre-drain flush completed in <duration>` confirms the path ran.
  4. **rc.vault shutdown window extended from 15 s to 45 s with intermediate SIGINT.** The plugin's service script (`plugin/rc.vault`) and the Ansible deploy role's inline `rc.vault` template (`ansible/roles/deploy/tasks/main.yml`) now both: poll `kill -0 $pid` for up to 45 s after SIGTERM (matching the 30 s drain + flush headroom), send SIGINT before escalating to SIGKILL, and log forced-shutdown reasons. The previous one-line `stop()` (`kill $pid; rm -f $PIDFILE; echo "stopped"`) returned in milliseconds without waiting, which is what introduced the SQLITE_BUSY race observed during `make deploy` (the new daemon started before the old one finished its flush).

  Verified end-to-end on Unraid against the live "Test Containers", "Folders Backup", and other configured jobs: every `rc.vault restart` cycle now logs `server shutdown: pre-drain flush completed in 1.2-3.0 s` → `Vault daemon stopped gracefully` → fresh startup with `Database restoration: source=primary path=/mnt/cache/.vault/vault.db (restored from configured snapshot path)`. Configuration survives across multiple back-to-back restarts with zero `database is locked` errors.

### Added

- **Startup persistence diagnostics on `/api/v1/health`.** The health endpoint now includes a `startup` object exposing the boot-time facts the daemon learned during initialisation: `hybrid_mode`, `detected_pool`, `pool_mounted`, `pool_retry_wait_ms` (how long the pool-mount retry loop waited before declaring success), the `restoration` source/path/reason, `has_configuration` (true iff the DB holds ≥1 job or ≥1 storage destination), a full `configuration` row-count breakdown, and `unraid_boot_kind` (`"flash"` for traditional USB boot, `"internal"` for Unraid 7.3+ internal boot, `"unknown"` for non-Linux dev hosts). Support engineers (and `make verify`) can confirm at a glance whether configuration survived an Unraid restart or upgrade without parsing the daemon log. Backed by a new lightweight `db.ValidateHasConfiguration(ctx)` helper (`internal/db/validation.go`) that runs three indexed `COUNT(*)` queries against `jobs`, `storage_destinations`, and `settings`.

- **Prominent startup warning when the database appears empty after restoration.** Right after `db.Open`, the daemon now calls `ValidateHasConfiguration` and either logs `Database configuration validated: N jobs, M storage destinations, K settings` (the happy path) or, when both counts are zero, emits a single `WARNING:` line that names which snapshot/USB-backup paths were attempted and links to issue #108. Catches the silent-fresh-database failure mode that previously needed a support bundle to diagnose.

- **Boot-time startup delay in `rc.vault`** (`plugin/rc.vault` + the Ansible deploy role's inline). Read `/proc/uptime`; if the kernel has been up for less than 120 s, sleep 8 s before launching the daemon. Manual restarts (deploy iteration, `rc.vault restart` from the command line) skip the delay entirely – the check is purely a belt-and-braces measure complementing the in-daemon 30 s pool-mount retry loop, for the case where Unraid's plugin startup races the array mount on first boot. No effect on iteration speed; only the first ~2 minutes after kernel boot pay the 8 s cost.

- **Periodic USB safety-net refresh every 30 min** (hybrid mode only). Belt-and-braces for the case where the event-driven flushes – `configChangeHook` on every mutation, post-backup snapshot save, SIGTERM pre-drain flush – all happen to be quiet for a long stretch (e.g. an idle system that loses power unexpectedly). A background ticker calls `SnapshotManager.SaveSnapshotAndUSBBackup()` every 30 minutes; the pool-snapshot write always runs (zero flash wear), while the USB-flash write is gated by the existing 1-hour `usbMinInterval` throttle, bounding worst-case wear to one USB write per hour regardless of cadence. On Unraid 7.3 internal-boot systems where wear is essentially not a concern, the throttle just means the USB-equivalent backup stays at most one hour fresh. Skipped in non-hybrid mode because the working DB _is_ the USB file there, so a backup would be a no-op self-copy.

### Changed

- **`db.RestorationInfo` fields now serialise as `source`, `path`, `reason`** (snake_case JSON tags) to match the rest of the API surface. Was previously emitting `Source`, `Path`, `Reason` PascalCase, which was inconsistent with every other Vault JSON response. The Go field names are unchanged so no internal callers move.

- **Unraid 7.3 internal-boot compatibility documented (and confirmed safe).** Unraid 7.3.0 (stable, released 12 May 2026) introduces internal boot – booting Unraid from an internal NVMe/SSD/eMMC (optionally a ZFS-mirrored boot pool) instead of a USB flash drive. Vault's persistence model relies on `/boot/config/plugins/vault/vault.db.backup` as the safety-net copy. On Unraid 7.3 internal boot, `/boot/` is still the canonical mount point for the boot device's `config` partition – Unraid copies the flash content to the internal device during the onboarding-wizard migration, so existing Vault installs that survive the OS upgrade keep their settings without code changes. The daemon now reports `unraid_boot_kind` in `/api/v1/health` (`"flash"` or `"internal"`) so support can verify which path is in use, and a few user-facing log messages drop the obsolete "USB flash" wording in favour of "boot device" / "boot flash" where the difference matters. Migration path for existing users: do the standard Unraid 7.3 internal-boot migration; Vault settings carry over because they live in the `config` directory that Unraid copies. Two boot devices in a ZFS mirror also adds redundancy to Vault's USB safety-net (one boot device can fail without losing `vault.db.backup`).

- **Docker (`vault-replica`) build now copies `CHANGELOG.md` into `internal/release/` before `go build`.** The 2026.05.03 Docker workflow failed with `internal/release/embed.go:7: pattern CHANGELOG.md: no matching files found` because the `//go:embed` directive added with the About card requires the file next to `embed.go` at build time. The Makefile and the Ansible build role already do that copy; the Dockerfile didn't (the embed-location copy is gitignored). The published GitHub release (`vault-2026.05.03.txz`) was unaffected because it ships through the Makefile path. Adds the `cp` step in the builder stage of `Dockerfile`.

- **Settings → About card now reports a daemon ahead of the latest GitHub release as "Pre-release" rather than the misleading "Update available".** `web/src/pages/Settings.svelte` previously treated any version inequality as "Update available", so a freshly-tagged build (or a development build that's ahead of the most recent published release) wore the same orange "Update available" badge a genuinely out-of-date daemon would. The check now uses an ordering comparison on the normalized `YYYY.MM.PATCH` strings (which sort chronologically because the patch is 0-padded): `daemon === latest` → "Up to date", `daemon > latest` → "Pre-release" (with `Latest published: vX.Y.Z` note), `daemon < latest` → "Update available". Closes the unreleased Known issue tracked here.

## [v2026.05.03] - 2026-05-27

### Added

- **Per-destination storage capacity on the Storage page.** Every backup destination now shows how much space it has left, refreshed daily alongside the 03:30 health-check sweep. Quota-aware providers (`local` and `nfs` via `unix.Statfs`; `webdav` via RFC 4331 PROPFIND on Nextcloud / ownCloud; `sftp` via the `statvfs@openssh.com` extension; `smb` via `FileFsFullSizeInformation`) render a coloured progress bar – Vault brand below 80 %, amber 80–90 %, rose ≥ 90 %. Providers without a protocol-level quota (S3 / Backblaze B2) render a "used-only" line whose number comes from a paginated `ListObjectsV2` sum under the destination's base path. New endpoint `POST /api/v1/storage/{id}/capacity-check` runs an on-demand probe with a 30 s ceiling and broadcasts `storage_capacity_updated` on the WebSocket so any open Storage page repaints live. Six new nullable columns on `storage_destinations` (`capacity_total_bytes`, `capacity_used_bytes`, `capacity_free_bytes`, `capacity_probed_at`, `capacity_source`, `capacity_error`) carry the persisted reading; the daily scheduler ceiling is 60 s; failures are stored in `capacity_error` for support reports but never affect the health-check verdict or breaker. All values render through the existing `formatBytes()` helper so operators see KB / MB / GB / TB / PB, never raw `int64`. The API returns raw `int64` bytes for machine consumers (MCP tools, scripts, diagnostics bundle); only the UI does the conversion.
- **About card on Settings → General.** Compact card at the bottom of the General tab showing the daemon's current version, an "Up to date" / "Update available" status badge backed by a 1-hour-cached GitHub releases query, and a "View Changelog" button that opens a modal listing every shipped release in collapsible form (latest auto-expanded; click any row to expand it). The full release history lives inside the modal so the Settings page itself stays uncluttered. New endpoints `GET /api/v1/release/changelog` (serves the embedded `CHANGELOG.md` parsed by version, Unreleased excluded) and `GET /api/v1/release/latest` (returns the latest GitHub release tag with a 1 h server-side cache; 204 when GitHub is unreachable so the card renders a clean offline state). Version comparison normalises the leading `v` so a daemon reporting `2026.05.02` matches a GitHub tag like `v2026.05.02`. `CHANGELOG.md` is embedded into the binary via `//go:embed` at build time (the Makefile and Ansible build role copy the repo-root file into the embed location; the copy is gitignored to keep the repo root the single source of truth).
- **Run-level retry policy.** Failed runs now schedule themselves for automatic retry up to a configurable cap before going permanently failed. Settings exposes a global default (max retries + JSON delays array, defaults `2` and `[900,3600,14400]` seconds → 15 min / 1 h / 4 h). Each job can override both fields in the wizard's Advanced step. A new scheduler watcher runs `@every 1m`, atomically claims rows whose `retry_next_at` has expired, and dispatches via a new `RunJobRetry(jobID, originalRunID, attempt)` path. Triggers retries on: stall cancellation, pre-flight failure, encryption-config error, pre-script failure, panic recovery, and terminal `failed` status. Suppresses retries when the destination breaker is open, when the run was operator-cancelled, or when the run was a manual "run now" (the API/MCP "run now" callers now route through `RunJobManual` so they don't auto-retry).
- **Pre-flight destination check.** Every scheduled run runs a fast `TestConnection` (15 s ceiling) against the destination before opening the backup pipeline. Unreachable destinations now produce a `skipped` `job_run` row with a clear reason instead of consuming the 4-hour job timeout. The skip counts toward the circuit breaker so a chronically unreachable destination eventually opens its breaker.
- **Per-destination circuit breaker.** Each storage destination tracks `consecutive_failures` and a `breaker_state` (`closed` / `open`). The breaker opens after 3 consecutive failures (job runs OR daily health checks OR preflight) and auto-closes after 2 consecutive successes. While open, scheduled runs targeting the destination skip with a clear reason instead of failing. New `POST /api/v1/storage/{id}/breaker/close` endpoint resets the breaker manually (204). Storage page shows a "Breaker open" badge with the timestamp tooltip and a "Reset breaker" button when the breaker is open. Encryption/pre-script failures and operator cancellations intentionally do NOT count against the breaker (they're config issues, not destination health).
- **Heartbeat file at `/var/local/vault/heartbeat`** (hybrid mode) or alongside `vault.db`. Refreshed every 30 s with `<RFC3339 timestamp> v<version>` so external monitoring (Unraid notifications, monit, custom watchdog) can detect a hung daemon by checking the file mtime. RAM-backed in hybrid mode so it doesn't wear flash. Write failures are logged at most once per hour to avoid log spam.
- **Graceful drain on SIGTERM.** Daemon shutdown now waits up to 30 s for the active backup to finish at the next per-file boundary before tearing down the HTTP server. After the drain ceiling fires, the existing context-cancel still terminates mid-flight work. New `Runner.Drain(ctx)` API; runner refuses new `RunJob` invocations once draining.
- **Encrypted offsite database backup with fan-out.** The post-backup DB copy now (a) runs `PRAGMA wal_checkpoint(TRUNCATE)` so the on-disk file is self-contained, (b) encrypts with the global passphrase when one is configured (writes age-format `.age`; plaintext + warning log otherwise), (c) writes both a timestamped historical copy (`_vault/vault.db.YYYY-MM-DDTHH-MM-SS.age`) and a stable `_vault/vault.db.latest.age` pointer, and (d) fans out to every destination flagged "Include in DB backup" in addition to the job's own destination. New `backup_database_enabled` column on `storage_destinations` (default off). Storage page exposes the toggle as "Include in DB backup".
- **Rolling snapshot history (keep last 7).** After every successful primary snapshot save, the file is also copied to `<snapshot_dir>/rotated/vault.db.YYYY-MM-DDTHH-MM-SS.nanos` and the rotated directory is pruned to the 7 newest entries. Uses a hardlink on the same filesystem (zero extra bytes for unchanged snapshots) and falls back to a byte copy on cross-device errors. Filenames use UTC dashes-only timestamps with nanosecond resolution so they sort chronologically and never collide. Rotation failures are logged but never block the snapshot pipeline, so a transient disk issue cannot poison the main save path.
- **Per-destination deduplication (opt-in).** Storage destinations gain an "Enable deduplication" toggle (immutable after creation). When enabled, folder, plugin, and container-volume backups to that destination are content-defined-chunked, encrypted per-chunk, and packed so identical data across snapshots, jobs, and containers is stored once. VM, ZFS, and flash backups continue to use the classic tar pipeline. The Storage card shows the dedup ratio, chunk/pack counts, reclaimable bytes (the space a cleanup could reclaim, measured at the last GC and persisted in a new `dedup_gc_runs` table so the figure and last-cleanup time survive daemon restarts and are visible from any request – they no longer read 0), and a "Run cleanup" button. "Run cleanup" now also **compacts** mixed packs (those above a configurable dead-bytes threshold): live chunks are copied verbatim into fresh packs (no decrypt/re-encrypt – chunk encryption is deterministic and keyed by content ID, so the on-disk bytes are identical regardless of which pack holds them), chunks are atomically re-pointed in the DB, and the old packs are tombstoned + deleted. Chunks remain readable from at least one pack at every observable step. The threshold lives in Settings → General as **"Compaction threshold (% dead bytes)"** (key `dedup_compaction_min_dead_ratio`, default `0.5` = 50%; set to 100 to disable compaction). The on-storage `_vault/index/*.idx` log gained a tombstone record + last-writer-wins rebuild semantics so `vault dedup repair` correctly removes deleted packs (and re-points moved chunks) during a disaster-recovery rebuild – closes a latent bug where the rebuild path would resurrect packs that GC had deleted. GC's sweep also now reaps empty packs (created if a compaction crashes between writing the new pack and re-pointing chunks) so any orphan from a partial compaction self-cleans on the next run. The `dedup_gc_runs` table gained `compacted_packs` and `reclaimed_bytes` columns; both surface in the `dedup_gc_complete` WebSocket payload and the daemon log line. New endpoints `GET /api/v1/storage/{id}/dedup-stats` and `POST /api/v1/storage/{id}/gc`. New CLI subcommands `vault dedup repair --dest=<id>` (rebuild the SQLite index from on-storage data after DB loss) and `vault dedup gc --dest=<id>`; both accept a `--key` flag to read `vault.key` from a non-default location (e.g. a disaster-recovery restore where the key was placed beside a copied database). Quick + deep verify both work on dedup restore points without UI changes.
- **Restore wizard file picker.** The restore wizard's summary step now has a "Restore specific files…" disclosure per item. Pick individual files (or whole subtrees) with a path filter, select-all, and clear. Items left untouched still restore in full. Falls back to whole-archive extract for backups produced before partial restore shipped.
- **Partial restore via tar index sidecar.** Folder, plugin, and container-volume backups now write a small index sidecar (`<archive>.index.json`) next to each tar archive listing every entry. The restore API accepts an optional `file_paths` map so only the named entries are extracted (descendants of selected directories are included automatically). Sidecars are encrypted alongside the archive when the job uses encryption. Pre-existing backups continue to restore everything via the legacy whole-archive path.
- **Grandfather-father-son (GFS) retention.** New optional `keep_latest`, `keep_daily`, `keep_weekly`, `keep_monthly`, `keep_yearly` fields per job (all default 0 = disabled). When any are set, the runner keeps the newest N latest plus the first restore point per day/week/month/year bucket. A single restore point can fill several buckets at once. Existing `retention_count` / `retention_days` are unchanged and continue to apply on every other job. Chain-ancestor protection still applies so kept incrementals always have a restorable parent.
- **GFS retention preview in the Jobs wizard.** As users tune the keep counts, the wizard shows "Would keep X of Y current restore points · Z would be pruned" 300 ms after the last keystroke. Backed by a new `GET /api/v1/jobs/{id}/retention-preview` endpoint. Hidden for new jobs that don't have restore points yet.
- **Restore-point verification with quick and deep modes.** `POST /api/v1/jobs/{id}/restore-points/{rpid}/verify` queues a verify run and returns a `verify_run_id`; progress streams over the WebSocket. **Quick** stats every recorded file and fails on missing files or size mismatches (no data transfer, suitable for weekly scheduled runs). **Deep** streams every file and re-checks SHA-256 against the backup-time manifest – catches silent bit rot on cold storage. Two helper endpoints round out the API (`GET .../verify-runs/{vrid}` and `GET .../restore-points/{rpid}/verify-runs`). Verify runs in its own goroutine and does not block scheduled backups.
- **Scheduled verification per job.** Two new job columns (`verify_schedule`, `verify_mode`) let you run quick or deep verify on its own cadence, independent of the backup schedule (e.g. nightly backups + weekly deep verify). Configured in the wizard's Advanced step via the same friendly day/time picker used for the backup schedule; no cron expertise required.
- **Daily storage destination health check.** The scheduler runs `TestConnection` against every destination at 03:30 local (deliberately after typical backup windows so a failing destination is caught before the next morning's run). Results persist on the destination row and broadcast over the WebSocket. The Storage page shows a Healthy / Unhealthy badge with the error in the tooltip. `POST /api/v1/storage/{id}/health-check` triggers an on-demand check.
- **Orphan file GC (dry-run by default).** `POST /api/v1/storage/{id}/scan-orphans` lists files on a destination that don't belong to any active restore point. Safe to call repeatedly; no state changes. `POST /api/v1/storage/{id}/delete-orphans` deletes specified paths after re-scanning to ensure each is still orphaned. Useful for reclaiming quota on managed providers after failed runs. UI is API-only in v1.
- **Per-destination bandwidth throttling.** Optional `bandwidth_limit_mbps` field on every non-local storage config caps upload + download throughput (megabits per second). Default 0 = unlimited. Metadata operations (List/Stat/Delete/TestConnection) are never throttled. Exposed in the Storage form as a single "Bandwidth limit (Mbps)" input.
- **Configurable S3 multipart part size (`part_size_mb`).** Default 0 uses 64 MiB parts (640 GB per-object ceiling, fits typical home-server workloads). Raise to 256, 512, or 1024 MiB for very large datasets (up to 10 TB). Range is enforced at 5–5120 MiB per the S3 protocol. Peak upload memory ≈ part_size × concurrency (default 5), so 1 GiB parts cost roughly 5 GiB of RAM during active uploads.
- **Configurable WebDAV chunk size (`chunk_size_mb`).** Default 0 uses 50 MiB chunks. Positive values set the chunk size in MiB. Negative values disable chunking but keep memory-safe known-length writes.
- **Automatic compression downgrade for media-heavy backups.** Folder, plugin, and container-volume backups now sample the source up-front and, when ≥ 70% of the bytes have already-compressed file extensions (.mp4, .mkv, .flac, .jpg, .zip, .gz, .zst, …), automatically drop the requested gzip/zstd compression to none for that archive. A 200 GB Immich library or a Jellyfin folder no longer wastes CPU re-compressing already-compressed bytes. The decision is logged and the manifest records the compression actually used so restore continues to auto-detect via magic bytes.
- **Diagnostics bundle captures the daemon log, per-job item settings, storage health-check trend, runtime settings, and disk space.** Every bug we triaged in recent QA was diagnosed by reading the daemon log, inspecting per-job item settings, or checking storage health history – none of which were in the previous bundle. The collector now tees daemon output through a 1 MiB in-memory ring buffer at startup and includes the redacted snapshot as `vault.log` in the ZIP. Each job's items are included with redacted settings (exclusion paths, container ID, mount info, ZFS dataset, etc.) so support reports show which items were configured and how. Storage destinations include their dedup state and last health-check result. A credential-free settings snapshot reports things like which categories are enabled, whether an API key is set, and the configured staging/snapshot overrides. Disk usage is probed for `/boot`, `/tmp`, `/var/local/vault`, the DB directory, the staging dir, and every discovered Unraid pool. Run history is split into a structured log + extracted error messages instead of one stuffed field. Activity entries now include `category` and `details`. A new redactor scrubs Authorization, X-API-Key, Cookie/Set-Cookie, Proxy-Authorization, AWS sigv4 Credential=, JSON/query-string credential fields, inline URL credentials, and Discord webhook tokens from the log tail before it's embedded.
- **Diagnostics also captures verify-run history, per-destination dedup stats, runtime metrics, pool discovery, Docker / libvirt connectivity, and scheduler state.** New ZIP entries: `verify_runs.json` (last 25 quick + deep runs), `dedup_stats.json` (per dedup destination), `runtime.json` (goroutines, heap, GC, uptime), `pools.json` (every discovered Unraid pool with its mount status), `connectivity.json` (Docker socket + libvirt URI probes; errors are captured so "Docker not reachable" is itself the diagnostic), `scheduler.json` (next-run timestamp per enabled job).
- **Diagnostics ZIP layout is split into per-section files** instead of one fat `diagnostics.json`. Support engineers can now `unzip -p bundle.zip jobs.json | jq` without paging through unrelated sections. The top-level `diagnostics.json` is a one-screen overview that omits activity, runs, and the log tail.

### Changed

- **`SaveSnapshot` now runs `PRAGMA wal_checkpoint(TRUNCATE)` before invoking the SQLite Online Backup API** so the resulting snapshot file is self-contained and the WAL is reclaimed on disk. Checkpoint failures are logged but never block the snapshot. New `PRAGMA journal_size_limit = 67108864` (64 MiB) at every `Open()` bounds the WAL between checkpoints.
- **`restoreWithFallback` runs `PRAGMA integrity_check` on every successfully-restored tier** and falls through to the next tier (primary → default cache → USB backup → fresh DB) when the check fails. A corrupt snapshot can no longer silently become the working database – at worst the daemon starts with a fresh DB and tells the operator to reconfigure.
- **HTTP API shutdown now drains the runner for up to 30 s before the existing 5 s HTTP `Shutdown` window.** A planned restart (plugin upgrade) lets the active per-file upload reach the next boundary instead of being killed mid-stream. After the drain ceiling fires, the existing context-cancel path still tears down mid-flight work. New `Runner.Drain(ctx)` is the API surface.
- **`job_runs.status` can now be `skipped`.** Two paths produce skipped runs: a pre-flight check failing to reach the destination, and a scheduled run firing against an open breaker. The History page renders skipped rows neutrally (not red), and the deferred retry watcher picks up preflight-skipped rows for re-attempt.
- **Bandwidth limit no longer offered for local storage destinations.** Throttling local I/O slowed backups for no operational benefit. The Storage form hides the field for local destinations and the factory ignores any stale value left in an older config. SFTP, SMB, NFS, WebDAV, and S3 continue to honour the limit.
- **Restore wizard, History timeline, Logs, and Dashboard Recent Activity now show absolute timestamps as the primary label**, with the relative form (`48m ago`) preserved as a hover tooltip. Matches how Veeam, restic, and Time Machine present restore points (closes #81).

### Fixed

- **Editing any field on a storage destination no longer silently corrupts the saved password.** The Settings → Edit Storage modal pre-fills its password input with whatever the API returned (`"••••••••"` for any destination with credentials – the redaction marker). Saving the form without retyping the password posted that marker back to `PUT /api/v1/storage/{id}`, which the server then stored verbatim as the new password, causing every subsequent backup/test to 401. `PUT /storage/{id}` now runs the incoming config through `preserveRedactedSecrets`: any `sensitiveConfigKey` whose value equals the `"••••••••"` marker is rewritten to the corresponding value from the previously-stored config before persistence. New typed credentials still overwrite as before. The fix is server-side because the trap affected the UI modal AND any other client (MCP tools, ansible automation, direct API scripts) round-tripping a partial edit.
- **S3 destinations no longer fail with `Head "//<bucket>./<endpoint>": unsupported protocol scheme ""` when the operator pasted a bare-hostname endpoint** (e.g. `s3.us-east-005.backblazeb2.com`, exactly as Backblaze B2's web console displays it). The adapter handed the unmodified string to the AWS SDK, where `url.Parse` left `Host` empty and the virtual-host-style bucket-prefix resolver emitted a malformed URL with no scheme. `NewS3Adapter` now runs every endpoint through `normalizeS3Endpoint`: bare hostnames are promoted to `https://…`, schemes other than `http(s)` are rejected at construction time, and parsed URLs with an empty host are rejected. `TestConnection`-style checks and previously-stored destinations are unaffected once the daemon restarts. The same constructor now also `TrimSpace`s `access_key` and `secret_key` to defend against the related copy-paste failure where stray whitespace from the B2 console produced a 403 `SignatureDoesNotMatch` with no obvious cause.
- **WebDAV chunked uploads to Nextcloud (and other Sabre/DAV servers) no longer fail with `WriteStreamWithLength …/000000.part: 400`.** The WebDAV adapter wrote each chunk of a logical-file upload as `<index>.part` inside the `.chunks` sidecar directory. Nextcloud's default `forbidden_filename_extensions` / `blacklisted_files_regex` reserves `.part` and `.filepart` for its own in-progress-upload mechanism and rejects external PUTs to those names with **HTTP 400 Bad Request**. Single-PUT uploads (small backups, < 50 MiB) were unaffected, so `TestConnection` and small jobs passed while every chunked container backup failed on the first chunk. Chunk files are now written with a `.dat` suffix, which is not on any known WebDAV server blacklist. The fix is forward-only safe: every chunk's absolute path is recorded in the manifest, so historical restore points continue to read correctly from their original `.part` chunks. `writeChunked`'s cleanup path also now removes the (empty) `.chunks` collection when a chunked upload aborts on the first chunk, so failures leave nothing behind on the remote.
- **Dedup ratio and logical-bytes stats are correct for multi-item dedup destinations.** The Storage card's dedup ratio showed `0×` / `0 B → N` (and the diagnostics bundle reported zero logical bytes) for any destination fed by a multi-item job – e.g. a containers dedup backup. `DedupAggregates` summed `restore_points.size_bytes` only `WHERE manifest_id IS NOT NULL`, but that column is set only for single-item jobs; multi-item jobs leave it NULL and store per-item IDs in `metadata.item_manifests`, so their logical bytes were excluded entirely. The query now sums every restore point for the destination's jobs (the destination is already known to be dedup-enabled and dedup mode is immutable per destination), so the ratio reflects real savings.
- **GC no longer deletes live data from large container/plugin dedup backups.** A container's dedup manifest references its volume file data only _indirectly_: each `__vol__<dest>` entry points at a sub-manifest, which lists the actual data chunks. GC's reachability set (`collectLiveManifestIDs`, used by both the daemon's `POST /storage/{id}/gc` and the `vault dedup gc` CLI) collected only the _top-level_ manifest IDs, and GC marks just the direct chunks of each live manifest – so the volume data chunks were never marked. Any pack containing only such chunks (i.e. every data-only pack of a backup larger than one 24 MiB pack) was swept, silently corrupting the backup; the next restore would fail with missing chunks. The live set is now expanded through a new `engine.WalkManifestClosure` that recurses into volume sub-manifests, so every reachable chunk is marked. Folder/plugin single-level backups were unaffected; small single-pack container backups happened to survive because their data shared a pack with a manifest chunk. Confirmed with a multi-pack regression test.
- **Deep and quick verify now work on multi-item dedup restore points and actually re-hash container volume data.** Verify keyed off `restore_points.manifest_id`, which is only set for _single-item_ dedup jobs; a multi-item job (e.g. a containers backup) stores per-item IDs under `metadata.item_manifests` and leaves `manifest_id` empty, so verify fell through to the classic per-file path and failed with _"no recorded file checksums in restore point metadata"_. Verify now detects a dedup restore point from either source, walks every item's manifest closure (including the nested volume sub-manifests), and in deep mode re-reads + re-hashes every leaf data chunk – previously even a single-item container deep verify only checked the top-level manifest's pointer chunks, not the file data. Quick mode stats the unique packs across the full closure.
- **Dedup (chunked) backups now honour container/folder path exclusions, matching the classic tar pipeline.** `ContainerHandler.BackupChunked` ignored the job's `exclude_paths` entirely: it never applied `shouldExcludeMount` (so a whole-mount exclusion like `/rootfs` was skipped) and never mapped per-volume globs into the chunk walk. A container that bind-mounts the host root (Glances, Telegraf, Netdata: `/ → /rootfs`) therefore had its **entire host filesystem** content-chunked into the dedup repo despite a `/rootfs` exclusion – slow runs, a bloated repo, and unrelated host files (`boot/`, `lib64/`, `mnt/cache/appdata/…`) appearing in the restore-point file list. The chunked path now reads `exclude_paths`, skips excluded mounts wholesale (recorded as skipped volumes), and passes volume-relative patterns through to the walk. `FolderHandler.BackupChunked` (used directly for folder/plugin dedup jobs and for each container volume) now applies the same `shouldExcludePath` filter the tar path uses – a matching directory is pruned (`SkipDir`) and never traversed. Classic tar backups were already correct; only the dedup path was affected.
- **Running dedup backups no longer display "-1%" in the Dashboard progress list.** The daemon emits `-1` as an "indeterminate progress" sentinel during the streaming chunk walk (total size isn't known up front). The per-item progress bar rendered this literally as a "-1%" label and a negative-width bar. Negative percent is now treated as indeterminate: the bar pulses at full width and the numeric label shows `···` until a real percentage arrives.
- **"Include in DB backup" toggle on the Storage page now persists.** Two coordinated bugs hid behind the toast. (1) `UpdateStorageDestination` did not include `backup_database_enabled` in its UPDATE clause, so the DB silently dropped the field. (2) The storage PUT handler decodes into a partial-patch struct that omitted the field, so the request body's value was thrown away before even reaching the DB. Both were corrected.
- **`retry_max_override` and `retry_delays_override` (job edit) + `retry_of_run_id` / `retry_next_at` (job runs) now serialise as native JSON `null` / number / string** instead of `{"Valid":false,"Int64":0}` wrapper objects. The override-retry input previously showed "[object Object]" with an "Invalid JSON" error because the form bound the wrapper struct directly. Backend struct fields are now pointer types (`*int64`, `*string`, `*time.Time`) so `database/sql` round-trips nullables transparently and the JSON encoder emits clean values.
- **Activity log details render duration as `1 min`, `2.0 s`, `7 min 10 s` etc.** instead of raw `60002ms` / `430s`. A new `formatDuration` helper in Logs.svelte handles both `duration_ms` and `duration_seconds` detail keys.
- **Retry policy delays are no longer a JSON textbox.** Both Settings → Retry Policy and Job edit → Override retry policy now use a friendly editor: preset dropdown (Default 15 m / 1 h / 4 h, Aggressive 1 m / 5 m / 15 m, Patient 1 h / 6 h / 24 h, Custom) plus per-row `[number] [unit ▾]` rows with + Add / × Remove. The override section adds a "Use global default" checkbox that hides the editor and emits an empty value (= NULL on save).

- **S3-compatible uploads (MinIO, MEGA, IDrive E2, Backblaze B2 via S3) no longer fail with `403 SignatureDoesNotMatch` when the job name contains spaces or other URL-reserved characters.** The aws-sdk-go-v2 + custom endpoint resolver + path-style combo has a signing-vs-sending URL-encoding asymmetry that breaks every PutObject and DeleteObject for keys containing reserved characters. TestConnection (HeadBucket) keeps passing because it has no path beyond the bucket – the "test passes, every upload fails" fingerprint. The S3 adapter now sanitizes each key path segment to the RFC 3986 unreserved set before sending to the SDK. Both Write and Read use the same translation, so existing backups continue to restore and new backups produce sanitized keys that all gateways accept (closes follow-ups on #88).
- **S3 PutObject no longer attaches a CRC32 SigV4 trailer that breaks S3-compatible gateways.** The 2026.05.02 fix set the global `RequestChecksumCalculation=WhenRequired` but the upload-layer client hard-codes its own CRC32 default, so the trailer was attached anyway. The S3 adapter now uses the stable `feature/s3/manager.Uploader`, which honours the global setting correctly. Multipart `PartSize` binding (640 GB → 10 TB per-object ceiling for large streams) is preserved.
- **Container backups for containers that bind-mount the host root (Glances, Telegraf, Netdata, cAdvisor, node-exporter with `/` → `/rootfs`) no longer recursively walk the host filesystem before the volume is skipped.** The 2026.05.01 fix moved the exclusion check above the per-volume backup branch, but the auto-compression-downgrade pre-scan still ran on the bind-mount source first – a full `filepath.Walk` of the host root. A Test Containers job that took 37 s before regressed to **14 minutes**. The exclusion check now genuinely runs first; the compression pre-scan only touches volumes that will actually be archived. Same job is back to 38 s.
- **`PUT /api/v1/storage/{id}` no longer destroys the destination when the caller sends a partial body.** The handler was decoding into a fresh struct and writing the whole row, so a request like `{"config":"..."}` blanked `name`, `type`, and `dedup_enabled` and orphaned every job pointing at the destination. It now loads the existing row, merges only the fields explicitly provided, and rejects attempts to change immutable fields (`type`, `dedup_enabled`) with HTTP 400.
- **`POST /api/v1/storage` no longer leaks the plaintext password / S3 secret key in its 201 response.** `Get()` redacted the config blob but `Create()` echoed the request body verbatim – credentials were visible in browser devtools' Network tab during Add Storage. Both `Create()` and `Update()` now re-fetch the persisted row and apply the same redaction.
- **`POST /api/v1/storage` now validates the type and config before persisting.** Previously accepted arbitrary types (`{"type":"bogus"}` was 201-ed) and empty configs that could never construct a working adapter. Both `Create()` and `Update()` now build the adapter up-front and return HTTP 400 on construction failure with the underlying error.
- **`POST /api/v1/jobs` and `PUT /api/v1/jobs/{id}` now include the persisted items in their response** so callers can chain on the server-assigned item IDs. Job fields stay at the top level for backwards compatibility (`result.id` still works).
- **`GET /api/v1/storage/{id}/jobs` returns the list of dependent jobs**, not just a scalar count. Response now includes a `jobs` array of `{id, name}` so the UI can show which jobs would be orphaned by a delete. `job_count` is preserved.
- **`GET /api/v1/storage/{id}/dedup-stats` no longer returns 500 on a freshly-created dedup destination** that hasn't run a backup yet. The Storage card now renders "0 chunks · 0 packs" instead of a broken-card state until real stats start flowing.
- **`GET /api/v1/jobs/{id}/restore-points/{rpid}/contents?item=…` now works on dedup restore points** instead of returning 500. The handler previously expected a per-item tar archive directory; dedup destinations don't have one. It now synthesizes the file list from the dedup manifest's per-file metadata so the restore-wizard file picker works for both classic and dedup restore points.
- **Recovery page no longer flags items as Unprotected when their owning job is disabled.** The recovery API correctly reports `has_restore_point: true` regardless of the parent job's `enabled` flag, but the Svelte page derived its own protected set from enabled jobs only, so disabling a schedule (a common manual-only workflow) made items appear unprotected even though their backups were intact. The page now derives protection from `has_restore_point` directly, matching the API. The Dashboard's matching logic was updated the same way.
- **Recovery plan step status now considers every item**, not just the first. The handler previously checked only `items[0]` to badge a step "ready" or "warning"; a step with one missing restore point but several intact ones was shown as ready. It now downgrades to "warning" if any item is missing.
- **Restore wizard file picker no longer hangs on "Loading…"** after expanding "Restore specific files". The per-item state was held in a `SvelteMap` whose value objects were mutated directly after an `await` boundary – SvelteMap doesn't propagate mutations across awaits, so the UI never received the `loading: false` flip. The picker now writes a fresh object reference on every transition.
- **Folder/Plugin Items wizard step no longer falsely flags every custom folder as "Not found".** The stale-detection check compared selected items against `/api/v1/folders`, which only returns engine-discoverable presets like the Flash Drive – so any user-added custom folder appeared "not found" even when the path was perfectly valid. A new `GET /api/v1/path-exists?path=…` endpoint does a safepath-validated `os.Stat`; the picker now async-checks every custom folder's path on mount and only flags it when the stat actually fails. The empty-state message was also rewritten to point users at the "Add Custom Folder" workflow instead of looking like an error.
- **Dedup stats endpoint now reports correct totals across daemon restarts** and from any goroutine. `Stats()` previously returned in-memory counters that only the writing process saw, so the Storage card showed zeros after a restart. It now reads totals from SQL aggregates and derives logical bytes from `restore_points.size_bytes` summed over the destination's live dedup restore points.
- **`GET /api/v1/jobs/{id}/history` and `/restore-points` return `[]` (not JSON `null`)** for jobs with no rows. Front-end code that called `.length` or `.map()` on the response was throwing.
- **`GET /api/v1/activity?limit=N` clamps `limit` to ≤ 1000** to prevent an authenticated caller (or misconfigured monitor) from OOM-ing the daemon by requesting a huge limit.
- **WebSocket origin patterns now cover the entire RFC 1918 `172.16.0.0/12` range** (172.16.x.x through 172.31.x.x). Previously only `172.16.*.*` was listed, so users on `172.17.0.0/16` (Docker's default network) through `172.31.x.x` never received progress updates.
- **Password inputs across Settings, Storage, Restore wizard, and Replication forms now declare appropriate `autocomplete` attributes** so browsers stop offering inappropriate suggestions and the verbose DOM warning on focus goes away.
- **Failed backup jobs no longer leave orphaned partial uploads at the destination.** When the upload retry loop exhausted (or hit a verify mismatch or context cancellation), the runner returned without cleaning up the per-item files it had already written, wasting remote quota and confusing the next run. It now best-effort deletes every partial file before surfacing the error.
- **WebDAV chunk uploads use exponential backoff with HTTP-status-aware retry classification.** Chunk PUTs retry on `423 Locked`, `409 Conflict`, `429 Too Many Requests`, any `5xx`, stall-watchdog timeouts, and transport errors (`100ms → 300ms → 1s → 3s → 8s`, 6 attempts). Permanent `4xx` failures (`401`, `403`, `404`, `413`, …) fail fast on the first attempt instead of consuming the full retry budget.
- **WebDAV uploads no longer buffer non-seekable backup streams into memory** or leave encryption goroutines alive after stalled retries. Bounded objects use `WriteStreamWithLength` so the fallback that copies unknown-length streams into RAM is avoided (closes #96).
- **Large WebDAV backups are split into manifest-backed chunks** instead of one monolithic PUT. Files larger than the configured WebDAV chunk size upload as independent fixed-size objects with per-chunk SHA-256 hashes and a manifest written last. Restore, verify, list, stat, and delete are manifest-aware while older single-file WebDAV backups remain readable (closes #97).
- **Importing dedup backups from another Vault instance now produces restorable restore points.** `manifest.json` written to storage didn't include per-item dedup manifest IDs, and the import path didn't read them either – so re-discovered dedup backups appeared in the UI but the restore would fail because the chunks were unreachable. `writeManifest` now embeds `item_manifests` for dedup runs, and `ImportBackups` reads the field back, persisting per-item IDs in the restore-point metadata and promoting the ID onto the row directly for single-item dedup jobs. Non-dedup imports are unchanged. Manifests written before this change still import as classic file-based restore points (no regression).
- **Dead code cleanup: `Server.Start`, `SettingsHandler.RestorationInfo`, `Client.GetJob`, `Syncer.SetHub`, `parseDomainDisks`/`domainDiskPaths`, and `decompressReader`/`fileCompressionExt` removed.** Each was either superseded by a context-aware variant, replaced by a content-based equivalent, or had no callers in the live tree.
- **Daemon now flushes the DB snapshot to USB flash after every config mutation, not just on startup/shutdown.** `Server.SetConfigChangeHook` stored the hook on the Server struct but never forwarded it to the per-handler `onConfigChange` fields, so every `notifyConfigChange()` call across the four CRUD handlers was a no-op. The Server now stashes references to all four handlers and propagates the hook. `StorageHandler` and `ReplicationHandler` gained the missing hook plumbing too – every Create/Update/Delete now triggers the flush.

### Security

- **Folder dedup restore now validates every manifest path against the destination root before writing.** `FolderHandler.RestoreChunked` joined every manifest entry to `destPath` with `filepath.Join`, which does not prevent `..` segments from escaping the target directory. A tampered manifest at the storage destination could therefore have caused the restore to write files outside the chosen recovery folder (CWE-22 / CodeQL `go/path-injection`). Every entry now goes through `safepath.JoinUnderBase`, which rejects any path that wouldn't stay inside `destPath`. Closes CodeQL alerts #32–#35.
- **Pack writer now bounds its pre-allocation size.** The pack-flush path allocated a buffer sized by `bufLen + footerLen + 4` without an explicit cap. In practice these values are bounded by `PackTargetSize` (24 MiB) plus one chunk's slop, but CodeQL `go/allocation-size-overflow` couldn't see that. An explicit ceiling (`PackTargetSize * 4`) is now enforced with a clear error if exceeded. Closes CodeQL alert #37.
- **Discord-webhook log redaction now anchors on the `https://` scheme prefix** so it only matches genuine webhook URLs, not arbitrary log text that happens to mention the substring `discord.com/api/webhooks/…`. Behavioural impact is nil for real logs (the existing test still passes) but the regex now satisfies CodeQL `go/regex/missing-regexp-anchor`. Closes CodeQL alert #36.

## [2026.05.02] - 2026-05-15

### Fixed

- **S3 / Backblaze B2 uploads of multi-GB objects no longer abort with `context deadline exceeded` mid-multipart (closes #95).** The S3 adapter previously routed every operation – including large multipart uploads via `transfermanager.Uploader` – through a single hardcoded 5-minute context (`ctxOp`). A real Immich-style folder backup to Backblaze B2 exceeded that ceiling well before the upload (and its in-flight `AbortMultipartUpload` cleanup) could complete, producing a cascading context-cancellation failure. Upload operations are now scoped to a separate, configurable deadline (`uploadTimeout`, default **240 minutes / 4 hours**) while metadata operations (Read / List / Stat / Delete / TestConnection) continue to use the existing 5-minute budget unchanged. A new optional `upload_timeout_minutes` field on the S3 storage config – surfaced in the Storage form as "Upload timeout (minutes)" under the existing advanced options – lets users tune the ceiling for very large files over slow links (set `0` to accept the 4-hour default; negative values are rejected at construction time).
- **Restored Docker containers now keep their port mappings – Unraid's "Container Port" and "LAN IP:Port" columns no longer go blank after a restore.** Container backups capture `Config.ExposedPorts` and `HostConfig.PortBindings` from `docker inspect`, but the restore path declared a local `portBindings` map and immediately discarded it (`_ = portBindings // avoid unused variable`) without ever populating it from the inspect data or assigning it to the new `container.HostConfig`. Restored containers were therefore created with zero exposed ports and zero host-port bindings, which is exactly what Unraid's Docker page renders as a blank port column. The user could "fix" the row by clicking Edit → Done because Unraid then rebuilds the container from the on-disk template XML, masking the bug. The restore engine now converts both maps into the typed `network.PortSet` and `network.PortMap` the Docker API requires (parsing keys with `network.ParsePort` and `netip.ParseAddr`, skipping malformed entries with a log line), and assigns them to `containerConfig.ExposedPorts` and `hostConfig.PortBindings` respectively. Empty/invalid `HostIP` values are left as the zero `netip.Addr` so Docker treats them as "bind on all interfaces", matching its own default. Restored containers now show their port mappings immediately, with no Edit→Done dance required.
- **Restored Docker containers now show their correct update status in the Unraid Docker Manager UI instead of "not available".** Unraid computes a container's "up-to-date" / "update available" badge by reading `RepoDigests[0]` from each image's metadata, but `docker load` (used during restore) does not populate `RepoDigests` – only `docker pull` does. As a result, restored containers showed "not available" and the "Check for Updates" button could not resolve a local digest, leaving the badge stuck. The container engine now captures each image's `RepoDigests` at backup time into a small `image_meta.json` companion file (alongside `image.tar*`), and the restore path uses that to re-seed `/var/lib/docker/unraid-update-status.json` with the recorded local digest after `ImageLoad`. The Unraid UI then resolves "up-to-date" or "update available" immediately, and "Check for Updates" works against the restored container. Verified end-to-end on Unraid against the "Test Containers" job: Grafana, Influxdb, and telegraf all flipped from "not available" to "up-to-date" after a fresh backup→restore cycle.
- **Restore now also performs a `docker pull` after `ImageLoad` to authoritatively populate `RepoDigests` for the restored image.** This handles the chicken-and-egg case where the source container's image itself had no `RepoDigests` at backup time (e.g. the image was previously restored from tar without ever being pulled, or the user is upgrading from a Vault version older than the `image_meta.json` capture), in which case the backup's `image_meta.json` recorded `repo_digests: null` and the prior `unraid-update-status.json` seeder had nothing to write. The pull is non-destructive – when layers already exist locally (the common case immediately after `ImageLoad`) Docker only fetches the manifest, which is exactly the metadata required. The freshly-pulled digest is then written directly into `unraid-update-status.json`, so the badge flips to "up-to-date" without depending on the backup's recorded metadata. If the daemon is offline or the registry is unreachable, the call fails silently and the path falls back to `image_meta.json`-based seeding. Verified end-to-end on Unraid: `nicolargo/glances:latest` (which had empty `RepoDigests` on the host from a prior tar-only restore) flipped from "not available" to "up-to-date" after restore-with-pull.
- **Container Path Exclusions now skip directory bind mounts at the volume level (closes #70).** The earlier fix (2026.05.01) only applied exclusion patterns to single-file bind mounts. Directory mounts – most notably the recursive `/` → `/rootfs` mount used by Telegraf, Netdata, cAdvisor, Glances, and Prometheus node-exporter – still entered the recursive walk and only filtered special-file inodes, so the engine eventually started archiving the host filesystem (including the array into itself) and the job hung indefinitely. Exclusion matching now runs once, up front, against every bind mount's container-side destination regardless of whether the mount is a file or a directory, mirroring the single-file behaviour the user reported as working. Verified end-to-end on Unraid with a real "Test Containers" job (Influxdb + Grafana + Glances + Telegraf, both Glances and Telegraf bind-mounting `/` → `/rootfs`): job completed in 37 s (4/4 items, 1.9 GB) with `engine: skipping volume / … matches exclusion pattern` in the daemon log, replacing a previous 13 m 37 s hang that failed at 2/4 items.
- **Compression setting now controls the actual on-disk archive format.** Previously the engine always emitted gzip-wrapped tar archives while the runner additionally wrapped the upload stream with whatever compression the user selected, so jobs configured for `zstd` shipped double-compressed `volume_*.tar.gz.zst` files and jobs configured for `None` still produced `.tar.gz`. The engine (`internal/engine/container.go`, `folder.go`, `plugin.go`) is now the single source of truth for archive compression and emits `.tar`, `.tar.gz`, or `.tar.zst` per `BackupItem.Compression`, while the runner's upload path no longer wraps the stream a second time. Restore auto-detects the format via magic bytes (`0x1f 0x8b` for gzip, `0x28 0xb5 0x2f 0xfd` for zstd, plain otherwise) and the engine looks up archives by trying `base`, `base+".gz"`, and `base+".zst"` in turn, so existing `.tar.gz` backups (and legacy double-wrapped `.tar.gz.zst` files via the runner-side `decompressStoredReader`) continue to restore correctly. Verified end-to-end on Unraid against the "Test Containers" job: `none` → `.tar`, `gzip` → `.tar.gz`, `zstd` → `.tar.zst`.
- **Restore wizard "Choose Version" step now shows the absolute date alongside the relative offset inline (closes #81 follow-up from @SebboGit).** The previous fix relied on a native `title` tooltip to surface the relative time on hover, but native browser tooltips were unreliable on the parent button row (Firefox in particular suppresses them when the `<span>` lives inside a `role="button"`/`cursor: pointer` ancestor). Both forms are now rendered together as `12 May 2026, 02:09 am · 7h ago`, giving an unambiguous absolute timestamp with the relative offset always visible – no hover required, works on touch.
- **Logs page no longer collapses expanded "Details" rows every 5 s during auto-refresh.** `loadLogs()` previously called `expandedIds.clear()` on every poll cycle and re-added only error rows, so any non-error row a user had manually expanded was wiped on the next refresh. The expanded set is now preserved across reloads, entries that have aged out of the visible window are pruned, and the auto-expand-error behaviour now tracks a separate "already auto-expanded" set so collapsing an auto-expanded error keeps it collapsed.
- **Failed backup jobs no longer leave orphaned partial uploads at the storage destination.** When `uploadStagedFiles` exhausted its 4-attempt retry loop (or hit a verify mismatch or ctx cancellation), it returned an error without cleaning up the per-item files it had already successfully uploaded, or the partially-written bytes from the failing item. This wasted remote-storage quota (especially painful on quota-bounded providers like Hetzner Storage Box) and made the destination directory look "half done" to the next run. The runner now performs best-effort `adapter.Delete()` on every known partial file before returning the error. Cleanup failures are logged but never mask the original upload error.
- **WebDAV uploads of multi-GB files no longer fail with `context deadline exceeded ... Client.Timeout exceeded while awaiting headers` (closes #83 follow-up from @SebboGit).** The WebDAV adapter previously called `gowebdav.Client.SetTimeout(60*time.Second)`, which maps to `http.Client.Timeout` – a single deadline that covers the **entire** request lifetime, including the upload body. A 20-container backup to Hetzner Storage Box repeatedly failed during the upload-retry loop (4× exponential-backoff attempts per item, all timing out at the same 60 s mark), eventually crashing the daemon. The fixed 60 s deadline is replaced with **phase-specific** `http.Transport` timeouts that do not bound body-transfer duration:

  - TCP dial 30 s, TCP keepalive 30 s
  - TLS handshake 30 s
  - Expect-Continue 5 s
  - Response headers 5 min (applies AFTER the body is fully sent)
  - Idle keep-alive 90 s
  - `http.Client.Timeout` left at 0 (unlimited) by default

  In addition, every upload reader is now wrapped in a stall watchdog: it records the timestamp of every successful `Read()` and aborts the PUT with `webdav: upload stalled` when no bytes flow for the configured window (default **300 s / 5 min**). Slow-but-progressing transfers of any size succeed; truly dead connections still fail promptly without depending on the OS keepalive.

- **Restore no longer fails with `invalid input: magic number mismatch` for backups produced by the new engine-side compression path.** After the compression refactor that made the engine the single source of truth for archive compression, the runner stopped transport-wrapping uploads but the restore path's `decompressStoredReader` still blindly applied `job.Compression` to every downloaded file. That caused plain artifacts like `config.json` to be force-fed into a zstd reader during the restore of any zstd-mode job, producing `downloading Test Containers/.../Glances/config.json: invalid input: magic number mismatch` and aborting the run at 0/N items. `decompressStoredReader` is now **content-based** – it peeks the first four bytes and only strips a layer when the leading bytes actually match the gzip (`0x1f 0x8b`) or zstd (`0x28 0xb5 0x2f 0xfd`) magic, ignoring both the filename extension and the job's compression setting. This still strips one transport layer from legacy double-wrapped backups while leaving newly produced plain files (`config.json`, `manifest.json`, `image.tar`) untouched. Verified end-to-end on Unraid: a fresh zstd backup of 4 containers (Influxdb + Grafana + Glances + telegraf, 575 MB) restored in 1 s with 4/4 items succeeded, replacing the previous 1-failed/0-done error.

### Added

- **Image metadata capture (`image_meta.json`) is now written next to each container's `image.tar*` during backup.** Stores `image_tag` and `repo_digests` so the engine can repopulate Unraid's docker `unraid-update-status.json` on restore (see Fixed). Old backups without this file fall back to current behaviour silently; the file is best-effort and never fails a backup.
- **Backup Size Trend chart on the History page is now coloured by backup target category.** Each run is rendered as a bar tinted by its dominant item type – Containers (blue), VMs (purple), Folders & Files (green), Flash (amber), Other (gray) – with a top-right legend that doubles as a category filter. The hover tooltip shows the category swatch alongside the run's size, date, and job name, making it easy to see at a glance whether a size spike came from a container-heavy run, a VM snapshot, or a folder backup. The linear-regression trend indicator (Growing / Stable / Shrinking) is preserved. Job categories are derived from the dominant `item_type` across each job's items, hydrated via parallel `getJob` calls when the History page loads.
- **Helper text under the Compression dropdown in the Job wizard.** Each option now surfaces a one-line trade-off summary so users can choose deliberately: `None` (fastest, zero CPU overhead, best for already-compressed media), `Gzip` (universal compatibility, moderate ratio/speed), `Zstd` (recommended; better compression than gzip and ~3–5× faster).
- **Two new optional WebDAV config fields exposed in the Storage form under "Advanced · Timeouts":**
  - `timeout_seconds` – overall hard ceiling on every WebDAV request including upload body. Default 0 = unlimited (recommended). Power users can set a value if they want a strict per-request cap.
  - `stall_timeout_seconds` – abort an upload if no bytes flow for this many seconds. Default 300 (5 min). Set to a negative value to disable the watchdog entirely.
- **Recommended-exclusion presets for host-mount monitoring agents and Docker-socket-consuming management containers.** Adds curated `ContainerExclusionPresets` entries for **Telegraf**, **Glances**, **Netdata**, **cAdvisor**, **Prometheus node-exporter**, **Scrutiny**, **Prometheus**, **Loki**, **VictoriaMetrics**, **Uptime Kuma**, **Watchtower**, **Diun**, **Dozzle**, **Autoheal**, **Dockhand**, and **docker-socket-proxy**, and enhances the existing **Portainer** preset to include `/var/run/docker.sock`. Telegraf and Glances now ship with `/rootfs`/`/hostfs`/`/var/run/docker.sock` (and friends) so the "Load recommended exclusions" button on the Container Path Exclusions step auto-populates the exact paths needed to prevent the recursive host-filesystem walk described in #70. The existing Svelte UI flow (`fetchContainerPresets()` → `GET /api/v1/presets/exclusions?image=...`) picks up the new presets automatically – no UI change required. Verified end-to-end on Unraid: clicking the button on the Test Containers job's Glances item populated `/rootfs`, `/var/run/docker.sock`, `/etc/os-release` (3 paths) and on the telegraf item populated `/rootfs`, `/hostfs`, `/var/run/docker.sock`, `/var/run/utmp`, `/run/udev` (5 paths), with both buttons flipping to the disabled "Recommended exclusions loaded" state.
- **`/var/run/docker.sock` and any other socket bind mounts are now auto-suggested as exclusions even when no image preset matches.** The presets API (`GET /api/v1/presets/exclusions`) now accepts an optional `container=<name_or_id>` query parameter alongside `image=`. When provided, the daemon inspects the live container via the Docker SDK and appends every bind-mount destination whose host source ends in `.sock` (e.g. `/var/run/docker.sock`, `/var/run/docker-shim.sock`) to the recommended exclusions, deduplicated against the static image preset list. The job editor's "Container Path Exclusions" panel now passes the container name, so any container mounting a runtime socket gets the exclusion auto-populated without anyone having to maintain a per-image preset entry. Inspect failures are silently ignored so the editor still falls back to the static image preset list.

### Changed

- Renamed the internal helper `shouldExcludeFileMount` to `shouldExcludeMount` and hoisted the call above the `IsDir()` dispatch in `ContainerHandler.Backup()` so it covers both directory and file mounts.

### Security

- **Bumped Go toolchain to 1.26.3 and `golang.org/x/net` to v0.53.0 to address two `govulncheck` findings.** `GO-2026-4971` (net: panic in `Dial`/`LookupPort` on Windows when handling NUL bytes – stdlib, fixed in Go 1.26.3) and `GO-2026-4918` (HTTP/2 transport infinite loop on bad `SETTINGS_MAX_FRAME_SIZE` – both stdlib and `golang.org/x/net`, fixed in Go 1.26.3 / `x/net` v0.53.0). `make security-check` (gosec + govulncheck + `go mod verify`) is now clean: 0 gosec issues, 0 vulnerabilities, all modules verified.

## [2026.05.01] - 2026-05-10

### Fixed

- **VM checkpoint creation now succeeds for cold (shut-off) backups.** Previously the engine called `DomainCheckpointCreateXML` against the persistent domain handle _after_ `restoreDomainState()` had already destroyed the transient paused session – libvirt rejected the call with "Operation not supported: cannot create checkpoint for inactive domain", so every cold incremental/differential ran without ever recording a parent checkpoint and silently fell back to producing a full-size qcow2. Checkpoints are now created against the live (paused) `backupDom` while the transient backup session is still active, and only after the bitmap is persisted to qcow2 does the runner tear the session down. End-to-end verified against a cold Fedora VM: full = 2.3 GB, incremental and differential = 192 KB on a no-change cycle.
- **Engine no longer reports "incremental" / "differential" when no parent checkpoint is recorded.** When the runner had no checkpoint metadata to pass (first run after a chain reset), the engine still produced a full-size backup but labelled the result `vm_backup_type: incremental`, which corrupted the chain bookkeeping. The fall-back logic now also covers the empty-parent case and downgrades `actualType` to `"full"` with a clear log entry before writing `vm_meta.json` and `result.Meta`.
- **VM incremental backups now actually capture only changed blocks.** Previously every "incremental" or "differential" run silently produced a full copy of each qcow2 disk: the engine emitted a regular libvirt push-mode backup XML with no `<incremental>` element, and the only "incremental" behaviour was a file-mtime gate that either (a) re-copied the whole disk anyway when the VM was running (mtime always advanced) or (b) skipped the disk entirely when the VM was cold (mtime unchanged after the previous backup) – silently losing data. The engine now creates a libvirt **checkpoint** (persistent dirty bitmap stored in qcow2) after each successful backup and references it via `<incremental>parent_checkpoint</incremental>` on subsequent runs, so libvirt streams only the dirty blocks since the parent checkpoint. Restore points record the checkpoint name in `vm_checkpoints` metadata; missing-parent or non-qcow2 disks fall back to a full backup with a clear log entry. Retention cleanup deletes orphaned libvirt checkpoints. (closes the broken VM Incremental / Differential modes)
- **Backups failing with `No space left on device` when staging to `/mnt/addons` (1 MB tmpfs).** The pool-discovery cascade in `internal/unraid/pools.go` selected any directory that exists under `/mnt/`, which on modern Unraid includes the `/mnt/addons` tmpfs mount. Pool discovery now reads `/proc/self/mountinfo` and rejects paths backed by `tmpfs`, `devtmpfs`, `ramfs`, `proc`, `sysfs`, `cgroup`, `cgroup2`, or `overlay` filesystems, so staging falls through to a real cache or array pool.

### Added

- VM **chain restore** for incremental and differential backups. The runner now stages each chain step into its own subdirectory and uses `qemu-img rebase -u` plus `qemu-img convert -O qcow2` to materialise a single self-contained qcow2 per disk before invoking the existing libvirt restore path. The qemu-img invocation lives in the runner package to preserve the engine package's pure-Go invariant.
- `BackupResult.Meta` channel for engine-specific metadata. The VM engine populates it with `vm_checkpoint`, `vm_backup_type`, and (when applicable) `vm_parent_checkpoint`, which the runner persists into restore-point metadata so future backups can locate their parent checkpoint and retention can clean up libvirt-side state.
- VM `vm_meta.json` sidecar now records `BackupType`, `Checkpoint`, `ParentCheckpoint`, and per-disk `Disks[]` entries (`Target`, `BackupFile`, `Format`) for diagnostics and forward compatibility.

### Changed

- Removed the legacy mtime-based `changed_since` gate from the VM backup path. Folder and container backups continue to use it. ZFS keeps its dataset-snapshot-based incremental flow unchanged.

### Verified

- Hot-VM backups end-to-end on a running Fedora guest: Full = 2.34 GB / 34 s (`vault-run-6`), Incremental from prior run = 3.5 MB / 1 s (`vault-run-7`), Differential from last full = 4.07 MB / 1 s (`vault-run-8`). All three runs created persistent libvirt checkpoints on the live (paused) backup session.
- VM **chain restore** end-to-end: restored Fedora from incremental RP 7 (parent = full RP 6) using `qemu-img rebase -u` + `qemu-img convert`. The runner staged both layers, materialised a single 2.18 GiB self-contained qcow2, the engine redefined the domain and auto-started it, and the guest kernel booted successfully (balloon driver active, vCPUs accumulating CPU time).

## [2026.05.00] - 2026-05-10

### Added

- **Defer remote upload mode** for slow-link backups (closes #77). New per-job toggle "Defer remote upload until all backups complete" stages every container backup to local disk first, restarts all containers as soon as staging is done, then streams the staged archives to the remote destination in a second phase. Containers go offline only for the (fast) local backup window, while the (slow) remote upload runs while every service is back online. The toggle is disabled when the destination is local (no benefit) and is automatically gated behind a non-local `dest.Type`. Per-file uploads are now retried up to 3 times with exponential backoff (5s → 30s → 2m), recovering automatically from transient remote-storage failures that previously failed entire jobs. WebSocket `backup_phase`, `item_staged`, and `item_upload_start` events drive a STAGING / UPLOADING phase indicator in the Backup Progress panel. Schema migration adds a `defer_remote_upload` column to `jobs` (default off). v1 scope: containers only – VM/folder/plugin/zfs items continue to upload inline.
- WebDAV storage backend (closes #83). Stateless HTTP-based backup target that avoids per-user concurrent-connection limits seen on managed SFTP/SMB providers. Supports Basic and Digest auth (negotiated automatically), optional self-signed TLS, and an optional base path. Compatible with Nextcloud, ownCloud, Synology WebDAV, and any RFC 4918 server.
- S3 / S3-compatible storage backend (closes #88). Built on AWS SDK v2 with a reusable, connection-pooled client. Works with AWS S3, Backblaze B2, MinIO, Cloudflare R2, and Wasabi via configurable endpoint and force-path-style options. Uses the SDK's manager.Uploader for streaming uploads of arbitrarily large archives without buffering to disk.

### Changed

- Restore wizard "Choose Version" step, the Restore page restore-point list, the Job History timeline, the Dashboard Recent Activity panel, and the Logs page now show **absolute timestamps** (e.g. `Apr 21, 2026, 21:22`) as the primary label on each row, with the relative form (`48m ago`, `2d ago`) preserved as a hover tooltip. This matches how Veeam, restic, and Time Machine present restore points and aligns with established UX guidance: when the user is matching a backup to a remembered point in time ("this was working fine until 17 April"), an absolute date is far easier to scan than mentally subtracting a relative offset (closes #81)

### Fixed

- S3 storage adapter requests now correctly include the bucket name in the URL when a custom endpoint is configured (e.g., MinIO, Backblaze B2, Cloudflare R2, Wasabi). The custom `EndpointResolverV2` previously returned the bare endpoint URI, which suppressed the AWS SDK v2's automatic bucket injection – every PutObject / GetObject / HeadBucket request landed on the root path and the server responded with `NoSuchBucket`. The resolver now injects the bucket into the URL path (path-style) or hostname (virtual-host style) itself, matching what the SDK does for the default AWS resolver. Confirmed end-to-end against MinIO via the new `make test-cloud-storage` smoke test (closes #88)
- Add Storage modal: switching between storage types (SFTP/SMB/NFS → Local Path, etc.) now correctly tears down the previous type's fields. Previously, fields from the prior selection could persist after a type change due to Svelte 5 reusing DOM input nodes across the dynamic `{#if}` branches. Wrapped the dynamic config block in `{#key form.type}` so the entire field subtree is recreated on every type switch
- Pool drive detection no longer falsely reports "No cache drive detected" when `/mnt/cache` exists as an unmounted directory or when the user's pool is named something other than `cache`. `unraid.PreferredPool()` now consults `/proc/self/mountinfo` (via the existing `IsMountedPool()` helper) and returns the first **mounted** pool from discovery instead of returning `/mnt/cache` whenever the directory is present. `checkCacheMount()` likewise uses `IsMountedPool()` rather than the previous "directory non-empty = mounted" heuristic, so empty-but-mounted pools are correctly recognised as available for hybrid mode. Daemon startup also now logs every discovered pool with its mount status to make this diagnosable from `/var/log/syslog` (closes #69)
- New / Edit Job wizard no longer freezes on the second step when accessed over plain HTTP (e.g. `http://<server>:81/plugins/vault/ui/...`). The Tooltip component called `crypto.randomUUID()` unconditionally, but that API is only available in secure contexts (HTTPS or `localhost`); on plain HTTP, Firefox throws `TypeError: crypto.randomUUID is not a function`, which crashed every wizard step that mounts new tooltips (Schedule / Details / Advanced) while the stepper indicator still advanced. Tooltip now generates its fallback id with a `Math.random()`-based path when `crypto.randomUUID` is unavailable. The same fix also restores the SMB/CIFS Username/Password fields and the Settings page, which previously failed to render in Brave / Edge / Firefox over plain HTTP for the same reason. Closes #67, closes #82
- Importing backups from a storage destination now restores the full job and per-item configuration, not just the job name and encryption type. The on-disk `manifest.json` is now versioned (v2) and persists per-item rows (`name`, `type`, `id`, `settings`) plus job-level settings (`backup_type_chain`, `retention_count`, `retention_days`, `container_mode`, `vm_mode`, `notify_on`, `verify_backup`). The Storage → Import flow uses these fields to recreate Vault's `job_items` rows so the restore wizard immediately lists each backed-up container/VM/folder. For older manifests without an `items` array, item names are inferred from `item_sizes`; appdata.backup imports create a single container item per file. Closes #75
- Restore points, Dashboard Protection Status, and the Disaster Recovery plan no longer disappear when a job's schedule is disabled. Protection is now derived from whether items have actual restore points on disk, not from the `enabled` schedule flag – so disabling a schedule (e.g. for a one-off / manual-only backup workflow) keeps already-backed-up items visible and protected. Affects `GET /api/v1/health/summary` (`protected_items` / `protection_pct`), `GET /api/v1/recovery/plan`, and the Restore page job picker (closes #76)
- Container backups no longer fail with `archive/tar: sockets not supported` when a container has a Unix domain socket bind-mounted (e.g. Dockhand mounting `/var/run/docker.sock`). The engine now (a) auto-skips bind mounts whose source is a non-regular inode (socket, named pipe, device, irregular) with a clear `unsupported inode type` skip reason, and (b) honours user-defined Container Path Exclusions for **file**-based bind mounts using the same pattern semantics as directory mounts – exact paths, parent directories, basenames, and globs (`*docker.sock*`, `*.sock`) all work as documented in the UI hint. Previously the file-mount branch ignored the exclusion list entirely (closes #70)
- Stop and Restart buttons on Settings → Vault no longer fail with `Vault service control failed (HTTP 403)`. The plugin's `control.php` was performing a redundant CSRF check, but Unraid's web framework already validates `csrf_token` at the gateway and **strips it from `$_POST` before forwarding to PHP** – so the in-script comparison always saw an empty token and returned 403. The redundant check has been removed; the gateway CSRF validation plus the POST-method requirement still protect the endpoint (closes #71)
- Eliminated the dual-scrollbar layout bug on the Vault web UI Settings page (and any other tall page). `html`, `body`, and `#app` are now locked to the viewport height with `overflow: hidden`, so the SPA's `<main>` is the only scroll surface – the page's left navigation can no longer scroll out of view (closes #73)
- Service Control on the Vault settings page no longer falsely reports "STOPPED" when a Stop/Restart action fails. The Stop and Restart buttons now use a conservative fallback (preserve the pre-action state on errors), surface an inline error message when the request fails or the rc script exits non-zero, and confirm the real outcome by polling the daemon after the action. The PHP `is_running()` helper now consults `/api/v1/health` (the same authoritative check used at page load) and only falls back to the PID file when the health endpoint is unreachable, so post-action status agrees with what the user sees on refresh (closes #71)
- Plugin upgrades now stop the running Vault daemon before `upgradepkg --install-new` and restart it afterwards, so users get the new binary without needing to reboot Unraid. User configuration (`vault.cfg`), the database (`vault.db`), and sealed credentials under `/boot/config/plugins/vault/` are preserved across upgrades (closes #72)
- Settings and configuration are no longer lost on plugin upgrade. In hybrid mode the daemon now refreshes the USB safety-net (`/boot/config/plugins/vault/vault.db.backup`) immediately after a successful restoration at startup, so the recovery chain (configured snapshot → default cache snapshot → USB backup) always has a current entry – even if a previous daemon shutdown was unclean. Combined with the graceful pre-upgrade stop, this guarantees a fresh-database fallback can no longer happen silently during an upgrade (closes #74)
- **Storage adapter durability:** `LocalAdapter`, `SFTPAdapter`, and `SMBAdapter` `Write()` now perform a checked `Sync()` (where supported) plus a checked `Close()` and remove the partial file on any error, instead of relying on a `defer f.Close()` whose error was swallowed. Previously a write that failed mid-stream – or a final `Close()` that returned an error from a buffered remote SMB/SFTP server – would leave a truncated file on the destination and report success to the caller.
- **Database restore endpoint hardening:** `POST /api/v1/storage/{id}/restore-db` now validates `storage_path`, rejecting empty values and any payload containing `..`. The handler also propagates errors from closing the live DB, the source temp file, and the destination DB file – and now `Sync()`s the destination before declaring success, removing the partial file on any failure. Previously these errors were silently discarded.
- **Health score rounding:** `GET /api/v1/health/summary` now rounds the weighted health score to the nearest integer instead of truncating, so a 99.6% score displays as 100 rather than 99.
- **Job history input validation:** `GET /api/v1/jobs/{id}/history` now returns HTTP 400 when `limit` is non-numeric or less than 1 instead of silently falling back to the default of 50.
- **Frontend listener registration:** the hash-based router and theme module now guard against duplicate `hashchange` and `prefers-color-scheme` listeners under hot module reload, eliminating dev-mode listener leaks.
- **SFTP port input validation:** the Storage modal `port` field now enforces `min=1`/`max=65535`, preventing accidental zero or negative values being stored.
- **Command palette error visibility:** `CommandPalette.svelte` now logs `listJobs` / `listStorage` / `runJob` / `testStorage` failures via `console.error` instead of swallowing them silently, making palette malfunctions diagnosable from devtools.
- **S3 List timeout consistency:** `S3Adapter.List()` now uses the shared `ctxOp()` helper instead of a divergent hardcoded 10-minute timeout, matching every other S3 operation.
- **Request logger guidance:** added an explicit comment in `internal/api/middleware.go` enumerating which authorization headers must be redacted if header logging is ever added (`Authorization`, `X-API-Key`, `Cookie`, `Set-Cookie`, `Proxy-Authorization`), to prevent accidental credential leaks in future changes.
- **Emergency-kit download race:** `Settings.svelte` now defers `URL.revokeObjectURL()` for one second after `a.click()` so slow disks/browsers don't lose the blob URL before the download starts.
- **Missing dynamix.cfg log warning:** `detectTimeFormatFromPath()` now logs a warning when reading `/boot/config/plugins/dynamix/dynamix.cfg` returns an unexpected error (anything other than "file not found"), so silent fallbacks to `auto` are no longer invisible.

## [2026.04.00] - 2026-04-16

### Added

- "Apply" button on the Temporary Work Area custom location input for consistency with the Database Location pattern
- GitHub Sponsors link in the About Vault section on the Settings page
- CORS middleware (`go-chi/cors`) restricting cross-origin requests to `*.myunraid.net`, `localhost`, and `127.0.0.1` origins only (OWASP A01)
- IP-based rate limiting (`go-chi/httprate`) on auth-sensitive endpoints: encryption verify (10 req/min), API key generate/rotate (5 req/min) (OWASP A05/A07)
- Auto-seal migration on daemon startup: legacy plaintext `encryption_passphrase` values are automatically sealed with the server key and the plaintext is cleared (OWASP A02)
- `Cache-Control: no-store` header on `GET /api/v1/settings/encryption/passphrase` to prevent caching of sensitive passphrase responses (OWASP A02)
- Remote Vault API Key field on the Add/Edit Replication Target form – allows users to enter the shared API key for authenticating with a remote Vault server during replication sync
- Replication sync and test-connection now use the configured API key (via `X-API-Key` header) when connecting to authenticated remote Vault instances
- Test Connection in the replication modal now always performs a live connectivity check against the remote Vault server, verifying the URL is reachable and the server is healthy
- API key management: generate, reveal, rotate, copy, and revoke a shared API key from Settings > Security for authenticating external integrations (Home Assistant, replication) – key is stored sealed (AES-256-GCM) and verified via bcrypt
- Settings > Security > API Access card showing key status, reveal/copy, rotate, and revoke controls with confirmation dialog
- `X-API-Key` header support in the replication client for authenticated cross-server sync
- `api_key` column on `replication_sources` table for storing per-source API keys
- ZFS zpool support for database location: the path browser now includes ZFS pool mountpoints when browsing for custom database snapshot locations via `include_zfs` query parameter (closes #50)
- ZFS zpool support for temporary work area: NVMe-backed ZFS zpools are automatically detected at daemon startup and prepended to the staging cascade, giving them the highest priority for backup assembly (closes #51)
- `ListNVMePools()` method on `ZFSHandler` to discover zpools composed entirely of NVMe devices
- `ListZFSMountpoints()` method on `ZFSHandler` to enumerate all accessible ZFS dataset mountpoints
- `PrependCachePaths()` function in `tempdir` package to inject high-priority staging paths at runtime
- `BrowseHandler.SetZFSLister()` for pluggable ZFS mountpoint discovery in the browse API
- Updated Settings page text to mention ZFS zpools as available locations for database and staging
- `internal/unraid` package with `DiscoverPools()`, `PreferredPool()`, and `IsMountedPool()` for dynamic Unraid pool detection – replaces hardcoded `/mnt/cache` references across the codebase (closes #49)
- Contextual tooltips across Settings, Jobs, Storage, and Replication pages – reusable `Tooltip.svelte` component with hover/click-to-toggle, viewport-aware positioning, keyboard dismissal, and full ARIA accessibility (closes #34)
- Enriched activity logs with contextual details for troubleshooting: backup started/completed and restore completed entries now include job name, backup type, storage destination, duration, and size; per-item container health check results are logged individually under a new "health" category; stop_all health check summary includes aggregate counts (containers checked/healthy/unhealthy) (closes #30)
- "Health" category filter on the Logs page to isolate container health check entries
- Smart formatting for activity log detail badges: backup types are capitalised, durations show unit suffixes, byte sizes are human-readable (e.g. 2.2 GB), and null values are hidden
- Diagnostic bundle download: `GET /api/v1/settings/diagnostics` endpoint and "Download diagnostics bundle" button on the Settings page generates a ZIP containing system info, database details, storage destinations, job configurations, recent run history, and activity logs with a unique correlation ID for support workflows (closes #29)
- `internal/diagnostics` package with collector, ZIP packager, and comprehensive redaction for sensitive data (passwords, API keys, tokens, webhook secrets, inline URL credentials)
- `ListRecentRuns(limit)` database method for fetching recent job runs across all jobs
- Purge activity logs: `DELETE /api/v1/activity` endpoint and "Purge" button on the Logs page with confirmation dialog to permanently delete all activity log entries (closes #32)
- Purge job run history: `DELETE /api/v1/history` endpoint and "Purge" button on the History page with confirmation dialog to permanently delete all job run records (closes #32)
- `PurgeJobRuns()` database method for bulk deletion of job run history; activity log purge reuses `DeleteOldActivityLogs(0)` to clear all entries
- Job run history purge actions are logged in the activity log with the count of deleted records
- Cancel API endpoint `POST /api/v1/jobs/{id}/cancel` to abort a running backup job (closes #28)
- Cancellable context propagated through the entire backup pipeline: Runner → engine handlers → tar/copy I/O operations
- 4-hour job timeout with automatic cancellation via `context.WithTimeout`
- Stall detection: warns after 30 minutes of no progress, auto-cancels after 2 hours of inactivity
- `cancelling` field added to runner status for real-time UI feedback
- `job_cancelling` WebSocket event broadcast when cancellation is requested
- "cancelled" job run status with descriptive log messages (user-initiated vs timeout)
- Context-aware `contextCopy` helper that checks for cancellation every 32 KiB during file I/O
- `ctx.Err()` checks in `filepath.Walk` callbacks to abort directory traversal on cancellation
- Backup target category toggles in Settings → General: independently enable/disable tracking for Containers, Virtual Machines, and Flash Drive; disabled categories are excluded from protection status on the Dashboard and readiness metrics on the Recovery page (closes #20)
- Three new settings keys (`container_backup_enabled`, `vm_backup_enabled`, `flash_backup_enabled`) with `"true"` defaults in the settings API
- Monthly and yearly scheduling now support "First day of month" and "Last day of month" options in the schedule builder UI; last-day jobs use a daily-check pattern on the backend with an `isLastDayOfMonth()` guard so they fire correctly on months of any length (closes #15)
- Unraid display time format is now detected from `dynamix.cfg` and injected into the runtime config, allowing the UI to honour the user's 12-hour or 24-hour preference
- Go daemon (direct-access mode) now injects `window.__VAULT_RUNTIME_CONFIG__` into the SPA HTML, ensuring time format detection works when accessing Vault directly on port 24085 without the PHP proxy
- `getTimeFormat()` and `getHour12()` helpers added to `runtime-config.js` for locale-aware time rendering
- `formatDate()` utility now used consistently for all date/time display in the Storage and Settings pages

### Changed

- Storage form: added tooltips on SFTP Remote Path, SMB Share, NFS Export Path, and NFS Base Path to clarify the distinction between fields that look similar (e.g. export vs sub-path within mount)
- Replication target form: API key field is now required (marked with asterisk, form submit blocked without it); "Test Connection" is blocked if no API key is entered; warning callout directs users to generate a key on the remote server under Settings → API Access
- Removed the "Target Type" dropdown from the Replication target form – only "Remote Vault Server" is supported
- Removed the Fallback Locations collapsible section from the Temporary Work Area on the Settings page to reduce clutter
- Removed the WebSocket status row and Reconnect button from Server Information on the Settings page
- Removed the WebSocket/Polling status indicator from the sidebar footer
- Renamed "Staging Directory" section to "Temporary Work Area" with descriptive subtitle explaining its purpose (closes #13)
- Replaced "SSD Cache (automatic)" label with "Using SSD cache for fast backup processing" and "Custom override" with "Custom location"
- Renamed "Custom Path (optional)" to "Custom Location" with description: "Override the automatic location. Use this if you want backups to be assembled on a specific drive."
- Renamed "Cascade order" to "Fallback locations" with description: "Vault tries each location in order and uses the first available one."
- Updated Database Location subtitle to explain that Vault's database tracks jobs, schedules, and restore points
- Replaced "Hybrid (RAM + SSD snapshots)" with "Hybrid – runs in memory for speed, saves to SSD periodically"
- Renamed "Working" to "Active database" with tooltip explaining hybrid mode operates from RAM
- Renamed "Snapshot" to "Saved copy", "Last snapshot" to "Last saved", and "Snapshot size" to "Saved copy size"
- Renamed "Custom Snapshot Path (optional)" to "Custom save location" with description: "Choose where the persistent database copy is stored. Defaults to SSD cache."
- Enhanced USB warning to suggest adding a cache drive or setting a custom save location
- Simplified Backup Targets subtitle to "Select what Vault should monitor. Disabled items won't show as unprotected on Dashboard or Recovery."
- `engine.Handler` interface now accepts `context.Context` as the first parameter for `Backup()` and `Restore()`
- All engine handlers (Container, VM, Folder, Plugin) updated to accept and propagate context
- `Runner.backupItem()` now receives and passes context to engine handlers
- Vault database backup now writes to a centralized `_vault/vault.db` path at the storage root instead of inside each job run directory, eliminating duplicate database copies across backup jobs
- Import Backups "Restore Full Database" section now shows a single "Vault Database" entry with the backup date instead of listing individual job names

### Removed

- Removed Google Drive and OneDrive replication support – only Remote Vault Server replication is now supported
- Removed OAuth infrastructure (client credentials, build-time ldflags, callback handlers) for cloud storage providers

### Fixed

- Fixed job creation wizard step indicator scrolling out of view on tall steps (e.g. step 3 with many schedule and storage fields) – the step indicator is now pinned in a non-scrolling band below the modal title, always visible regardless of scroll position
- Fixed path browser breadcrumbs showing double slashes (e.g. `//mnt` instead of `/mnt`) when browsing server paths for storage and database locations
- Added per-restore-point deletion: each restore point in the Restore wizard now has a trash button (two-click confirm) that deletes both the backup files from storage and the database record – closes the user request for "delete a backup without deleting the job"
- Added subfolder field to the Import Backups modal on the Storage page – lets users point the scanner at a specific subdirectory when their AppData Backup archives are not at the storage root (e.g. `appdata-backups/`)
- Fixed AppData Backup flash-backup detection to match any `<hostname>-<date>.zip` file instead of only `cube-*.zip` – works for systems named tower, unraid, or any other hostname
- Fixed Backup Size Trend chart showing wildly incorrect percentages (e.g. +1120%) when multiple jobs are visible – switched from last-point comparison to linear regression; mixed-job views now show a directional label (Growing/Shrinking/Stable) instead of a misleading number, while single-job filtered views still show the exact percentage
- Verified sequential job execution: 3 jobs queued simultaneously (Jackett, Mosquitto/Tailscale, Fedora VM) all completed in sequence without stalling – the reported "stops after 2 backups" issue does not reproduce on the current codebase
- Fixed missing `getAPIKeyStatus`, `generateAPIKey`, and `revokeAPIKey` methods in the API client (`api.js`), which caused a console error on every Settings page load and always showed "No API key configured" regardless of actual state
- Fixed undefined `bg-accent`/`text-accent` Tailwind v4 tokens on the "backup" type badge in History run rows – replaced with `bg-vault/15 text-vault` so the badge is now visible in both light and dark modes
- Added `aria-pressed` state to all filter/segmented-control buttons in History and Logs pages, and wrapped filter groups in `role="group"` with descriptive `aria-label` for screen-reader usability
- Added `aria-current="page"` to sidebar navigation and mobile bottom-nav buttons so the active page is announced by screen readers
- Added `aria-label` to the search input on the History page
- Changed mobile bottom-nav "More" button icon from a gear to a three-dots ellipsis, matching the standard convention for overflow menus
- Added an active indicator dot beneath the current page icon in the mobile bottom navigation bar
- Scoped the `html` theme transition (`background-color`/`color`) inside `@media (prefers-reduced-motion: no-preference)` to respect the OS reduced-motion accessibility setting
- Added scroll-fade gradient hint on mobile Dashboard stats row to indicate horizontal scrollability
- Replaced non-standard checkbox in Logs page auto-scroll control with a proper `role="switch"` toggle button matching the design pattern used throughout the Settings page
- Removed duplicate action buttons on Jobs, Storage, and Replication pages – top-right header button now only appears when items exist, eliminating redundancy with the empty-state center button
- Fixed nil pointer dereference on startup: `BrowseHandler` was not assigned to the server struct in `setupRoutes`, causing a panic when `SetZFSLister` was called
- Fixed `sync.Mutex` deadlock in runner: `RunJob` already holds `r.mu`, removed redundant lock around `snapshotManager` access in snapshot save
- Clipboard copy in Settings UI now handles errors with an error toast instead of silently failing
- Middleware test `SetSetting` calls now check for errors to prevent misleading test results
- API error responses no longer leak internal error details to clients; all 500 responses now return a generic "internal server error" message while the real error is logged server-side (OWASP A09)
- SMB storage adapter now enforces a 30-second dial timeout via `context.WithTimeout` to prevent indefinite connection hangs
- SFTP adapter logs a warning when falling back to `InsecureIgnoreHostKey` due to missing host key verification configuration
- Runner `SetSnapshotManager` write is now protected by mutex to prevent a data race with concurrent job execution
- SMB `smbReadCloser.Close()` now uses `errors.Join` to surface file/share/session close failures instead of silently discarding them
- NFS adapter `unmount()` now logs errors from `umount` and temp directory removal instead of silently discarding them
- Mirrored SSD cache pools (e.g. `/mnt/cache2`, `/mnt/cache3`) not detected under Settings → Database Location and Temporary Work Area – pool discovery now scans `/mnt/` at runtime using exclusion-based filtering (closes #49)
- Browse handler filesystem roots now dynamically discover all pool drives instead of relying on a hardcoded "Cache" entry
- Path traversal vulnerability (CWE-22) in `SnapshotManager` – added `validateSnapshotPath` defense-in-depth validation to `SaveSnapshot`, `SetSnapshotPath`, `RestoreFromSnapshot`, `RestoreFromPath`, `SetUSBBackupPath`, and `saveUSBBackup` with `..` component rejection before `filepath.Clean` + `filepath.Abs` normalisation; uses `filepath.ToSlash` for cross-platform traversal detection (closes #27, closes #28)
- Data race in `SaveSnapshot` reading `snapshotPath` without mutex protection – now reads the field under lock consistently with other accessors
- Diagnostics collector hybrid-mode detection now checks that the preferred pool is mounted (matching daemon startup behaviour) instead of only checking directory existence
- CSRF token validation added to `control.php` for state-changing actions (start, stop, restart, reset-config) – token sourced exclusively from POST
- IPv6 loopback (`::1`) bind address now connects via `[::1]` instead of `127.0.0.1` in the PHP proxy, fixing connectivity when the daemon binds exclusively to IPv6
- Bind-address validation in `apply.sh` and `rc.vault` now uses `grep -F` (fixed-string) to prevent regex wildcard matching of IPv4 dots, and `apply.sh` accepts IPv6 loopback/wildcard (`::1`, `::`)
- `apply.sh` no longer sources the config file directly – safely extracts only the `BIND_ADDRESS` key via grep/sed to prevent arbitrary code execution from user-editable config
- `apply.sh` now checks `sed -i` exit status and aborts with an error if the config update fails
- INI sanitisation in `control.php` now strips backslashes in addition to quotes and newlines, preventing backslash-escape attacks on INI quoting
- Tooltip clipping when positioned near viewport edges – switched from `position: absolute` to `position: fixed` with JS-calculated viewport coordinates and horizontal clamping
- Container path exclusion presets now load correctly when Vault runs behind the Unraid web proxy; `fetchContainerPresets()` uses `buildApiRequest()` instead of raw `fetch()` to route through the authenticated proxy endpoint (closes #11)
- Stuck backup jobs can no longer run indefinitely – timeout and stall detection ensure jobs are always bounded (closes #28)
- Time format detection now falls back to `[notify][time]` in `dynamix.cfg` when `[display][time]` is absent, fixing detection on Unraid 7.x where the time format preference is stored in the notification settings section
- Unraid Settings/Vault page was blank due to duplicated PHP code in `api.php` causing a syntax error; removed the corrupted duplicate block to restore the service control panel, Web UI button, and port/binding configuration
- SMB and SFTP storage adapters now honour the "Path" field: frontend forms send `base_path` matching the backend struct, and adapters accept the legacy `path` JSON key as a fallback for backward compatibility (closes #25)
- Job deletion with "Delete Backup Files" now properly removes empty directories after deleting their contents, fixing the issue where backup files and directories were left on Local and SMB storage (closes #26)
- SMB adapter `Write()` now propagates `MkdirAll` errors instead of silently ignoring them
- `ItemPicker` selected-items map wrapped in `$state()` to ensure Svelte 5 reactive tracking (closes #22)
- Items deleted from Unraid (containers, VMs, folders, plugins) can now be removed from backup jobs via the new remove button in the Backup Order list; stale items that no longer exist on the system are visually flagged with a "Not found" warning indicator (closes #24)
- Storage form "Save" button now guards against double-submission with a `saving` flag and shows a "Saving…" state while the request is in flight
- Container volume backups now skip Unix sockets, character/block devices, and named pipes instead of failing with "sockets not supported" errors; affected containers (e.g. those mounting `/var/run/docker.sock`) will complete successfully with a log entry for each skipped special file (closes #5)
- Monthly schedule day picker now shows all 31 days instead of only days 1–28; previously `Array(27)` omitted days 29, 30, and 31 (closes #9)

## [2026.03.02] - 2026-03-19

### Added

- Cleaned up documentation.

### Fixed

- Tailscale enabled containers backups failing.
- UI/UX fixes and polish.

## [2026.03.01] - 2026-03-18

### Added

- MCP tools for plugin discovery and runner status
- Restore-point chain health annotations in the API and MCP restore-point listings

### Changed

- MCP health output now includes version and mode, aligned with the REST `/health` response
- README refreshed to document the current REST API, MCP transports, and tool coverage
- `make verify` now exercises MCP streamable HTTP via the official Go SDK client
- Release packaging now targets `.txz` bundles with SHA256 verification and release automation updates the PLG checksum accordingly
- The PLG now advertises `project` and `readme` metadata and prunes stale cached plugin bundles during install

### Fixed

- Restore-point docs now reflect chain health and retention-preserved parents
- Repository URLs now point at `ruaan-deysel/vault`
- UI Fixes

## [2026.03.00] - 2026-03-02

### Added in 2026.03.00

- Full backup/restore engine for Docker containers, libvirt VMs, and folders
- Storage backends: Local, SMB, NFS, SFTP, NFS
- Cron-based job scheduling with retention policies
- Svelte 5 web UI with real-time WebSocket progress
- API key authentication and TLS support
- Encrypted storage credentials (AES-256-GCM sealed passphrase)
- Replication: sync restore points to remote Vault instances
- Job duplication with one-click copy
- Mobile-responsive bottom navigation bar
- Pull-to-refresh on Dashboard and History pages
- Theme cycle keyboard shortcut (Ctrl+Shift+L)
- Aria-labels on all icon-only action buttons
- Backup size trend chart (filters to completed runs only)
- Ansible-driven build/deploy/verify pipeline
- Proper Unraid plugin bundle pattern with MD5 verification
- GitHub Actions release workflow with automatic PLG MD5 update

### Fixed in 2026.03.00

- Backup trend chart no longer includes failed runs with partial sizes

## [0.1.0] - 2025-01-01

### Added in 0.1.0

- Initial release
- Docker container backup and restore (full image + config + appdata)
- VM backup and restore (live snapshot + cold backup)
- Storage destinations: Local, SMB, NFS, SFTP, NFS
- Full, incremental, and differential backup types
- Job scheduling with retention policies
- Web UI with Dashboard, Jobs, Restore, Storage, History, Settings