Heute früh habe ich das 2. Mal Daten vermisst und in den Logs eine korrupte SQLite-DB gemeldet bekommen. Das System hat einfach die vorhandene DB gesichert und eine neue, leere DB angelegt, so dass die alten Daten futsch waren.
Nun meine Frage - kann ich über die HA-Restore-Funktion die verschwundenen Daten in die neue DB einlesen? Ich habe in der Häkchen-Liste keine Option für die SQLite DB gefunden.
Am Rande bemerkt - die ursprüngliche, gesicherte Datenbank war nicht korrupt! Der Integritätscheck lief ohne Fehler durch und nachdem ich sie wieder aktiviert hatte, waren alle Daten (bis auf die letzten 24h) wieder da.
auch am Rande bemerkt, Du solltest mal in den Logs schauen, ob es nicht schon vorher Meldungen gab, dass recorder etwas nicht eintragen konnte, dann auch mal schauen wie sich der Speicherplatz verhält, sollte das öfter vorkommen, ist es auch wichtig zu erfahren, wie und wo HA läuft, es kann auch auf einen Defekt des Speichermediums hinweisen.
Ich nutze das HA Backup nicht, aber soweit mir bekannt ist, kann man ein einzelnes File nicht über die Restorefunktion zurückholen.
Du kannst HA stoppen, sodass kein Zugriff auf die Datenbank erfolgt, dann das Backup auf einem anderen PC auspacken, geht auch mit 7Zip unter Windows und das Datenbankfile extrahieren und per scp, sftp kopieren.
Moin Bernd,
in dem Logfile, dass ich heute angeschaut und gleich runtergeladen habe, war das der erste recorder Fehler. Diese Art von Fehler taucht immer morgens um 04:12 (vermutlich UTC) auf, wenn da ein cron job den Datenbank purge ausführen soll. Eine entsprechende issue ich auch schon im HA github vermerkt.
Wenn ich mir die betroffenen SQL statements (und auch das Schema) anschaue, bekomme ich das Gefühl, dass das Datenbankdesign (und der Umgang mit derselben) etwas “seltsam” ist, um es vorsichtig zu formulieren.
Da der Purge ja in Konkurrenz zum Mitschreiben der laufenden Daten auf einem monolithischen DB-File operiert, liegt für mir der Verdacht nahe, dass da etwas nicht so ganz richtig programmiert ist.
HA läuft bei mir auf einer VirtualBox (mit dem originalen Image von HA), die wiederum auf einem Ubuntu i5 NUC mit SSD läuft. Parallel dazu läuft noch FHEM, evcc und steve auf dem NUC, und das ohne Probleme.
Ich habe mir das tar vom Backup mal angeschaut, da sind wirklich nur stumpf die Verzeichnisse zusammenkopiert. Auch die db ist da am Stück enthalten (nicht als Dump). Ob während des Kopierens die Zugriffe auf die DB gestoppt werden, damit das File konsistent ist? Nobody knows. Das wird wohl also nichts mit dem Klick im WEB-UI für den Restore. Schade.
Bleibt für mich die Aussage, dass der Recorder buggy ist. Mindestens ist er zu einem falschen Schluss hinsichtlich des DB-Zustands gekommen.
(Background on this error at: https://sqlalche.me/e/20/4xp6)
2025-05-13 04:12:02.138 ERROR (Recorder) [homeassistant.components.recorder.core] Unrecoverable sqlite3 database corruption detected: (sqlite3.DatabaseError) database disk image is malformed
Und seltsam ist, dass dies Problem wohl oft nach einem Core-Update (den ich am Montag ausgeführt hatte) auftritt.
ich maße mir mal nicht an alles zu verstehen, aber die Standard-Datenbank ist ja eine SQLite, diese wiederum ist ja kein vollwertiger Datenbankmanager.
SQLite ist auf jedem Handy somit glaube ich ist das schon etwas Vernünftiges
Die Datenbank ist halt auf externe Logik (HA) angewiesen und nutzt nicht den vollen Umfang der SQLite Datenbank, z. B. views, trigger, usw., oder wenn man eine Externe MariaDB, etc. verwendet, dann halt auch dort nicht alle Möglichkeiten, das hat den Vorteil, dass man vom Wirtssystem unabhängig ist.
Das würde ich ausschließen, denn alles, was da parallel gemacht wird, wird erst in einem zweiten File abgelegt, müsste das .wal = für Rollback sein, das .shm ist das shared memory wo die Aktionen zwischengespeichert worden, zudem werden, so weit ich die Datenbank von HA verstehe, keine Daten die einmal geschrieben wurden geändert, sondern jede Aktion, Event wird neu erfasst.
Somit ist das Prugen auch ok, obwohl noch zugriff auf die Tabelle besteht.
Ich müsste mal schauen, aber ich bin der Meinung, dass ich hier, schon öfter mal gelesen habe, dass sich HA in eine VirtualBox VM seltsam verhalten hat, soll jetzt aber nicht heißen, dass das schlecht ist, ist aber eher ein Exot unter den Installationen.
Das kannst nur Du beurteilen, ich habe hier im Forum schon öfter mal gesehen, dass SQLite versucht hat, die Daten wieder zu bereinigen und das, was da dann nicht konsistent war, in neue Tabellen geschrieben hat.
So sieht auf jeden Fall eine standard Datenbank aus
Was evtl. noch von Interesse sein kann, wie groß ist Deine SQLite Datenbank?
Sind noch genügen inodes auf dem virtuellen Laufwerk frei?
Aber ansonsten kann ich auch nichts weiter dazu sagen, ich habe HA jetzt seit Dezember 2023 im Einsatz und noch nie ein Problem mit der Datenbank gehabt.
Meine Aussage bezog sich auf die “Gestaltung” z. B. der SQL-Statements seitens HA. So würde ich sie in keinem Falle gestalten, auch nicht bei PostgreSQL etc.
Das betrachtete (und gescheiterte) Statement aus dem Logfile ist:
Da sollen anscheinend events gepurged werden. Man beachte den Kommentar … 3900 parameters truncated … in der Parameterliste. Es soll ja auch noch Systeme geben, die mit dann doch irgendwo endlichen Buffern arbeiten … Der scheint vom Logger-Mechanismus zu stammen, sonst gäb’s einen Syntaxfehler zur Laufzeit. Ich würde die state records mit einem Zeitstempel und einem oder ggf. mehreren Tags versehen, um "where Tag=‘xy’ and created<“Zeit” OSLT selektieren zu können. Wäre etwas kürzer.
Durch das 2. Hinsehen habe ich immerhin erkannt, dass der Fehler vom SQLite API gemeldet wurde:
Traceback (most recent call last):
File "/usr/local/lib/python3.13/site-packages/sqlalchemy/engine/base.py", line 1964, in _exec_single_context
self.dialect.do_execute(
~~~~~~~~~~~~~~~~~~~~~~~^
cursor, str_statement, effective_parameters, context
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/local/lib/python3.13/site-packages/sqlalchemy/engine/default.py", line 945, in do_execute
cursor.execute(statement, parameters)
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
sqlite3.DatabaseError: database disk image is malformed
Vielleicht war dem “do_execute” das Statement doch zu lang. Da dieser Purge jeden Tag erfolgt, scheint mir die Anzahlt der state records auch recht groß zu sein. Die Aufbereitung der Liste erfolgt anscheinend hier:
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 96, in session_scope
yield session
File "/usr/src/homeassistant/homeassistant/components/recorder/purge.py", line 88, in purge_old_data
has_more_to_purge |= _purge_states_and_attributes_ids(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
instance, session, states_batch_size, purge_before
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/src/homeassistant/homeassistant/components/recorder/purge.py", line 203, in _purge_states_and_attributes_ids
_purge_state_ids(instance, session, state_ids)
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Rein spekulativ - da ich am Tag vorher ein Core Update gemacht hatte, führte dies evtl. durch einen Programmierfehler in HA zu dieser gewaltigen Liste an aufgezählten IDs. Halbwegs performant wäre sowas vielleicht nur, wenn da ein Hash Index auf dem ID wäre. ABer vielleicht wäre es sogar noch schneller, den Index zu droppen, die states sequentiell zu lesen und die passenden zu löschen und den Index dann neu aufzubauen.
Anyway. Da die DB danach “in Sicherheit kopiert wurde” und diese Sicherung dann einfach wieder nutzen konnte, auch über den nächsten Purge hinaus, ist SQLite zu einem falschen Schluss gekommen, der sich vielleicht auch auf die .wal oder .shm Datei bezogen hat. Das SQLite vor der Sicherungskopie noch etwas repariert haben sollte, erscheint mir sehr unwahrscheinlich.
Die homeassistant_v2.db hat 982 MB. Da sehe ich noch kein inode-Problem auf der VBox. Das OS dort ist:
uname -a
Linux homeassistant 6.12.23-haos #1 SMP PREEMPT_DYNAMIC Mon Apr 14 16:26:58 UTC 2025 x86_64 HAOS
Ich denke, dass die HA developer das OS schon passend konfiguriert haben. Dass die VBox Engine von Oracle da ein Problem hat, schließe ich aus. Ich benutze sowas seit über 2 Jahrzehnten und hatte damit nie Probleme (und meistens wurden Windows OS gehostet …).
Danke aber für die Hinweise auf die .wal und die .shm Files. Das bringt mich auf die Idee, doch mal RTFM mit den SQLite manuals zu spielen. Zumindest würde ich davon nicht dümmer werden …
da bist Du aber sehr tief in die Materie eingestiegen.
Das ist für mich ein Vergleich von Äpfeln, mit Birnen
Ich hatte seit eineinhalb Jahren noch nie Probleme mit meiner SQLite Datenbank in meiner Proxmox VM und seit ca. 6 Monaten, auch noch nie Probleme mit der SQLite in meinem HA LX Container, nur das ist auch eine Aussage, die niemanden hilft
Jede Installation ist mehr oder minder einzigartig und somit sind die Probleme, Fehler auch einzigartig.
In den vielen Posts, die ich hier schon gelesen habe, taucht das Problem mit der korrupten Datenbank immer wieder in Logfiles auf.
Auf Github gibt es diese Issues dazu HA SQLite Issues
Aber Hut ab, wie weit Du dich da, in den Kaninchenbau, hinein begeben hast
Eine andere Möglichkeit, wäre noch, auf eine externe MariaDB, Postgrsql umzusteigen
