[vz-users] DB Backup auf NAS via sqlite

[Thomas Höpfner]

Hallo Micha,



dann könnte mein workaround funktionieren:



rufe einmal dbcopy auf, wenn es mit fehler abbricht gib als nächstes folgendes ein:



:~# while [ $? -gt 0 ];do <dein dbcopy Befehl> ; done



Das ist ein Script das dbcopy solange stardet bis es den Fehler 0 zurückgibt. Deshalb muss es direckt nach einer Fehlermeldung gestardet werden.

Als einmaliger workarount eventuell machbar  aber für die Zukunft sollte die Ursache gefunden werden. Da stimme ich Andreas voll zu.

Als Ansatz dient eventuell der Timestamp, der ist nähmlich nicht immer größer.



1. Screenshot

 timestamp: Tue Dec  8 14:19:53 UTC 2020

 channel_id: 15

 id (key PRIMARY): 14611172  



2. Screenshot

 timestemp: Wed Dec  9 17:51:05 UTC 2020

 channel_id: 3

 id (key PRIMARY): 14635746



3. Screenshot

 timestemp: Wed Dec  9 17:50:00 UTC 2020

 channel_id: 3

 id (key PRIMARY): 14635755



Für mich stellt sich die Frage, warum ist vom 3. Kanal ein älterer Wert mit höherer id vorhanden?
Das ist aber nur ein Indiz für den Fehler, das bleibt die scheinbar doppelt vorhandene id , und die wird von der Datenbank vergeben.
Ich habe irgendwo gelesen, das MySQL relativ fehlertolerant ist. Das heißt, der Fehler kann unbemerkt in der originalen DB sein und ist im Backup gesichert.
Das ist aber reine Spekulation von mir.

Mit freundlichen Grüßen,

Thomas 





-----Ursprüngliche Nachricht-----
Von: Andreas Goetz <cpuidle at gmail.com>
Gesendet: Dienstag 29 Dezember 2020 09:06
An: volkszaehler.org - users <volkszaehler-users at demo.volkszaehler.org>
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

Vielleicht solltest Du mal überlegen wo diese Einträge eigentlich her kommen? Von DBCopy werden sie vmtl nicht erzeugt...

Viele Grüße, Andreas


Am 29.12.2020 um 07:55 schrieb Michael Hartmann <hartmann-micha at web.de>:

Hallo Thomas,

 
anbei drei Screenshots von drei unmittelbar aufeinanderfolgenden Aufrufen mit den Fehlermeldungen bei denen dbcopy aussteigt. Wie man sieht, ist es jedes Mal ein Datum mit höherer ID an denen sich dbcopy aufhängt.

 
Grüße

 
Micha

 
Von: volkszaehler-users [mailto:volkszaehler-users-bounces at demo.volkszaehler.org] Im Auftrag von Thomas Höpfner
Gesendet: Montag, 28. Dezember 2020 22:27
An: volkszaehler.org - users
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

 
Hallo Micha,

 
ist dein Testsystem noch aktiv?

Kannst du einen Screenshot von der Fehlermeldung machen? Am besten 2 kurz hintereinander. 

Eventuell habe ich einen Workaround. 

Thomas 

 
Am 28.12.2020 um 20:43 schrieb Michael Hartmann <hartmann-micha at web.de>:

Hallo Thomas,

Ich habe auch keine Idee mehr. Egal ob aus einer parallelen DB via mysql oder über sqlite es läuft beim restore immer auf duplicate entries bei denen dbcopy aussteigt.

Grüße

Micha

P.S.: Um das share egal ob nun via cifs oder nfs eingebunden nach reboot verfügbar zu haben musste ich autofs installieren. Über einen Eintrag in fstab lief es nicht. Obwohl der korrekt war.

Am 28. Dezember 2020 17:04:57 MEZ schrieb "Thomas Höpfner" <thomas at thhoe.de>:

Hallo Micha,

 
warum das bei dir nicht funktioniert ist mir ein Rätsel. Ohne funktionierendes Backup ist es auch nicht gut, hatte ich aber auch ein paar Jahre. 

 
Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten Backups für den VZ.

 
Grüße

 
Micha

 
 
Bei mir funktioniert es zuverlässig. 

 
Thomas 


--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

<2020-12-29 07_51_21-pi at SmartMeterTS_sqlite_restore3.png>
<2020-12-29 07_47_52-pi at SmartMeterTS_sqlite_restore.png>
<2020-12-29 07_47_52-pi at SmartMeterTS_sqlite_restore_2.png>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20201229/e42b8181/attachment.html>