Proxmox-Backups automatisiert: PVE- und PBS-API mit Home Assistant WoL und Ping verknüpfen

Wer einen kleinen Homelab-Server betreibt, kennt das Problem: Der Proxmox Backup Server (PBS) ist wichtig, muss aber nicht rund um die Uhr laufen. Ein eigener Rechner, der dauerhaft Strom zieht, nur damit nachts einmal eine Sicherung eintrudelt, ist unnötig teuer. Die Lösung liegt auf der Hand: den Backup-Server per Wake-on-LAN (WoL) aufwecken, den Sicherungslauf per API anstoßen und den Rechner danach wieder herunterfahren.

Dieser Text zeigt, wie sich das mit Proxmox VE (PVE), Proxmox Backup Server und Home Assistant zu einer Kette aus drei Integrationsbausteinen verbinden lässt: WoL zum Aufwecken, ein Ping-Sensor zur Bestätigung, dass der Rechner wirklich bereit ist, die PVE-API zum Starten des Backups sowie ein Webhook, der das Ende des Laufs meldet und den Shutdown auslöst.

Kurzantwort

So startest du Proxmox Backup Server nur bei Bedarf per Wake-on-LAN, stößt per PVE-API einen vzdump an und fährst den Server danach automatisch wieder herunter. Kurz gesagt: ki tools praxis ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

Die Aufgabe: Sicherung ohne Dauerbetrieb

Der Ausgangspunkt ist ein konkreter Aufbau mit zwei NUCs: einer läuft als PVE-Hypervisor, der zweite als PBS 1. Der PBS soll nicht rund um die Uhr aktiv sein. Stattdessen übernimmt Home Assistant die Rolle des Orchestrators, der die einzelnen Schritte nacheinander anstößt und auf Bedingungen wartet.

Der Ablauf, den es nachzubauen gilt, ist dieser:

Um 03:00 Uhr sendet Home Assistant ein WoL-Paket an den PBS.
Ein Ping-Sensor prüft, ob der Rechner tatsächlich hochfährt, mit einem Timeout von fünf Minuten.
Sobald der Rechner erreichbar ist, ruft Home Assistant die PVE-API auf und startet einen vzdump.
PVE meldet das Ende des Backups per Webhook zurück, gesteuert über einen Benachrichtigungs-Matcher mit exact:type=vzdump.
Home Assistant ruft die PBS-API auf, um den Server herunterzufahren.

Diese Kette lässt sich vollständig mit Bordmitteln der drei Systeme umsetzen. Die einzige Voraussetzung ist, dass der PBS WoL unterstützt und die beteiligten Geräte im selben Netz erreichbar sind.

Schritt 1: Den Backup-Server mit Wake-on-LAN aufwecken

Home Assistant bringt mit der Integration Wake on LAN zwei Bausteine mit: einen Button und einen Switch 2. Für diese Aufgabe ist der Button die richtige Wahl, denn ein WoL-Button ist zustandslos. Er sendet ein Magic Packet an eine konfigurierte MAC-Adresse, kann aber per Definition nicht prüfen, ob das Ziel tatsächlich gestartet ist.

Das ist kein Nachteil, sondern eine sinnvolle Trennung der Zuständigkeiten: Das Magic Packet ist ein Broadcast, für den es keine Bestätigung gibt. Ob der Rechner wirklich hochfährt, prüft anschließend ein separater Sensor. Der WoL-Button selbst wird über die Aktion wake_on_lan.send_magic_packet angesteuert, die in einer Automation direkt aufgerufen werden kann, ohne dass dafür ein Schalter im Dashboard existieren muss 2.

Damit das Paket ankommt, müssen drei Dinge stimmen:

Die MAC-Adresse des PBS ist im System hinterlegt (Format 00:01:02:03:04:05).
WoL ist im BIOS/UEFI des PBS aktiviert und im Betriebssystem möglichst zusätzlich bestätigt.
Der Broadcast erreicht den Rechner. Wenn der PBS heiß bleiben soll, auch über ein VLAN oder Subnetz hinweg, kann neben der MAC-Adresse eine Broadcast-Adresse und ein Broadcast-Port konfiguriert werden 2.

Ein häufiger Stolperstein: WoL funktioniert nur, wenn die Netzwerkkarte nach dem Ausschalten weiter mit Strom versorgt wird. Bei manchen Boards ist das standardmäßig deaktiviert oder funktioniert erst nach einem vollständigen Herunterfahren statt eines Neustarts. Wer das erste Mal einrichtet, sollte den Weckvorgang deshalb einmal von Hand testen, bevor die Automation um 03:00 Uhr ins Leere läuft.

ki tools praxis – Illustration 2

Schritt 2: Sicherstellen, dass der Rechner wirklich bereit ist

Ein WoL-Paket ist abgeschickt, sobald es auf dem Draht ist. Ob der Rechner danach tatsächlich bootet, ist damit noch nicht beantwortet. Genau hier greift die zweite Integration: der Ping-Sensor 3.

Home Assistant bietet eine Ping-Integration auf ICMP-Basis, die ein Gerät in einem konfigurierbaren Intervall anpingt und daraus einen Erreichbarkeitszustand ableitet 3. In dieser Kette dient der Ping nicht als dauerhaftes Monitoring, sondern als Kriterium in einer Automation: Der nächste Schritt darf erst starten, wenn der PBS auf Ping antwortet.

Die Wartezeit lässt sich mit einem Timeout von fünf Minuten begrenzen. Konkret heißt das: Die Automation sendet das WoL-Paket, wartet dann darauf, dass der Ping-Sensor auf „erreichbar" wechselt, und bricht ab, wenn das nach fünf Minuten noch nicht passiert ist. Ein Timeout ist wichtig, weil ein nicht erreichtes Ziel sonst die gesamte Automation blockieren würde und der API-Aufruf ins Leere liefe.

Die Reihenfolge WoL → Ping → API ist bewusst gewählt. Sie verhindert, dass Home Assistant die PVE-API anstößt, noch bevor der PBS seinen Dienst überhaupt hochgefahren hat. Der Ping misst nur die IP-Erreichbarkeit, nicht die volle Betriebsbereitschaft des Backup-Daemons. In der Praxis reicht das meist, weil der Daemon in der Regel wenige Sekunden nach dem Netzwerkstart verfügbar ist. Wer es genauer will, kann zwischen Ping und API-Aufruf eine kurze zusätzliche Verzögerung einbauen oder später den Rückgabewert der API prüfen.

Schritt 3: Den vzdump über die PVE-API starten

Der eigentliche Sicherungslauf wird nicht über die Oberfläche, sondern über die API von Proxmox VE angestoßen. Dafür wird ein API-Token verwendet, den man in PVE anlegt und auf die nötigen Rechte beschränkt. Der Aufruf startet einen Backup-Job vom Typ vzdump für die gewünschte VM oder den Container.

Der vzdump selbst ist das Werkzeug, das Proxmox seit Jahren für Konsistenzprüfung und Sicherung von Gästen nutzt. Die Anbindung über die API macht den Lauf skript- und damit automationsfähig. Welche Berechtigungen das Token mindestens braucht, hängt vom Umfang ab: zum Starten eines Backups genügt laut PVE-API-Dokumentation die Kombination aus VM.Backup auf den jeweiligen Gast-Ressourcen und Datastore.AllocateSpace auf dem Backup-Storage 4. Ein Token mit unbegrenzten Rechten ist für eine reine Backup-Automation unnötig und erhöht nur das Risiko.

An dieser Stelle lohnt ein Blick auf die Sicherheitspraxis: Ein API-Token ist bewusst ein eigenständiger Zugang. Es sollte nur die Rechte bekommen, die der konkrete Automation-Ablauf tatsächlich braucht, und nicht als Ersatz für den administrativen Root-Zugang dienen. Der Token wird in Home Assistant als Secret hinterlegt, damit er nicht im Klartext in Automations- oder Konfigurationsdateien landet.

Schritt 4: Das Ende des Backups über einen Webhook erkennen

Ein API-Aufruf, der einen Backup-Job startet, ist nur die halbe Miete. Entscheidend ist, zu wissen, wann der Lauf fertig ist — und ob er geklappt hat. An dieser Stelle kommt das Benachrichtigungssystem von Proxmox VE ins Spiel.

Proxmox VE sendet für Ereignisse wie „Backup abgeschlossen" oder „Backup fehlgeschlagen" interne Benachrichtigungsereignisse 5. Diese Ereignisse tragen Metadaten: einen Zeitstempel, eine Schweregradstufe (info, notice, warning, error, unknown) und einen Typ. Für Backups ist der Typ vzdump maßgeblich; er wird bei erfolgreichem wie fehlgeschlagenem Lauf mit dem jeweiligen Schweregrad gemeldet 5.

Damit aus diesem Ereignis eine Aktion in Home Assistant wird, braucht es zwei Bausteine im PVE-Benachrichtigungssystem:

Zum einen ein Benachrichtigungsziel vom Typ Webhook. Dieses führt einen HTTP-Aufruf an eine konfigurierbare URL aus und unterstützt die HTTP-Methoden POST, PUT und GET. URL, Header und Body lassen sich per Handlebars-Templates füllen, etwa mit {{ message }} für den Benachrichtigungstext oder {{ severity }} für den Schweregrad 5. Ein Webhook-Ziel wird damit zur Brücke zwischen PVE und Home Assistant: PVE ruft bei Abschluss eines Backups einfach einen Webhook in Home Assistant auf.

Zum anderen ein Matcher, der steuert, welche Ereignisse an welches Ziel gehen. Ohne Matcher-Regel wird ein Ziel bei jedem Ereignis benachrichtigt. Mit einer Regel lässt sich das gezielt eingrenzen. Für diese Aufgabe lautet die passende Regel match-field exact:type=vzdump, die ausschließlich Backup-Ereignisse erfasst 5. Die Syntax erlaubt mit exact eine präzise Feld-Übereinstimmung, mit regex dagegen einen Musterabgleich.

Praktisch sieht die Konfiguration in /etc/pve/notifications.cfg dann etwa so aus: ein Webhook-Ziel, das an eine Home-Assistant-Webhook-URL zeigt, und ein Matcher, der genau die vzdump-Ereignisse auf dieses Ziel lenkt. Ein eventuell nötiger Token oder Secret für den Webhook wird nicht im Klartext in dieser Datei abgelegt, sondern in einer separaten, nur von root lesbaren Konfiguration 5.

Der Webhook-Aufruf bildet damit das Startsignal für den letzten Schritt der Kette: Home Assistant weiß nun, dass der Backup-Lauf beendet ist, und kann den PBS herunterfahren.

Schritt 5: Den Server über die PBS-API ausschalten

Ist das Backup abgeschlossen, hat der Backup-Server seinen Zweck für diese Nacht erfüllt und kann wieder ausgeschaltet werden. Dafür ruft Home Assistant die API des Proxmox Backup Server auf und löst das Herunterfahren des Systems aus.

Der PBS bringt, wie PVE auch, eine HTTP-API mit, über die sich Verwaltungsaktionen anstoßen lassen 6. Für diese Kette reicht der Aufruf des Shutdown-Endpunkts: POST /nodes/{node}/status mit command=shutdown, was die Berechtigung Sys.PowerManagement voraussetzt. Die Authentifizierung erfolgt, wie bei PVE, bevorzugt über ein eigenes, eng begrenztes API-Token statt über den Root-Login.

Auch hier gilt die gleiche Sicherheitsregel wie beim PVE-Token: ein eigenes Token, minimal ausgestattet, in Home Assistant als Secret hinterlegt. Der Unterschied zwischen „Backup-Server läuft weiter, weil der Shutdown nicht durchging" und einem sauber beendeten Lauf liegt oft an fehlenden Rechten oder einem Tippfehler im Endpunkt — ein kurzer manueller Testaufruf vor der ersten echten Nacht zahlt sich aus.

Den kompletten Ablauf als Automation

Die fünf Schritte lassen sich in Home Assistant zu einer einzigen Automation zusammenfassen. Der zeitliche Trigger um 03:00 Uhr stößt die Kette an:

WoL-Paket senden (wake_on_lan.send_magic_packet).
Auf den Ping-Sensor warten, Timeout fünf Minuten; bei Timeout abbrechen.
PVE-API aufrufen und den vzdump starten.
Auf den Webhook von PVE warten, der das Ende des Laufs signalisiert.
PBS-API aufrufen und den Server herunterfahren.

Der Ablauf ist absichtlich linear und explizit: Jeder Schritt wartet auf ein konkretes, überprüfbares Signal des vorherigen, statt blind aufeinander zu folgen. Genau das ist der Unterschied zu einer rein zeitbasierten Lösung, bei der ein verschlafener Boot jede folgende Aktion ins Leere laufen lässt.

Ein Detail verdient an dieser Stelle besondere Aufmerksamkeit: die Fehlerbehandlung. Wenn ein Backup fehlschlägt, sendet PVE zwar ebenfalls ein vzdump-Ereignis, aber mit Schweregrad error 5. Wer den Matcher nur auf den Typ vzdump beschränkt, bekommt Erfolg und Fehler gleichermaßen gemeldet — und fährt den Server im Fehlerfall ebenfalls herunter. Das kann gewollt sein, muss aber bewusst entschieden werden.

Wer genauer trennen will, kann den Matcher um eine Schweregrad-Regel ergänzen: match-field exact:type=vzdump zusammen mit match-severity info erfasst nur erfolgreiche Läufe 5. Der Fehlerfall ließe sich dann über einen zweiten Matcher gesondert behandeln, etwa für eine Alarmierung statt eines sauberen Shutdowns. Diese Unterscheidung ist kein Sahnehäubchen, sondern die Stelle, an der sich zeigt, ob die Automation im Ernstfall meldet oder stillschweigt.

Fehlerursachen, wenn es nicht läuft

Die Kette hat mehrere Glieder, und jedes kann einzeln brechen. Die häufigsten Ursachen sind erfahrungsgemäß diese:

WoL-Paket kommt nicht an. Prüfen, ob WoL im BIOS/UEFI aktiv ist und die MAC-Adresse korrekt hinterlegt wurde. Ein manueller Wecktest ohne Automation isoliert das Problem.
Ping bleibt rot. Der Rechner bootet langsam oder das Paket erreicht ihn nicht. Das Timeout von fünf Minuten ist hier bewusst als Grenze gesetzt; wer knapp darüber liegt, sollte prüfen, ob der Boot selbst länger dauert oder das Paket gar nicht ankam.
API-Aufruf schlägt fehl. Häufigste Ursache sind fehlende Token-Rechte oder ein falscher Endpunkt. Ein API-Token mit minimalen Rechten, das in Home Assistant als Secret hinterlegt ist, ist der richtige Ansatz; bei Fehlern hilft ein manueller Aufruf mit demselben Token.
Webhook feuert nicht. Der Matcher greift nicht, weil die Feld-Regel nicht zutrifft. Die Syntax match-field exact:type=vzdump ist pingelig; ein fehlendes exact: oder ein falscher Typ lassen den Matcher still bleiben.
Shutdown wird ausgelöst, aber der Server läuft weiter. Meist fehlende Rechte am PBS-Token oder ein nicht erreichbarer Endpunkt.

Die Reihenfolge der Diagnose folgt der Reihenfolge der Kette: erst das Wecken, dann die Erreichbarkeit, dann der Backup-Start, dann der Webhook, zuletzt der Shutdown. Wer nacheinander vorgeht, findet die Bruchstelle zuverlässiger als wer alle Komponenten gleichzeitig anzweifelt.

Grenzen dieses Ansatzes

Der Aufbau löst ein konkretes Problem: einen Backup-Server, der nur für die Sicherung läuft und danach wieder aus ist. Er ist aber keine Allzwecklösung.

Die größte Annahme liegt im WoL-Schritt. Wake-on-LAN ist ein Broadcast-Mechanismus ohne Bestätigung. Ob ein Rechner wirklich aufwacht, lässt sich erst im Nachhinein über den Ping feststellen. Wer einen Backup-Server betreibt, bei dem Zuverlässigkeit wichtiger ist als Stromersparnis, sollte den Weckvorgang deshalb nicht als stille Voraussetzung behandeln, sondern das Ausbleiben des Erfolgs aktiv überwachen und melden.

Eine zweite Grenze betrifft die Abhängigkeit von Home Assistant als Orchestrator. Die gesamte Kette läuft über den Smart-Home-Controller. Fällt er aus, fällt auch die nächtliche Sicherung aus — still. Wer darauf nicht angewiesen sein will, kann die Absicherung zusätzlich in PVE selbst hinterlegen, etwa über einen regulären geplanten Backup-Job als Rückfallebene, auch wenn der im normalen Betrieb den PBS gar nicht braucht.

Drittens ist der Ansatz an die Erreichbarkeit im selben Netz gebunden. WoL über mehrere Netze hinweg erfordert Broadcast-Weiterleitung oder einen Relay, und der Webhook von PVE zu Home Assistant funktioniert nur, solange beide einander erreichen. Das ist im Heimnetz meist gegeben, aber kein Gesetz.

Entscheidungshilfe: Wann ist das sinnvoll?

Eher sinnvoll, wenn du ki tools praxis nicht nur als Nachricht lesen willst, sondern eine praktische Einordnung brauchst: Was ändert sich, wen betrifft es und welche nächsten Schritte sind realistisch?

Eher abwarten, wenn die Quellenlage noch dünn ist, wichtige technische Details fehlen oder der Nutzen nur aus Hersteller- oder Projektversprechen besteht. Dann ist Beobachten besser als vorschnelles Umstellen.

Worauf du achten solltest: konkrete Verfügbarkeit, nachvollziehbare Kosten, offene Einschränkungen, Sicherheits- oder Datenschutzfolgen und belastbare Quellen statt bloßer Ankündigungen.

Fazit: Ein nützliches Muster, kein Selbstläufer

Die Kombination aus PVE-API, PBS-API und Home Assistant löst ein echtes Alltagsproblem im Homelab: Ein Backup-Server muss nicht dauerlaufen, wenn sich sein Start und sein Ende deterministisch steuern lassen. WoL weckt ihn, Ping bestätigt den Start, die PVE-API startet den Lauf, ein Webhook meldet das Ende und die PBS-API fährt ihn herunter.

Der entscheidende Baustein ist dabei nicht ein bestimmtes Werkzeug, sondern die Verkettung über überprüfbare Signale statt fester Wartezeiten. Jeder Schritt hängt an einem konkreten Ereignis, das der vorherige auslöst. Das macht den Ablauf robust gegenüber langsamen Boots und verschlafenen Paketen — und es macht ihn gleichzeitig lesbar, weil jede Station im Log einzeln nachvollziehbar ist.

Wer den Aufbau nachbaut, sollte zuerst die Fehlerbehandlung klären, bevor er die erste echte Nacht anstößt: Was passiert, wenn das Backup fehlschlägt? Soll der Server dann auch herunterfahren, oder soll stattdessen alarmiert werden? Die Antwort darauf ist eine bewusste Entscheidung anhand des eigenen Sicherungsbedürfnisses, keine Einstellung, die sich nebenbei von selbst ergibt.

Passende Produktrecherchen

Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

ki tools praxis – Illustration 3

Weiterführende Artikel

Häufige Fragen

Was beantwortet dieser Beitrag zu Proxmox-Backups automatisiert: PVE- und PBS-API mit Home Assistant WoL und Ping verknüpfen?

Er ordnet die genannten Quellen ein und übersetzt sie in Prüfpunkte für die eigene Entscheidung. Er ersetzt keine individuelle Planung, Beratung oder Wirtschaftlichkeitsrechnung.

Welche Angaben sollte ich vor einer Entscheidung selbst prüfen?

Entscheidend sind die eigenen Verbrauchs- und Nutzungsdaten, Kosten, technische Voraussetzungen und die aktuell geltenden Regeln. Die Quellen am Ende zeigen, welche Aussagen aus der Meldung stammen und wo die Grenzen der Einordnung liegen.

Sind die genannten Zahlen auf jeden Haushalt übertragbar?

Nein. Umfrage- und Marktwerte beschreiben Gruppen oder Zeitpunkte. Ob eine Maßnahme im Einzelfall passt, hängt von den konkreten Voraussetzungen vor Ort ab.

Transparenzhinweis

Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.

Quellen

[1] Backup automation using PVE/PBS APIs and Home Assistant WoL and Ping integrations — Reddit r/Proxmox

[2] Wake on LAN — Home Assistant Dokumentation

[3] Ping (ICMP) — Home Assistant Dokumentation

[4] Proxmox VE API Documentation — vzdump

[5] Notifications — Proxmox VE Dokumentation

[6] Proxmox Backup Server API Documentation