[vz-users] Image mit dd erstellen / Datenbackup

Di Nov 24 10:39:34 CET 2020

Oder suchen wo die Daten herkommen, und die Quelle korrigieren.
Die DB ist es garantiert nicht.

Thomas 

Mail: thomas at thhoe.de

> Am 24.11.2020 um 10:27 schrieb John Doe <johndoe at 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.richter83 at gmail.com>
> To: "volkszaehler.org - users" <volkszaehler-users at 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-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/77d20964/attachment-0001.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 2082 bytes
Beschreibung: nicht verfügbar
URL         : <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20201124/77d20964/attachment-0001.bin>