Die Kurzfassung: Wir zogen fünf Jahre Home-Assistant-Verlauf — mehr als 400 Millionen Datenpunkte — aus dem InfluxDB-1.x-Add-on auf einen eigenen InfluxDB-2.x-Server um, ohne einen einzigen Punkt zu verlieren und ohne ein einziges Grafana-Dashboard umzuschreiben. Drei Phasen, eine Naht, null Drama.

Das ist die Geschichte dieser Migration: wie wir sie in Phasen planten, welche Fallstricke uns fast erwischt hätten und was wir anders machen würden, wenn wir es noch einmal tun müssten (und was wir exakt genauso machen würden).

Warum überhaupt migrieren?

Das Add-on hat uns jahrelang gute Dienste geleistet, aber drei Dinge gaben den Ausschlag:

  1. Kopplung. InfluxDB lebte innerhalb von Home Assistant. Jeder HA-Neustart, jedes Add-on-Update oder jeder Platten-Aussetzer zog die Datenbank mit — und umgekehrt.
  2. InfluxDB 1.x ist end-of-life. Die 2.x-Linie ist die Gegenwart, und das Add-on stand auf altem Code still, während unsere Anforderungen weiterwuchsen.
  3. Isolation. Eine Zeitreihen-Datenbank ist ein langlebiger, plattenhungriger Dienst. Sie verdient ein eigenes Zuhause, inklusive eigener Neustarts.

Also das Ziel: neue Server, gleiche Historie, gleiche Dashboards, null Datenverlust.

Der Plan: drei Phasen, kein „Big Bang"

Der verlockende Ansatz ist ein großer Cutover: Add-on stoppen, alles exportieren, importieren, HA umstellen. Das klingt einfach — und genau so verliert man Daten. Ein Voll-Export von 400 Mio.+ Zeilen dauert Stunden, und „jetzt" verschiebt sich, während man arbeitet. Alles, was nach deinem Snapshot eintrifft, wird zur Lücke.

Wir haben die Migration in drei Phasen aufgeteilt:

Phase Was Datenfenster
1. Historischer Import Bulk-Export aller 5 Jahre aus dem 1.x-Add-on → Import in 2.x 5 Jahre, die Masse (400 Mio.+ Zeilen)
2. Live-Cutover HA-InfluxDB-Integration zeigt auf den neuen Server Alles ab dem Cutover
3. Lücken-Merge Nur den Abschnitt zwischen Snapshot und Cutover exportieren + importieren Minuten, ~80k Punkte

Der Kern: nur Phase 3 ist zeitkritisch. Die Phasen 1 und 2 können jederzeit passieren; Phase 3 schließt die Naht.

Phase 1: 400 Mio.+ Zeilen verschieben (der langweilige, lange Teil)

Das entscheidende Tool: influx_inspect

Unser erster Versuch nutzte die normale influx-CLI des Add-on-Containers, um Line Protocol zu exportieren. Sie scheiterte sofort — dieser spezielle 1.x-Build unterstützt das benötigte Exportformat schlicht nicht. Es wurde nichts beschädigt, denn das Skript hatte eine eingebaute Sicherheitsklappe: Es brach vor dem Importschritt ab, sobald der Export nicht die erwartete Ausgabe lieferte.

Das Tool, das tatsächlich funktionierte, ist das, das InfluxDB genau für diesen Job mitliefert: influx_inspect export. Es schreibt die rohen Shards direkt als Line Protocol — keine Queries, kein Pagination-Schmerz, einfach ein Stream.

Reality Check: es ist riesig

  • 402.431.663 Zeilen über 10 Measurements (W, kWh, °C, %, A, bar, hPa, EUR, MAD, m³), jeweils mit domain- und entity_id-Tags.
  • Der gzippte Export war 2,95 GB. Auf einer kleinen HA-Platte zählt das.
  • Alte InfluxDB-1.x-Timestamps haben Nanosekunden-Präzision — und die Line-Protocol-Standards können das stillschweigend abschneiden. Wir schrieben mit precision=ns, damit jeder historische Timestamp bitgenau überlebte.

Import

Der Import auf den neuen InfluxDB-2.x-Server war ein direkter Line-Protocol-Write des Exports. Lang, langweilig und genau das, was wir wollten: keine Punkt-für-Punkt-API-Aufrufe, eine Streaming-Pipe, Stunden statt Wochen.

Fallstrick #1: unterschätze die Exportdatei nicht — 2,95 GB komprimiert passen nicht überall hin. Prüfe zuerst den freien Speicher auf beiden Hosts.

Fallstrick #2: vertraue nicht der Standard-Zeitstempel-Präzision. Wenn du jahrzehntelange Historie importierst, erzwinge precision=ns.

Phase 2: der Cutover

Mit der sicher auf dem neuen Server gelagerten Historie war der dramatische Teil eigentlich langweilig by design: Wir ließen die HA-InfluxDB-Integration auf den neuen Server zeigen, mit einem scoped Token (Read + Write auf genau dem Bucket, sonst nichts).

Das erste Anzeichen für Probleme wären HTTP-401s in den HA-Logs gewesen — wir sahen keine. Eine Minute später landeten neue Punkte auf dem neuen Server. HA schrieb live, und das alte Add-on wurde geräuschlos still.

Phase 3: die Lücke schließen (nicht überspringen)

Hier ist der Teil, den die meisten Migrationsanleitungen vergessen. Zwischen dem Moment unseres Snapshots und dem Moment, in dem HA umschaltete, empfing das alte Add-on weiterhin Live-Daten. Hätten wir dort aufgehört, fehlte dieser Abschnitt für immer.

Wir exportierten dieses Fenster — ~80.337 Punkte — über die schreibgeschützte v1-HTTP-Query-API mit epoch=ns, gzippten es und POSTeten es an den neuen Server. Ergebnis: 82.489 Punkte auf dem neuen Server bei der anschließenden Verifikation (die Differenz ist die Live-Daten, die dazwischen eintrafen).

Eine Datenlücke von 80k Punkten zu schließen, wenn der Datensatz 400 Mio. Zeilen umfasst, fühlt sich antiklimaktisch klein an — und genau das ist der Punkt. Diese winzige Naht ist es, was „null Datenverlust" bedeutet.

Der Trick, der unsere Dashboards rettete: v1-Kompatibilität

Wir erwarteten, dass das Umschreiben der Grafana-Dashboards für InfluxDB 2.x der schlimmste Teil würde. War es nicht. InfluxDB 2.x bringt eine v1-kompatible HTTP-API mit, und Grafana kann sie einfach im InfluxQL-Modus nutzen: gleiche Queries, gleiche Dashboards, null Umschreibungen.

Jedes unserer Panels — Energie, Klima, Wasserdruck, Wechselkurse — funktionierte weiter, sobald die Data Source auf den neuen Host zeigte.

Faustregel: nutzt du nur InfluxQL, dann ist deine Migration mit v1-compat ein Server-Tausch, keine Query-Migration. Hast du eigene Flux-Queries geschrieben, auditiere die separat — dort versteckt sich die echte Arbeit.

Verifikation & Rollback

Zwei Dinge waren für uns nicht verhandelbar:

  1. Verifiziere, bevor du feierst. Wir prüften: Anzahl der Measurements (SHOW MEASUREMENTS), den neuesten Punkt (muss „jetzt" sein), Zählwerte auf dem neuen Server und Stichproben echter Sensor-Serien gegen den alten Server.
  2. Behalte das alte Add-on, bis du sicher bist. Wir stoppten es erst, als alles grün war — und löschten es trotzdem nicht. Ein gestopptes Add-on ist eine kostenlose Sicherung; in fünf Minuten wieder aktiviert, falls Monate später etwas in deinen Daten auftaucht.

Das klingt vielleicht übervorsichtig für „nur ein Datenbank-Umzug." Genau diese Vorsicht macht aus einer 400-Mio.-Zeilen-Migration ein Non-Event.

Gelernte Lektionen (die ehrliche Liste)

  1. Phase es. Ein Mega-Cutover bei 400 Mio. Zeilen ist, wie du ein Loch in deine Historie bekommst. Import → Cutover → Lücken-Merge schließt jede Naht.
  2. Teste die Tools zuerst in deinem Container. Das Add-on unterstützte das Exportformat nicht, das wir angenommen hatten. Wir merkten es nur dank einer Dry-Run-Sicherheitsklappe vor jedem Import sicher.
  3. Behalte die Platte zweimal im Blick. Exportdatei auf dem alten Host, neue Datenbank auf dem neuen Host — beide brauchen Luft. 2,95 GB komprimiert ≠ 3 GB unkomprimiert.
  4. Timestamps haben auch Gefühle. Nanosekunden-Präzision ist in alten Daten real; schreibe mit precision=ns oder rundest deine Historie stillschweigend.
  5. Die Lücke ist der Feind, nicht die großen Zahlen. Der angstmachende Moment sind die Minuten zwischen Snapshot und Cutover, nicht die 400 Mio. Zeilen.
  6. Nutze scoped Tokens. Das Token des neuen Servers hat Read+Write auf genau einem Bucket — sonst nichts.
  7. v1-compat ist dein Freund. Es verwandelte ein potenziell haarsträubendes Grafana-Umschreiben in „Data Source woandershin zeigen".
  8. Behalte das alte Add-on. Stopp es, lösche es nicht. Rollback-Versicherung kostet nichts und ist alles wert.

Was danach passierte

Das alte Add-on steht nun gestoppt — eine stille Sicherung. Die HA-Box bekam 2,95 GB frei (das Exportarchiv lag auf /share und ist weg, jetzt wo der neue Server verifiziert ist). Wir behielten einen leichtgewichtigen, schreibgeschützten Health-Check, der ein paar Mal am Tag läuft: Er bestätigt, dass der neue Server antwortet, dass Grafana antwortet und — am wichtigsten — dass Home Assistant immer noch schreibt und der neueste Punkt nie älter als eine Stunde ist. Falls das alte Add-on je wieder aufwacht, wollen wir das sofort wissen.

Fünf Jahre. Vierhundert Millionen Zeilen. Eine Naht, geschlossen mit ~80k Punkten. Neue Server, gleiche Historie, gleiche Dashboards, weiterhin live.

So zieht man das Gedächtnis eines Smart Homes um.