Tobias hatte achtzig Geräte, drei selbstgeschriebene Integrationen, einen Frigate-Server mit zwei Wochen Aufnahmen und ein InfluxDB-Addon, das sechs Jahre Sensorhistorie enthielt. Er hatte alles brav per Backup gesichert, jeden Sonntagnacht eine Datei mit dem Format Full_2026-XX-XX.tar, abgelegt auf einem USB-Stick im Heimserver. Als sein Raspberry Pi 4 an einem Donnerstagmorgen im März einfach nicht mehr hochfuhr (Netzteil kaputt, SD-Karte mit Bad Blocks), hatte er also drei volle Wochen aktuelle Backups, einen frischen Pi 5, der seit zwei Tagen auf dem Schreibtisch lag, und einen Plan für den Abend: Pi 5 starten, Backup hochladen, Restore drücken, fertig vor dem Schlafengehen.

Um halb zwei Uhr nachts hat seine Frau ihn gefragt, ob er wirklich noch immer am Computer sitzt. Er hatte Geräte zurückbekommen, ja. Aber das InfluxDB-Addon mit den sechs Jahren Daten weigerte sich, die Restore-Operation zu beenden. "Not a gzipped file", stand im Log, ein Fehler, den seit 2024 zahlreiche Forennutzer mit demselben Symptom melden. Bug 4909 im Supervisor-Repo, dokumentiert auf GitHub, ist seit Februar 2024 offen und hat noch Stand April 2026 keine zuverlässige Lösung. [^1]

Solche Geschichten erzählen Home-Assistant-Nutzer im Discord, im r/homeassistant-Subreddit und im Community-Forum häufiger, als die offizielle Dokumentation vermuten lässt. Ein Backup ist nicht dasselbe wie ein wiederherstellbares Backup, und 2026 ist die Diskrepanz zwischen Marketing ("ein Knopf und alles ist zurück") und Realität ("der wichtigste Addon ist die Hälfte der Zeit nicht zurück") größer denn je.

Dieser Artikel ist der Versuch, das Backup-Thema realistisch zu durchleuchten. Was eine Full-Backup-Datei tatsächlich enthält, wo sie versagt und wie eine ehrliche Backup-Strategie 2026 aussieht, die nicht nur am Sonntagabend Files erzeugt, sondern dich an einem ungeplanten Donnerstagmorgen tatsächlich zurück zu deinem Smart Home bringt.

Was eine Full Backup wirklich beinhaltet

Die offizielle Definition aus dem Home Assistant Green Guide ist erstaunlich knapp. [^2] Eine Full Backup enthält:

  • Konfigurationsdateien (configuration.yaml, automations.yaml, scripts.yaml, secrets.yaml, alle Inhalte des /config-Verzeichnisses)
  • Die Geräte- und Entitätsregistrierung (also welche Geräte mit welchen IDs und Namen Home Assistant kennt)
  • Alle installierten Addons inklusive ihrer Konfigurationen und Daten
  • Die Systemkonfiguration (Netzwerk, User, Updates)
  • Medien aus dem /media-Verzeichnis
Was nicht enthalten ist:
  • Snapshots aus externen Datenbanken, die nicht über Addons laufen (eine externe MariaDB auf einem separaten Server bleibt selbst gesichert)
  • Frigate-Aufnahmen, wenn sie auf NFS oder externen Volumes liegen
  • Inhalte, die explizit aus der Backup ausgeschlossen wurden — die Default-Backup-Konfiguration schließt zum Beispiel die Recorder-Datenbank aus, wenn sie sehr groß ist
  • Z2M-State, falls Z2M außerhalb des Supervisor läuft (z.B. auf einem separaten Pi)
Die letzten zwei Punkte sind die häufigsten Stolperfallen. Wer einen separaten Z2M-Container auf einem zweiten Gerät betreibt — was viele aus Latenzgründen tun — hat sein Zigbee-Netzwerk nicht in der HA-Backup. Wer Frigate nutzt und die Aufnahmen auf einem NAS gespeichert hat, sichert mit der HA-Backup nur die Konfiguration, nicht die Aufnahmen.

Die Frage "ist das ein Problem?" hängt vom Use-Case ab. Aufnahmen will man oft gar nicht in einer Backup haben (zu groß, ohnehin separat). Ein Z2M-State ohne separates Backup ist dagegen eine echte Lücke.

Bug 4909: Wenn das Restore die Hälfte vergisst

Im Februar 2024 hat ein Nutzer namens "boesing" auf GitHub den Issue 4909 eröffnet: Sein voller Restore lief durch, alle Sensoren waren zurück, aber das größte Addon — eine TimescaleDB-Instanz — wurde mit der Fehlermeldung "Not a gzipped file" übersprungen. [^1] Er versuchte einen partiellen Restore nur für dieses Addon — auch das schlug fehl. Mehr als ein Dutzend Nutzer haben sich seitdem mit identischem Symptom gemeldet. Der gemeinsame Nenner: große Addons (üblicherweise Datenbanken wie TimescaleDB, MariaDB oder InfluxDB), die durch ein Format-Update im Supervisor-Backup-System nicht mehr korrekt extrahiert werden.

Stand April 2026 ist der Bug noch nicht eindeutig behoben. Es gibt Workarounds — manuelles Entpacken der .tar-Datei mit den Linux-Tools tar und gzip, dann selektives Wiederherstellen der einzelnen Komponenten — aber das ist nichts, was einer Hausautomatisierungs-Anwender ohne Linux-Kenntnisse hinbekommt. Das hat eine ärgerliche Konsequenz: Bei jedem Restore mit großem Datenbank-Addon ist die Wahrscheinlichkeit, dass dieses Addon fehlt, hoch.

Die Empfehlung der erfahrenen Nutzer im r/homeassistant lautet seither: Datenbanken separat sichern. Nicht als Teil der HA-Backup, sondern über die Datenbank selbst (mariadb-dump, influx backup, pg_dump). Diese Backups sind klein, schnell wiederherstellbar und unabhängig vom Supervisor-Bug.

Die ehrliche 3-2-1-Strategie für Home Assistant 2026

Die Datensicherungs-Faustregel "3 Kopien, 2 Medien, 1 off-site" lässt sich auch auf Home Assistant anwenden. So sieht eine konkrete Umsetzung aus:

Kopie 1: Lokale Full Backups, automatisch erstellt

Im UI unter Settings → System → Backups eine automatische tägliche Backup einrichten. Behalt die letzten 7 Tage, weitere ältere wöchentlich. Die Default-Speichermenge ist meist okay; wer einen kleinen Pi 4 hat und nur 32 GB SD-Karte, sollte die Datenbankaddons aus der Backup ausschließen und sie separat sichern.

Kopie 2: Off-site auf NAS oder zweiter Maschine

Über das offizielle "Samba Backup" oder "Google Drive Backup" Addon lassen sich die täglichen Backups automatisch auf eine Synology, einen NAS oder ein anderes Netzwerklaufwerk schieben. Das Samba-Addon ist die einfachste Lösung im lokalen Netz, aber es schützt nicht gegen einen Wohnungsbrand. Wer das ernst meint, nutzt das Google-Drive-Addon (kostenlos für 15 GB) oder Nabu Casas eingebauten Cloud-Backup-Service (5 USD/Monat, automatisch aufgenommen in den Cloud-Plan).

Kopie 3: Nabu Casa Cloud Backup

Seit der Home Assistant 2026.3-Version ist das Cloud Backup ein erstklassiger Bestandteil von Nabu Casa. Die Backups werden verschlüsselt zu Backblaze hochgeladen, sind im UI direkt restorebar und überleben ohne weiteres Zutun einen kompletten Hardwareausfall. Wer die monatlichen 5 USD ohnehin für den Fernzugriff zahlt, hat hier die einfachste Lösung.

Zusätzlich: Datenbank-Snapshots separat

Wer eine MariaDB- oder InfluxDB-Instanz mit großem Datenbestand betreibt, sollte einen wöchentlichen mariadb-dump-Cron-Job einrichten und die Dumps separat ablegen. Beispiel über die SSH-Addon-Konsole:

mariadb-dump --all-databases --single-transaction \
  --quick --lock-tables=false \
  | gzip > /backup/maria_$(date +%Y%m%d).sql.gz

Eine wöchentliche solche Datei ist klein (typischerweise 50–500 MB), restorebar in unter zehn Minuten und unabhängig vom Supervisor-Backup-Mechanismus.

Migration zu neuer Hardware: Der Idealfall

Wenn die Backup vollständig und das Restore-System frisch ist, sieht die Migration so aus:

  1. Neue Hardware mit Home Assistant OS installieren (Yellow, Green, Pi 5 mit dem offiziellen Image, virtuelle Maschine).
  2. Beim Onboarding die Option "Restore from backup" wählen.
  3. Backup-Datei hochladen oder aus Cloud auswählen.
  4. Warten. Bei mittelgroßen Setups dauert das 30 bis 60 Minuten, bei großen mit zwanzig Addons auch 90 Minuten oder mehr.
  5. Nach Restart prüfen, ob alle Geräte wieder erreichbar sind.
In der Praxis muss man oft einzelne Addons hinterher noch einmal manuell starten oder neu konfigurieren, weil der Restore-Prozess zwar die Daten zurückspielt, aber bei Format-Mismatch zwischen alter und neuer Supervisor-Version stockt. Wer eine sehr alte Backup wiederherstellt (älter als ein Jahr), hat häufig ein Update-Problem: Der Supervisor will erst auf die neue Version migrieren, bevor er Addons startet. Das funktioniert in der Regel, dauert aber lange.

Was beim Pi 4 zu Pi 5-Wechsel zu beachten ist

Ein Sonderfall, den viele 2026 vor sich haben: Migration vom Raspberry Pi 4 (32-bit OS-Variante in alten Setups) auf den Pi 5 (rein 64-bit). Wer noch ein altes 32-bit-Image fährt, kann nicht direkt migrieren — die Backup ist zwar architekturunabhängig, aber bestimmte Addons sind plattformspezifisch.

Die Migration läuft so: Erst auf dem alten Pi auf 64-bit aktualisieren (was in den meisten Fällen ohnehin nötig ist, weil Home Assistant Core 2025.x die 32-bit-Pi-Unterstützung beendet hat), dann frische Backup, dann auf dem Pi 5 restoren. Dieser Zwischenschritt verhindert die meisten Format-Probleme.

Wer einen Z-Wave-USB-Stick weiternutzen will, muss daran denken, dass der Stick im neuen Pi auf einem anderen /dev/ttyUSB-Pfad landen kann. Im Restore-Prozess merkt man das daran, dass die Z-Wave-Integration nach dem ersten Reboot rot wird. Lösung: Settings → Geräte → Z-Wave → Konfigurieren → richtigen seriellen Port auswählen.

Wenn das Restore versagt: Plan B

Tobias hat seine sechs Jahre InfluxDB nicht über das Supervisor-Restore zurückbekommen. Was er stattdessen gemacht hat: Die .tar-Backup-Datei manuell entpackt, aus dem Inneren das Verzeichnis addon_a0d7b954_influxdb extrahiert, das eigentliche Datenverzeichnis des Addons (mit den .tsm-Dateien) auf den neuen Pi kopiert und dann das InfluxDB-Addon manuell installiert, gestoppt, das Datenverzeichnis ausgetauscht und neu gestartet. Das hat funktioniert, hat aber zwei Stunden gedauert und Linux-Kenntnisse verlangt. Alternativen, die für ihn funktioniert hätten: ein zweites Skript (influx backup), das die Datenbank wöchentlich extra sichert. Hat er heute eingerichtet.

Andere Plan-B-Optionen, wenn das Restore nicht durchläuft:

Manueller Konfig-Restore: Nur den Inhalt von /config aus der Backup-Datei extrahieren und auf eine frische Home-Assistant-Installation kopieren. Geht in der Praxis sehr gut: alle Automations, Scripts, Lovelace-Layouts, Custom-Components werden dadurch zurückgespielt. Was fehlt sind die Addons und die Geräte-Registrierung. Letztere muss man unter Umständen neu pairen. Partial Restore Cherry-Picking: In der HA-UI bei einer hochgeladenen Backup nur einzelne Komponenten anklicken (z.B. nur "Home Assistant Core configuration" und "Mosquitto"). Das umgeht den Bug 4909 für die nicht-betroffenen Teile. Rückfall auf vorletzte Backup: Wenn die letzte Backup defekt ist, die vorletzte versuchen. Die Wahrscheinlichkeit, dass zwei Backups hintereinander dieselbe Korruption haben, ist klein.

Was 2026 wichtiger ist als 2024

Drei Dinge haben sich in den letzten zwei Jahren geändert:

  1. Cloud Backup ist erwachsen geworden. Nabu Casas integriertes Cloud-Backup ist Stand 2026 zuverlässiger als die meisten DIY-Lösungen. Wer zahlt, sollte es nutzen.
  1. Recorder-Datenbanken brauchen separate Sicherung. Mit dem Supervisor-Bug 4909 ist das vom "nice to have" zur Pflicht geworden, wenn die Datenbank-Historie wertvoll ist.
  1. Netzwerk-State braucht eigenes Backup. Wer einen Sonoff-Koordinator, einen separaten Z2M-Server oder ein Z-Wave-Mesh hat, sollte den Zigbee-Network-Backup (Settings → Geräte → Zigbee → Backup) und das Z-Wave-NVM-Backup separat ablegen. Die HA-Full-Backup enthält diese Komponenten nur, wenn sie über den Supervisor laufen.
Die Quintessenz: Eine einzelne automatische Sonntagnacht-Backup ist nicht mehr genug. Wer ernsthaft auf seine Hausautomatisierung angewiesen ist, betreibt 2026 eine kleine Backup-Pyramide. Drei Schichten, vielleicht eine Stunde Setup-Zeit am ersten Wochenende, und danach läuft sie still im Hintergrund. Das einzige, was du regelmäßig tun musst: ein Restore-Test einmal im halben Jahr, in einer virtuellen Maschine. Eine Backup, die nie ausprobiert wurde, ist eine Hoffnung. Eine Backup, die einmal getestet wurde, ist eine Sicherheit.

Tobias hat seitdem genau das eingeführt. Im Oktober wird er das nächste Mal proben. Das InfluxDB-Backup-Skript läuft jetzt jeden Mittwoch und Sonntag.

[^1]: GitHub Issue home-assistant/supervisor#4909, "New backup format in latest supervisor breaks partial restore", offen seit Februar 2024. https://github.com/home-assistant/supervisor/issues/4909

[^2]: Home Assistant Green Documentation, "Restoring or migrating Home Assistant Green from a backup" (Stand Februar 2026). https://green.home-assistant.io/guides/restore-backup/

[^3]: GitHub Issue home-assistant/supervisor#5637, "Restoring partial backups not possible", geschlossen 2025.