Was in meinen Backups fehlte
Die meisten Ratschläge zum Home-Assistant-Backup laufen darauf hinaus, den config-Ordner zu archivieren, und genau das habe ich lange gemacht — nach Zeitplan, mit einer Kopie außer Haus.
Irgendwann habe ich mich hingesetzt und durchgespielt, was bei einem Ausfall der VM tatsächlich passiert. Die Liste der Dinge, die mir fehlen würden, war länger als erwartet. Die Automatisierungen kämen zurück. Aber das WireGuard-Setup, über das mein Handy Home Assistant von außerhalb des LAN erreicht, lag nicht im Archiv, die Firewall-Regeln auch nicht. Ebenso wenig der Cronjob, der die Backups überhaupt erzeugt. Und den exakten docker run-Aufruf, der einen Container mit dem richtigen Netzwerkmodus und den richtigen Volumes ergibt, hatte ich längst nicht mehr im Kopf.
Das Config-Archiv hätte Home Assistant also wieder zum Laufen gebracht, auf einem Host, der nicht viel konnte.
Was ins Archiv gehört
Der tägliche Job packt inzwischen Folgendes ein, und jedes Teil steht dort aus einem Grund, in den ich hineingelaufen bin:
Die Datenbank und die YAML-Dateien — home-assistant_v2.db, alle .yaml-Dateien und das aufgeteilte automations-Verzeichnis.
.storage/ — dort liegen die Dashboards. Änderungen an der Lovelace-Oberfläche landen nicht im YAML, ohne dieses Verzeichnis bekommt man also eine laufende Instanz mit leeren Dashboards.
custom_components/ — alles, was über HACS installiert wurde. Fehlt es, kommt ein guter Teil der Entitäten als unavailable zurück, und man verbringt einen Abend damit herauszufinden, welche Integration fehlt.
Die VPN-Konfiguration samt Keys — bei mir WireGuard. Keys neu zu erzeugen heißt, jedes Client-Gerät von Hand neu einzurichten, deshalb lohnt es, sie mitzunehmen.
Die Firewall-Regeln — ein wiederhergestellter Host, der erreichbar und ungeschützt ist, ist keine besonders gute Wiederherstellung.
Das Cron-Verzeichnis, inklusive des Backup-Scripts selbst — wenn die Maschine weg ist, die die Backups erzeugt, ist es praktisch, wenn das Script dazu nicht ebenfalls weg ist.
Die docker inspect-Ausgabe als JSON — das sehe ich selten erwähnt. Sie hält Image, Netzwerkmodus, Volumes, Restart-Policy und Environment des laufenden Containers fest, man kann den richtigen docker run also aus einer Datei ablesen statt ihn zu erinnern.
Wo die Kopien liegen
Zwei Ziele: sieben Tagesarchive lokal auf der VM und ein Blob-Storage-Container außer Haus, der sie spiegelt.
Gegen 3-2-1 gehalten — drei Kopien, zwei Medien, eine außer Haus — geht das zahlenmäßig auf. Es ist allerdings schwächer, als die Zahl aussieht, denn die lokale Kopie liegt auf derselben Disk wie die Daten, die sie sichert. Fällt diese Disk aus, ist das lokale Archiv mit weg, und der Spiegel außer Haus ist das Einzige, was bleibt.
Ich behalte die lokale Kopie trotzdem, weil sie den häufigen Fall schnell macht. Fast jede Wiederherstellung, die ich wirklich gebraucht habe, war „ich habe heute früh eine YAML-Datei zerschossen" und nicht der Verlust der Maschine. Für den seltenen Fall zählt die Kopie außer Haus, und die kontrolliere ich deshalb auch.
Keine Zugangsdaten im Backup-Script
Der Upload läuft über die verwaltete Identität der VM selbst. Der Cloud-Anbieter gibt der Maschine ein kurzlebiges Token, der Storage-Container gewährt dieser Identität Schreibrecht, und im Script steht kein Key und kein Connection-String.
Bei einem Backup-Script lohnt sich dabei etwas Sorgfalt, wegen dem, was es tut: es hat Lesezugriff auf alles auf dem Host und spricht regelmäßig mit einem Ort außer Haus. Ein langlebiger Storage-Key in dieser Datei wäre ein recht direkter Weg nach draußen.
Wenn dein Host keine verwaltete Identität anbietet, erfüllt ein eng gefasster, nur schreibender Zugang mit kurzer Gültigkeit denselben Zweck. Der Kontoschlüssel nicht.
Einmal zurückspielen
Ich hatte nie eine vollständige Wiederherstellung gemacht, wusste also nicht wirklich, ob das Archiv komplett war. Also habe ich sie auf einer frischen VM durchgespielt, mit Stoppuhr.
Zwei Schritte zeigten sich erst dabei. Die Maschinen-Identität muss auf dem neuen Host neu vergeben werden, und die Netzwerk-Sicherheitsregeln müssen an die neue Schnittstelle gehängt werden. Beides liegt in keinem Backup-Archiv, und beides hält die Wiederherstellung auf, bis man es merkt. Nach diesem Durchlauf hat sich das Script geändert.
Der komplette Durchlauf mit den Zeiten ist ein eigener Beitrag. Hier geht es darum, was vorher im Archiv liegen muss, damit sich der Versuch überhaupt lohnt.
Zwei verwandte Dinge, falls sie nützlich sind. Vor einem Update zu sichern ist eine andere Aufgabe in einem anderen Rhythmus, dazu habe ich separat geschrieben, samt der Frage, wie der Container-Rollback praktisch abläuft. Und das Ganze läuft auf Home Assistant in Docker auf einer Cloud-VM, deren Einrichtung Schritt für Schritt in einem früheren Beitrag steht.
Zusammenfassung
Archiviere den Host und nicht bloß den Ordner: die VPN-Keys, die Firewall-Regeln, das Cron-Verzeichnis, das Backup-Script und die Container-Definition, zusätzlich zu Config und Datenbank. Halte eine lokale Kopie für die Geschwindigkeit und eine außer Haus für den Fall, den die lokale nicht übersteht. Und spiel eine Wiederherstellung einmal durch, solange nichts kaputt ist.
