[os-nextcloud-backup] Add API endpoint for remote backup status / last successful upload

Aperta
  • Qualcosa non va?
#5,744 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
php
Ambito
api, backend, cloud

Direzione di ricerca

Start by tracing the existing /api/core/backup/backups/this endpoint and the os-nextcloud-backup WebDAV PUT upload handling. Determine how a provider-independent status could persist the last attempt and success result, then verify that the proposed API output supports the listed Zabbix monitoring use case.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

Is your feature request related to a problem? Please describe.

Currently, there does not seem to be an API endpoint that exposes the status of remote configuration backups, specifically whether the most recent upload to a configured backup provider such as Nextcloud was successful.

The existing endpoint:

/api/core/backup/backups/this

provides information about local configuration revisions, including their timestamp, description and file size. This is useful for determining whether recent local configuration backups exist, but it does not indicate whether a backup was successfully transferred to the configured remote backup provider.

For external monitoring systems such as Zabbix, this makes it difficult to distinguish between:

  • a recent local configuration backup existing,
  • the remote backup job having run,
  • the remote upload having succeeded,
  • and the remote backup destination being unavailable or failing.

For example, the Nextcloud backup provider performs the upload via WebDAV PUT and considers HTTP status codes in the 2xx range successful. However, this result does not appear to be exposed through the API or persisted as a status that can be queried by an external monitoring system.

Describe the solution you'd like

It would be useful to have an API endpoint exposing the status of the configured remote backup provider.

For example:

GET /api/core/backup/status

or, if this should be implemented by the individual backup plugin:

GET /api/nextcloud/backup/status

The response could contain information similar to:

{
  "provider": "Nextcloud",
  "enabled": true,
  "last_attempt": "2026-09-30T04:05:02+02:00",
  "last_success": "2026-09-30T04:05:03+02:00",
  "success": true,
  "filename": "config-20260930.xml",
  "remote_path": "OPNsense/config-20260930.xml",
  "http_status": 201,
  "message": "Backup successfully uploaded"
}

At minimum, the following information would be sufficient for monitoring purposes:

  • configured backup provider
  • timestamp of the last backup attempt
  • timestamp of the last successful backup/upload
  • success/failure state of the last attempt
  • optional error/status message

Ideally, the concept could be implemented generically so other remote backup providers can expose their status through the same API rather than introducing provider-specific monitoring interfaces.

This would allow external monitoring systems such as Zabbix to retrieve the backup status directly through the OPNsense API and implement triggers such as:

  • OK: last successful remote backup < 24 hours
  • WARNING: last successful remote backup > 24 hours
  • HIGH: last successful remote backup > 48 hours
  • HIGH: most recent upload attempt failed

The timestamps could be exposed as Unix timestamps and/or ISO 8601 values, making them straightforward to process using Zabbix preprocessing and trigger expressions.

It would also make it possible to distinguish a remote backup failure from the absence of recent local configuration changes.

Describe alternatives you've considered

One alternative is to query:

/api/core/backup/backups/this

and use the timestamp of the newest local configuration revision.

However, this only verifies that a local configuration revision exists. It does not verify that the revision was successfully uploaded to the remote backup destination.

Another alternative is to query the Nextcloud server directly via WebDAV PROPFIND and inspect the modification timestamp of the latest remote backup file.

While this verifies the actual remote state, it requires the Zabbix server/proxy to have separate credentials and connectivity to the backup destination. It also duplicates some of the logic already implemented by the OPNsense backup provider.

Another possibility is monitoring the OPNsense system log for failed WebDAV PUT operations. This can detect individual failures, but does not provide a reliable current state such as "last successful remote backup was X hours ago".

Additional context

The concrete use case is monitoring OPNsense configuration backups with Zabbix.

Ideally, Zabbix should only need access to the OPNsense API and should not require additional credentials for the configured backup destination.

For the Nextcloud backup provider, OPNsense already knows whether an upload succeeded because the provider evaluates the HTTP response from the WebDAV PUT request. Persisting the timestamp/result of the last attempt and exposing this information through the API would make this state available to monitoring systems without requiring them to independently access Nextcloud.

This could, for example, be consumed by a Zabbix HTTP agent item with JSONPath preprocessing to create dependent items for last_success, success, http_status, etc.

A provider-independent status interface would be especially useful, as monitoring systems could then verify remote backup health without needing implementation-specific knowledge or credentials for each individual backup backend.

Lingua principale
PHP
Stelle
1.2k
Fork
905
Merge medio
4g 12h
PR unite (30g)
22

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di opnsense/plugins

Tutte le issue di opnsense/plugins

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.