Proxmox Backup Server über die API überwachen¶

Ein Backup, das niemand ansieht, ist eine Hoffnung — kein Backup. Vesana überwacht einen Proxmox Backup Server (PBS) über dessen REST-API auf Port 8007 und beantwortet genau die Fragen, an denen ein Backup-Konzept scheitert:

Füllt sich der Datastore, und wie lange reicht er noch?
Wie alt ist das älteste Backup — läuft die Sicherung überhaupt noch?
Ist die letzte Überprüfung (Verify) durchgegangen, oder existiert das Backup zwar, lässt sich aber nicht zurückspielen?
Läuft die Garbage Collection? Ohne sie gibt PBS gelöschte Snapshots nie frei, und der Datastore läuft voll, obwohl die Aufbewahrung greift.
Ist eine Aufgabe (Backup, Verify, Sync, Prune) fehlgeschlagen?

Auf dem PBS läuft kein Agent, und es wird keine Shell gebraucht. Die Checks laufen über ein editierbares Python-Script (Scripts-Bibliothek: „Proxmox Backup Server — API"), das der Collector ausführt.

Dieses Profil ergänzt Proxmox VE (API): der Hypervisor meldet, ob der Backup-Lauf durchging — der Backup-Server, ob das Backup noch gut ist.

1. API-Token in PBS anlegen¶

Im PBS-Web-UI:

Configuration → Access Control → API Token → Add.
Benutzer wählen (z. B. monitoring@pbs), Token-ID vergeben (z. B. vesana). Der vollständige Bezeichner lautet dann benutzer@realm!tokenid.
Das einmalig angezeigte Secret kopieren.

Rechte vergeben: Configuration → Access Control → Permissions → Add → API Token Permission, Pfad /, Rolle Audit.

Privilege Separation

Wie bei Proxmox VE: ist sie beim Token aktiv, braucht der Token einen eigenen Permission-Eintrag; sonst erbt er die Rechte des Benutzers.

2. Profil holen und Host anlegen¶

Das Profil „Proxmox Backup Server (API)" liegt in der Vesana-Bibliothek (Stufe Beta, bisher gegen das offizielle API-Schema geprüft, nicht an einem echten PBS) — installieren, dann einen Host anlegen:

Ziel: IP oder DNS-Name des Backup-Servers.
Profil: „Proxmox Backup Server (API)".
API-Zugang (im Host-Assistenten bzw. in den Host-Einstellungen im Reiter Verbindung):
Benutzer: benutzer@realm!tokenid
Passwort / Geheimnis: das Token-Secret

PBS trennt mit einem Doppelpunkt

Der PBS-Auth-Header lautet PBSAPIToken=user@realm!id:secret — mit Doppelpunkt, während Proxmox VE ein = benutzt. Vesana baut den Header selbst; du trägst nur ID und Secret in die zwei Felder ein. Wer den Header von Hand aus einem PVE-Beispiel kopiert, bekommt 401 und sucht am falschen Ende.

Was die Checks messen¶

Datastore¶

Check	Bedeutung
Datastore usage (fullest)	Füllstand des vollsten Datastores; alle stehen in den Details. Ein volles Backup-Ziel nimmt keine Backups mehr an — und dann ist das neueste Backup still das letzte.
Datastore unusable	Datastores, die PBS nicht benutzen kann: nicht lesbarer Chunk-Store oder ein nicht eingehängtes Wechselmedium. Fällt auf, bevor das nächste Backup-Fenster es tut.
Days until full	PBS' eigene Hochrechnung, wann ein Datastore voll ist. Die Richtung ist abwärts — weniger Tage sind schlimmer. UNKNOWN, solange PBS noch keine Schätzung hat (er braucht etwa einen Monat Historie).

Backups¶

Check	Bedeutung
Oldest backup age	Alter des jüngsten Snapshots der Gruppe, die am längsten nicht gesichert wurde. Ein Snapshot-Zähler beantwortet das nicht: der bleibt hoch, während seit Wochen nichts Neues dazukommt.
Verification failures	Snapshots der letzten 30 Tage, deren Überprüfung fehlgeschlagen ist — das Backup existiert, ist aber nicht wiederherstellbar. Der wichtigste Check auf einem Backup-Server, und derjenige, den ohne Monitoring niemand bemerkt: der Backup-Lauf selbst hat Erfolg gemeldet.
Snapshots never verified	Nie überprüfte Snapshots — Statistik. Standardmäßig aus: ohne Verify-Zeitplan wäre das jeder Snapshot.
Snapshots	Anzahl je Datastore, reine Anzeige mit Graph.

Wartung¶

Check	Bedeutung
Garbage collection age	Stunden seit dem letzten abgeschlossenen GC-Lauf (Vorgaben: WARNING ab 200 h, CRITICAL ab 400 h); WARNING, wenn GC noch nie gelaufen ist.
Garbage collection result	Ergebnis des letzten Laufs und die Zahl der danach verbliebenen beschädigten Chunks. Beschädigte Chunks sind CRITICAL, auch wenn der Lauf selbst „OK" meldet — die betroffenen Backups lassen sich nicht zurückspielen.
Failed tasks	Fehlgeschlagene Aufgaben in einem echten Zeitfenster (Vorgabe 26 h). Am Check lässt sich auf einzelne Arten einschränken — ein fehlgeschlagener Sync zum Auslagerungsziel ist ein anderes Gespräch als ein fehlgeschlagenes Backup.

Maschine¶

CPU, Speicher, System-Dateisystem, Uptime (Info-Modus), Dienste und offene Paket-Updates (Info-Modus) — dieselbe Logik wie beim Proxmox-VE-Profil. Standardmäßig nicht angelegt, bei Bedarf am Gerät hinzuzufügen: Last pro Kern, ZFS-Pools, SMART und Subscription-Status.

Anpassen¶

Einstellbar am Check: Datastores und Backup-Gruppen ausschließen, einem Datastore eigene Grenzen geben (NAME:warn:crit), das Verify-Fenster und das Aufgaben-Fenster ändern, Aufgaben-Arten einschränken. Ausnahmen sind präfix-fähig (ct/*, host/laptop).

Grenzwerte gehören in die Schwellwert-Felder des Checks, nicht in die einstellbaren Werte — dort wirken sie sofort und lassen sich pro Gerät überschreiben.

Troubleshooting¶

HTTP 401: Token-ID (mit !tokenid) und Secret prüfen. Bei aktiver „Privilege Separation" braucht der Token einen eigenen Permission-Eintrag.
HTTP 403: Dem Token fehlt die Rolle Audit am Pfad /.
Ein Datastore fehlt in den Zahlen: Kann der Token ihn nicht lesen, steht er als „not readable" in der Meldung — der Rest wird trotzdem beurteilt. Sind alle unlesbar, meldet der Check UNKNOWN.
„PBS not reachable": Der Collector muss Port 8007 erreichen.
Der Check bleibt UNKNOWN mit „Server-side plugins are not enabled for this tenant": Script-Checks auf dem Aktiven Collector brauchen die Freigabe „Eigene Plugins auf dem Server" für den Mandanten unter Admin → Agents & Collectors → Active-Checker. Checks, die ein Super-Admin gespeichert hat, laufen unabhängig davon.