Add a Proxmox Backup Server integration: datastore/snapshot verification status
Proxmox VE already shows whether the last vzdump push to PBS succeeded, but has no visibility into PBS's own backup verification, GC/prune health, or host status. This adds PBS as its own integration (own adapter, page, nav entry, and Dashboard widget) that reads datastore usage and, for every stored snapshot, its verification state directly from PBS. A new daily check (mirroring the existing Proxmox backup-failure check) notifies when a snapshot has failed verification or a datastore couldn't be read, with its own toggle in Settings -> Notifications and its own maintenance-window silencing. Not verified against a live PBS instance — built from PBS's published API docs and a scratch test against a mocked PBS server exercising the adapter's parsing and auth-header format (PBSAPIToken uses a colon separator, unlike PVE's PVEAPIToken which uses =). See INTEGRATIONS.md for details and the "not verified" caveat. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
1 parent
70ba60c7da
commit
df2a5ce42b
24 files changed
+897
-13
No files matched your search
@@ -79,6 +79,31 @@ the dashboard views themselves load fine.
|
||||
metrics endpoint only exposes current status, not a monitor's scheduled start/end time, so this reflects
|
||||
what's in maintenance right now rather than mirroring Uptime Kuma's own schedule.
|
||||
|
||||
### Proxmox Backup Server
|
||||
|
||||
- **Config fields:** Proxmox Backup Server URL, API token ID, API token secret, allow self-signed certificate
|
||||
- **Auth:** `PBSAPIToken=<tokenId>:<tokenSecret>` header — note the **colon** between the token id and secret; Proxmox
|
||||
VE's own token header uses `=` there instead, so a PVE token/secret pair copied verbatim into this integration's
|
||||
fields will still format correctly (the adapter supplies the colon itself) as long as the id/secret values
|
||||
themselves are right.
|
||||
- **Actions used:** read-only — list datastores and their usage, read every stored snapshot's verification status,
|
||||
read the PBS host's own CPU/RAM/disk. No writes; nothing here can prune, delete, or re-verify a backup.
|
||||
- **Required access:** A dedicated API token (Configuration → Access Control → API Token) belonging to a user with
|
||||
**Datastore.Audit** on the datastore(s) to show, and **Sys.Audit** for the node status card to populate. A token
|
||||
scoped to just `Datastore.Audit` on one datastore will still work — other datastores it can't read are shown with
|
||||
an error rather than failing the whole page.
|
||||
- **What you get, and why it's separate from the Proxmox VE integration:** Proxmox VE (the "Proxmox" integration
|
||||
above) already shows whether the last `vzdump` push to PBS succeeded, but has no visibility at all into PBS's own
|
||||
backup **verification** — whether the data PBS actually stored still passes an integrity check, run separately by
|
||||
PBS's verify jobs. This integration reads that directly from PBS (`verification.state` on each stored snapshot),
|
||||
and a daily check (mirroring the Proxmox backup-failure check) sends a notification when a snapshot has failed
|
||||
verification or a datastore couldn't be read at all — the "Notify on" section in Settings → Notifications has a
|
||||
dedicated toggle for it, sharing the same daily reminder time as the other daily checks.
|
||||
- **Not verified against a live instance** — built from PBS's own published API documentation (endpoints, the
|
||||
`PBSAPIToken` header format, and the datastore/snapshot field names all cross-checked there), but nobody has run
|
||||
it against a real Proxmox Backup Server yet. If a datastore comes back empty or with the wrong fields, tell us
|
||||
what your instance actually returned and we'll adjust.
|
||||
|
||||
### phpIPAM
|
||||
|
||||
- **Config fields:** phpIPAM URL, API app ID, App token
|
||||
|
||||
Reference in new issue
Block a user