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 <cpui...@gmail.com> Gesendet: Dienstag 29 Dezember 2020 09:06 An: volkszaehler.org - users <volkszaehler-users@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-mi...@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-boun...@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-mi...@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" <tho...@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@SmartMeterTS_sqlite_restore3.png> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore.png> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore_2.png>
