SQLite recorder purge fails with full disk issues

Hello,
below I have share the details of my setup. I’m running HA on an ODROID n2+ with 64GB of storage. The recorder currently uses almost 34GB of that, which leads to a disk space usage ration of 98%. Not a good state for my production system to be in :speak_no_evil::see_no_evil:

I did try to purge the recorder in various flavors of the below but nothing happens.

action: recorder.purge
data:
  keep_days: 1
  repack: false
  apply_filter: false

Is anyone out here experienced with the sqlite storage managed by HA and how I can cleanse it? I would be totally fine to delete all history and bring the database close to zero size. What is the best way to access the database directly and which tables would I want to delete or be careful around?

Thanks!

Edit: As suspected, the purge command errors out because of the full disk issue itself.

2024-10-09 19:32:12.472 ERROR (Recorder) [homeassistant.helpers.recorder] Error executing query
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context
    self.dialect.do_execute(
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/default.py", line 924, in do_execute
    cursor.execute(statement, parameters)
sqlite3.OperationalError: database or disk is full

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/recorder.py", line 101, in session_scope
    yield session
  File "/usr/src/homeassistant/homeassistant/components/recorder/migration.py", line 2708, in rebuild_sqlite_table
    session.execute(text(f"DROP TABLE {orig_name}"))
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/orm/session.py", line 2351, in execute
    return self._execute_internal(
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/orm/session.py", line 2245, in _execute_internal
    result = conn.execute(
             ^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1418, in execute
    return meth(
           ^^^^^
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/sql/elements.py", line 515, in _execute_on_connection
    return connection._execute_clauseelement(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1640, in _execute_clauseelement
    ret = self._execute_context(
          ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1846, in _execute_context
    return self._exec_single_context(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1986, in _exec_single_context
    self._handle_dbapi_exception(
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 2353, in _handle_dbapi_exception
    raise sqlalchemy_exception.with_traceback(exc_info[2]) from e
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context
    self.dialect.do_execute(
  File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/default.py", line 924, in do_execute
    cursor.execute(statement, parameters)
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) database or disk is full
[SQL: DROP TABLE states]
(Background on this error at: https://sqlalche.me/e/20/e3q8)

version core-2024.10.0
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.12.4
os_name Linux
os_version 6.6.46-haos
arch aarch64
timezone Europe/Berlin
config_dir /config
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
HACS Data ok
GitHub API Calls Remaining 5000
Installed Version 2.0.1
Stage running
Available Repositories 1441
Downloaded Repositories 74
Home Assistant Supervisor
host_os Home Assistant OS 13.1
update_channel stable
supervisor_version supervisor-2024.10.0
agent_version 1.6.0
docker_version 26.1.4
disk_total 56.6 GB
disk_used 54.2 GB
healthy true
supported true
host_connectivity true
supervisor_connectivity true
ntp_synchronized true
virtualization
board odroid-n2
supervisor_api ok
version_api ok
installed_addons Mosquitto broker (6.4.1), Samba share (12.3.2), SSH Tunnel & Forwarding (1.2.1), Terminal & SSH (9.15.0), Studio Code Server (5.16.3), evcc (0.130.12), Rclone Backup (3.3.2)
Dashboards
dashboards 4
resources 47
views 12
mode storage
Recorder
oldest_recorder_run 23. Juni 2024 um 08:11
current_recorder_run 9. Oktober 2024 um 18:23
estimated_db_size 33722.29 MiB
database_engine sqlite
database_version 3.45.3
Solcast PV Forecast
error failed to load: unknown

Hi ThomDietrich,

Well, I have a suggestion, but you won’t like it.

Look at recorder and set the save days to default.
Delete home-assistant_v2.db file where the database is. Let it rebuild.
Install influx database and send your save forever stuff over there, keep it out of the database that is trying to work quickly on all now aspects of your home assistant experience.

I delete mine about once a year or if it gets over 600mb.

If you still want to fix it, look in the docs how to add a data disk and move it there. A lot of database operations require a space the size of the database as free space to do their stuff, and it doesn’t look like that’s happening where it’s at. It will likely take days.

1 Like

I agree the fix is to just delete the .db and let it rebuild.

To keep it from growing that big again, exclude all the entities you don’t need to keep, and set a short keep_days parameter. More information here:

To this I’d add that there are some inherently “chatty” integrations which create a lot of records, or fill each record with a lot of duplicated attributes. You can use SQL to query your database to find the worst offenders and focus on those.

1 Like

Someone in Community once said that purging needs a free space = size of DB.
I am not an expert in DB. My several attempts to purge a huge DB with a small amount of free space always completed with deleting the db file.

1 Like

Hey guys!
Thanks great answers, @Sir_Goodenough I absolutely like the idea. I wasn’t sure whether I can simply delete the file though.

I am totally fine with that, as well as with setting short keep_days number. I am an InfluxDB user since many years, all my HA history of the last few years is there and and many complex queries do their job in Grafana :slight_smile:

Q: Now please help me out here, I might just be stupid right now but HOW do I delete the file? Is there a HA-OS way or do I need to physically unplug the memory card and delete the file from another OS?

Thanks, I might do that after it works again. Sounds reasonable to exclude the silly ones.

Would you look at that! I can simply yank it from underneath a running Home Assistant instance (using the SSH Terminal addon in HA-OS), restart, and all is settled.
Thanks guys! :slight_smile:

Glad that worked!!

Now would be a good time to mark one of the posts above as the solution.

Also, maybe go back to that other thread where you asked the same question and fill everyone in on how you got the file deleted.

Thank you!

1 Like

Valid reminder. Thanks

1 Like

I have probably the same issue.
My home-assistant_v2.db is around 57 GB.
And the home-assistant_v2.db-wal starts after every reboot to increase in size. 17 GB is often seen for it.

Questions:

  1. How do I delete the home-assistant_v2.db?
  2. Should I also delete the home-assistant_v2.db-wal?

I am running HA on a Rapsi 4 with an SSD of 128 GB.
Every night at around 4:00 AM the sensors are stop showing me the data. So I guess it has something to do with missing space on the SSD.
I had in my configuration.yaml the purge_keep_days: 30 to delete it after 30 days. But still I can see older data, that is not the long-term-statistic data. Now I deleted this line in the configuration.yaml to have the default value of 10. No changes.

Of course it would be nice to keep the long-term statistic. But I am willing to delete all the history, to have my system work again.

Hi Balcony,
You just find it and delete it. It is located in the dame folser as the configuration.yaml file is usually.
Both files are safe to delete if starting over.
Be sure to adjust recorder so that you don’t get tight back in the same problem.

Thanks for the answer!

I could not find it in Studio Code Server. But in the File Editor I could find it and delete it there.

After Reboot the host system, the history graphs are not working. They say Loading state history.... Maybe it is still writing a new database. I will let it run over night and see what will happen.

Yes, I will now use filter to just save some of the data. Not all. 57 GB was huge!!!

Thank you again for your quick help!

History is what you deleted.
History starts today.
Only save what you need to save locally in sqllite, and install influxDB to store the other 56GB next time.

I looked it up, and everything works fine now. Everything is running again. I am so happy!

Yes I know, that the new history starts today. With the standard purge option, after 10 days the database-size should be not growing any more. I made now a sensor to track this. From the graph I can assume from the slope at what size my database will end up.

Actually I deleted influxDB one week ago. I thought this is the problem, as it is saving all the data. Because for the sqllite I had the purge days at 30. -.- Somehow my system hat purge-problems. So I deleted influxDB without any reason… Well… Thats how we learn things :wink:

My next stepts:

  • see if the database size will stop after 10 days (to check that the purging works correctly)
  • create filters so that I save only the neccesary data
  • delete the database again
  • thinking about installing influxDB one more time together with grafana. I am not sure if I need this long-term-history data.
  • search for big files, as my HA is still using 28% of the 128GB SSD. That means it is still 35GB big. Which seems to much for my point of view

Edit:
From the slope I get the theoretical sizes:
1h: 6,5 MB
1d: 155 MB
7d: 1086 MB = 1 GB
10d: 1552 MB = 1.6 GB
30d: 4656 MB = 4.7 GB
1y: 56644 MB = 56.6 GB

So lets see if it stops at approx 1,6 GB. That would be fine for me.

1 Like