Re: [vz-users] Image mit dd erstellen / Datenbackup

[John Doe]

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="" 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.