DbRep: kann kein sqlite3 Dump auf Fritz!Nas schreiben

Begonnen von pechnase, 15 Januar 2025, 12:37:06

Vorheriges Thema - Nächstes Thema

pechnase

Hallo zusammen,
ich ziehe gerade ein FHEM von einem RPI 3B mit SSD auf ein FHEM in einer VM auf einem NUC um. Bei der Einrichtung der Backup Pfade kommt es zu einem Fehler: DBD::SQLite::db sqlite_backup_to_file failed: disk I/O error at ./FHEM/93_DbRep.pm line 8952

Ich habe unter https://forum.fhem.de/index.php?topic=95593.0 ein ähnliches Problem gefunden, komme damit aber nicht weiter.

Hier die Beschreibung bzw. meiner Ergebnisse bei der Fehlersuche:

- als Ziel für den sqlite Dump habe ich an einer FB einen USB-Stick angesteckt. Der mount erfolgt mit autofs:
auto.master:
/nas /etc/auto.nas --timeout=120 browse

auto.nas:

fb-nas-gw -fstype=cifs,vers=1.0,user=fhem,password=pw,uid=998,gid=20,sec=ntlmv2 ://192.168.223.yyy/fb-nas-gw

Es wird das Verzeichnis:
/nas/fb-nas-gw/USB_16GB_FB/fhem_VM_backup_db/gemountet, was so auch als Attribut in DbRep angegeben ist:

defmod BackupDb DbRep WhngDB
attr BackupDb dumpDirLocal /nas/fb-nas-gw/USB_16GB_FB/fhem_VM_backup_db/
attr BackupDb dumpFilesKeep 2
attr BackupDb executeAfterProc { fhem("set WhngDB reopen") }
attr BackupDb executeBeforeProc { fhem("set WhngDB reopen 3600") }
attr BackupDb optimizeTablesBeforeDump 0
attr BackupDb room DB
attr BackupDb showproctime 1
attr BackupDb verbose 5

setstate BackupDb error
setstate BackupDb 2025-01-15 01:10:00 errortext DBD::SQLite::db sqlite_backup_to_file failed: disk I/O error at ./FHEM/93_DbRep.pm line 8952.\

setstate BackupDb 2025-01-15 01:10:00 state error

Der mount selbst funktioniert aus meiner Sicht:
attempting to mount entry /nas/fb-nas-gw
lookup_mount: lookup(file): looking up fb-nas-gw
lookup_mount: lookup(file): fb-nas-gw -> -fstype=cifs,vers=1.0,user=fhem,password=pw,uid=998,gid=20,sec=ntlmv2 ://192.168.223.yyy/fb-nas-gw
parse_mount: parse(sun): expanded entry: -fstype=cifs,vers=1.0,user=fhem,password=pw,uid=998,gid=20,sec=ntlmv2 ://192.168.223.yyy/fb-nas-gw
parse_mount: parse(sun): gathered options: fstype=cifs,vers=1.0,user=fhem,password=pw,uid=998,gid=20,sec=ntlmv2
parse_mount: parse(sun): dequote("://192.168.223.yyy/fb-nas-gw") -> ://192.168.223.yyy/fb-nas-gw
parse_mount: parse(sun): core of entry: options=fstype=cifs,vers=1.0,user=fhem,password=pw,uid=998,gid=20,sec=ntlmv2, loc=://192.168.223.yyy/fb-nas-gw
sun_mount: parse(sun): mounting root /nas, mountpoint fb-nas-gw, what //192.168.223.yyy/fb-nas-gw, fstype cifs, options vers=1.0,user=fhem,password=pw,uid=998,gid=20,sec=ntlmv2
do_mount: //192.168.223.yyy/fb-nas-gw /nas/fb-nas-gw type cifs options vers=1.0,user=fhem,password=pw,uid=998,gid=20,sec=ntlmv2 using module generic
mount_mount: mount(generic): calling mkdir_path /nas/fb-nas-gw
mount(generic): calling mount -t cifs -o vers=1.0,user=fhem,password=pw,uid=998,gid=20,sec=ntlmv2 //192.168.223.yyy/fb-nas-gw /nas/fb-nas-gw
mount_mount: mount(generic): mounted //192.168.223.yyy/fb-nas-gw type cifs on /nas/fb-nas-gw
dev_ioctl_send_ready: token = 32
mounted /nas/fb-nas-gw

das sind die gleichen autofs Parameter, die ich auch am Produktivsystem verwende.

Das FHEM Log sieht wie folgt aus:
2025.01.15 01:10:00 3: DbRep BackupDb - ################################################################
2025.01.15 01:10:00 3: DbRep BackupDb - ###                    New SQLite dump                       ###
2025.01.15 01:10:00 3: DbRep BackupDb - ################################################################
2025.01.15 01:10:00 3: DbRep BackupDb - execute command before dump: '{ fhem("set WhngDB reopen 3600") }'
2025.01.15 01:10:00 2: WhngDB - Connection closed until 02:10:00 (3600 seconds).
2025.01.15 01:10:00 2: DB_Alarm: {my $dbstate = ReadingsVal("WhngDB","state"," ")}: -1
2025.01.15 01:10:00 3: WhngDB - Database disconnected by request.
2025.01.15 01:10:00 4: DbRep BackupDb - Database Model: SQLITE
2025.01.15 01:10:00 4: DbRep BackupDb - Database connect - user: no, UTF-8 option set: no
2025.01.15 01:10:00 4: DbRep BackupDb - simple do statement: PRAGMA temp_store=FILE
2025.01.15 01:10:00 4: DbRep BackupDb - simple do statement: PRAGMA synchronous=FULL
2025.01.15 01:10:00 3: DbRep BackupDb - Starting dump of database 'fhem.db' (model: SQLITE)
2025.01.15 01:10:00 5: DbRep BackupDb - Use Outfile: /nas/fb-nas-gw/USB_16GB_FB/fhem_VM_backup_db/fhem_2025_01_15_01_10.sqlitebkp
2025.01.15 01:10:00 2: DbRep BackupDb - DBD::SQLite::db sqlite_backup_to_file failed: disk I/O error at ./FHEM/93_DbRep.pm line 8952.

2025.01.15 01:10:00 3: DbRep BackupDb - execute command after dump: '{ fhem("set WhngDB reopen") }'
2025.01.15 01:10:00 3: WhngDB - Reopen requested
2025.01.15 01:10:00 3: set WhngDB reopen : Reopen executed.
2025.01.15 01:10:00 3: WhngDB - Database disconnected by request.
2025.01.15 01:10:00 3: WhngDB - SubProcess connected to /db/FHEM_DB/fhem.db

Auf dem USB-Stick an der FB wird ein leerer File mit der richtigen Bezeichnung angelegt. Wenn ich auf der Linux Kommandozeile ein
sudo -u fhem nano /nas/fb-nas-gw/USB_16GB_FB/fhem_VM_backup_db/fhem_2025_01_15_01_10.sqlitebkp
kann ich den File öffnen, allerdings zeigt nano zunächst einen Fehler  [ Eingabe-/Ausgabefehler ] an. Wenn man den nicht beachtet und irgend eine Text eingibt und abspeichert mit Strg+S, enthält der File die richtigen Daten.

Für mich sieht es wie ein Zeitproblem aus, dass nach dem mount 'zu schnell' auf den USB-Stick zugegriffen wird. Der USB-Stick ist in einer FB 7490 (FRITZ!OS: 8.00) gesteckt. Dort kann man bei den USB Einstellungen eine Standby Zeit einstellen und zwischen USB 2.0 und USB 3.0 umschalten. Ich habe das Standby schon ausgeschaltet und mit USB 2.0 und USB 3.0 versucht, alles hat nicht funktioniert.

Ein fhem-Backup funktioniert auf den USB-Stick, nur der sqlite Dump funktioniert nicht.
Noch eine Beobachtung: verwende ich für den sqlite Dump den mount für das Produktivsystem, dann funktioniert es. Der USB-Stick des Produktivsystems ist an einer FB 7390 (FRITZ!OS: 06.88) angesteckt, die 'weniger' USB-Einstellungen hat.

Fazit: gibt es ein Zeitproblem das sich zwischen den Fritz!Boxen unterscheidet? Wie könnte man das debuggen?

Danke für eure Unterstützung

VG Wolfgang
2 x RPI mit FHEM 6.3 (RPI B+ & RPI 2B) verbunden über FHEM2FHEM
- HM Fensterkontakte, Rauchmelder, Fernbedienung, Schalter
- Optolink (Selbstbau) Vitotronic 200KW2
- 1-wire DS1820 Temp.Sensoren, TX29DT-IT
- CUL (busware), nanoCUL433, Jeelink (Nachbau), nanoCUL868 WMbus

betateilchen

kannst Du den dump nicht lokal machen und nach Fertigstellung auf das NAS verschieben?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

pechnase

könnte ich machen, aber dann muss ich das DumpFileKeep Attribut nachbauen. Es wird insgesamt halt 'komplizierter' und es sind weitere Fehlerquellen vorhanden.
Mich ärgert, dass ich den Fehler nicht finden kann, da es ja prinzipiell geht, siehe meine Anmerkung zu dem Mount eines USB-Stick auf einer anderen Fritz!Box.
2 x RPI mit FHEM 6.3 (RPI B+ & RPI 2B) verbunden über FHEM2FHEM
- HM Fensterkontakte, Rauchmelder, Fernbedienung, Schalter
- Optolink (Selbstbau) Vitotronic 200KW2
- 1-wire DS1820 Temp.Sensoren, TX29DT-IT
- CUL (busware), nanoCUL433, Jeelink (Nachbau), nanoCUL868 WMbus

betateilchen

Du vergleichst zum Einen unterschiedliche Hardware die auch noch mit unterschiedlichen Firmwares läuft - das ist doch ein Vergleich von Äpfeln mit Birnen. Gerade bei den unterschiedlichen Fritzkotz Modellen ist das ein hoffnungsloses Unterfangen.

Zum Anderen ist Dir völlig bewusst, dass es auch bei manuellem Aufruf zu Problemen kommt.


Zitat von: pechnase am 15 Januar 2025, 12:37:06Wenn ich auf der Linux Kommandozeile ein
...
kann ich den File öffnen, allerdings zeigt nano zunächst einen Fehler  [ Eingabe-/Ausgabefehler ] an.

Und...

Zitat von: pechnase am 15 Januar 2025, 12:37:06Wenn man den nicht beachtet ...

handelt man m.E. ohnehin schon grob fahrlässig.
Eine solche Fehlermeldung wird in der Regel nicht ohne Grund ausgegeben.

Und da möchtest Du Dich allen Ernstes darauf verlassen, dass das Backup Deines Dump-files automatisiert zuverlässig funktioniert? Na dann, viel Glück.

Wenn beim Verschieben einer lokal erstellten Datei auf das NAS ein Problem auftritt, ist wenigstens die Datei lokal noch vorhanden.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

pechnase

Hallo betateilchen,

danke für die ausführliche Antwort. Ich würde ja nicht so über dem Problem grübeln, wenn der Dump nicht schon seit vielen Jahren zuverlässig ohne einen Ausfall auf einen an die Frit!Box 7390 angesteckten USB-Stick funktionieren würde.
Ob das 'nicht beachten' einer Fehlermeldung von nano jetzt grob fahrlässig ist, lasse ich mal dahingestellt. Ich habe mit der Aussage ja nur versucht eine Spur zu dem Problem zu legen und hatte da auf das grße Know-How der Community gesetzt.
Und wie geschrieben, der fhem Backup läuft zuverlässig jede Nacht auf den USB-Stick, der bei DbRep den Fehler generiert.
Ich habe jetzt ja schon Vorschläge für ein 'Workaround' und vielleicht hat ja jemand aus der Community noch eine Idee.
2 x RPI mit FHEM 6.3 (RPI B+ & RPI 2B) verbunden über FHEM2FHEM
- HM Fensterkontakte, Rauchmelder, Fernbedienung, Schalter
- Optolink (Selbstbau) Vitotronic 200KW2
- 1-wire DS1820 Temp.Sensoren, TX29DT-IT
- CUL (busware), nanoCUL433, Jeelink (Nachbau), nanoCUL868 WMbus