Home-Assistant-Datenbank auf Proxmox: MariaDB und Recorder sicher einrichten

Home Assistant funktioniert ohne externe Datenbank. Die eingebaute SQLite-Datenbank ist laut offizieller Dokumentation der empfohlene Standard. Ein eigener MariaDB-Gast ist sinnvoll, wenn du Datenbankbetrieb, Backup und Speicher bewusst auslagern willst. In meinem Homelab läuft Home Assistant als VM und MariaDB als separater Proxmox-LXC. Diese Anleitung zeigt eine neue Einrichtung – nicht die blinde Migration einer bestehenden Historie.

Wichtig: Home Assistant unterstützt beim Wechsel des Recorder-Datenbanktyps keine automatische Migration der alten Verlaufsdaten. Plane deshalb einen Backup- und Umstellungszeitpunkt. Wer mit SQLite zufrieden ist, muss diesen Umbau nicht machen.

Schritt 1: Vor dem Umbau sichern

Erstelle zuerst ein vollständiges Home-Assistant-Backup und ein Proxmox-Backup der VM. Dokumentiere die bestehende recorder:-Konfiguration. Die neue MariaDB braucht ebenfalls ein eigenes Backup-Ziel. Ein Snapshot ersetzt keinen geprüften Export, ist aber ein guter Rückkehrpunkt vor der Umschaltung.

Schritt 2: MariaDB-LXC auf Proxmox installieren

Für ein neues Homelab kannst du den MariaDB-Installer der Proxmox-Community-Skripte nutzen. Prüfe den heruntergeladenen Quelltext und wähle im Dialog Speicher, CPU, RAM, Netzwerk und Backup-Ziel. Ein Beispielbefehl für Debian:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/mariadb.sh)"

Notiere die neue ID als <CTID> und prüfe:

pct status <CTID>
pct exec <CTID> -- systemctl is-active mariadb
pct exec <CTID> -- mariadb-admin ping
pct exec <CTID> -- mariadb --version

Für produktive Systeme Versionssprünge nicht ungeprüft übernehmen. Bei mir läuft eine getestete MariaDB-12.3-Installation; die aktuelle Script-Seite kann inzwischen eine andere Hauptversion anbieten. Vor Upgrades immer die Kompatibilität zu Home Assistant und ein Rücksicherungsszenario prüfen.

Schritt 3: Datenbank und eingeschränkten Benutzer anlegen

Betrete den MariaDB-Gast und öffne die lokale SQL-Konsole:

pct enter <CTID>
sudo mariadb

Ersetze HA_VM_IP durch die IP der Home-Assistant-VM und vergib ein eigenes langes Kennwort. Der SQL-Block wird nur auf deiner privaten Instanz ausgeführt:

CREATE DATABASE homeassistant
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'homeassistant'@'HA_VM_IP'
  IDENTIFIED BY 'EIN_EIGENES_LANGES_PASSWORT';
GRANT ALL PRIVILEGES ON homeassistant.*
  TO 'homeassistant'@'HA_VM_IP';
FLUSH PRIVILEGES;
SHOW GRANTS FOR 'homeassistant'@'HA_VM_IP';
EXIT;

Die Host-Einschränkung ist absichtlich enger als '%'. MariaDB soll nur aus der Home-Assistant-VM erreichbar sein. Falls MariaDB ausschließlich auf Loopback lauscht, muss die Bind-Adresse für das interne Interface angepasst werden; danach Firewall auf genau den benötigten Client und TCP-Port 3306 begrenzen. Keine öffentliche Portfreigabe.

Schritt 4: Zugangsdaten in Home Assistant ablegen

In /config/secrets.yaml eine URL mit deinem Benutzernamen, Kennwort und privaten Datenbank-Host eintragen. Sonderzeichen im Passwort müssen URL-kodiert werden:

mariadb_url: "mysql://homeassistant:EIN_URL_KODIERTES_PASSWORT@DB_HOST/homeassistant?charset=utf8mb4"

In /config/configuration.yaml referenzierst du nur noch das Secret:

recorder:
  db_url: !secret mariadb_url
  purge_keep_days: 10
  auto_purge: true
  auto_repack: true

DB_HOST ist der private DNS-Name beziehungsweise die interne Adresse des MariaDB-Gasts. Verwende nicht localhost, denn Home Assistant und MariaDB laufen in unterschiedlichen Gästen. Schütze secrets.yaml und nimm die Datei nicht in öffentliche Repositories auf.

Schritt 5: Konfiguration prüfen und Recorder beobachten

Nutze in Home Assistant Entwicklerwerkzeuge → YAML → Konfiguration prüfen. Nur bei erfolgreicher Prüfung Home Assistant geplant neu starten. Danach:

pct exec <CTID> -- mariadb-admin ping
pct exec <CTID> -- mariadb-check homeassistant --quick
pct exec <CTID> -- df -h

In Home Assistant unter Einstellungen → System → Protokolle nach Recorder-Verbindungsfehlern suchen. Prüfe außerdem, ob der Verlauf für ein bekanntes Sensor-Entity neue Punkte bekommt. Auf der Datenbankseite muss die Zahl der neu geschriebenen Zustände über Zeit steigen; ein einmalig erfolgreicher Login beweist das noch nicht.

Warum die Aufbewahrung so wichtig ist

Wenn purge_keep_days deutlich größer als die bisherige Laufzeit ist, greift die automatische Bereinigung noch nicht. So kann die Datenbank über Monate wachsen, obwohl auto_purge eingeschaltet ist. Zehn Tage Rohhistorie sind für viele Setups ein guter Start; Langzeitstatistiken sind davon getrennt zu betrachten. Wähle den Wert bewusst nach Speicher und Analysebedarf.

Bei Platzproblemen zuerst Datenbankgröße, freie Blöcke, Schreiblast und Recorder-Konfiguration untersuchen. Ein DROP DATABASE löscht Historie und ist keine reguläre Wartung. Wenn nötig, vorher konsistenten Dump und Restore-Test vorbereiten.

Backup und Rückweg

Ein anwendungsnaher Dump für eine geplante Sicherung sieht so aus:

mariadb-dump --single-transaction --quick \
  --routines --events --triggers homeassistant \
  | gzip -1 > homeassistant-$(date +%F).sql.gz
gzip -t homeassistant-YYYY-MM-DD.sql.gz

Der Befehl gehört in eine geschützte Umgebung mit passender DB-Authentifizierung; das Archiv enthält private Smart-Home-Daten. Zusätzlich den MariaDB-LXC auf PBS sichern. Für den Rückweg das Home-Assistant-Backup und die alte Recorder-Konfiguration bereithalten; eine neue externe Datenbank nicht mit einer alten SQLite-Historie verwechseln.

Quellen und Ergänzungen: offizielle Recorder-Dokumentation · Proxmox-Backups im Homelab.