Home Assistant Energy Data Storage: Recorder vs InfluxDB vs Grafana

Quick Summary (TL;DR)

For most homes, Home Assistant Recorder with its default SQLite database is the best first choice for energy monitoring. It already supports the Energy dashboard and long-term statistics, without another server or database to maintain. Add InfluxDB when you have a defined need for higher-resolution history over months or years, complex queries, or a dedicated telemetry archive. Add Grafana if you want advanced visualisations, comparisons and analytical dashboards on top of that stored data. Grafana is not a database, and InfluxDB does not replace Recorder.

A sensible progression is Recorder → selective InfluxDB export → Grafana, not installing all three because a forum screenshot looks attractive. The main design questions are which measurements actually need long retention, how often they change, which database owns the data, and how backups and restores work. The correct answer for a 20-sensor household can be very different from the answer for a 400-entity house with solar PV, a heat pump, EV charging and sub-minute tariff analysis.

This guide uses Home Assistant terminology current in October 2026 and distinguishes high-resolution Recorder state history, short-term statistics, and hourly long-term statistics. It includes practical YAML, hardware sizing illustrations, storage arithmetic, retention planning, model comparisons, security advice and a commissioning checklist. All cost and capacity examples are illustrative rather than performance guarantees.

The short answer: Recorder, InfluxDB and Grafana solve different problems

Home Assistant integrates devices and manages live state, events, automations, history and statistics. Recorder is the subsystem that stores that activity. InfluxDB is a purpose-built time-series database that can receive selected state changes exported by a Home Assistant integration. Grafana queries a supported data source, such as InfluxDB, and turns its results into dashboards. Comparing them as three competing database products is therefore misleading: Recorder and InfluxDB are storage paths; Grafana is principally a query and presentation layer.

If the only goal is to see yesterday’s grid import, this month’s solar generation and last year’s consumption, the built-in Home Assistant Energy dashboard is designed for exactly that. Its statistics model can preserve useful historical summaries without retaining every second-by-second state change forever. By contrast, if an electrician needs to determine whether a 60-second EV charger power oscillation has been recurring every winter evening, hourly aggregate statistics may hide the behaviour. A selectively configured InfluxDB archive—or suitably extended Recorder retention—can preserve the required fidelity.

The best architecture is driven by a question, not a brand: “Which decisions or diagnoses require this data, and at what resolution?” A Grafana chart of high-frequency measurements can be useful, but it can also be confidently wrong if sensors have the wrong sign, counters reset unexpectedly, samples vanish during a WAN outage, or two energy boundaries are added twice.

Component	Primary role	What it stores or displays	Works without other two?	Typical recommendation
Recorder / SQLite	Core Home Assistant state and event history	Recent detailed history plus eligible statistics	Yes; built in	Default for most households
Recorder / external SQL	Same Recorder function on supported SQL server	Home Assistant history and statistics in managed SQL backend	Yes, but extra administration	Specialist SQL use, not a default speed upgrade
InfluxDB	Parallel time-series export and retention	Selected HA states at recorded change times	Yes as a database, but needs a data producer	Add for long high-resolution telemetry
Grafana	Queries, charts, panels, dashboards	Dashboard definitions; data remains in data sources	Needs a configured source	Add for engineering analysis and custom displays
Built-in Energy dashboard	Energy accounting presentation	Uses Home Assistant statistics	Works with Recorder	Start here before buying anything

Understand Home Assistant Recorder before adding more storage

Home Assistant Recorder documentation identifies SQLite as the default and recommended database engine, with its file at /config/home-assistant_v2.db. That matters: many advice threads still suggest immediately migrating to MariaDB on a NAS AliExpress price, although extra moving parts are not automatically a performance improvement. SQLite can work very well for a modest Home Assistant installation, particularly on SSD-backed storage and with the standard purge and repack policies.

By default Recorder retains detailed state/event history for 10 days. Its auto_purge setting is enabled and purge_keep_days is 10 unless changed; the current documentation also describes an automatic repack schedule. These details are configurable and can change between releases, so verify against your installed version before making a large retention adjustment. Do not assume deleting entries from the UI immediately reduces the database file size: reclaiming disk space can require repacking, and a long-running task may need time and free space.

Recorder logs changes; it does not sample every entity at a fixed frequency regardless of whether it changed. A power sensor that changes once every second can create orders of magnitude more records than a battery percentage that updates every five minutes. Likewise a chattering relay, noisy Wi-Fi device, constantly changing attribute or misconfigured template can generate enormous history with little analytical value. Eliminating noisy or irrelevant entities often provides more benefit than buying a faster processor.

Setting / concept	Current documented default	Implication	When to customise
`db_url`	SQLite in configuration directory	Simple, local and no external database dependency	Only with a clear SQL-operational requirement
`purge_keep_days`	10 days	Bounded detailed state history	Need 20–30 day device-event analysis and have capacity
`auto_purge`	Enabled	Periodic pruning of old detailed state rows	Almost never disable without alternate policy
`auto_repack`	Enabled	Reclaims unused database space periodically	Monitor free disk before heavy repacks
`commit_interval`	5 seconds	Balances database writes and latency	SD wear tuning with understood durability trade-off
Long-term statistics	Never automatically purged	Retains eligible aggregated measurements	Use correct sensor metadata, not infinite raw retention

Detailed history is not the same as long-term energy statistics

Home Assistant keeps different levels of data. Its detailed history records state transitions for the configured retention window, normally 10 days. For sensors that qualify for statistics, Home Assistant also calculates short-term summaries at five-minute intervals and long-term summaries each hour. The official long-term statistics guide says eligible hourly statistics are not automatically deleted. This does not mean that every raw power reading survives forever.

For a sensor with state_class: measurement, long-term summaries can include a time-weighted average and extremes for each window. A cumulative energy sensor with state_class: total_increasing participates differently; it represents a meter that normally advances and may handle recognised resets. The state_class, device_class and physical unit should match the underlying quantity. An instantaneous 2.4 kW power measurement is not a 2.4 kWh energy reading. Do not give power a total-increasing state class just to make it appear on a graph.

The Energy dashboard uses long-term statistics, and it can retain year-scale energy comparisons with relatively modest storage. However, those summaries cannot reconstruct every transient. If a compressor cycles on for 30 seconds and off for 30 seconds, an hourly mean may look stable. That may be perfectly adequate for billing, but inadequate for short-cycling diagnosis or relay testing. Retention planning must separate energy accounting from transient troubleshooting.

Requirement	Best starting record	Time resolution	Why
Annual solar production	Cumulative solar kWh with long-term statistics	Hourly aggregate	Annual totals do not need 1-second power samples
Month-to-month import/export	Validated directional energy counters	Hourly aggregate	Works with Energy dashboard and utility bill checks
EV charger contactor chatter	Power/current and charger state transitions	Seconds to tens of seconds	Need to see rapid state changes
Heat pump defrost event	Native defrost flag, electrical power, relevant temperatures	10–60 seconds depending on device	Hourly average masks individual cycles
Seasonal indoor comfort	Temperature and humidity history	5–60 minutes	Slow thermal dynamics
Time-of-use cost reconciliation	Interval kWh and charged retail price	Match supplier billing interval	A correct temporal join matters more than chart smoothness
Long-term occupancy trends	Privacy-minimised derived summaries	Hourly or daily	Raw motion events may be unnecessary and sensitive

Recorder database engines: SQLite, MariaDB, MySQL and PostgreSQL

Recorder supports several SQL backends; the official compatibility information lists SQLite, MariaDB, MySQL and PostgreSQL with specified minimum versions. These are alternatives for Recorder, not reasons to replace it with InfluxDB. An external MariaDB server does not automatically turn the Home Assistant History graph into a time-series database. It simply changes where Recorder stores Home Assistant’s database tables.

External SQL can be sensible when you already administer a reliable server, require particular backup tooling, or have measured a database workload that benefits from a different engine. It also introduces credentials, network dependency, upgrades, backup coordination and recovery steps. If the NAS AliExpress price is rebooting when Home Assistant needs to log state transitions, the system has acquired another failure point. A local SQLite file may be the better resilience choice on a dedicated mini PC AliExpress price.

Do not casually switch Recorder databases expecting old history to move across. Home Assistant’s documentation warns that Recorder database migration is not supported as a simple configuration change. Preserve a tested backup, plan the cutover, and understand which long-term records and dashboards may be affected. For most home energy projects, keep SQLite and add an independent InfluxDB export only if the requirements justify it.

Recorder database	Advantages	Limitations	Appropriate owner
SQLite (default)	Zero database-server administration; local; straightforward backup	Storage I/O on Home Assistant host; careful with SD cards	Typical HA household
MariaDB	Mature managed SQL, widely used in homelabs	Service maintenance, backups, dependencies	Existing managed DB environment
MySQL	Known SQL tooling and backup procedures	External service or extra server processes	Managed SQL infrastructure
PostgreSQL	Powerful SQL and administrative tooling	Needs skilled operations; no automatic speed miracle	Advanced self-hosted deployments

What InfluxDB adds to a Home Assistant energy system

The official Home Assistant InfluxDB integration exports Home Assistant state changes to an external time-series store. Crucially, it runs in parallel with Recorder and does not replace the Home Assistant database. If the InfluxDB host is down, Recorder may continue serving core Home Assistant history. Conversely, an InfluxDB archive might retain selected high-resolution data after Recorder has purged the corresponding detailed states.

InfluxDB is optimised for numerical values associated with timestamps, measurements, tags and fields. It suits long-term solar inverter output, phase current, import/export, heat pump flow temperatures, EV charger power and similar telemetry. The database also has retention and query policies, making it possible to keep detailed samples for a controlled period. It is not a cure for poor sensor data: a miswired CT or missing measurement remains wrong regardless of storage technology.

An important 2026 detail is version diversity. Home Assistant currently documents InfluxDB 1.x, 2.x and InfluxDB 3 Core / Enterprise support, with compatibility differences for write APIs and query languages. Many old blog tutorials assume InfluxDB 1.x and InfluxQL; InfluxDB 2.x examples typically use Flux, while InfluxDB 3 has a different native query/storage architecture and compatibility APIs. Do not copy a query from one major generation into another and assume Grafana will accept it.

InfluxDB generation	HA integration notes	Grafana query language options	Operational consideration
InfluxDB 1.x	Legacy database, username/password configuration	InfluxQL	Older tutorials abundant; not ideal for new unsupported installs
InfluxDB 2.x	Bucket, organisation, write token; HA Flux query sensors	Flux or supported compatibility query paths	Retention managed per bucket; mature home-lab tutorials
InfluxDB 3 Core	Supported by documented HA write compatibility	SQL and InfluxQL where appropriate	Understand product-specific retention and historical query limits
InfluxDB 3 Enterprise	Supported through compatible APIs	SQL and InfluxQL according to data-source setup	More capabilities, but verify licence and deployment fit

Where Grafana fits, and what it does not do

Grafana connects to one or more data sources to fetch information on demand. It creates dashboards, charts, transformations, annotations, variables and alerting configurations. The Grafana InfluxDB data source documentation supports various InfluxDB product generations and query languages. Grafana usually does not hold the underlying power measurements: deleting the InfluxDB data or misconfiguring its retention does not become harmless because a Grafana dashboard still exists.

This distinction affects purchasing. A user who installs Grafana expecting it to preserve Home Assistant history can end up with a beautiful blank chart once source data expires. Equally, installing InfluxDB does not immediately create useful Grafana dashboards. Someone must understand series selection, timestamps, units, intervals and missing-data handling, then build and maintain panels. The built-in Energy dashboard is more approachable for routine household consumption and tariff discussions.

Grafana is particularly helpful when comparing two systems over the same time axis, for example solar PV generation, grid export, battery state-of-charge and EV charging across a cloudy weekend. It is also useful for repeated troubleshooting: annotate firmware updates, compressor service visits and meter replacements to explain sudden changes. However, a panel that sums instantaneous watts over time using the wrong time bucket can fabricate energy, and smoothing can hide short transient loads.

Feature	Built-in Home Assistant	Grafana connected to InfluxDB
Household Energy dashboard	Ready to use after sensor configuration	Must build energy accounting views yourself
Custom multi-axis analysis	Possible with HA chart cards / custom cards	Flexible panel queries and transforms
Multi-year high-resolution archive	Not through standard short raw-history retention	Possible with planned InfluxDB retention and hardware
Device history around a fault	Recent Recorder history	Flexible long-range, high-resolution review
Dashboards for multiple sites	Depends on HA deployment/integrations	Strong cross-data-source visualisation options
Ease of setup	Low	Moderate to high
Security and credentials	Within HA user/admin boundary	Separate users, token scopes and data-source security
Storage of sensor values	Recorder plus statistics	In InfluxDB, not the Grafana dashboard file

Choose storage by answering five practical questions

First, what will you actually decide from the data? A reader who wants to reduce monthly electricity cost needs trustworthy interval energy and import price, not necessarily a 1 Hz archive. A reader troubleshooting phase imbalance or contactor cycling may genuinely need high-frequency sampling. Label each sensor as an accounting measure, control signal, engineering diagnostic or decorative dashboard item. Prioritise storage for the first three, and be willing to drop the fourth.

Second, how much history is meaningful? For heat-pump seasonal performance, hourly energy totals may be enough. For defrost detection, individual events and surrounding temperature traces matter, but five-year retention of second-by-second samples is harder to justify. If the objective is detecting an intermittent fault over winter, 60–90 days of minute-resolution data can be more valuable than indefinite unfiltered retention.

Third, where does the database live? SSD-backed local storage is often an improvement over a low-cost SD card AliExpress price. A separate NAS AliExpress price can be effective when it is already running continuously, but it creates network and availability dependencies. Fourth, who maintains the system? InfluxDB upgrades, API tokens and backup restores consume time. Fifth, can your measurements be reconciled to reality? If import and export are inverted, no data stack can deliver valid insights.

Use Recorder only when standard Energy dashboard statistics and a few days of event history answer your questions.
Increase Recorder history cautiously when you need a moderately longer window for all relevant raw events and your SSD has room.
Use selective InfluxDB export when only a subset of sensors requires months of granular telemetry.
Add Grafana when the built-in visualisations cannot compare or investigate the selected data effectively.
Do not buy a NAS solely for this without a realistic storage, backup and electricity-use justification.

A practical sensor inventory for solar, EV charging and heat pumps

Before setting up a new database, list every physical meter and its role. Useful sources include a utility import/export meter, inverter AC production, home battery charge and discharge energy, EV charger delivered energy, heat pump input energy and thermal heat output when a properly installed heat meter is present. These measurements are not all additive: total household consumption and a branch circuit overlap, and battery flows require a consistent sign convention.

Give each series an unambiguous name and unit. The property-wide meter is the accounting reference for purchased or exported electricity. A charger meter is a branch measurement that helps allocate that total; adding the charger kWh to the whole-home import kWh double counts it. Export readings must be directional rather than a negative number mixed into an import-only cumulative counter, unless your chosen integration and templates explicitly support signed measurements correctly.

Timestamps are part of the data model. A 15-minute tariff feed should align with the energy consumed in those intervals, using aware timestamps and the correct local timezone when presenting bills. Never infer a reading was valid for an entire hour merely because its last reported value remains available. Add freshness monitoring or explicit gap annotations so a network dropout is not drawn as a flat line of fictional consumption.

Suggested sensor	Quantity	Typical change rate	Long-term need	Watch out for
Grid import energy	Cumulative kWh	Seconds to minutes	Years at hourly aggregate	Rollover and meter reset
Grid export energy	Cumulative kWh	Seconds to minutes	Years at hourly aggregate	Never add to import as another load
Inverter power	Instantaneous W	Seconds	Hours to months depending on diagnosis	Clipped PV peaks hidden by hourly averaging
Battery SoC	Percentage	30 seconds–minutes	Hourly or minutely for diagnostics	Stale value during gateway outage
Battery power	Signed W	Seconds	Days to months	Sign convention and inverter rounding
EVSE energy	Delivered cumulative kWh	10 seconds–minutes	Monthly/yearly totals	Wall energy vs car battery energy
Heat pump electric input	kW / cumulative kWh	Seconds–minutes	Energy long-term; power for cycles	Auxiliary heaters and pumps boundary
Heat pump flow/return	°C	10–60 seconds	Detailed defrost windows	Mounting bias and sensor offset
Outdoor temperature	°C	Minutes	Hourly climatology	Solar radiation and sensor placement
Tariff retail price	Currency per kWh	15–60 minutes	Interval history for billing	Wholesale price is not retail billed price

How to estimate data volume without guessing your SSD size

Raw event counts, not the number of dashboards, drive storage. For an idealised sensor reporting one observation every minute, the daily number of points is 1,440. One observation every ten seconds is 8,640 points a day. At one sample every second, it is 86,400 daily points. Multiply by active series, retained days and average disk consumption per point to obtain a rough planning figure. It is a capacity estimate, not an accurate prediction of SQLite or InfluxDB internals.

The actual disk bytes per point vary greatly: tags, fields, value compression, WAL, indexes, measurement cardinality, schema choices, retained attributes and background compaction can change results substantially. An assumption of 100 bytes per stored sample is useful for arithmetic but should never be treated as a vendor specification. Run a controlled one-week measurement with the intended export filter, measure the real database growth and extrapolate conservatively. Keep generous free space for backups and database maintenance.

An important difference is that Home Assistant writes state changes, not a fixed sample for every sensor. A constant temperature value might yield few new rows; a jittery 1 Hz current sensor might produce almost 86,400 per day. Your calculation should therefore use observed points per day rather than blindly multiplying device polling settings.

Scenario	Assumed rate	Points/day	Illustrative 100 bytes/point	30 days uncompressed estimate
1 sensor, every 60 s	1/min	1,440	0.14 MB/day	4.32 MB
1 sensor, every 10 s	6/min	8,640	0.86 MB/day	25.92 MB
1 sensor, every 1 s	60/min	86,400	8.64 MB/day	259.2 MB
20 sensors, every 10 s	20 × 6/min	172,800	17.28 MB/day	518.4 MB
100 sensors, every 60 s	100/min	144,000	14.4 MB/day	432 MB
100 sensors, every 1 s	100 × 60/min	8,640,000	864 MB/day	25.9 GB

Example: suppose 40 power and temperature sensors produce one useful stored change every 15 seconds on average. That is 40 × 4 × 60 × 24 = 230,400 points per day. At an illustrative 100 bytes each, the uncompressed arithmetic is 23.04 MB/day or around 2.1 GB over 90 days before indexes, compaction, replication, backups and database-specific compression effects. If half those sensors only change every minute, the observation count drops substantially. Conversely, extra tags and high-cardinality attributes may raise the burden.

In one household, a 256 GB SSD can appear excessive for energy readings but be worth choosing for reliability, inexpensive headroom and the ability to keep multiple backups or other services. In another household, a 64 GB SSD may suffice because Home Assistant keeps hourly statistics and the high-resolution InfluxDB archive is deliberately filtered. Measure the database growth before purchasing storage for a hypothetical worst case.

Cardinality: the storage trap that does not show up in simple point-count estimates

InfluxDB identifies time series through a combination of measurements and tag values. A stable tag for entity_id or room makes sense; a tag that changes on every reading can create a huge number of unique series. A timestamp, monotonically increasing request ID, dynamically generated error string or raw JSON object should generally not become an indexed tag. High cardinality can harm index efficiency and query performance even when the total recorded point count seems reasonable.

Treat tags as stable dimensions—such as site, device type, phase or sensor—and fields as the changing numeric or textual measured values. A frequent string field can still consume storage, but it does not necessarily multiply series identity the way a changing tag does. Avoid dumping entire nested Home Assistant attributes blindly into a time-series database. Create a limited allowlist of entities and a conscious tag policy.

For an energy-only export, it is tempting to send every sensor.* because it seems harmless. That also captures battery health messages, signal strength, firmware counters, diagnostic metadata and other noisy series that will never appear in a useful chart. A whitelist of 20–50 meaningful sensors is easier to test, back up and trust than a blind export of hundreds of entities.

Data field	Good or poor choice?	Reason
`site=home` tag	Good	Stable and useful grouping
`phase=L1` tag	Good	Small set of known possible values
`entity_id=sensor.grid_power` tag	Usually good	Stable identifier for selected series
`timestamp=2026...` tag	Poor	Every sample may create a new series
`event_uuid=random` tag	Poor	Unbounded unique values
`power_w=1245.3` field	Good	Numeric measured value, not tag
`friendly_name` tag	Use cautiously	Changes/relabeling can create extra series

Step 1: make Recorder lean before adding InfluxDB

The first optimisation costs nothing. Open Home Assistant developer tools and the History/Statistics pages, inspect noisy entities and determine whether they are useful. Prefer correcting a sensor that changes unnecessarily rather than suppressing all its measurements. A temperature device reporting to six decimal places every second may be creating state churn without adding real accuracy. A sensible sensor update strategy uses instrument precision and the physical dynamics you actually wish to capture.

Configure Recorder filters only after you know which entities matter. Remember that Recorder retention and export retention are independent: filtering a sensor out of Recorder can affect History, Logbook, History Stats and other features that rely on its state changes, while the Home Assistant InfluxDB integration can have a separate filter. In general, retain core control and energy sensors in Recorder, and use filters to keep out high-frequency diagnostic clutter rather than removing essential automation history.

The recorder: section belongs in configuration.yaml. Existing deployments may already have Recorder settings; merge into the existing section rather than declaring the integration twice. Back up the configuration before changing anything and use Home Assistant’s configuration validation. Allow the purge/repack cycle to run before concluding that the file-size behaviour has changed.

# configuration.yaml — illustrative Recorder policy
recorder:
  purge_keep_days: 14
  auto_purge: true
  auto_repack: true
  commit_interval: 5
  exclude:
    entities:
      - sensor.test_debug_counter
      - sensor.temporary_signal_rssi
    entity_globs:
      - sensor.lab_diagnostic_*
# Keep utility energy, critical control and fault-history entities recorded.

This example extends detailed history to 14 days, and excludes only explicitly named diagnostic sensors. The glob is a deliberate convention, not a magic list of universally safe exclusions. Use the entity IDs that actually exist in your installation. The commit_interval setting is a database transaction interval, not a sensor sampling interval, so increasing it from five to 30 seconds will not make measurements arrive only every 30 seconds or reduce how frequently entities change.

What not to exclude without a proper reason

Be careful with utility meters, tariff selections, safety-related status, boiler demand, EV charger state, alarms and major energy counters. History-based automations and diagnostics can need their past states. Filtering out “everything but sensor” is particularly risky if you later want to analyse when a heating demand signal turned on or whether a charger refused a command. A safe filter is based on documented dependencies, not a blanket policy copied from a forum post.

If you need detailed history for an entity for 60 days, changing purge_keep_days globally extends the whole Recorder history, not that one entity alone. That is an excellent reason to investigate a selective InfluxDB export instead: preserve routine state history for two weeks while archiving only a chosen handful of diagnostic measurements for a longer duration.

Step 2: configure the InfluxDB export using the correct major-version path

Install and secure an InfluxDB instance that your Home Assistant host can reach, ideally on a stable local network or a properly protected trusted segment. For a first deployment, choose a supported version and documentation set you are willing to maintain. InfluxDB 2.x remains common in existing Home Assistant setups, while version 3 is now documented by Home Assistant as well. The current integration is added through Settings → Devices & services, with credentials and endpoint configured in the integration interface. Additional export filters may still be specified in YAML.

For InfluxDB 2.x, create a dedicated bucket with an appropriate retention period and a scoped write token. Avoid reusing an all-powerful administrator token for a single telemetry writer. Give Grafana a separate least-privilege query credential where supported. Test DNS and the actual endpoint from the Home Assistant environment, not just from a laptop on another VLAN. Container names such as influxdb do not necessarily resolve from every add-on or Docker network.

For InfluxDB 3, check the precise compatibility instructions for your installed release rather than assuming every 2.x Flux example applies. The HA documentation describes v1/v2 write API compatibility for 3 Core and Enterprise, while queries can use InfluxQL through the HA integration and SQL in external tools. The safest approach is to make a small test bucket, write two known readings and query them back before enabling a wide export.

Implementation step	What to verify	Common failure
Create retention/bucket	Correct InfluxDB version and retention policy	Assume buckets work identically in 1.x and 3.x
Create write credential	Scoped permission to chosen database/bucket	Using admin token in plain-text screenshot
Add HA integration	Endpoint, token, organisation and bucket	Wrong Docker hostname or port
Apply YAML filter	List only intended sensor entities	All hundreds of HA entities exported
Confirm sample arrival	Inspect timestamps and numeric field values	Network reachable but writes rejected
Add Grafana read data source	Correct query dialect and rights	Flux dashboard connected to SQL-only datasource
Run outage test	Reconnect, inspect gaps and service recovery	Assume guaranteed replay of all missed points

# configuration.yaml — optional entity filter for the InfluxDB integration
# Add the integration credentials in Settings > Devices & services.
influxdb:
  include:
    entities:
      - sensor.grid_import_power
      - sensor.grid_export_power
      - sensor.solar_pv_power
      - sensor.home_battery_power
      - sensor.ev_charger_power
      - sensor.heat_pump_electric_power
      - sensor.heat_pump_flow_temperature
      - sensor.heat_pump_return_temperature
  tags:
    site: main_home
    source: home_assistant
  ignore_attributes:
    - icon
    - friendly_name

These example entity IDs are placeholders: replace them with your actual integration entities. A user who has already configured influxdb: YAML should merge carefully, because current Home Assistant versions import connection settings into config entries and use YAML for additional options. Restart/reload only as instructed by the integration and inspect logs. Do not paste an API token into a public article, forum comment or Grafana panel title.

InfluxDB retention and downsampling: keep what you can use

Unlike a never-ending spreadsheet, a telemetry store should have an explicit retention design. One useful model is a high-resolution measurement bucket for 30–90 days and a separate aggregated dataset for one or more years. The precise implementation differs by InfluxDB generation and available task or processing features. InfluxDB 2.x exposes bucket retention periods directly, and official documentation describes data older than the specified duration becoming eligible for deletion.

Aggregates need to respect the meaning of the underlying variable. An average of 60 one-second power samples can describe a one-minute power level if the samples represent uniform intervals; if sampling is uneven, a time-weighted average is safer. Energy accumulated over an interval should come from a proper cumulative energy counter or integration method rather than blindly summing values labelled watts. A counter reset at midnight, or a swapped sign after an inverter update, can produce a huge false spike.

For heat pumps, retain high-resolution compressor status, flow/return temperatures and electricity power while investigating defrost and cycling, but aggregate seasonal energy input and heat output for long comparisons. For EV chargers, store charge-session start/stop, site current and delivered energy with enough detail to understand charging interruptions. For whole-home power, a one-minute summary may be enough once you are confident there are no narrow peaks or faults of interest.

Data class	Illustrative high-resolution retention	Illustrative long-term form	Why
Grid power	1-minute values for 90 days	Hourly/daily kWh totals	Bill accounting plus recent anomalies
EV current / status	5–15 seconds for 30 days	Session summaries for 2 years	Troubleshoot interruptions without huge archive
Heat pump flow / return	10–30 seconds for winter diagnostics	Hourly temperature distributions	Defrost and cycling studies
PV power	30–60 seconds for 90 days	Hourly production, annual energy	Monitor clouds and inverter clipping
Battery SoC	1 minute for 90 days	Hourly low/high/average	Check control reserve and trends
Indoor comfort	5 minutes for 90 days	Hourly mean and extrema	Room physics changes slowly
Tariff price	Supplier pricing interval	Interval price history plus monthly results	Accurate tariff-cost joins

Step 3: connect Grafana correctly and build an energy dashboard

Grafana’s InfluxDB data source is maintained as an officially supported integration and supports InfluxQL, Flux or SQL according to the selected database generation and datasource settings. Create the datasource with a query credential rather than a write token whenever your deployment supports that separation. The Grafana server must be able to reach InfluxDB from its own network context. A browser reaching the InfluxDB dashboard says little about whether Grafana’s backend service can connect.

Start with a single dashboard containing six panels: grid import power, grid export power, solar generation, EV charger power, battery charge/discharge power and heat pump electric input. Use explicit units: watts or kilowatts for instantaneous power, kilowatt-hours for energy, °C for water temperature, and currency per kWh for tariff price. Do not put a kW line on an axis labelled kWh. Mark gaps as gaps unless there is a defensible reason for fill-forward.

Add annotations for major changes such as inverter firmware updates, CT clamp replacement, heating commissioning and new electricity tariffs. A chart before and after an intervention is much easier to interpret when the measurement configuration is documented. Grafana’s alerts should be carefully chosen: notification storms from every sensor disconnection can be less useful than one alert for missing grid data or an InfluxDB ingestion failure.

Grafana panel	Source series	Useful interval	Quality gate
Grid net flow	Separate import/export W or signed documented net W	1–5 minutes	Direction agrees with utility meter
Solar production	Inverter AC output W	1–5 minutes	DC capacity not confused with AC output
EV charging	EVSE measured W and charging status	10–60 seconds	Charging current and wall energy consistent
Heat pump cycling	Actual compressor/burner state when exposed	10–30 seconds	Not inferred from thermostat demand alone
Cost per interval	Supplier retail price × matching interval kWh	Billing interval	Standing charges and VAT treated consistently
Data freshness	Timestamp of latest valid sample	Every few minutes	Alert when stale rather than drawing fake zero

Flux, InfluxQL and SQL: a query example is not universally portable

A 2026 deployment might use Grafana with an InfluxDB 2.x Flux datasource, an InfluxDB 3 SQL datasource or a legacy InfluxQL datasource. These query languages have different syntax, schema and aggregation functions. InfluxDB 2.x creates a measurement and tag layout from the Home Assistant export. Do not assume that a blog query referring to mean_value or temperature matches your exported series: inspect a real point in the data explorer first.

In an InfluxDB 2.x installation using Flux, an illustrative power aggregation might be written as follows. It intentionally uses placeholders for the bucket and measurement, and assumes an entity ID tag plus a numeric value field. Those names can differ with the measurement configuration and the sensor units, so verify the actual schema before running it. In particular, a mean of power is still power, not energy.

// Flux for an InfluxDB 2.x datasource — schema-specific illustration
from(bucket: "home_energy")
  |> range(start: -24h)
  |> filter(fn: (r) => r._measurement == "W")
  |> filter(fn: (r) => r.entity_id == "grid_import_power")
  |> filter(fn: (r) => r._field == "value")
  |> aggregateWindow(every: 5m, fn: mean, createEmpty: false)
  |> yield(name: "mean_grid_import_watts")

If your export stores the full entity ID in the entity_id tag instead of its object ID, update the filter. If the measurement is called state instead of W, update that as well. Successful syntax parsing does not prove that a query returns meaningful values. Preview raw points, check units, compare against an existing HA sensor, then create dashboard transformations.

How to derive energy from irregular power samples

Energy is the integral of power over time: kWh = ∫ kW × hours. For evenly spaced samples with a known integration convention, rectangular integration approximates the area. For irregularly sampled state changes, an accurate calculation needs interval duration or a deliberately chosen interpolation method. Filling missing samples with the last value during an outage can severely overestimate consumption. Ideally use an independent cumulative energy sensor whose calibration can be checked against the site meter.

Suppose a charger reads 6.8 kW for 12 minutes, 7.1 kW for 18 minutes, then 0 kW for the rest of the hour. The correctly segmented energy is 6.8 × 12/60 + 7.1 × 18/60 = 3.49 kWh. A simple mean of those two non-zero values gives 6.95 kW, which is not the one-hour average; if incorrectly applied for the entire hour it produces a fictitious 6.95 kWh. This is why “the graph looks right” is not sufficient validation.

Worked example: three homes, three sensible architectures

Consider first a small flat using Home Assistant Green with 30–40 relevant energy and temperature sensors. It has a smart meter gateway, a few metered plugs and one fixed overnight tariff. The user mainly wants a reliable Energy dashboard, monthly kWh totals and a week of device history. Recorder on its default SQLite setup, with verified cumulative energy entities and automatic backups, meets the need. Adding InfluxDB and Grafana would increase electricity use and administrative time without providing a decision that cannot already be made.

Now consider a detached property with 7 kWp PV, a hybrid inverter, battery storage, two EV chargers and a heat pump. It exports power, has several tariffs and produces frequent inverter measurements. The user needs to compare battery SoC with tariff, charger current and heat-pump load during cloud transients. Keep Recorder for Home Assistant functionality, export 25 carefully selected sensors to InfluxDB and build a Grafana operational dashboard. Preserve high-resolution data for a defined diagnostics window and aggregate longer-term values.

Finally consider a keen engineer with an oscilloscope-like interest in relay chatter and power-quality-adjacent monitoring. Home Assistant is not a precision power analyser, nor is a typical Wi-Fi smart plug a calibrated disturbance recorder. Use the correct dedicated instrument or meter for very short events. An InfluxDB archive can help analyse the instrument’s timestamped output if the integration genuinely supports the sampling rate. Do not extrapolate second-level HA state changes into millisecond electrical events that were never measured.

Home profile	Recommended stack	Up-front extra equipment	Primary reason
Small flat, fixed tariff	Recorder only	None if existing HA storage is adequate	Annual energy and basic appliance history
PV + battery + EV, several local integrations	Recorder + selective InfluxDB	Possibly SSD/mini PC if existing host is limited	Retain useful minute-scale energy traces
Advanced home lab with multi-year diagnostic queries	Recorder + InfluxDB + Grafana	Reliable host, backups, monitored storage	Query, compare and annotate many sensor histories
Only wants a beautiful wall dashboard	Recorder and native dashboard first	Possibly display hardware	A second database may not be necessary
Needs sub-second electrical event capture	Approved fast instrument + separate analysis	Instrument appropriate to required accuracy	Home Assistant sensor samples may be too slow

Hardware choices: Raspberry Pi, Home Assistant Green, mini PC or NAS?

The best host is the one that meets the measured write load without compromising home automation reliability. Home Assistant Green or Raspberry Pi with solid external SSD storage can be sufficient for ordinary Recorder operation and a small selective archive. A modern x86 mini PC provides more headroom for multiple services, faster restores and extensive Grafana queries, but also consumes electricity. A NAS can centralise backups, Docker services and storage when it is already running for other purposes.

Avoid drawing simplistic conclusions from RAM or CPU marketing specifications. High write frequency, database compaction, disk latency, a large number of unique series and dashboards that refresh every few seconds can dominate the workload. A fast CPU paired with a failing SSD is not resilient. A powerful NAS that sleeps, reboots or loses network connectivity during an automation window may be less reliable than a modest standalone Home Assistant machine.

If the archive is not required for real-time control, you can separate responsibilities: Home Assistant remains available locally while InfluxDB and Grafana run on another machine. However, do not falsely assume there is guaranteed catch-up after outages. The integration’s retry behaviour and buffering are release-dependent; monitor the archive for gaps and plan around them.

Hosting choice	Advantages	Limits	Best fit
Existing HA host with SSD	No additional machine, simple topology	Shared CPU, RAM, writes and failures	Small to moderate targeted telemetry
Raspberry Pi with SSD	Low running power, familiar ecosystem	Limited headroom for heavy simultaneous queries	Energy monitoring without huge archives
Home Assistant Green	Appliance-style HA deployment	Do not overload with unnecessary services	Recorder and mainstream integrations
N100/N150-class mini PC	Good headroom for Docker/VM plus SSD	Additional device management and power	Medium/advanced self-hosted archive
Existing always-on NAS	Central storage, backup ecosystem	Network dependency and resource contention	Households already operating a NAS
Cloud InfluxDB/Grafana	Remote access and managed aspects	Subscriptions, WAN/privacy, data egress	Only if cloud trade-offs are understood

Five-year running cost: electricity and maintenance can outweigh storage

A dedicated mini PC may be an excellent investment, but count its power consumption. Assume, purely for illustration, an additional always-on 9 W average at £0.25/kWh. Yearly electricity is 0.009 kW × 8,760 h = 78.84 kWh, or approximately £19.71 per year. Over five years, that is about £98.55 before hardware, replacement SSDs or time spent administering it. A 20 W incremental host uses 175.2 kWh a year and costs about £43.80 annually at the same rate.

Those numbers vary by actual wall power and electricity tariff; the idle power printed on a processor specification is not a reliable measurement of the complete host. Compare the incremental consumption against running InfluxDB on equipment you already own. If an existing NAS runs 24 hours a day for unrelated reasons, its marginal cost may be quite small. If you buy a whole extra NAS for one graph, the economics look different.

Storage media and backup cost matter too. InfluxDB might use only a few gigabytes after filtering, but reliable operation needs free space for compaction, software updates and backups. Write endurance should not be treated as an exact countdown clock: vendor TBW ratings are planning parameters, while observed write amplification, temperature and system load vary. Use SSD health monitoring and backup tests instead of assuming either indefinite life or imminent failure.

Illustrative incremental running power	Energy per year	Cost/year at £0.25/kWh	Cost over five years
0 W: use already-running hardware	0 kWh	£0.00	£0
5 W	43.8 kWh	£10.95	£54.75
9 W	78.84 kWh	£19.71	£98.55
15 W	131.4 kWh	£32.85	£164.25
20 W	175.2 kWh	£43.80	£219.00
35 W	306.6 kWh	£76.65	£383.25

Backups: separate the Home Assistant brain from the telemetry archive

A Home Assistant backup and an InfluxDB database backup are not automatically the same thing. A Home Assistant OS backup typically includes chosen Home Assistant configuration and apps according to the backup settings. An InfluxDB server running in a separate Docker host, NAS or cloud account may fall entirely outside that archive. Likewise, exporting Grafana dashboards as JSON or keeping them in its internal database preserves only the dashboard configuration; it does not preserve the underlying sensor data.

Create an inventory of recovery assets: Home Assistant configuration and Recorder database, InfluxDB datasets and tokens, Grafana dashboards and data-source credentials, MQTT or meter integration settings, time-series schema and your retention policy. Put backup copies in more than one failure domain, preferably including an off-host destination and an offline or suitably protected version. Encrypt or otherwise secure backups because occupancy patterns, vehicle charging times and energy profiles can reveal when people are home.

Test restoration, not just backup creation. Restore into an isolated test environment or spare disk, check that Home Assistant boots, long-term statistics appear, the Grafana datasource reconnects using its credentials and the time series retains expected timestamps. If the dataset is truly expendable, document that choice and back up only the configuration, so users do not believe multi-year history is protected when it is not.

Data asset	Owner	Suggested backup approach	Restore test
Home Assistant configuration and Recorder	Home Assistant	Scheduled encrypted HA backup stored off-host	Start HA, verify entities and history
InfluxDB telemetry	InfluxDB host	Version-appropriate consistent database export or snapshot	Query known historical timestamps
Grafana dashboards	Grafana	Export/provision dashboards and store server settings securely	Import and render six representative panels
Credentials and encryption key	Secure secret store	Restricted, encrypted copy separate from primary host	Verify credentials usable without exposing publicly
Calibration records / CT mapping	Installation documentation	Version-controlled text or PDF stored privately	Reconcile physical meter readings
Tariff definitions	Home Assistant/supplier	Archive rate plans and effective dates	Recompute a known billing interval

Privacy and security: energy data can reveal household routines

An energy record is not inherently anonymous. Charging patterns can suggest a vehicle is away, room heating and water use can reveal routine, and lighting or appliance activity may correlate with occupancy. Minimise the number of exported entities, especially people, presence, alarm, location and access-control sensors. An InfluxDB whitelist of essential power and energy readings is typically safer than a blanket export of every Home Assistant state, even if Grafana never displays the private information.

Keep databases and dashboards off the public internet unless there is a carefully designed remote-access architecture. Restrict ports with firewall rules, use TLS where appropriate, rotate tokens, apply security updates and avoid embedding privileged credentials in publicly shared dashboard JSON. Grafana’s data-source permissions can limit who queries sensitive information in applicable editions, but authorisation decisions should be designed across the database, proxy, user accounts and network as a whole.

When sharing screenshots of an energy dashboard, remove identifying tags, addresses, meter serials, internal hostnames and private IP addresses. If a solar-inverter API allows setting export limits or battery schedules, separate read-only analytical credentials from write-control permissions. The energy data layer should not unintentionally become a pathway for unauthorised changes to electrical equipment.

Performance tuning: what to check when Home Assistant slows down

First identify the bottleneck. CPU usage, memory pressure, disk I/O latency, database size, network retries and failing integrations can all create delays. The official System Monitor integration can report disk use, CPU, memory and network metrics; note that its entities may be disabled by default and must be enabled as needed. It does not report arbitrary directory sizes, so a filesystem or database-specific tool may still be required to inspect the Recorder file.

Test one change at a time. If Recorder is growing too quickly, investigate high-frequency entity updates and excessive attributes first. If the InfluxDB exporter generates errors, look for bad authentication, DNS or write-rate overload. If only Grafana is slow, narrow its time range, reduce panel count, use sensible query aggregation and stop refreshing yearly charts every five seconds. Be wary of increasing retention and then blaming the resulting database size for a performance issue.

Measure improvement with a simple baseline: Home Assistant startup time, CPU and RAM at similar occupancy, disk free capacity, recent event ingestion delay, six representative dashboard query times and the number of missing samples over a day. The goal is reliable energy insight, not winning a synthetic database benchmark.

Symptom	Likely avenue	First check	Bad shortcut
Recorder file constantly grows	Noisy entities or purge settings	Recent entity changes, retention, purge logs	Delete database without backup
Home Assistant UI slow	Resource contention or integration errors	CPU, storage latency, logs	Assume MariaDB is always faster
InfluxDB disk fills	Retention too long, wide export, tag cardinality	Points/day, bucket policy, tags	Buy huge disk without trimming export
Grafana chart hangs	Oversized query or too many refreshes	Time range, aggregation, panel frequency	Increase polling of every sensor
InfluxDB gaps	WAN/LAN outages, write errors	Ingestion logs, last successful point	Fill all missing values with previous
Energy totals disagree	Counters, boundaries, time zone	Supplier bill and meter signs	Adjust arbitrary scale factor until close
Device flash wear concern	Frequent writes to weak media	Storage medium, Recorder policy	Disable Recorder entirely

Validate the numbers: an attractive dashboard can still be wrong

For purchased electricity, use the utility meter as the reference whenever feasible. Compare daily and monthly grid import/export totals with supplier data, allowing for supplier interval boundaries, meter reporting lag and date/time conventions. Be cautious with sensors derived from instantaneous power: integrating a low-frequency or irregular power stream is only an estimate, not necessarily billing-grade kWh. Check the underlying energy counter before blaming Grafana query syntax.

For solar and batteries, define the energy-flow boundaries on paper. A PV inverter’s AC generation is different from DC array output; charging a battery and later discharging it are not new generation. For EV charging, a wallbox kWh counter measures energy supplied at the charger boundary, not necessarily the increase in the traction battery. For heat pumps, compressor electrical power and a whole-system electricity meter may give different results because auxiliaries and backup heaters are included differently.

Build three trust checks into every advanced dashboard: a raw-value spot check against Home Assistant developer tools, an interval-total comparison against an independent meter where possible, and a missing-data indicator that shows sensor age. An archive with apparently continuous lines but unreported gaps is dangerous when evaluating control savings, boiler efficiency or heat-pump COP.

Migration path: make changes incrementally and preserve rollback

Phase 1: Keep Recorder with its current stable configuration and gather a baseline of file growth, History availability and Energy dashboard totals. Correct the most important sensor metadata and ensure a recoverable backup exists. Phase 2: Identify three to five high-value telemetry streams—perhaps grid power, heat pump electricity power, EV charger power, battery SoC and PV output—and connect them to a supported InfluxDB instance with a 30-day retention policy.

Phase 3: After a week, compare InfluxDB raw points against Recorder and a physical meter. Only then enlarge the export list and extend the desired retention. Phase 4: Add Grafana dashboards and annotations. Confirm that Grafana’s chosen query dialect matches the database generation and that each panel’s unit is correctly configured. Phase 5: Run failure and restore tests before relying on archived data for a financial or engineering decision.

If the new database complicates operation without adding insight, turn off the export, retain Recorder and remove the unnecessary service after an orderly backup. There is no need to keep an experimental stack forever because you once spent a weekend setting it up. A smaller and more dependable system often yields better decisions than a highly configured stack whose measurements no one trusts.

Phase	Duration (illustrative)	Evidence needed to proceed	Rollback
1. Recorder baseline	7 days	Stable history, valid statistics, backup tested	Return to previous configuration
2. Small InfluxDB pilot	7–14 days	Selected series match HA and no unexplained gaps	Disable optional exporter
3. Selective retention design	14–30 days	Known storage growth and sufficient free space	Reduce filter or retention
4. Grafana deployment	Several sessions	Panels have units, legends, source and annotations	Use built-in HA dashboards
5. Recovery validation	One scheduled test	Restored history, credentials and sample queries	Restore prior known-good backups

Decision checklist: do you actually need InfluxDB and Grafana?

Are your grid import and export kWh already accurate in the Home Assistant Energy dashboard?
Do you have a specific question requiring raw or minute-level data older than Recorder retention?
Have you measured the actual update frequency of the candidate sensors?
Can you explain why hourly long-term statistics are insufficient for the decision?
Will you filter high-frequency exports rather than record every entity?
Do you understand the InfluxDB version and query language your Grafana dashboard expects?
Do you have independent backups for HA, InfluxDB and Grafana configuration?
Can your host maintain healthy storage free space and consistent network connectivity?
Have you documented units, meter boundaries, timestamps and sign conventions?
Is the planned archive worth the power, hardware and maintenance costs of another service?

Frequently asked questions

Does InfluxDB replace the Home Assistant Recorder database?

No. The official Home Assistant InfluxDB integration exports state changes in parallel with Recorder. Home Assistant still relies on Recorder for its core history and statistics. Turning off Recorder because an external InfluxDB server exists may break History and Energy dashboard functions.

Is Grafana a database?

No. Grafana is chiefly a query, dashboard and visualisation service. Its datasource—InfluxDB, PostgreSQL or another system—holds the underlying measurements. Grafana stores dashboard definitions and related configuration, but it does not magically preserve sensor history.

Do I need InfluxDB for the Energy dashboard?

No. Home Assistant uses Recorder statistics for the Energy dashboard. Confirm the energy sensors have the appropriate state class, device class, units and reliable cumulative counter behaviour; the default storage is often enough.

Why do I still see months of energy history if Recorder only keeps 10 days?

The 10-day default is for detailed state/event history. Eligible five-minute and hourly statistics are separate. The hourly long-term statistics are not automatically purged, allowing historical energy comparisons without keeping all raw samples.

Can Recorder keep 30 or 90 days of raw history?

Yes, by configuring purge_keep_days, but the setting extends detailed retention globally. Verify host storage and database performance, rather than assuming 90 days is cheap for high-frequency sensors. A selective InfluxDB archive may be more efficient for a small subset.

Should I move Recorder from SQLite to MariaDB?

Only if you have a specific operational reason, measured issue or existing well-maintained database server. SQLite is Home Assistant’s default and recommended engine. External SQL adds network and service dependencies, and changing Recorder databases does not automatically migrate existing history.

What InfluxDB version should a new installation use?

Choose a current supported version based on your host, query language, retention and administration needs. Home Assistant documents 1.x, 2.x and 3 Core/Enterprise compatibility; avoid blindly using 1.x or 2.x settings against an InfluxDB 3 deployment. Confirm the exact version matrix before installation.

Can I use Grafana without InfluxDB?

Yes. Grafana supports other data sources, including SQL databases. That does not mean querying Home Assistant Recorder directly is always advisable: schema familiarity, read-only access and future compatibility matter. For time-series energy analysis, InfluxDB is a common option, not the only one.

Why are Grafana readings different from Home Assistant?

Common causes include differing aggregation windows, data gaps, sign convention, unit conversion, timestamp/timezone handling and selecting power rather than energy. Check raw values and the actual physical meter before adjusting the chart.

How long should I keep one-second power readings?

As long as they answer a specific engineering question. One-second telemetry from many entities can grow rapidly and may offer no extra value for monthly billing. Keep shorter high-resolution windows and longer aggregate summaries unless you have a proven need.

Does my Raspberry Pi need an SSD?

For a write-heavy or frequently accessed database, an SSD is generally preferable to relying on a small SD card. However, choose based on observed I/O load and available supported hardware. Better filtering and sensible retention are also important.

How do I protect energy data from cloud access?

Host services locally if that meets your requirements, avoid exposing database ports directly to the internet, restrict tokens and users, use protected backups and export only necessary entities. Appliance load patterns can reveal occupancy, so treat the archive as private.

Can InfluxDB calculate my true electricity bill?

It can store and query measurements, but accurate billing needs correct meter boundaries, matching tariff periods, tax, fixed charges, export payment and supplier rules. A beautiful 5-minute power graph is not a substitute for reconciled kWh from the billing meter.

Why are there gaps in my InfluxDB graph after Home Assistant restarts?

The exporter, database or network may have been unavailable, and recovery/backfill cannot be assumed. Check integration logs, retry policy, timestamps and service availability. Explicitly show the missing intervals instead of treating them as zero energy.

Will Grafana dashboards make my Home Assistant automations faster?

No. Grafana mainly visualises data and does not improve automations merely by being installed. Running extra services may even contend for resources. Keep safety-critical or time-sensitive control on supported device logic and Home Assistant’s appropriate control interfaces.

What is the simplest reliable setup for a household with solar and an EV?

Use a reliable local Home Assistant host with a verified grid meter and suitable cumulative energy entities. Keep Recorder, configure the Energy dashboard and backups, and review a month of actual use. Add targeted InfluxDB export only if a particular diagnostic or long-range analytics need remains unmet.

How should I back up a Grafana and InfluxDB setup?

Back up Home Assistant independently, preserve InfluxDB data through version-appropriate consistent backups and separately export Grafana dashboards and data-source settings. Test restoring known historical points, not just whether the backup file exists.

Is there a faster way to fix excessive Recorder disk growth?

First inspect noisy sensors, unwanted attributes, entity churn, Recorder exclusions and purge/repack settings. A fresh SQL backend may move the problem rather than solve it. Always back up before irreversible changes.