Ich weiß nicht, was ihr da schaut, aber wenn man das durch 1000 teilt und natürlich ohne nachkommastellen nimmt, kommt 29.05.2020 - 16:16:21 raus
Stefan Von meinem iPad gesendet > Am 24.11.2020 um 10:26 schrieb John Doe <john...@null.net>: > > > Das führt zu 16. Januar 1975, 3:49b Uhr (UTC). Das scheint mir auch nicht > viel richtiger zu sein ... > Ich würde händisch, d.h. visuell Woche für Woche im Frontend durchgehen, nach > Auffälligkeiten suchen, entsprechende (kurze) Abschnitte ggfs. löschen und > dann ein neues Backup nach wiki anlegen. > Grüße > > JD. > > > Sent: Tuesday, November 24, 2020 at 9:56 AM > From: "Frank Richter" <frank.richte...@gmail.com> > To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> > Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup > Die Timestamps bei vz sind ms, also bitte vorher durch 1000 teilen :-) > > Grüße > Frank > > Michael Hartmann <hartmann-mi...@web.de> schrieb am Di., 24. Nov. 2020, 09:52: >> Der Timestamp der dort berichtet wird erscheint mir auch "surreal". >> Zumindest wenn man voraussetzt das es sich um einen UNIX-Timestamp >> handelt... und nicht um ein anderes Format. >> >> Ich habe das Backup der DB auf meinem NAS via Frontend von MariaDB geprüft. >> Der erste Eintrag liegt Ende Mai (Inbetriebnahme VZ), der letzte zum >> Zeitpunkt des Backups. Diesen auffälligen Timestamp finde ich dort nicht. >> >> Grüße >> >> Micha >> Gesendet: Dienstag, 24. November 2020 um 09:21 Uhr >> Von: "John Doe" <john...@null.net> >> An: volkszaehler-users@demo.volkszaehler.org >> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup >> Hallo zusammen, >> >> der timestamp 1590761781023 ergibt Dienstag, 27 März 52379, 16:30:23 Uhr. >> Das klingt ein wenig surreal. Wie sehen denn die Daten per visueller >> Kontrolle im Verlauf der Monate aus ? Könnte ein Reboot bei noch nicht >> wieder vorliegender korrekter Systemzeit des Raspis da ein wenig Unordnung >> gemacht haben ? Ich tippe auf inkonsistente Datenbank an der Stelle. Gibt es >> eigentlich eine Möglichkeit, die "Richtigkeit" der DB im Sinne der >> Konsistenz, speziell bei der Uhr-/Systemzeit zu überprüfen ? Das Problem >> habe ich auch immer mal wieder und muss dann Daten per ....&action=delete >> solange bereinigen, bis es wieder passt, d.h. unsinnige Peaks verschwunden >> sind. >> Grüße >> >> JD. >> >> >> Sent: Monday, November 23, 2020 at 8:48 PM >> From: "Michael Hartmann" <hartmann-mi...@web.de> >> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> >> Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup >> Hallo Thomas, >> >> Ich bin raus. Keine Ahnung, warum ich die Daten nicht retour bekomme. Es ist >> scheinbar nur für Menschen mit detailierten DB-Kenntmissen lösbar. Was >> solls... >> >> Grüße Micha >> >> Am 22. November 2020 15:44:46 MEZ schrieb "Thomas Höpfner" <tho...@thhoe.de>: >>> >>> Hallo Micha, >>> >>> bei mir sieht es so aus: >>> - NFS-Freigabe auf NAS backup/methusalix2 (muss einmal erstellt werden) >>> - auf Rechner methusalix2 ein Script backup.sh mit folgenden Funktion: >>> 1. mounten der NFS -Freigabe nach /tmp/backup >>> 2. Backup der Datenbank mit dbcopy nach /tmp/backup/sqlite.db3 >>> 3. umount /tmp/backup >>> - das Script wird täglich über cron gestardet >>> >>> Für meinen Test habe ich >>> - VM methusalix3 erstellt >>> - volkszähler installeirt >>> - die Datei sqlite.db3 in die vm kopiert >>> - ein Restore der DB mit dbcopy gestardet, das hat ca 2h gedauert >>> - heute habe ich das Backup der letzen Nacht in die VM kopiert >>> - und wieder ein Restore der DB mit dbcopy gestardet, diesmal hat es wenige >>> Sekunden gedauert. >>> >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Michael Hartmann <hartmann-mi...@web.de> >>> Gesendet: Sonntag 22 November 2020 14:52 >>> An: 'volkszaehler.org - users' <volkszaehler-users@demo.volkszaehler.org> >>> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup >>> >>> Hallo Thomas, >>> >>> was soll ich sagen? Ich bekomme die Daten weder in ein mit DD erstelltes >>> Image, noch in ein komplett neu installiertes System zurückgespielt. Es >>> läuft immer wieder auf diesen Fehler: >>> >>> pi@SmartMeter:~ $ sudo /usr/bin/php >>> /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy_restore.yaml >>> entities: copying 7 rows (overwrite) >>> [============================] 100% < 1 sec/< 1 sec 7 rows >>> >>> properties: copying 63 rows (overwrite) >>> [============================] 100% < 1 sec/< 1 sec 63 rows >>> >>> entities_in_aggregator: copying 0 rows (overwrite) >>> 0 [->--------------------------] < 1 sec 4.0 MiB >>> >>> data: copying 7855387 rows (overwrite) >>> [>---------------------------] 0% < 1 sec/< 1 sec 0 rows >>> In AbstractMySQLDriver.php line 74: >>> >>> An exception occurred while executing 'INSERT INTO `data` >>> (`id`,`channel_id`,`timestamp`,`value`) VALUES (?,?,?,?)' with para >>> ms ["1", "2", "1590761781023", "826598.2"]: >>> >>> SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' >>> for key 'PRIMARY' >>> >>> >>> In Exception.php line 18: >>> >>> SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' >>> for key 'PRIMARY' >>> >>> >>> In PDOStatement.php line 115: >>> >>> SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' >>> for key 'PRIMARY' >>> >>> >>> copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] >>> [<tables>...] >>> >>> Die Kanäle werde dabei korrekt zurückgespielt, den sie stehen mir im FE zur >>> Verfügung. >>> >>> Das ist frustrierend. Nun habe ich mit eurer Hilfe eine DB auf meinem NAS >>> generiert in die ich täglich die Daten sichere, aber scheinbar ohne >>> nutzbaren Wert da ich sie nicht wieder heraus bekomme. :-/ >>> >>> Grüße >>> >>> Micha >>> Wie gesagt, das währe mit Netzwerk zu erklären. >>> >>> Mit freundlichen Grüßen, >>> >>> Thomas >>> >>> >>> >>> >> >> -- >> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
