Hallo,
ich befürchte, mir ist der ein- oder andere Anfängerfehler unterlaufen.
Ich wollte doch nur :-)
jessie auf bullseye und python anheben.
Also über stretch und buster dann bullseye jeweils mit gestopptem fhem angehoben.
Nach einem Fehler beim letzten step für bullseye (kein Zugriff mehr auf die Raspberry 3), habe ich das backup eingespielt.
Nun habe ich fhem wieder laufen mit:
buster (10)
python 3.99
python3 3.11.1
SQLite version 3.27.2 2019-02-25 16:06:06
Aber die fhem.db auf einen recht neuen Sandisk USB Stick 256 GB hatte ich zuerst Zugriffsprobleme und musste den USB Stick neu mit einigen Schwierigkeiten (nonempty) mounten.
Nun kann ich über putty zumindest die fhem.db wieder sehen.
Fhem DbLog zeigt jedoch an:
STATE DBD::SQLite::db prepare failed: file is encrypted or is not a database at ./FHEM/93_DbLog.pm line 2880.
Ein direkter Zugriff sqlite3 fhem.db über putty meldet: Error: file is not a database
FHEM hat ein frisches update
MODE asynchronous
FVERSION 93_DbLog.pm:v4.13.3-s26750/2022-11-26
SQLite:dbname=/media/usb256/fhem.db
6,8 GB fhem.db
Was kann ich tun, um das leider 3 Monate alte Backup nicht einspielen zu müssen ?
Danke und Grüße
Jörg
Zitat
Ein direkter Zugriff sqlite3 fhem.db über putty meldet: Error: file is not a database
Naja, DbLog kann das auch nicht besser machen als sqlite3 selbst. ;)
Nur eine Vermutung ... könnte es sein dass unter dem alten BS die SQLite V2 werkelte ?
Nun ist es die V3.
Falls meine Vermutung stimmt könnte das helfen -> https://www.informaticscentre.co.uk/blog/convert-sqlite-version-2-database-version-3-mysql/
Grüße,
Heiko
Zeig doch mal den Inhalt der DbLog Konfigurationsdatei, in der die Verbindungsdaten zur Datenbank stehen.
Und was liefert
ls -lh /media/usb256/fhem.db
Zitat von: DS_Starter am 14 Dezember 2022, 16:53:46
Nur eine Vermutung ... könnte es sein dass unter dem alten BS die SQLite V2 werkelte ?
Nun ist es die V3.
Aktuell ist es : SQLite version 3.27.2 2019-02-25 16:06:06
Da ich aber bisher immer mit
sudo sqlite3 /media/usb256/fhem.db gestartet habe, müsste es doch eine V3 auch bisher gewesen sein.
Zitat von: betateilchen am 14 Dezember 2022, 17:28:33
Zeig doch mal den Inhalt der DbLog Konfigurationsdatei, in der die Verbindungsdaten zur Datenbank stehen.
Und was liefert
ls -lh /media/usb256/fhem.db
ls -lh /media/usb256/fhem.db liefert:
-rwxrwxrwx 1 fhem dialout 6,3G Dez 5 23:57 /media/usb256/fhem.db
... und jetzt werde ich dann doch mehr als unruhig...
Gerade die fhem.db Sicherung (Kopie von Raspi fhem.db auf meinen Windows PC) zurück gepielt auf den Raspi unter einem anderen Namen. Nur um zu sehen, ob das backup klappt. Habe es nicht in die dbconf eingebunden!
Mit Zugriff auf diese fhem_b.db erhalte ich: Error: database disk image is malformed
Nun wäre also sogar mein backup korrupt? Ich habe zwar noch ein Jahresbackup von Ende 2021 - aber ich befürchte ja, dass das dann auch nicht geht.
Eine sqlite Datenbank mit 6,3GB auf einem Raspberry 3 ist durchaus eine kritische Größe...
Zitat
Error: database disk image is malformed
Ist halt auch die Frage wie du ein Backup der Datenbank anfertigst?
Was mir noch einfallen würde, wäre ein Reparaturversuch.
Kann man "zu Fuß" machen oder mit DbRep.
Der Weg wäre
-> DbLog aktivieren aber auf disable setzen damit nichts versucht wird zu loggen
-> ein DbRep definieren wenn noch nicht geschehen
-> in dem Device ein "set ...repairSQLite" ausführen
Erfolg möglich aber ungewiss ... probieren.
Man braucht auch mindestens zusätzlichen Plattenplatz in der Größe der DB.
Zitat von: DS_Starter am 14 Dezember 2022, 19:30:25
Ist halt auch die Frage wie du ein Backup der Datenbank anfertigst?
Ich hatte fhem gestoppt und dann mit FileZilla vom /media/usb256/fhem.db die Datei auf die HDD des windows System/PC kopiert.
Da das Rückkopieren jeweils 2 1/2 Std dauert, war ich ja guter Hoffnung. Aber auch die 2 Kopie zurück mit FileZilla in ein anderes Verzeichnis des USB Stick und anschließendem Zugriff per sqlite3 bringt den Error: database disk image is malformed