[os-nextcloud-backup] Add API endpoint for remote backup status / last successful upload
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
- I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
- I have searched the existing issues, open and closed, and I'm convinced that mine is new.
- When the request is meant for an existing plugin, I've added its name to the title.
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 hoursWARNING: last successful remote backup > 24 hoursHIGH: last successful remote backup > 48 hoursHIGH: 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.
- 主要言語
- PHP
- スター
- 1.2k
- フォーク
- 905
- 平均マージ
- 4日 21時間
- マージ済み PR(30日)
- 20
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
opnsense/plugins のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 2 日以内に返信
-
security/tailscale: add description to restart service対応中かも @drpsyko101 が 7 日前に担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
メンテナーはふだん 2 日以内に返信
-
security/acme-client: missing accounts directory causes DNS-01 validation failure再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンsupport
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
opnsense/plugins#5770 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
security/tor: Advanced mode / help toggles are broken対応中かも @txr13 が 49 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 2 日以内に返信
-
os-opnproxy 1.0.5_5オープンincomplete
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
opnsense/plugins#5710 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
opnsense/plugins の issue をすべて見る
似ている issue
-
docs good first issue php
難易度 1/5 1〜3時間 初心者へのやさしさ 90/100
メンテナーはふだん 1 日以内に返信
-
Area: UI Priority: High Status: Available Type: Maintenance
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
fix(flexi-content): wrap editor aria-labels with i18n対応中かも @Ankitavasudev が今日担当しました。 オープンfirst-timers-only focus: accessibility focus: blocks focus: i18n good first issue hacktoberfest help wanted type: bug up-for-grabs winter-of-code
難易度 1/5 1〜3時間 初心者へのやさしさ 90/100
noruzzamans/gslider-blocks#697 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
I forgot the add database cross reference button対応中かも @dsenalik が今日担当しました。 オープンGood First Issue Group 2 - Data Storage | Tripal DBX | Chado Group 7 - Page Display
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100