Saltar a contenido

Failure mode: recorder DB bloat / lentitud

Quinta entrada del catálogo. La base de datos del recorder de HA (SQLite default, o MariaDB/PostgreSQL externa) crece sin control hasta que HA arranca lento, UI lagea, queries históricas timeout, o el disco se llena. Causa: política de retention default sub-óptima + muchos entities con high-frequency updates.

Cómo se manifiesta

  • HA UI tarda 10+ segundos en cargar dashboards con history graphs.
  • Restarts de HA toman 5-15 min (default 30-60s sano).
  • Disk usage growing 1+ GB/mes en /config/home-assistant_v2.db (SQLite).
  • Alertas Recorder timeout o Failed to commit transaction en logs.
  • Eventualmente: disk full → HA no arranca.

Cómo se detecta proactivamente

  • Prometheus: node_filesystem_avail_bytes{mountpoint="/"} < 10% — alerta.
  • HA exporter: tiempo de restart como métrica derivada.
  • Custom check via Gatus: response time del API /api/states > 5s.
  • Direct query: SELECT COUNT(*) FROM states — si > 5M rows, hay bloat.

Cómo se previene

Configuración recomendada del recorder

En configuration.yaml:

recorder:
  # default es SQLite — para production considerar MariaDB en mini-PC
  db_url: !secret recorder_db_url
  purge_keep_days: 14  # retention en DB (default 10)
  commit_interval: 5   # batch writes (default 1)
  include:
    domains:
      - sensor
      - binary_sensor
      - climate
      - light
      - lock
      - switch
  exclude:
    entity_globs:
      - sensor.*_uptime
      - sensor.*_last_seen
      - sensor.weather_*
      - sensor.sun_*
    event_types:
      - call_service  # noisy, raramente útil

Por qué exclude agresivo

  • Cada state change ocupa ~100-500 bytes según attributes.
  • Sensors de weather, sun, uptime cambian frecuente y casi nunca son útiles en history.
  • Excluir el 20% de entities más ruidosas reduce DB size en 50%+.

Migrar a MariaDB / PostgreSQL externa

Cuando SQLite ya no alcanza (típicamente >5 GB):

  1. Levantar MariaDB / PostgreSQL en mini-PC (docker compose).
  2. Configurar recorder.db_url en HA.
  3. Migración: HA crea schema nuevo; el history viejo de SQLite se pierde salvo migración manual.
  4. Backups del DB externo van al stack normal de backups.

Long-term storage separado

Para métricas que sí querés a largo plazo (consumo eléctrico, temperatura outdoor):

  • HA Statistics integration (no recorder) — agrega métricas con hourly buckets.
  • O integrar InfluxDB + HA → escribe a InfluxDB en paralelo al recorder.
  • Recorder se queda con 14 días (UI rápido), InfluxDB con histórico largo (queries Grafana).

Cómo se recupera

Caso A — DB ya enorme pero HA arranca

  1. Backup pre-cualquier cosa.
  2. Bajar purge_keep_days a 7.
  3. recorder.purge service call → fuerza limpieza inmediata.
  4. VACUUM del SQLite (HA lo hace por default en sleep window, pero se puede forzar).
  5. Restart HA. Tiempo de restart debería bajar dramáticamente.

Caso B — Disk full, HA no arranca

  1. SSH al Yellow / mini-PC.
  2. No borrar home-assistant_v2.db directamente — corrompe el state registry.
  3. Truncar tablas grandes manualmente vía sqlite CLI: 
    sqlite3 home-assistant_v2.db
DELETE FROM states WHERE last_updated < datetime('now', '-7 days');
VACUUM;
  4. Restart HA.

Caso C — DB corrupta (rare pero pasa)

  1. Restore desde backup.
  2. Si no hay backup reciente: reinit DB. HA reconstruye desde state actual; histórico se pierde.

Lo que el agente AI hace (perímetro autónomo)

Acción ¿Autónomo?
Alertar cuando disk > 80% lleno Sí desde mes 1
Force recorder.purge cuando disk > 90% Sí desde mes 3 (operación documentada-safe)
Bajar purge_keep_days dinámicamente No, pide approval (cambio de config persistente)
Migración a MariaDB Nunca — change muy grande, humano
VACUUM scheduled Sí vía cron

Relaciones

Abierto / gaps

  • Patrón concreto de migración SQLite → MariaDB sin pérdida de history (no trivial).
  • Patrón "long-term storage en InfluxDB en paralelo al recorder" como techniques/long-term-storage-influxdb.
  • ¿HA Statistics integration es suficiente para el use case "ver consumo eléctrico anual"? Probable que sí.