[vz-users] Image mit dd erstellen / Datenbackup

[Frank Richter]

Die Timestamps bei vz sind ms, also bitte vorher durch 1000 teilen :-)

Grüße
Frank

Michael Hartmann <hartmann-micha at 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" <johndoe at null.net>
> *An:* volkszaehler-users at 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-micha at web.de>
> *To:* "volkszaehler.org - users" <volkszaehler-users at 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" <
> thomas at 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-micha at web.de>
>> *Gesendet:* Sonntag 22 November 2020 14:52
>> *An:* 'volkszaehler.org - users' <
>> volkszaehler-users at 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 at 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.
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20201124/7cf5be92/attachment-0001.html>