Home Assistant sollte nur dann einen separaten Datenbank- oder Speicherhost verwenden, wenn diese Trennung ein nachgewiesenes Problem bei Kapazität, Aufbewahrungsdauer, Backups oder der Fehlerdomäne löst. Das Auslagern des Zustands vom Controller ist nicht automatisch eine Verbesserung.
Für viele Haushalte ist eine lokale SQLite-Recorder-Datenbank auf zuverlässigem SSD-Speicher der einfachste Weg, da dadurch Abhängigkeiten von Netzwerk, Authentifizierung, DNS und dem Start eines Datenbankservers entfallen. Bevor Sie einen weiteren Host einrichten, ermitteln Sie zunächst, ob das eigentliche Problem zu viele Recorder-Schreibvorgänge, eine zu lange Aufbewahrungsdauer, langsame Verlaufsabfragen, begrenzte lokale Kapazität oder die Notwendigkeit ist, einen Dienst unabhängig wiederherzustellen.
Optimieren Sie den Recorder, bevor Sie einen Datenbankserver hinzufügen
Das Wachstum des Recorders wird durch die gespeicherten Entitäten und Ereignisse, ihre Änderungsfrequenz und die Dauer der Verlaufsaufbewahrung bestimmt. Wenn geräuschvolle Sensoren oder unnötige Domänen den Großteil der Schreibvorgänge verursachen, verlagert das Verschieben derselben Arbeitslast auf einen größeren Datenbankserver das Problem lediglich, statt es zu beseitigen.
Ein aktueller Optimierungsablauf für den Recorder zeigt, wie Aufbewahrungsdauer, Include-/Exclude-Regeln und das Commit-Verhalten die Schreiblast beeinflussen, bevor eine Datenbankmigration in Betracht gezogen wird. Messen Sie nach der Optimierung die Datenbankgröße, die Dauer von Verlaufsabfragen, die Speicherlatenz und die Schreibaktivität.
Belassen Sie die Datenbank lokal, wenn die optimierte Arbeitslast reaktionsschnell bleibt, Backups innerhalb des Wartungsfensters abgeschlossen werden und ausreichend SSD-Kapazität verfügbar ist. Eine Trennung sollte auf einer nicht erfüllten Anforderung beruhen, nicht auf der allgemeinen Annahme, dass Client-Server-Datenbanken immer schneller sind.
Verwenden Sie eine externe Datenbank, wenn ihre betrieblichen Vorteile tatsächlich bestehen
Ein separater MariaDB-, MySQL- oder PostgreSQL-Host kann sinnvoll sein, wenn Home Assistant eine bereits gut betriebene Datenbankplattform mitnutzt, eine lange Aufbewahrungsdauer dauerhaft zu hoher Abfragelast führt, der Controller-Host schlank oder austauschbar bleiben muss oder Datenbanksicherung und -überwachung einen unabhängigen Lebenszyklus benötigen.
Ein Beispiel für eine SQLite-zu-MariaDB-Migration veranschaulicht die zusätzlichen Komponenten dieser Entscheidung: Datenbankdienst, Zugangsdaten, Netzwerkadresse, Schemainitialisierung, Migrationsverfahren, Validierung und Rollback. Ein umfangreicherer Praxisfall zur Migration einer Home-Assistant-Datenbank zeigt, warum eine lange Historie und große Datenmengen den zusätzlichen Administrationsaufwand rechtfertigen können.
Der ZimaSpace-Artikel über die Zuverlässigkeit externer Datenbanken bei Upgrades beschreibt die entsprechende Wartungsgrenze: Die Datenbank muss als eigener Dienst gesichert, aktualisiert und wiederhergestellt werden, statt als unsichtbare Infrastruktur behandelt zu werden.
Speichern Sie eine aktive SQLite-Datenbank nicht standardmäßig auf einer Netzwerkfreigabe
Ein Remote-Datenbankserver und eine auf SMB oder NFS gespeicherte Datenbankdatei sind unterschiedliche Architekturen. Eine Client-Server-Datenbank führt Sperren und Transaktionen innerhalb des Datenbankdienstes aus und sendet Anfragen über das Netzwerk. SQLite führt die Sperrung der Datenbankdatei über das Dateisystem durch, sodass Semantik, Verfügbarkeit, Latenz und Sperrverhalten des Netzwerkdateisystems Bestandteil jeder Transaktion werden.
Die umfassendere Analyse der SQLite-Sperrung erklärt, warum Netzwerkdateisysteme ein anderes Sperrverhalten als lokale Datenträger hervorrufen können. Ein Fehlerfall mit einer Netzwerkfreigabe für Home Assistant zeigt das praktische Risiko, wenn die aktive Recorder-Datenbank von einer Remote-Einhängung abhängt.
Verwenden Sie ein NAS problemlos für Sicherungskopien, Exporte, Medien und andere Daten, die für die Netzwerkspeicherung vorgesehen sind. Wenn der aktive Recorder-Zustand auf einem anderen Rechner liegen muss, bevorzugen Sie eine unterstützte Client-Server-Datenbank, statt die SQLite-Datei auf eine Freigabe zu verschieben.
Trennen Sie Massenspeicher vom aktiven Home-Assistant-Zustand
Nicht jedes wachsende Home-Assistant-Verzeichnis gehört in dieselbe Speicherebene. Konfiguration, Integrationszustand, die aktive Recorder-Datenbank, Medien, Kameraclips, Exporte und Backups haben unterschiedliche Anforderungen an Latenz und Wiederherstellung. Belassen Sie kleine, häufig aktualisierte Zustandsdaten auf lokalem Speicher mit niedriger Latenz, sofern sie nicht bewusst von einem separaten Dienst verwaltet werden.
Verschieben Sie umfangreiche Medien oder Backup-Generationen auf NAS-Kapazität hinter stabilen Einhängepunkten. Dokumentieren Sie, ob Home Assistant ohne diese Einhängung starten darf. Ein fehlendes Fotoarchiv sollte den Start von Lichtautomationen nicht verhindern, während eine fehlende aktive Datenbank einen ausdrücklich eingeschränkten Zustand auslösen sollte, statt unbemerkt auf eine Fallback-Lösung auszuweichen.
| Datenrolle | Standardplatzierung | Grund für die Trennung |
|---|---|---|
| Konfiguration und aktiver Zustand | Lokale SSD | Geringe Latenz und einfache Wiederherstellung |
| Recorder-SQLite | Lokale SSD | Abhängigkeiten von Sperren auf Netzwerkdateisystemen vermeiden |
| Externe SQL-Datenbank | Lokaler oder separater Datenbankhost | Unabhängige Skalierung, Aufbewahrung, Sicherung und Administration |
| Medien und Exporte | Lokal oder NAS | Kapazität ist oft wichtiger als Latenz |
| Backups | Mindestens eine Kopie außerhalb des Hosts | Den Verlust des aktiven Hosts überstehen |
Überprüfen Sie Start, Ausfälle und Wiederherstellung, bevor Sie die Trennung dauerhaft einführen
Stellen Sie die neue Datenbank- oder Speicherrolle bereit, ohne den bisherigen Wiederherstellungspfad zu löschen. Starten Sie den Datenbankhost vor Home Assistant neu, starten Sie Home Assistant, bevor die Datenbank bereit ist, unterbrechen Sie das Netzwerk, ändern Sie Zugangsdaten, füllen Sie das Zielfilesystem nahezu bis zur Reservegrenze und stellen Sie die Datenbank auf einer sauberen Instanz wieder her.
Messen Sie die p95-Zeit von Verlaufsabfragen, die Latenz von Automationen während hoher Recorder-Aktivität, die Neustartdauer, die Backupdauer und die Wiederherstellungszeit nach einem Ausfall des Datenbankhosts. Wenn die Trennung eine Kennzahl verbessert, aber aus einem dreißigsekündigen Controller-Neustart ein Wiederherstellungsablauf über mehrere Dienste macht, beziehen Sie diese betrieblichen Kosten in die Entscheidung ein.
Behalten Sie den lokalen Speicher bei, wenn er die Zielanforderungen bereits erfüllt. Verwenden Sie einen separaten Datenbankhost, wenn Client-Server-Datenbankoperationen und eine unabhängige Wiederherstellung echte Vorteile bieten. Verwenden Sie für umfangreiche Daten und Backups einen separaten Speicherhost, machen Sie jedoch die kritische lokale Steuerung nicht ohne getesteten Grund von einem entfernten Dateisystem abhängig.
NAS- und Servereinrichtung
Mehr zum Lesen

Eine lokale RAG-Einrichtung für Forschungsarbeiten, Notizen und private Dokumente
Originaldokumente bleiben maßgeblich, die Indexierung wird wiederholbar gestaltet, Zitate sind erforderlich, und austauschbare Modelle werden von privaten Quelldaten getrennt.

Warum verwenden Entwickler einen Gateway-Knoten für private DNS-Dienste, VPNs und Test-Apps?
Ein Gateway-Knoten bietet privaten Apps einen kontrollierten Namen und Zugangsweg, während Compute-Knoten nicht öffentlich zugänglich und austauschbar bleiben.

So erstellst du einen reproduzierbaren App-Stack mit getrennten Compose-Dateien, Secrets und persistenten Daten
Halten Sie Compose-Definitionen portabel, schützen Sie Geheimnisse und sichern Sie App-Daten unabhängig, damit der Stack auf einem sauberen Host neu erstellt werden kann.

