De korte versie: we verplaatsten vijf jaar Home Assistant-geschiedenis — meer dan 400 miljoen datapunten — uit de InfluxDB 1.x add-on naar een eigen InfluxDB 2.x-server, zonder één punt te verliezen en zonder één Grafana-dashboard te herschrijven. Drie fases, één naad, nul drama.

Dit is het verhaal van die migratie: hoe we hem in fases planden, welke valkuilen ons bijna te pakken namen, en wat we anders zouden doen als we het overnieuw moesten doen (en wat we precies hetzelfde zouden doen).

Waarom überhaupt migreren?

De add-on deed zijn werk jarenlang prima, maar drie dingen deden de deur dicht:

  1. Koppeling. InfluxDB leefde binnen Home Assistant. Elke HA-herstart, add-on-update of schijfhick-up nam de database mee — en andersom.
  2. InfluxDB 1.x is end-of-life. De 2.x-lijn is het heden, en de add-on stond stil op oude code terwijl onze behoeften bleven groeien.
  3. Isolatie. Een time-series-database is een langlevende, schijfhongerige dienst. Die verdient een eigen huis, inclusief eigen herstarts.

Dus het doel: nieuwe server, zelfde geschiedenis, zelfde dashboards, nul dataverlies.

Het plan: drie fases, geen “big bang”

De verleidelijke aanpak is één grote cutover: stop de add-on, exporteer alles, importeer het, zet HA om. Dat klinkt simpel — en het is precies hoe je data verliest. Een volledige export van 400M+ rijen duurt uren, en “nu” blijft verschuiven terwijl jij werkt. Alles wat na jouw snapshot binnenkomt wordt een gat.

We splitsen de migratie in drie fases:

Fase Wat Data-venster
1. Historische import Bulk-export van alle 5 jaar uit de 1.x add-on → import in 2.x 5 jaar, het gros (400M+ rijen)
2. Live cutover HA InfluxDB-integratie wijst naar de nieuwe server Alles vanaf de cutover
3. Gap-merge Alleen het stuk tussen snapshot en cutover exporteren + importeren Minuten, ~80k punten

De kern: alleen fase 3 is tijdkritisch. Fases 1 en 2 kunnen wanneer dan ook; fase 3 dicht de naad.

Fase 1: 400M+ rijen verplaatsen (het saaie, lange deel)

De tool die ertoe doet: influx_inspect

Onze eerste poging gebruikte de reguliere influx-CLI van de add-on-container om line protocol te exporteren. Dat faalde direct — die specifieke 1.x-build ondersteunt simpelweg het exportformaat niet dat we nodig hadden. Er werd niets beschadigd, want het script had een ingebouwde veiligheidsklep: het stopte vóór de importstap op het moment dat de export niet de verwachte output opleverde.

De tool die wél werkte is de tool die InfluxDB voor precies deze klus meelevert: influx_inspect export. Die dumpt de ruwe shards rechtstreeks naar line protocol — geen queries, geen pagination-pijn, gewoon één stream.

Reality check: het is enorm

  • 402.431.663 rijen verdeeld over 10 measurements (W, kWh, °C, %, A, bar, hPa, EUR, MAD, m³), elk met domain- en entity_id-tags.
  • De gezipte export was 2,95 GB. Op een kleine HA-schijf maakt dat uit.
  • Oude InfluxDB 1.x-timestamps hebben nanoseconde-precisie — en de line-protocol-defaults kunnen dat stilletjes afkappen. Wij schreven met precision=ns, zodat elke historische timestamp bit-voor-bit overleefde.

Import

De import naar de nieuwe InfluxDB 2.x-server was een rechte line-protocol-write van de export. Lang, saai en precies wat we wilden: geen per-punt-API-calls, één streaming pipe, uren in plaats van weken.

Valkuil #1: onderschat het exportbestand niet — 2,95 GB gecomprimeerd past niet overal. Check vrije schijfruimte op beide hosts vóór je begint.

Valkuil #2: vertrouw de standaard timestamp-precisie niet. Importeer je decennia-oude geschiedenis, forceer dan precision=ns.

Fase 2: de cutover

Met de geschiedenis veilig op de nieuwe server was het dramatische deel eigenlijk saai by design: we lieten de HA InfluxDB-integratie naar de nieuwe server wijzen met een scoped token (read + write op de bucket, niets meer).

Het eerste teken van problemen zou HTTP 401 in de HA-logs zijn geweest — we zagen er geen. Een minuut later landden nieuwe punten op de nieuwe server. HA schreef live, en de oude add-on werd geruisloos stil.

Fase 3: de naad dichten (sla dit niet over)

Hier is het deel dat de meeste migratiegidsen vergeten. Tussen het moment dat onze snapshot werd genomen en het moment dat HA omschakelde, bleef de oude add-on live data ontvangen. Hadden we daar gestopt, dan was dat stuk voor altijd weg.

We exporteerden dat venster — ~80.337 punten — via de read-only v1 HTTP query API met epoch=ns, gzip-compresseerden het en POSTten het naar de nieuwe server. Resultaat: 82.489 punten op de nieuwe server toen we daarna verifieerden (het verschil is de live data die tussentijds binnenkwam).

Een datagat van 80k punten dichten terwijl je dataset 400M rijen groot is, voelt anticlimactisch klein — en dat is precies de bedoeling. Die kleine naad is wat “nul dataverlies” betekent.

De truc die onze dashboards redde: v1-compatibiliteit

We verwachtten dat het herschrijven van Grafana-dashboards voor InfluxDB 2.x het ergste deel zou zijn. Was het niet. InfluxDB 2.x levert een v1-compatibele HTTP API, en Grafana kan die gewoon in InfluxQL-modus gebruiken: zelfde queries, zelfde dashboards, nul herschrijvingen.

Elk van onze panelen — energie, klimaat, waterdruk, wisselkoersen — bleef werken op het moment dat de data source naar de nieuwe host wees.

Vuistregel: gebruik je alleen InfluxQL, dan is v1-compat je migratie een serverwissel, geen query-migratie. Heb je eigen Flux-queries geschreven, audit die dan apart — dáár zit het echte werk verstopt.

Verificatie & rollback

Twee dingen waren voor ons niet onderhandelbaar:

  1. Verifieer vóór je viert. We checkten: aantal measurements (SHOW MEASUREMENTS), het nieuwste punt (moet “nu” zijn), tellingen op de nieuwe server, en steekproeven van echte sensor-series tegen de oude server.
  2. Houd de oude add-on tot je zeker bent. We stopten hem pas toen alles groen was — en verwijderden hem nog steeds niet. Een gestopte add-on is een gratis backup; binnen vijf minuten weer aan, mocht er maanden later iets in je data opduiken.

Dat klinkt misschien overdreven voorzichtig voor “gewoon een database verhuizen.” Het is precies de voorzichtigheid die van een 400M-rijen-migratie een non-event maakt.

Lessen geleerd (de eerlijke lijst)

  1. Faseer het. Eén mega-cutover op 400M rijen is hóe je een gat in je geschiedenis krijgt. Import → cutover → gap-merge dicht elke naad.
  2. Test de tools eerst in jouw container. De add-on ondersteunde het exportformaat niet dat we aannamen. We kwamen er veilig achter, alleen dankzij een dry-run-veiligheidsklep vóór elke import.
  3. Houd de schijf twee keer in de gaten. Exportbestand op de oude host, nieuwe database op de nieuwe host — beide hebben speling nodig. 2,95 GB gecomprimeerd ≠ 3 GB ongecomprimeerd.
  4. Timestamps hebben ook gevoelens. Nanoseconde-precisie is echt in oude data; schrijf met precision=ns of rond je geschiedenis stilletjes af.
  5. Het gat is de vijand, niet de grote getallen. Het spannende moment is de minuten tussen snapshot en cutover, niet de 400M rijen.
  6. Gebruik scoped tokens. Het token van de nieuwe server heeft read+write op precies één bucket — niets meer.
  7. v1-compat is je vriend. Het maakte van een mogelijk haarrijzende Grafana-herschrijving “wijs de data source ergens anders heen.”
  8. Houd de oude add-on. Stop hem, verwijder hem niet. Rollback-verzekering kost niets en is alles waard.

Wat er daarna gebeurde

De oude add-on staat nu gestopt — een stille backup. De HA-box kreeg 2,95 GB vrij (het exportarchief lag op /share en is weg nu de nieuwe server is geverifieerd). We hielden een lichtgewicht read-only healthcheck die een paar keer per dag draait: hij bevestigt dat de nieuwe server reageert, dat Grafana reageert, en — het allerbelangrijkste — dat Home Assistant nog steeds schrijft en het nieuwste punt nooit ouder is dan een uur. Mocht de oude add-on ooit weer wakker worden, dan willen we dat direct weten.

Vijf jaar. Vierhonderd miljoen rijen. Eén naad, gedicht met ~80k punten. Nieuwe server, zelfde geschiedenis, zelfde dashboards, nog steeds live.

Zo verplaats je het geheugen van een slim huis.