subject:"\[vz\-users\] Image mit dd erstellen \/ Datenbackup"

Hallo Thomas,

wiederholen ist gut, denn ich hatte nicht verstanden was ich ausprobieren 
kann/soll. Ich schaue mir im Wiki an, wie der Transfer in sqlite.db3 
funktioniert!

Grüße

Micha

-Ursprüngliche Nachricht-
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Dienstag, 24. November 2020 17:44
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo Micha,


> 
> Am 24.11.2020 um 17:30 schrieb Michael Hartmann :
> 
> Ja klar. Ziel ist unverändert die DB auf dem NAS.
> 
> Grüße
> 
> Micha

ich wiederhole mich ungern, aber ich denke hier ist die Ursache für dein 
Problem.
Dbcopy hat bestimmt keine Netzwerkpuffer, und ob die DB Anwendung auf den NAS 
100% kompatibel ist kann auch keiner sagen.
Bitte teste das Beispiel aus den WIKI mit der sqlite.db3 Datei. Hast du schon 
die SSD angeschlossen? Wenn nicht nimm einen USB-Stick und schreibe darauf. 

Thomas 

Mail: tho...@thhoe.de

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

Hallo Micha,


> 
> Am 24.11.2020 um 17:30 schrieb Michael Hartmann :
> 
> Ja klar. Ziel ist unverändert die DB auf dem NAS.
> 
> Grüße
> 
> Micha

ich wiederhole mich ungern, aber ich denke hier ist die Ursache für dein 
Problem.
Dbcopy hat bestimmt keine Netzwerkpuffer, und ob die DB Anwendung auf den NAS 
100% kompatibel ist kann auch keiner sagen.
Bitte teste das Beispiel aus den WIKI mit der sqlite.db3 Datei. Hast du schon 
die SSD angeschlossen? Wenn nicht nimm einen USB-Stick und schreibe darauf. 

Thomas 

Mail: tho...@thhoe.de



smime.p7s
Description: S/MIME cryptographic signature

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

Ja klar. Ziel ist unverändert die DB auf dem NAS.

Grüße

Micha

-Ursprüngliche Nachricht-
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Dienstag, 24. November 2020 17:25
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo Michael,
sorry hatte es falsch verstanden.
Wie sieht deine aktuelle dbcopy.yaml aus? Ist das Ziel wieder die DB auf den 
NAS?

Thomas 

Mail: tho...@thhoe.de


> Am 24.11.2020 um 17:18 schrieb Michael Hartmann :
> 
> Hallo Thomas,
> 
> nein ich habe beim 1. Durchlauf data: copy gesetzt. Nicht data: skip!
> 
> Ich habe nun den Inhalt der DB im Backupüber das FE von MariaDB komplett 
> gelöscht und mittel dbcopy create die Struktur wieder angelegt. Dann habe ich 
> eine erneuten Durchlauch mit data: copy durchgeführt und auch hier ist das 
> nach 2sec abgearbeitet, ohne das Daten in die DB transferiert worden wären.
> 
> Ich denke copy ist im wiki falsch beschrieben, bzw. ich verstehe es nicht 
> richtig:
> --
> copy
> Bedeutet die Tabelle in der Ziel-Datenbank wird geleert und aus der Quelle 
> neu beschrieben. Ein derart kopierte Tabelle ist keine „echtes“ Backup!
> --
> 
> Nun läuft gerade ein Durchlauf mit data: pk auf die leere DB. Das dauert 5h 
> und läuft gerade
> 
> Grüße
> 
> Micha
> 
> -Ursprüngliche Nachricht-
> Von: volkszaehler-users 
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
> Thomas Höpfner
> Gesendet: Dienstag, 24. November 2020 17:07
> An: volkszaehler.org - users
> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
> 
> Hallo Micha,
> 
> bei deinen 1. durchlauf hast du data übersprungen (skip),
> beim 2. sind die Daten im Ziel scheinbar noch nicht vorhanden.
> 
> Thomas 
> 
> Mail: tho...@thhoe.de
> 
> 
>> Am 24.11.2020 um 16:42 schrieb Michael Hartmann :
>> 
>> Irgendwas stimmt da generell nicht.
>> 
>> Wenn ich in dbcopy.yaml "data: copy" setzte, dann will dbcopy in 2sec 
>> 6204433 Datensätze kopiert haben.
>> 
>> -
>> pi@SmartMeter:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
>> /etc/dbcopy.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 6204433 rows (overwrite)
>> [] 100%   2 secs/2 secs   6204433 rows
>> 
>> aggregate: skipping
>> --
>> 
>> Setze ich "data: pk" zurück, läuft wieder ein volles Backup
>> 
>> ---
>> pi@SmartMeter:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
>> /etc/dbcopy.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 6203559 rows (partial copy)
>> [>---]   0%   8 secs/4 hrs   3000 rows
>> ---
>> 
>> ?
>> 
>> Grüße
>> 
>> Micha
>> 
>> 
>> 
>> 
>> -Ursprüngliche Nachricht-
>> Von: volkszaehler-users 
>> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
>> Daniel Lauckner
>> Gesendet: Dienstag, 24. November 2020 15:41
>> An: volkszaehler.org - users
>> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
>> 
>> Hallo,
>> 
>> 
>>> am Dienstag, 24. November 2020 um 15:28 hat Friedrich Kessler geschrieben:
>>> - eigentlich sollte dieses Feld erst gar nicht gesichert werden wenn die
>>> Rücksicherung in eine VzDB erfolgen soll.
>> 
>> Ich glaube das ist für die Ergänzungsfunktion nötig.
>> Wenn beide Datenbanken die selben Primarys haben kannst du mit einer 
>> schnellen Abfrage ermitteln bis wohin die letzte Ergänzung ausgeführt 
>> wurde und dort wieder ansetzen.
>> 
>> 
>> mfg Daniel
>> 
>> 
> 


dbcopy.yaml
Description: Binary data

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

Hallo Michael,
sorry hatte es falsch verstanden.
Wie sieht deine aktuelle dbcopy.yaml aus? Ist das Ziel wieder die DB auf den 
NAS?

Thomas 

Mail: tho...@thhoe.de


> Am 24.11.2020 um 17:18 schrieb Michael Hartmann :
> 
> Hallo Thomas,
> 
> nein ich habe beim 1. Durchlauf data: copy gesetzt. Nicht data: skip!
> 
> Ich habe nun den Inhalt der DB im Backupüber das FE von MariaDB komplett 
> gelöscht und mittel dbcopy create die Struktur wieder angelegt. Dann habe ich 
> eine erneuten Durchlauch mit data: copy durchgeführt und auch hier ist das 
> nach 2sec abgearbeitet, ohne das Daten in die DB transferiert worden wären.
> 
> Ich denke copy ist im wiki falsch beschrieben, bzw. ich verstehe es nicht 
> richtig:
> --
> copy
> Bedeutet die Tabelle in der Ziel-Datenbank wird geleert und aus der Quelle 
> neu beschrieben. Ein derart kopierte Tabelle ist keine „echtes“ Backup!
> --
> 
> Nun läuft gerade ein Durchlauf mit data: pk auf die leere DB. Das dauert 5h 
> und läuft gerade
> 
> Grüße
> 
> Micha
> 
> -Ursprüngliche Nachricht-
> Von: volkszaehler-users 
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
> Thomas Höpfner
> Gesendet: Dienstag, 24. November 2020 17:07
> An: volkszaehler.org - users
> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
> 
> Hallo Micha,
> 
> bei deinen 1. durchlauf hast du data übersprungen (skip),
> beim 2. sind die Daten im Ziel scheinbar noch nicht vorhanden.
> 
> Thomas 
> 
> Mail: tho...@thhoe.de
> 
> 
>> Am 24.11.2020 um 16:42 schrieb Michael Hartmann :
>> 
>> Irgendwas stimmt da generell nicht.
>> 
>> Wenn ich in dbcopy.yaml "data: copy" setzte, dann will dbcopy in 2sec 
>> 6204433 Datensätze kopiert haben.
>> 
>> -
>> pi@SmartMeter:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
>> /etc/dbcopy.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 6204433 rows (overwrite)
>> [] 100%   2 secs/2 secs   6204433 rows
>> 
>> aggregate: skipping
>> --
>> 
>> Setze ich "data: pk" zurück, läuft wieder ein volles Backup
>> 
>> ---
>> pi@SmartMeter:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
>> /etc/dbcopy.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 6203559 rows (partial copy)
>> [>---]   0%   8 secs/4 hrs   3000 rows
>> ---
>> 
>> ?
>> 
>> Grüße
>> 
>> Micha
>> 
>> 
>> 
>> 
>> -Ursprüngliche Nachricht-
>> Von: volkszaehler-users 
>> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
>> Daniel Lauckner
>> Gesendet: Dienstag, 24. November 2020 15:41
>> An: volkszaehler.org - users
>> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
>> 
>> Hallo,
>> 
>> 
>>> am Dienstag, 24. November 2020 um 15:28 hat Friedrich Kessler geschrieben:
>>> - eigentlich sollte dieses Feld erst gar nicht gesichert werden wenn die
>>> Rücksicherung in eine VzDB erfolgen soll.
>> 
>> Ich glaube das ist für die Ergänzungsfunktion nötig.
>> Wenn beide Datenbanken die selben Primarys haben kannst du mit einer 
>> schnellen Abfrage ermitteln bis wohin die letzte Ergänzung ausgeführt 
>> wurde und dort wieder ansetzen.
>> 
>> 
>> mfg Daniel
>> 
>> 
> 


smime.p7s
Description: S/MIME cryptographic signature

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

Hallo Thomas,

nein ich habe beim 1. Durchlauf data: copy gesetzt. Nicht data: skip!

Ich habe nun den Inhalt der DB im Backupüber das FE von MariaDB komplett 
gelöscht und mittel dbcopy create die Struktur wieder angelegt. Dann habe ich 
eine erneuten Durchlauch mit data: copy durchgeführt und auch hier ist das nach 
2sec abgearbeitet, ohne das Daten in die DB transferiert worden wären.

Ich denke copy ist im wiki falsch beschrieben, bzw. ich verstehe es nicht 
richtig:
--
copy
Bedeutet die Tabelle in der Ziel-Datenbank wird geleert und aus der Quelle neu 
beschrieben. Ein derart kopierte Tabelle ist keine „echtes“ Backup!
--

Nun läuft gerade ein Durchlauf mit data: pk auf die leere DB. Das dauert 5h und 
läuft gerade

Grüße

Micha

-Ursprüngliche Nachricht-
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Dienstag, 24. November 2020 17:07
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo Micha,

bei deinen 1. durchlauf hast du data übersprungen (skip),
beim 2. sind die Daten im Ziel scheinbar noch nicht vorhanden.

Thomas 

Mail: tho...@thhoe.de


> Am 24.11.2020 um 16:42 schrieb Michael Hartmann :
> 
> Irgendwas stimmt da generell nicht.
> 
> Wenn ich in dbcopy.yaml "data: copy" setzte, dann will dbcopy in 2sec 6204433 
> Datensätze kopiert haben.
> 
> -
> pi@SmartMeter:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
> /etc/dbcopy.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 6204433 rows (overwrite)
> [] 100%   2 secs/2 secs   6204433 rows
> 
> aggregate: skipping
> --
> 
> Setze ich "data: pk" zurück, läuft wieder ein volles Backup
> 
> ---
> pi@SmartMeter:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
> /etc/dbcopy.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 6203559 rows (partial copy)
> [>---]   0%   8 secs/4 hrs   3000 rows
> ---
> 
> ?
> 
> Grüße
> 
> Micha
> 
> 
> 
> 
> -Ursprüngliche Nachricht-----
> Von: volkszaehler-users 
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
> Daniel Lauckner
> Gesendet: Dienstag, 24. November 2020 15:41
> An: volkszaehler.org - users
> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
> 
> Hallo,
> 
> 
> am Dienstag, 24. November 2020 um 15:28 hat Friedrich Kessler geschrieben:
>> - eigentlich sollte dieses Feld erst gar nicht gesichert werden wenn die
>> Rücksicherung in eine VzDB erfolgen soll.
> 
> Ich glaube das ist für die Ergänzungsfunktion nötig.
> Wenn beide Datenbanken die selben Primarys haben kannst du mit einer 
> schnellen Abfrage ermitteln bis wohin die letzte Ergänzung ausgeführt 
> wurde und dort wieder ansetzen.
> 
> 
> mfg Daniel
> 
>

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

Hallo Micha,

bei deinen 1. durchlauf hast du data übersprungen (skip),
beim 2. sind die Daten im Ziel scheinbar noch nicht vorhanden.

Thomas 

Mail: tho...@thhoe.de


> Am 24.11.2020 um 16:42 schrieb Michael Hartmann :
> 
> Irgendwas stimmt da generell nicht.
> 
> Wenn ich in dbcopy.yaml "data: copy" setzte, dann will dbcopy in 2sec 6204433 
> Datensätze kopiert haben.
> 
> -
> pi@SmartMeter:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
> /etc/dbcopy.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 6204433 rows (overwrite)
> [] 100%   2 secs/2 secs   6204433 rows
> 
> aggregate: skipping
> --
> 
> Setze ich "data: pk" zurück, läuft wieder ein volles Backup
> 
> ---
> pi@SmartMeter:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
> /etc/dbcopy.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 6203559 rows (partial copy)
> [>---]   0%   8 secs/4 hrs   3000 rows
> ---
> 
> ?
> 
> Grüße
> 
> Micha
> 
> 
> 
> 
> -Ursprüngliche Nachricht-----
> Von: volkszaehler-users 
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
> Daniel Lauckner
> Gesendet: Dienstag, 24. November 2020 15:41
> An: volkszaehler.org - users
> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
> 
> Hallo,
> 
> 
> am Dienstag, 24. November 2020 um 15:28 hat Friedrich Kessler geschrieben:
>> - eigentlich sollte dieses Feld erst gar nicht gesichert werden wenn die
>> Rücksicherung in eine VzDB erfolgen soll.
> 
> Ich glaube das ist für die Ergänzungsfunktion nötig.
> Wenn beide Datenbanken die selben Primarys haben kannst du mit einer 
> schnellen Abfrage ermitteln bis wohin die letzte Ergänzung ausgeführt 
> wurde und dort wieder ansetzen.
> 
> 
> mfg Daniel
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

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

Irgendwas stimmt da generell nicht.

Wenn ich in dbcopy.yaml "data: copy" setzte, dann will dbcopy in 2sec 6204433 
Datensätze kopiert haben.

-
pi@SmartMeter:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
/etc/dbcopy.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 6204433 rows (overwrite)
 [] 100%   2 secs/2 secs   6204433 rows

aggregate: skipping
--

Setze ich "data: pk" zurück, läuft wieder ein volles Backup

---
pi@SmartMeter:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
/etc/dbcopy.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 6203559 rows (partial copy)
 [>---]   0%   8 secs/4 hrs   3000 rows
---

?

Grüße

Micha




-Ursprüngliche Nachricht-
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Daniel 
Lauckner
Gesendet: Dienstag, 24. November 2020 15:41
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo,


am Dienstag, 24. November 2020 um 15:28 hat Friedrich Kessler geschrieben:
> - eigentlich sollte dieses Feld erst gar nicht gesichert werden wenn die
> Rücksicherung in eine VzDB erfolgen soll.

Ich glaube das ist für die Ergänzungsfunktion nötig.
Wenn beide Datenbanken die selben Primarys haben kannst du mit einer 
schnellen Abfrage ermitteln bis wohin die letzte Ergänzung ausgeführt 
wurde und dort wieder ansetzen.


mfg Daniel

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

2020-11-24 Diskussionsfäden Daniel Lauckner

Hallo,


am Dienstag, 24. November 2020 um 15:28 hat Friedrich Kessler geschrieben:
> - eigentlich sollte dieses Feld erst gar nicht gesichert werden wenn die
> Rücksicherung in eine VzDB erfolgen soll.

Ich glaube das ist für die Ergänzungsfunktion nötig.
Wenn beide Datenbanken die selben Primarys haben kannst du mit einer 
schnellen Abfrage ermitteln bis wohin die letzte Ergänzung ausgeführt 
wurde und dort wieder ansetzen.


mfg Daniel

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

2020-11-24 Diskussionsfäden Friedrich Kessler

Hallo,
Die Data Tabelle sieht so aus:
mysql> desc data;
+++--+-+-++
| Field   | Type | Null | Key | Default | Extra   |
+++--+-+-++
| id  | int(11)  | NO   | PRI | NULL| auto_increment |
| channel_id  | int(11)  | YES  | MUL | NULL||
| timestamp   | bigint(20)   | NO   | | NULL||
| value   | double   | NO   | | NULL||
+++--+-+-++
4 rows in set (0.02 sec)

Wie Daniel schon geschrieben hat - dasFeld id wird durch die DB mittels
auto-increment beschrieben und kann nicht

mit „Usermitteln“ gefüllt werden. Ich kenne an dieser Stelle dbcopy nicht
- eigentlich sollte dieses Feld erst gar nicht gesichert werden wenn die
Rücksicherung in eine VzDB erfolgen soll.

Gruss
Fritz

Am 24.11.20, 11:01 schrieb "volkszaehler-users on behalf of Daniel
Lauckner" unter :

>Hallo,
>
>
>am Dienstag, 24. November 2020 um 09:21 hat John Doe geschrieben:
>> 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 ?
>
>Die Fehlermeldung besagt das dbcopy einen Index zu schreiben
>versucht den er nicht doppelt schreiben darf. Das hat nix mit dem
>Inhalt der übrigens Felder im Datensatz zu tun.
>Und der Inhalt der Felder wird da auch nicht auf externe Plausibilität
>überprüft. "Zeit" ist für die Datenbank nur ein Feld mit einer
>ordinären Ganzzahl.
>
>>  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.
>
>Wenn Peaks im Graph sind konnte die Datenbank die Anfrage bearbeiten.
>Da geht die Theorie schon nicht auf.
>
>
>mfg Daniel
>

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

2020-11-24 Diskussionsfäden Friedrich Kessler

Hallo zusammen,
Der Timestamp in der DB ist ein Unix Timestamp in ms. Also vorher den
Timestamp durch 1000 dividieren und dann in einen Zeitwert umwanden  dann
passt¹s
Grüsse
Fritz

Von:  volkszaehler-users 
on behalf of John Doe 
Antworten an:  "volkszaehler.org - users"

Datum:  Dienstag, 24. November 2020 um 09:21
An:  
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" 
To: "volkszaehler.org - users" 
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"
: 
> 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 
>> Gesendet: Sonntag 22 November 2020 14:52
>> An: 'volkszaehler.org - users' 
>> 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 sec0 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] [--]
>> [...]
>>  
>> 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.

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

Hallo Daniel,

 

Danke für die Erläuterung.

Mit "Überprüfung" dachte ich eigentlich an eine Möglichkeit, die ordinären Ganzzahlen bspw. auf monotone Steigung hin zu prüfen.

Sollte die Systemzeit nach einem Reboot eben noch nicht richtig synchronisiert sein, ergeben sich nach meinem Verständnis beim Berechnen der Energiewerte doch mitunter negative bzw. unsinnige Werte  (?)

Mir ist bewusst, dass eine Datenbank-SW das nicht intrinsisch prüft, daher fragte ich ja bewusst nach einem Programm, bspw. einer weiteren Funktion von dbcopy.

Grüße

 

JD.

 
 

Sent: Tuesday, November 24, 2020 at 11:01 AM
From: "Daniel Lauckner" 
To: "volkszaehler.org - users" 
Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo,


am Dienstag, 24. November 2020 um 09:21 hat John Doe geschrieben:
> 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 ?

Die Fehlermeldung besagt das dbcopy einen Index zu schreiben
versucht den er nicht doppelt schreiben darf. Das hat nix mit dem
Inhalt der übrigens Felder im Datensatz zu tun.
Und der Inhalt der Felder wird da auch nicht auf externe Plausibilität
überprüft. "Zeit" ist für die Datenbank nur ein Feld mit einer
ordinären Ganzzahl.

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

Wenn Peaks im Graph sind konnte die Datenbank die Anfrage bearbeiten.
Da geht die Theorie schon nicht auf.


mfg Daniel

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

2020-11-24 Diskussionsfäden Daniel Lauckner

Hallo,


am Dienstag, 24. November 2020 um 09:21 hat John Doe geschrieben:
> 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 ?

Die Fehlermeldung besagt das dbcopy einen Index zu schreiben 
versucht den er nicht doppelt schreiben darf. Das hat nix mit dem 
Inhalt der übrigens Felder im Datensatz zu tun.
Und der Inhalt der Felder wird da auch nicht auf externe Plausibilität 
überprüft. "Zeit" ist für die Datenbank nur ein Feld mit einer
ordinären Ganzzahl.

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

Wenn Peaks im Graph sind konnte die Datenbank die Anfrage bearbeiten.
Da geht die Theorie schon nicht auf.


mfg Daniel

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

2020-11-24 Diskussionsfäden Daniel Lauckner

Hallo,


am Dienstag, 24. November 2020 um 09:56 hat Frank Richter geschrieben:
> Die Timestamps bei vz sind ms, also bitte vorher durch 1000 teilen :-)

Oder einen Converter nutzen der mit ms klar kommt. z.B.
https://www.epochconverter.com

GMT: Friday, 29. May 2020 14:16:21.023


mfg Daniel

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

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

Thomas 

Mail: tho...@thhoe.de


> Am 24.11.2020 um 10:27 schrieb 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" 
> To: "volkszaehler.org - users" 
> 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  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" 
>> 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" 
>> To: "volkszaehler.org - users" 
>> 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" :
>>> 
>>> 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 
>>> Gesendet: Sonntag 22 November 2020 14:52
>>> An: 'volkszaehler.org - users' 
>>> 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 (ove

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

Stimmt ! :-D

Dann hieße das nach dem letzten Post, dass das Problem mit der DB schon ganz am Anfang auftaucht...

Grüße

JD.

Sent: Tuesday, November 24, 2020 at 10:29 AM
From: "Stefan Bauer"
To: "volkszaehler.org - users"
Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup

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 :

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"
To: "volkszaehler.org - users"
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:

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

2020-11-24 Diskussionsfäden Frank Richter

Ich nehme gerne epochconverter.com, der merkt selber wenn der Timestamp in
ms angegeben ist.

Grüße
Frank

Am Di., 24. Nov. 2020 um 10:29 Uhr schrieb Stefan Bauer <
s...@stefan-bauer.net>:

> 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 :
>
> 
> 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" 
> *To:* "volkszaehler.org - users"  >
> *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  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" 
>> *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" 
>> *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 
>>> *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

2020-11-24 Diskussionsfäden Stefan Bauer

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 :
> 
> 
> 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" 
> To: "volkszaehler.org - users" 
> 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  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" 
>> 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" 
>> To: "volkszaehler.org - users" 
>> 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" :
>>> 
>>> 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 
>>> Gesendet: Sonntag 22 November 2020 14:52
>>> An: 'volkszaehler.org - users' 
>>> 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
>

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

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" 
To: "volkszaehler.org - users" 
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]: Int

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

2020-11-24 Diskussionsfäden Frank Richter

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

Grüße
Frank

Michael Hartmann  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" 
> *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" 
> *To:* "volkszaehler.org - users"  >
> *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 
>> *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 sec0 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"]:
>>
>>
>>
>&g

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

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.

Grüße

Micha

Gesendet: Dienstag, 24. November 2020 um 09:21 Uhr
Von: "John Doe"
An: volkszaehler-users@demo.volkszaehler.org
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo zusammen,

Grüße

JD.

Sent: Monday, November 23, 2020 at 8:48 PM
From: "Michael Hartmann"
To: "volkszaehler.org - users"
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" :

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
Gesendet: Sonntag 22 November 2020 14:52
An: 'volkszaehler.org - users'
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] [--] [...]

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.

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" 
To: "volkszaehler.org - users" 
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" :

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 
Gesendet: Sonntag 22 November 2020 14:52
An: 'volkszaehler.org - users' 
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] [--] [...]


 

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.

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

2020-11-23 Diskussionsfäden Daniel Lauckner

Hallo,


am Montag, 23. November 2020 um 20:48 hat Michael Hartmann geschrieben:
> Ich bin raus. Keine Ahnung, warum ich die Daten nicht retour
> bekomme.

Mach mal ein Issue bei Github auf. Vielleicht weiß ja Andreas was.
(der ließt schon ne Weile nicht mehr bei Users mit)


mfg Daniel

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

2020-11-23 Diskussionsfäden Michael Hartmann

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" :
>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 
>Gesendet: Sonntag 22 November 2020 14:52
>An: 'volkszaehler.org - users'
>
>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]
>[--] [...]
>
> 
>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.

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

2020-11-22 Diskussionsfäden Thomas Höpfner

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 
Gesendet: Sonntag 22 November 2020 14:52
An: 'volkszaehler.org - users' 
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] [--] 
[...]

 
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

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

2020-11-22 Diskussionsfäden Michael Hartmann

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 sec0 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] [--] 
[...]

 

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

 

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Sonntag, 22. November 2020 13:51
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

 

Hallo Micha,

 

also mein Backup mit dbcopy und sqlite funktioniert.

Der erste Restore der Datenbank dauert zwar ziemlich lang:



Das Ergänzen funktioniert aber zügig:

Auf den Testsystem kommen keine Daten, deshalb habe ich mir um vzlogger und 
ähnliches nicht beachdet.

Meine Vermutung das deine DB einen Fehler hat kam weil ich nicht wusste wie du 
dein Backup machts.
Das von dier beschriebene Verhalten passt meiner Meinung nach zu 
Netzwerkschankungen, mit dehnen dbcopy nicht zurecht kommt.
Diese zu suchen und zu beheben ist aber nicht notwendig. Der Weg über sqlite 
funktioniert gut, und zusammen mit einen image sollte es auch schnell sein.
Ich persöhlich werde noch testen ob ich mit einen dump das Restore significant 
verkürzen kann.

PS: meine DB mit über 54 Mio Datensätzen hat 2,17 GB

Mit freundlichen Grüßen,

Thomas

 

-----Ursprüngliche Nachricht-
Von: Thomas Höpfner 
Gesendet: Samstag 21 November 2020 19:33
An: volkszaehler.org - users 
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo Micha, 

 

mein Backup liegt auch auf einen NAS. Aber nicht in einen SQL Server sondern 
als file. Bein Backup mounte ich das NAS und schreibe in eine postgrey Datei. 
Ich teste gerade, morgen weiß ich mehr.

Thomas  

 

Mail: tho...@thhoe.de

 

 

Am 21.11.2020 um 19:09 schrieb Michael Hartmann :

Das Backup der DB geht auf das NAS. Ich könnte auch direkt in diese DB 
schreiben, nur laufen die HDDs im NAS dann 24/7 mit entsprechendem Verschleiß 
und Stromaufnahme, Geräusch.

 

Idealerweise hätte ich gerne die Middleware und die DB auf einer SSD am 
USB-Port des NAS. Dann können die HDDs in den power down, wenn keine sonstigen 
Zugriffe erfolgen. Dann würde ich weiter auf die HDDs des selben NAS ein Backup 
fahren.  Einige haben das hier so laufen. Nur das bekomme ich nicht hin.

 

Grüße

 

Micha

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Samstag, 21. November 2020 18:57
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

 

Hallo Micha,

 

das dein Backup auf ein anderen SQL-Server im Netzwerk ist habe ich bis jetzt 
übersehen.  Das sind gleich 2 mögliche Fehlerquellen. Warum hast du überhaupt 
die DB auf den Pi wenn noch ein anderer Server läuft?

Thomas 

 

 

Am 21.11.2020 um 17:49 schrieb Frank Richter :

 

Versuch mal trotzdem vorher auf dem Zielsystem:

 

TRUNCATE TABLE volkszaehler.data;

 

Michael Hartmann  schrieb am Sa., 21. Nov. 2020, 17:26:

Hallo Frank,

 

konkret: leer!

 

Das Testsystem hat keine HW. vzlogger empfängt keine Werte, kann also auch 
keine Daten schreiben oder? Ich hänge die dbcopy config an.

 

Grüße

 

Micha

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Frank 
Richter
Gesen

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

2020-11-22 Diskussionsfäden Thomas Höpfner

Hallo Micha,



also mein Backup mit dbcopy und sqlite funktioniert.

Der erste Restore der Datenbank dauert zwar ziemlich lang:



Das Ergänzen funktioniert aber zügig:

Auf den Testsystem kommen keine Daten, deshalb habe ich mir um vzlogger und 
ähnliches nicht beachdet.

Meine Vermutung das deine DB einen Fehler hat kam weil ich nicht wusste wie du 
dein Backup machts.
Das von dier beschriebene Verhalten passt meiner Meinung nach zu 
Netzwerkschankungen, mit dehnen dbcopy nicht zurecht kommt.
Diese zu suchen und zu beheben ist aber nicht notwendig. Der Weg über sqlite 
funktioniert gut, und zusammen mit einen image sollte es auch schnell sein.
Ich persöhlich werde noch testen ob ich mit einen dump das Restore significant 
verkürzen kann.

PS: meine DB mit über 54 Mio Datensätzen hat 2,17 GB

Mit freundlichen Grüßen,

Thomas



-Ursprüngliche Nachricht-
Von: Thomas Höpfner 
Gesendet: Samstag 21 November 2020 19:33
An: volkszaehler.org - users 
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo Micha,

mein Backup liegt auch auf einen NAS. Aber nicht in einen SQL Server sondern 
als file. Bein Backup mounte ich das NAS und schreibe in eine postgrey Datei. 
Ich teste gerade, morgen weiß ich mehr.

Thomas 

Mail: tho...@thhoe.de


Am 21.11.2020 um 19:09 schrieb Michael Hartmann :

Das Backup der DB geht auf das NAS. Ich könnte auch direkt in diese DB 
schreiben, nur laufen die HDDs im NAS dann 24/7 mit entsprechendem Verschleiß 
und Stromaufnahme, Geräusch.

 
Idealerweise hätte ich gerne die Middleware und die DB auf einer SSD am 
USB-Port des NAS. Dann können die HDDs in den power down, wenn keine sonstigen 
Zugriffe erfolgen. Dann würde ich weiter auf die HDDs des selben NAS ein Backup 
fahren.  Einige haben das hier so laufen. Nur das bekomme ich nicht hin.

 
Grüße

 
Micha

 
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Samstag, 21. November 2020 18:57
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

 
Hallo Micha,

 
das dein Backup auf ein anderen SQL-Server im Netzwerk ist habe ich bis jetzt 
übersehen.  Das sind gleich 2 mögliche Fehlerquellen. Warum hast du überhaupt 
die DB auf den Pi wenn noch ein anderer Server läuft?

Thomas 

 



Am 21.11.2020 um 17:49 schrieb Frank Richter :

 
Versuch mal trotzdem vorher auf dem Zielsystem:

 
TRUNCATE TABLE volkszaehler.data;

 
Michael Hartmann mailto:hartmann-mi...@web.de> > 
schrieb am Sa., 21. Nov. 2020, 17:26:

Hallo Frank,

 
konkret: leer!

 
Das Testsystem hat keine HW. vzlogger empfängt keine Werte, kann also auch 
keine Daten schreiben oder? Ich hänge die dbcopy config an.

 
Grüße

 
Micha

 
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Frank 
Richter
Gesendet: Samstag, 21. November 2020 17:01
An: volkszaehler.org <http://volkszaehler.org> - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

 
Hallo Michael,

 
was heißt den "weitgehend leer"? Hast du den Restore-Versuch gemacht, bevor du 
vzlogger neue Daten in die DB schreiben lässt?

 
Viele Grüße

Frank

 
Michael Hartmann mailto:hartmann-mi...@web.de> > 
schrieb am Sa., 21. Nov. 2020, 16:27:

Ich habe nun das Testsystem mit dem Image das im Wiki zum DL bereitsteht 
komplett neu aufgebaut. Update vzlogger, middleware/frontend, alle 
Konfigurationen ...

Auf diesem System sollte sich eine weitgehend leere Datenbank befinden. Und das 
Ergebnis beim zurückspielen der Daten ist  genau das gleiche!

--
pi@SmartMeter:/usr/local/bin $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy 
-c /etc/dbcopy_restore.yaml
Dropping FK FK_87C331C781257D5D on properties
Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator
Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator
Dropping FK FK_ADF3F36372F5A1AA on data
Dropping FK FK_B77949FF72F5A1AA on aggregate
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 6.0 MiB

data: copying 7819821 rows (partial copy)
 [>---]   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 params ["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

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

2020-11-21 Diskussionsfäden Thomas Höpfner

Hallo Micha,

mein Backup liegt auch auf einen NAS. Aber nicht in einen SQL Server sondern 
als file. Bein Backup mounte ich das NAS und schreibe in eine postgrey Datei. 
Ich teste gerade, morgen weiß ich mehr.

Thomas 

Mail: tho...@thhoe.de


> Am 21.11.2020 um 19:09 schrieb Michael Hartmann :
> 
> 
> Das Backup der DB geht auf das NAS. Ich könnte auch direkt in diese DB 
> schreiben, nur laufen die HDDs im NAS dann 24/7 mit entsprechendem Verschleiß 
> und Stromaufnahme, Geräusch.
>  
> Idealerweise hätte ich gerne die Middleware und die DB auf einer SSD am 
> USB-Port des NAS. Dann können die HDDs in den power down, wenn keine 
> sonstigen Zugriffe erfolgen. Dann würde ich weiter auf die HDDs des selben 
> NAS ein Backup fahren.  Einige haben das hier so laufen. Nur das bekomme ich 
> nicht hin.
>  
> Grüße
>  
> Micha
>  
> Von: volkszaehler-users 
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
> Thomas Höpfner
> Gesendet: Samstag, 21. November 2020 18:57
> An: volkszaehler.org - users
> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
>  
> Hallo Micha,
>  
> das dein Backup auf ein anderen SQL-Server im Netzwerk ist habe ich bis jetzt 
> übersehen.  Das sind gleich 2 mögliche Fehlerquellen. Warum hast du überhaupt 
> die DB auf den Pi wenn noch ein anderer Server läuft?
> 
> Thomas 
>  
> 
> 
> Am 21.11.2020 um 17:49 schrieb Frank Richter :
> 
> 
> Versuch mal trotzdem vorher auf dem Zielsystem:
>  
> TRUNCATE TABLE volkszaehler.data;
>  
> Michael Hartmann  schrieb am Sa., 21. Nov. 2020, 17:26:
> Hallo Frank,
>  
> konkret: leer!
>  
> Das Testsystem hat keine HW. vzlogger empfängt keine Werte, kann also auch 
> keine Daten schreiben oder? Ich hänge die dbcopy config an.
>  
> Grüße
>  
> Micha
>  
> Von: volkszaehler-users 
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
> Frank Richter
> Gesendet: Samstag, 21. November 2020 17:01
> An: volkszaehler.org - users
> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
>  
> Hallo Michael,
>  
> was heißt den "weitgehend leer"? Hast du den Restore-Versuch gemacht, bevor 
> du vzlogger neue Daten in die DB schreiben lässt?
>  
> Viele Grüße
> Frank
>  
> Michael Hartmann  schrieb am Sa., 21. Nov. 2020, 16:27:
> Ich habe nun das Testsystem mit dem Image das im Wiki zum DL bereitsteht 
> komplett neu aufgebaut. Update vzlogger, middleware/frontend, alle 
> Konfigurationen ...
> 
> Auf diesem System sollte sich eine weitgehend leere Datenbank befinden. Und 
> das Ergebnis beim zurückspielen der Daten ist  genau das gleiche!
> 
> --
> pi@SmartMeter:/usr/local/bin $ /var/www/volkszaehler.org/vendor/bin/dbcopy 
> copy -c /etc/dbcopy_restore.yaml
> Dropping FK FK_87C331C781257D5D on properties
> Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator
> Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator
> Dropping FK FK_ADF3F36372F5A1AA on data
> Dropping FK FK_B77949FF72F5A1AA on aggregate
> 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 6.0 MiB
> 
> data: copying 7819821 rows (partial copy)
>  [>---]   0%  < 1 sec/< 1 sec0 rows
> In AbstractMySQLDriver.php line 74:
> 
>   An exception occurred while executing 'INSERT INTO `data` 
> (`id`,`channel_id`,`timestamp`,`value`) VALUES
>   (?,?,?,?)' with params ["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] [--] 
> [...]
> -
> 
> Und nun :-/
> 
> Grüße
> 
> Micha
> 
> -Ursprüngliche Nachricht-
> Von: volkszaehler-users 
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
> Thomas Höpfner
> Gesendet: Freit

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

Das Backup der DB geht auf das NAS. Ich könnte auch direkt in diese DB 
schreiben, nur laufen die HDDs im NAS dann 24/7 mit entsprechendem Verschleiß 
und Stromaufnahme, Geräusch.

 

Idealerweise hätte ich gerne die Middleware und die DB auf einer SSD am 
USB-Port des NAS. Dann können die HDDs in den power down, wenn keine sonstigen 
Zugriffe erfolgen. Dann würde ich weiter auf die HDDs des selben NAS ein Backup 
fahren.  Einige haben das hier so laufen. Nur das bekomme ich nicht hin.

 

Grüße

 

Micha

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Samstag, 21. November 2020 18:57
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

 

Hallo Micha,

 

das dein Backup auf ein anderen SQL-Server im Netzwerk ist habe ich bis jetzt 
übersehen.  Das sind gleich 2 mögliche Fehlerquellen. Warum hast du überhaupt 
die DB auf den Pi wenn noch ein anderer Server läuft?

Thomas 

 





Am 21.11.2020 um 17:49 schrieb Frank Richter :



Versuch mal trotzdem vorher auf dem Zielsystem:

 

TRUNCATE TABLE volkszaehler.data;

 

Michael Hartmann  schrieb am Sa., 21. Nov. 2020, 17:26:

Hallo Frank,

 

konkret: leer!

 

Das Testsystem hat keine HW. vzlogger empfängt keine Werte, kann also auch 
keine Daten schreiben oder? Ich hänge die dbcopy config an.

 

Grüße

 

Micha

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Frank 
Richter
Gesendet: Samstag, 21. November 2020 17:01
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

 

Hallo Michael,

 

was heißt den "weitgehend leer"? Hast du den Restore-Versuch gemacht, bevor du 
vzlogger neue Daten in die DB schreiben lässt?

 

Viele Grüße

Frank

 

Michael Hartmann  schrieb am Sa., 21. Nov. 2020, 16:27:

Ich habe nun das Testsystem mit dem Image das im Wiki zum DL bereitsteht 
komplett neu aufgebaut. Update vzlogger, middleware/frontend, alle 
Konfigurationen ...

Auf diesem System sollte sich eine weitgehend leere Datenbank befinden. Und das 
Ergebnis beim zurückspielen der Daten ist  genau das gleiche!

--
pi@SmartMeter:/usr/local/bin $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy 
-c /etc/dbcopy_restore.yaml
Dropping FK FK_87C331C781257D5D on properties
Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator
Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator
Dropping FK FK_ADF3F36372F5A1AA on data
Dropping FK FK_B77949FF72F5A1AA on aggregate
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 6.0 MiB

data: copying 7819821 rows (partial copy)
 [>---]   0%  < 1 sec/< 1 sec0 rows
In AbstractMySQLDriver.php line 74:

  An exception occurred while executing 'INSERT INTO `data` 
(`id`,`channel_id`,`timestamp`,`value`) VALUES
  (?,?,?,?)' with params ["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] [--] 
[...]
-

Und nun :-/

Grüße

Micha

-Ursprüngliche Nachricht-
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Freitag, 20. November 2020 19:31
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo Micha,

> Am 20.11.2020 um 17:45 schrieb Michael Hartmann :
> 
> Copy statt pk für die Daten in dbcopy.yaml hatte ich auf Daniels Anregung vor 
> ein paar Tagen bereits probiert und das Ergebnis hier berichtet: gleicher 
> Fehler!

auch beim backup?

Irgendwie glaube ich an einen Fehler in deiner aktiven DB. 
Werden fehler angezeigt wenn du auf der console
  :~# mysqlcheck -p --check volkszaehler 
ausführst?

Im Moment habe ich kein System um mein Backup zu testen, aber dein Weg sollte 
funktionieren. 

Thomas

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

Hallo Frank,

 

MariaDB [volkszaehler]> TRUNCATE TABLE volkszaehler.data;

Query OK, 0 rows affected (0.072 sec)

 

Dann:

 

pi@SmartMeter:~ $ /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 7819821 rows (overwrite)

[] 100%1 sec/1 sec7819821 rows

 

aggregate: skipping

 

Nur Daten sind scheinbar keine in der DB. Zumindest werden im FE keine 
angezeigt. 1sec für 7819821 Datensätze? Die angelegten Kanäle sind da:

 

MariaDB [volkszaehler]> select * from entities;

++--++-+

| id | uuid | type   | class   |

++--++-+

|  2 | f26a3af0-a10d-11ea-a487-7d0e2c482631 | electric meter | channel |

|  3 | 18688710-a10e-11ea-8ceb-61be7fd3ccbe | powersensor| channel |

| 10 | 65f77e50-c388-11ea-a32c-f99381422d2a | workinghours   | channel |

| 11 | 58842ff0-c38e-11ea-88ab-9b09e85c4c6e | power  | channel |

| 12 | d96e01b0-c392-11ea-8bfa-39ff07b6acb0 | virtualconsumption | channel |

| 14 | 70919b00-c5f8-11ea-8152-ed29ae9e5e38 | temperature| channel |

| 15 | b7a82280-d496-11ea-9c22-431f1d1ba5b0 | gas| channel |

++--++-+

7 rows in set (0.001 sec)

 

Grüße

 

Micha

 

 

 

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Frank 
Richter
Gesendet: Samstag, 21. November 2020 17:48
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

 

Versuch mal trotzdem vorher auf dem Zielsystem:

 

TRUNCATE TABLE volkszaehler.data;

 

Michael Hartmann  schrieb am Sa., 21. Nov. 2020, 17:26:

Hallo Frank,

 

konkret: leer!

 

Das Testsystem hat keine HW. vzlogger empfängt keine Werte, kann also auch 
keine Daten schreiben oder? Ich hänge die dbcopy config an.

 

Grüße

 

Micha

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Frank 
Richter
Gesendet: Samstag, 21. November 2020 17:01
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

 

Hallo Michael,

 

was heißt den "weitgehend leer"? Hast du den Restore-Versuch gemacht, bevor du 
vzlogger neue Daten in die DB schreiben lässt?

 

Viele Grüße

Frank

 

Michael Hartmann  schrieb am Sa., 21. Nov. 2020, 16:27:

Ich habe nun das Testsystem mit dem Image das im Wiki zum DL bereitsteht 
komplett neu aufgebaut. Update vzlogger, middleware/frontend, alle 
Konfigurationen ...

Auf diesem System sollte sich eine weitgehend leere Datenbank befinden. Und das 
Ergebnis beim zurückspielen der Daten ist  genau das gleiche!

--
pi@SmartMeter:/usr/local/bin $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy 
-c /etc/dbcopy_restore.yaml
Dropping FK FK_87C331C781257D5D on properties
Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator
Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator
Dropping FK FK_ADF3F36372F5A1AA on data
Dropping FK FK_B77949FF72F5A1AA on aggregate
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 6.0 MiB

data: copying 7819821 rows (partial copy)
 [>---]   0%  < 1 sec/< 1 sec0 rows
In AbstractMySQLDriver.php line 74:

  An exception occurred while executing 'INSERT INTO `data` 
(`id`,`channel_id`,`timestamp`,`value`) VALUES
  (?,?,?,?)' with params ["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] [--] 
[...]
-

Und nun :-/

Grüße

Micha

-Ursprüngliche Nachricht-
Von: volkszaehler-users 
[mailto:volkszaehle

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

2020-11-21 Diskussionsfäden Thomas Höpfner

Hallo Micha,

das dein Backup auf ein anderen SQL-Server im Netzwerk ist habe ich bis jetzt 
übersehen.  Das sind gleich 2 mögliche Fehlerquellen. Warum hast du überhaupt 
die DB auf den Pi wenn noch ein anderer Server läuft?

Thomas 


> Am 21.11.2020 um 17:49 schrieb Frank Richter :
> 
> 
> Versuch mal trotzdem vorher auf dem Zielsystem:
> 
> TRUNCATE TABLE volkszaehler.data;
> 
> Michael Hartmann  schrieb am Sa., 21. Nov. 2020, 17:26:
>> Hallo Frank,
>> 
>>  
>> 
>> konkret: leer!
>> 
>>  
>> 
>> Das Testsystem hat keine HW. vzlogger empfängt keine Werte, kann also auch 
>> keine Daten schreiben oder? Ich hänge die dbcopy config an.
>> 
>>  
>> 
>> Grüße
>> 
>>  
>> 
>> Micha
>> 
>>  
>> 
>> Von: volkszaehler-users 
>> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
>> Frank Richter
>> Gesendet: Samstag, 21. November 2020 17:01
>> An: volkszaehler.org - users
>> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
>> 
>>  
>> 
>> Hallo Michael,
>> 
>>  
>> 
>> was heißt den "weitgehend leer"? Hast du den Restore-Versuch gemacht, bevor 
>> du vzlogger neue Daten in die DB schreiben lässt?
>> 
>>  
>> 
>> Viele Grüße
>> 
>> Frank
>> 
>>  
>> 
>> Michael Hartmann  schrieb am Sa., 21. Nov. 2020, 
>> 16:27:
>> 
>> Ich habe nun das Testsystem mit dem Image das im Wiki zum DL bereitsteht 
>> komplett neu aufgebaut. Update vzlogger, middleware/frontend, alle 
>> Konfigurationen ...
>> 
>> Auf diesem System sollte sich eine weitgehend leere Datenbank befinden. Und 
>> das Ergebnis beim zurückspielen der Daten ist  genau das gleiche!
>> 
>> --
>> pi@SmartMeter:/usr/local/bin $ /var/www/volkszaehler.org/vendor/bin/dbcopy 
>> copy -c /etc/dbcopy_restore.yaml
>> Dropping FK FK_87C331C781257D5D on properties
>> Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator
>> Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator
>> Dropping FK FK_ADF3F36372F5A1AA on data
>> Dropping FK FK_B77949FF72F5A1AA on aggregate
>> 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 6.0 MiB
>> 
>> data: copying 7819821 rows (partial copy)
>>  [>---]   0%  < 1 sec/< 1 sec0 rows
>> In AbstractMySQLDriver.php line 74:
>> 
>>   An exception occurred while executing 'INSERT INTO `data` 
>> (`id`,`channel_id`,`timestamp`,`value`) VALUES
>>   (?,?,?,?)' with params ["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] [--] 
>> [...]
>> -
>> 
>> Und nun :-/
>> 
>> Grüße
>> 
>> Micha
>> 
>> -Ursprüngliche Nachricht-
>> Von: volkszaehler-users 
>> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
>> Thomas Höpfner
>> Gesendet: Freitag, 20. November 2020 19:31
>> An: volkszaehler.org - users
>> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
>> 
>> Hallo Micha,
>> 
>> > Am 20.11.2020 um 17:45 schrieb Michael Hartmann :
>> > 
>> > Copy statt pk für die Daten in dbcopy.yaml hatte ich auf Daniels Anregung 
>> > vor ein paar Tagen bereits probiert und das Ergebnis hier berichtet: 
>> > gleicher Fehler!
>> 
>> auch beim backup?
>> 
>> Irgendwie glaube ich an einen Fehler in deiner aktiven DB. 
>> Werden fehler angezeigt wenn du auf der console
>>   :~# mysqlcheck -p --check volkszaehler 
>> ausführst?
>> 
>> Im Moment habe ich kein System um mein Backup zu testen, aber dein Weg 
>> sollte funktionieren. 
>> 
>> Thomas 
>> 
>> 


smime.p7s
Description: S/MIME cryptographic signature

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

2020-11-21 Diskussionsfäden Frank Richter

Versuch mal trotzdem vorher auf dem Zielsystem:

TRUNCATE TABLE volkszaehler.data;

Michael Hartmann  schrieb am Sa., 21. Nov. 2020,
17:26:

> Hallo Frank,
>
>
>
> konkret: leer!
>
>
>
> Das Testsystem hat keine HW. vzlogger empfängt keine Werte, kann also auch
> keine Daten schreiben oder? Ich hänge die dbcopy config an.
>
>
>
> Grüße
>
>
>
> Micha
>
>
>
> *Von:* volkszaehler-users [mailto:
> volkszaehler-users-boun...@demo.volkszaehler.org] *Im Auftrag von *Frank
> Richter
> *Gesendet:* Samstag, 21. November 2020 17:01
> *An:* volkszaehler.org - users
> *Betreff:* Re: [vz-users] Image mit dd erstellen / Datenbackup
>
>
>
> Hallo Michael,
>
>
>
> was heißt den "weitgehend leer"? Hast du den Restore-Versuch gemacht,
> bevor du vzlogger neue Daten in die DB schreiben lässt?
>
>
>
> Viele Grüße
>
> Frank
>
>
>
> Michael Hartmann  schrieb am Sa., 21. Nov. 2020,
> 16:27:
>
> Ich habe nun das Testsystem mit dem Image das im Wiki zum DL bereitsteht
> komplett neu aufgebaut. Update vzlogger, middleware/frontend, alle
> Konfigurationen ...
>
> Auf diesem System sollte sich eine weitgehend leere Datenbank befinden.
> Und das Ergebnis beim zurückspielen der Daten ist  genau das gleiche!
>
> --
> pi@SmartMeter:/usr/local/bin $ /var/www/volkszaehler.org/vendor/bin/dbcopy
> copy -c /etc/dbcopy_restore.yaml
> Dropping FK FK_87C331C781257D5D on properties
> Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator
> Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator
> Dropping FK FK_ADF3F36372F5A1AA on data
> Dropping FK FK_B77949FF72F5A1AA on aggregate
> 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 6.0 MiB
>
> data: copying 7819821 rows (partial copy)
>  [>---]   0%  < 1 sec/< 1 sec0 rows
> In AbstractMySQLDriver.php line 74:
>
>   An exception occurred while executing 'INSERT INTO `data`
> (`id`,`channel_id`,`timestamp`,`value`) VALUES
>   (?,?,?,?)' with params ["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] [--]
> [...]
> -
>
> Und nun :-/
>
> Grüße
>
> Micha
>
> -Ursprüngliche Nachricht-
> Von: volkszaehler-users [mailto:
> volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas
> Höpfner
> Gesendet: Freitag, 20. November 2020 19:31
> An: volkszaehler.org - users
> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
>
> Hallo Micha,
>
> > Am 20.11.2020 um 17:45 schrieb Michael Hartmann :
> >
> > Copy statt pk für die Daten in dbcopy.yaml hatte ich auf Daniels
> Anregung vor ein paar Tagen bereits probiert und das Ergebnis hier
> berichtet: gleicher Fehler!
>
> auch beim backup?
>
> Irgendwie glaube ich an einen Fehler in deiner aktiven DB.
> Werden fehler angezeigt wenn du auf der console
>   :~# mysqlcheck -p --check volkszaehler
> ausführst?
>
> Im Moment habe ich kein System um mein Backup zu testen, aber dein Weg
> sollte funktionieren.
>
> Thomas
>
>
>

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

Nein! 

-Ursprüngliche Nachricht-
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Daniel 
Lauckner
Gesendet: Samstag, 21. November 2020 17:19
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo,


am Samstag, 21. November 2020 um 16:27 hat Michael Hartmann geschrieben:
> Und das Ergebnis beim zurückspielen der Daten ist  genau das gleiche!

Das stimmt so nicht.

>   SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' 
> for key 'PRIMARY'
vs.
>> SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 
>> '1325633' for key 'PRIMARY'

Er hängt sich an anderer Stelle auf.

Mal ganz blöd gefragt: ändert sich der Key wenn du dbcopy einfach
nochmal anstößt?


mfg Daniel

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

Hallo Frank,

 

konkret: leer!

 

Das Testsystem hat keine HW. vzlogger empfängt keine Werte, kann also auch 
keine Daten schreiben oder? Ich hänge die dbcopy config an.

 

Grüße

 

Micha

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Frank 
Richter
Gesendet: Samstag, 21. November 2020 17:01
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

 

Hallo Michael,

 

was heißt den "weitgehend leer"? Hast du den Restore-Versuch gemacht, bevor du 
vzlogger neue Daten in die DB schreiben lässt?

 

Viele Grüße

Frank

 

Michael Hartmann  schrieb am Sa., 21. Nov. 2020, 16:27:

Ich habe nun das Testsystem mit dem Image das im Wiki zum DL bereitsteht 
komplett neu aufgebaut. Update vzlogger, middleware/frontend, alle 
Konfigurationen ...

Auf diesem System sollte sich eine weitgehend leere Datenbank befinden. Und das 
Ergebnis beim zurückspielen der Daten ist  genau das gleiche!

--
pi@SmartMeter:/usr/local/bin $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy 
-c /etc/dbcopy_restore.yaml
Dropping FK FK_87C331C781257D5D on properties
Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator
Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator
Dropping FK FK_ADF3F36372F5A1AA on data
Dropping FK FK_B77949FF72F5A1AA on aggregate
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 6.0 MiB

data: copying 7819821 rows (partial copy)
 [>---]   0%  < 1 sec/< 1 sec0 rows
In AbstractMySQLDriver.php line 74:

  An exception occurred while executing 'INSERT INTO `data` 
(`id`,`channel_id`,`timestamp`,`value`) VALUES
  (?,?,?,?)' with params ["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] [--] 
[...]
-

Und nun :-/

Grüße

Micha

-Ursprüngliche Nachricht-
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Freitag, 20. November 2020 19:31
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo Micha,

> Am 20.11.2020 um 17:45 schrieb Michael Hartmann :
> 
> Copy statt pk für die Daten in dbcopy.yaml hatte ich auf Daniels Anregung vor 
> ein paar Tagen bereits probiert und das Ergebnis hier berichtet: gleicher 
> Fehler!

auch beim backup?

Irgendwie glaube ich an einen Fehler in deiner aktiven DB. 
Werden fehler angezeigt wenn du auf der console
  :~# mysqlcheck -p --check volkszaehler 
ausführst?

Im Moment habe ich kein System um mein Backup zu testen, aber dein Weg sollte 
funktionieren. 

Thomas 






dbcopy_restore.yaml
Description: Binary data

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

2020-11-21 Diskussionsfäden Daniel Lauckner

Hallo,


am Samstag, 21. November 2020 um 16:27 hat Michael Hartmann geschrieben:
> Und das Ergebnis beim zurückspielen der Daten ist  genau das gleiche!

Das stimmt so nicht.

>   SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' 
> for key 'PRIMARY'
vs.
>> SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 
>> '1325633' for key 'PRIMARY'

Er hängt sich an anderer Stelle auf.

Mal ganz blöd gefragt: ändert sich der Key wenn du dbcopy einfach
nochmal anstößt?


mfg Daniel

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

2020-11-21 Diskussionsfäden Frank Richter

Hallo Michael,

was heißt den "weitgehend leer"? Hast du den Restore-Versuch gemacht, bevor
du vzlogger neue Daten in die DB schreiben lässt?

Viele Grüße
Frank

Michael Hartmann  schrieb am Sa., 21. Nov. 2020,
16:27:

> Ich habe nun das Testsystem mit dem Image das im Wiki zum DL bereitsteht
> komplett neu aufgebaut. Update vzlogger, middleware/frontend, alle
> Konfigurationen ...
>
> Auf diesem System sollte sich eine weitgehend leere Datenbank befinden.
> Und das Ergebnis beim zurückspielen der Daten ist  genau das gleiche!
>
> --
> pi@SmartMeter:/usr/local/bin $ /var/www/volkszaehler.org/vendor/bin/dbcopy
> copy -c /etc/dbcopy_restore.yaml
> Dropping FK FK_87C331C781257D5D on properties
> Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator
> Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator
> Dropping FK FK_ADF3F36372F5A1AA on data
> Dropping FK FK_B77949FF72F5A1AA on aggregate
> 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 6.0 MiB
>
> data: copying 7819821 rows (partial copy)
>  [>---]   0%  < 1 sec/< 1 sec0 rows
> In AbstractMySQLDriver.php line 74:
>
>   An exception occurred while executing 'INSERT INTO `data`
> (`id`,`channel_id`,`timestamp`,`value`) VALUES
>   (?,?,?,?)' with params ["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] [--]
> [...]
> ---------
>
> Und nun :-/
>
> Grüße
>
> Micha
>
> -Ursprüngliche Nachricht-
> Von: volkszaehler-users [mailto:
> volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas
> Höpfner
> Gesendet: Freitag, 20. November 2020 19:31
> An: volkszaehler.org - users
> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
>
> Hallo Micha,
>
> > Am 20.11.2020 um 17:45 schrieb Michael Hartmann :
> >
> > Copy statt pk für die Daten in dbcopy.yaml hatte ich auf Daniels
> Anregung vor ein paar Tagen bereits probiert und das Ergebnis hier
> berichtet: gleicher Fehler!
>
> auch beim backup?
>
> Irgendwie glaube ich an einen Fehler in deiner aktiven DB.
> Werden fehler angezeigt wenn du auf der console
>   :~# mysqlcheck -p --check volkszaehler
> ausführst?
>
> Im Moment habe ich kein System um mein Backup zu testen, aber dein Weg
> sollte funktionieren.
>
> Thomas
>
>
>
>

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

Ich habe nun das Testsystem mit dem Image das im Wiki zum DL bereitsteht 
komplett neu aufgebaut. Update vzlogger, middleware/frontend, alle 
Konfigurationen ...

Auf diesem System sollte sich eine weitgehend leere Datenbank befinden. Und das 
Ergebnis beim zurückspielen der Daten ist  genau das gleiche!

--
pi@SmartMeter:/usr/local/bin $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy 
-c /etc/dbcopy_restore.yaml
Dropping FK FK_87C331C781257D5D on properties
Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator
Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator
Dropping FK FK_ADF3F36372F5A1AA on data
Dropping FK FK_B77949FF72F5A1AA on aggregate
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 6.0 MiB

data: copying 7819821 rows (partial copy)
 [>---]   0%  < 1 sec/< 1 sec0 rows
In AbstractMySQLDriver.php line 74:

  An exception occurred while executing 'INSERT INTO `data` 
(`id`,`channel_id`,`timestamp`,`value`) VALUES
  (?,?,?,?)' with params ["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] [--] 
[...]
-

Und nun :-/

Grüße

Micha

-Ursprüngliche Nachricht-
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Freitag, 20. November 2020 19:31
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo Micha,

> Am 20.11.2020 um 17:45 schrieb Michael Hartmann :
> 
> Copy statt pk für die Daten in dbcopy.yaml hatte ich auf Daniels Anregung vor 
> ein paar Tagen bereits probiert und das Ergebnis hier berichtet: gleicher 
> Fehler!

auch beim backup?

Irgendwie glaube ich an einen Fehler in deiner aktiven DB. 
Werden fehler angezeigt wenn du auf der console
  :~# mysqlcheck -p --check volkszaehler 
ausführst?

Im Moment habe ich kein System um mein Backup zu testen, aber dein Weg sollte 
funktionieren. 

Thomas

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

Hallo Thomas,

auch beim Backup :-).

Mit der DB auf dem Produktivsystem scheint alles i.O.

pi@SmartMeter:~ $ sudo mysqlcheck -p --check volkszaehler
Enter password:
volkszaehler.aggregate OK
volkszaehler.data  OK
volkszaehler.entities  OK
volkszaehler.entities_in_aggregatorOK
volkszaehler.propertiesOK


Grüße

Micha


-Ursprüngliche Nachricht-
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Freitag, 20. November 2020 19:31
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo Micha,

> Am 20.11.2020 um 17:45 schrieb Michael Hartmann :
> 
> Copy statt pk für die Daten in dbcopy.yaml hatte ich auf Daniels Anregung vor 
> ein paar Tagen bereits probiert und das Ergebnis hier berichtet: gleicher 
> Fehler!

auch beim backup?

Irgendwie glaube ich an einen Fehler in deiner aktiven DB. 
Werden fehler angezeigt wenn du auf der console
  :~# mysqlcheck -p --check volkszaehler 
ausführst?

Im Moment habe ich kein System um mein Backup zu testen, aber dein Weg sollte 
funktionieren. 

Thomas

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

2020-11-20 Diskussionsfäden Friedrich Kessler

Hallo,

Ich muss mich mal outen. Ich habe 3 Vz mit Erweiterungsplatinen (16 S0
Zähler) seit 2014 (wheezy und keine Updates) am Laufen. (Raspis mit SSDs).
Von diesen frage ich auf DB Ebene
die Daten der letzten 3 Tage (im 15 min Takt ab) ab und füge diese auf einem
weiteren gleichen „alten“ Raspi mit SSD ein. So habe ich in einer DB alle
Daten der 3 Raspis.
Von hier hole ich mitr alle Daten für Auswertungen. Von hier werden
ebenfalls per DB Scripts die Daten der letzten 3 Tage abgefragt und in einen
CubieTruck (hatte ich über) importiert. Alles ganz simpel mittels
Shellscripten und Cron Jobs. So habe ich bis heute 11.370.555  Datensätze in
der Data Tabelle. Die DB ist damit gut gesichert, ich brauche keine
Downtimes für die Sicherung und da die Raspis nur noch von der SD-Card
booten habe ich auch keine sooo grosse Angst vor einem Karten Crash.
Gebe zu, ist keine super professionelle Lösung -> läuft aber seit 2014
stabil. Bis dato hatte ich lediglich 3 x Downtimes. 2 x Stromausfall und
einmal Ausfall eines Switches welchen
Ich nicht sofort erkannt hatte.
Gruss
Fritz


Von:  volkszaehler-users 
on behalf of Michael Hartmann 
Antworten an:  "volkszaehler.org - users"

Datum:  Mittwoch, 18. November 2020 um 20:49
An:  "volkszaehler.org - users" 
Betreff:  Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo Fritz,

da ich in dbcopy.yaml pk konfiguriert habe sollten doch nur fehlende Daten
ergänzt werden. Das funktionert in der anderen Richtung beim täglichen
Backup via cronjob doch auch.

Grüße

Micha

Am 18. November 2020 19:27:04 MEZ schrieb Friedrich Kessler :
> Hallo,
> In der Fehlermeldung steht ja genau drin weshalb die Daten nicht importiert
> werden – die Daten sind bereits in der DB mit dem gleichen Primare Key.
> Import in eine leere DB sollte m.E problemlos funktionieren.
> Gruss
> Fritz
> 
> Von:  volkszaehler-users  on
> behalf of Michael Hartmann 
> Antworten an:  "volkszaehler.org - users"
> 
> Datum:  Dienstag, 17. November 2020 um 09:57
> An:  
> Betreff:  Re: [vz-users] Image mit dd erstellen / Datenbackup
> 
> Hallo,
>  
> ich habe gestern ein zweiten Versuch mit einem "frischen" DD-Image auf dem
> "Zweitsystem" gemacht. Das Resultat ist identisch. Beim Ergänzen der Daten aus
> dem DB-Backup bekomme ich den gleichen Fehler mit abweichenden Daten (s.
> Textfile im Anhang).
>  
> Nun interessiert mich nach wie vor, woran DBCOPY sich da stört. Denn ich habe
> die Befürchtung, dass sich die Daten auch in eine neue Installation mit leerer
> DB nicht zurückspielen lassen. Das hätte ich gerne geklärt, bevor ich mir die
> Mühe mache auf dem Zweitsystem eine identische Installation aufzubauen um von
> dieser dann ein Image anzufertigen.
>  
> Grüße
>  
> Micha
>  
> Gesendet: Montag, 16. November 2020 um 22:17 Uhr
> Von: "Daniel Lauckner" 
> An: "volkszaehler.org - users" 
> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
> Hallo,
> 
> 
> am Montag, 16. November 2020 um 16:45 hat John Doe geschrieben:
>> > Entweder Du
>> > spielst das Karten-Image zurück und hast für die Dauer
>> > Crash-Beginn+Rücksicherung keine Daten (zeitliche Größenordnung
>> > alles zusammen bis zum Wiederlaufen ca. eine Stunde) oder Du
>> > installierst ein neues VZ-Image und spielst darin die DB und die
>> vzlogger.conf zurück.
> 
> Oder man macht sich ein Image nachdem man mit der Konfiguration fertig
> ist und spielt da die DB-Sicherung wieder ein.
> Man hat 1x die 10 Minuten Ausfall, bekommt das System aber schneller
> wieder ans laufen weil die persönliche Konfiguration schon vorhanden ist.
> 
> 
> mfg Daniel
>  

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

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

Hallo Micha,

> Am 20.11.2020 um 17:45 schrieb Michael Hartmann :
> 
> Copy statt pk für die Daten in dbcopy.yaml hatte ich auf Daniels Anregung vor 
> ein paar Tagen bereits probiert und das Ergebnis hier berichtet: gleicher 
> Fehler!

auch beim backup?

Irgendwie glaube ich an einen Fehler in deiner aktiven DB. 
Werden fehler angezeigt wenn du auf der console
  :~# mysqlcheck -p --check volkszaehler 
ausführst?

Im Moment habe ich kein System um mein Backup zu testen, aber dein Weg sollte 
funktionieren. 

Thomas 




smime.p7s
Description: S/MIME cryptographic signature

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

2020-11-20 Diskussionsfäden Michael Hartmann

Hallo Thomas,

Copy statt pk für die Daten in dbcopy.yaml hatte ich auf Daniels Anregung vor 
ein paar Tagen bereits probiert und das Ergebnis hier berichtet: gleicher 
Fehler!

Grüße Micha

Am 20. November 2020 17:26:08 MEZ schrieb "Thomas Höpfner" :
>Hallo Micha,
>
>habe gerade alles noch einmal gelesen. Du hast den vorgeschlagen Test
>ja schon gemacht. 
>Du hast ja „pk“ in der config stehen. Das es im Backup keinen fehler
>gibt heist nicht das es beim restore funktioniert. Teste doch einmal
>„copy“.  Zuerst im restore, wenn noch immer dieser Fehler auch beim
>copy.
>
>Thomas 
>
>Mail: tho...@thhoe.de
>
>
>> Am 20.11.2020 um 16:44 schrieb Thomas Höpfner :
>> 
>> Hallo Michael,
>> 
>> du hast ja dein Testsystem.  Versuch doch bitte auf ein älteres image
>ein aktuelles Backup einzuspielen. Teste bitte welche Daten am Ende im
>Frondend zu sehen sind.
>> 
>> Thomas 
>> 
>> Mail: tho...@thhoe.de
>> 
>> 
 Am 20.11.2020 um 13:35 schrieb Michael Hartmann
>:
 
>>> 
>>> Das würde mir ja bereits weiterhelfen, könnte ich die bestehende DB
>auf dem Image leeren und aus dem Backup neu füllen.
>>>  
>>> Dann könnte ich auch das Zurückspielen von Daten aus meinem Backup
>testen.
>>>  
>>> Die Alternative wäre auf einem Zweisystem das Ganze komplett neu
>aufzubauen oder eben das Produktivsystem für die Dauer des Images
>offline zu schicken.
>>>  
>>> Grüße
>>>  
>>> Micha
>>> Thomas Höpfner  schrieb am Do. 19. Nov. 2020 um
>17:36:
  
 Aber egal wie man seine Daten sichert, das Restore muss geübt
>werden. Eventuell ein kleines Script zur Unterstützung erstellen?   
>>> 
>>> Das Script müsste die alte DB im Image löschen und aus den Backup
>neu zu erstellen. Die Abhängigkeiten (middleware stoppen,...) müsste
>das Script auch erfüllen.

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

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

Hallo Micha,

habe gerade alles noch einmal gelesen. Du hast den vorgeschlagen Test ja schon 
gemacht. 
Du hast ja „pk“ in der config stehen. Das es im Backup keinen fehler gibt heist 
nicht das es beim restore funktioniert. Teste doch einmal „copy“.  Zuerst im 
restore, wenn noch immer dieser Fehler auch beim copy.

Thomas 

Mail: tho...@thhoe.de


> Am 20.11.2020 um 16:44 schrieb Thomas Höpfner :
> 
> Hallo Michael,
> 
> du hast ja dein Testsystem.  Versuch doch bitte auf ein älteres image ein 
> aktuelles Backup einzuspielen. Teste bitte welche Daten am Ende im Frondend 
> zu sehen sind.
> 
> Thomas 
> 
> Mail: tho...@thhoe.de
> 
> 
>>> Am 20.11.2020 um 13:35 schrieb Michael Hartmann :
>>> 
>> 
>> Das würde mir ja bereits weiterhelfen, könnte ich die bestehende DB auf dem 
>> Image leeren und aus dem Backup neu füllen.
>>  
>> Dann könnte ich auch das Zurückspielen von Daten aus meinem Backup testen.
>>  
>> Die Alternative wäre auf einem Zweisystem das Ganze komplett neu aufzubauen 
>> oder eben das Produktivsystem für die Dauer des Images offline zu schicken.
>>  
>> Grüße
>>  
>> Micha
>> Thomas Höpfner  schrieb am Do. 19. Nov. 2020 um 17:36:
>>>  
>>> Aber egal wie man seine Daten sichert, das Restore muss geübt werden. 
>>> Eventuell ein kleines Script zur Unterstützung erstellen?   
>> 
>> Das Script müsste die alte DB im Image löschen und aus den Backup neu zu 
>> erstellen. Die Abhängigkeiten (middleware stoppen,...) müsste das Script 
>> auch erfüllen.


smime.p7s
Description: S/MIME cryptographic signature

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

Hallo Michael,

du hast ja dein Testsystem.  Versuch doch bitte auf ein älteres image ein 
aktuelles Backup einzuspielen. Teste bitte welche Daten am Ende im Frondend zu 
sehen sind.

Thomas 

Mail: tho...@thhoe.de


> Am 20.11.2020 um 13:35 schrieb Michael Hartmann :
> 
> 
> Das würde mir ja bereits weiterhelfen, könnte ich die bestehende DB auf dem 
> Image leeren und aus dem Backup neu füllen.
>  
> Dann könnte ich auch das Zurückspielen von Daten aus meinem Backup testen.
>  
> Die Alternative wäre auf einem Zweisystem das Ganze komplett neu aufzubauen 
> oder eben das Produktivsystem für die Dauer des Images offline zu schicken.
>  
> Grüße
>  
> Micha
> Thomas Höpfner  schrieb am Do. 19. Nov. 2020 um 17:36:
>>  
>> Aber egal wie man seine Daten sichert, das Restore muss geübt werden. 
>> Eventuell ein kleines Script zur Unterstützung erstellen?   
> 
> Das Script müsste die alte DB im Image löschen und aus den Backup neu zu 
> erstellen. Die Abhängigkeiten (middleware stoppen,...) müsste das Script auch 
> erfüllen.


smime.p7s
Description: S/MIME cryptographic signature

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

2020-11-20 Diskussionsfäden Michael Hartmann

Das würde mir ja bereits weiterhelfen, könnte ich die bestehende DB auf dem Image leeren und aus dem Backup neu füllen.

 

Dann könnte ich auch das Zurückspielen von Daten aus meinem Backup testen.

 

Die Alternative wäre auf einem Zweisystem das Ganze komplett neu aufzubauen oder eben das Produktivsystem für die Dauer des Images offline zu schicken.

 

Grüße

 

Micha


Thomas Höpfner  schrieb am Do. 19. Nov. 2020 um 17:36:













 

Aber egal wie man seine Daten sichert, das Restore muss geübt werden. Eventuell ein kleines Script zur Unterstützung erstellen?   













Das Script müsste die alte DB im Image löschen und aus den Backup neu zu erstellen. Die Abhängigkeiten (middleware stoppen,...) müsste das Script auch erfüllen.

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

Hallo Micha,





-Ursprüngliche Nachricht-
Von: Michael Hartmann 
Gesendet: Freitag 20 November 2020 10:28
An: volkszaehler-users@demo.volkszaehler.org
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Ich muss eingestehen, dass ich abgehängt bin. Ich hatte nach einer für Laien 
umsetzbaren Möglichkeit gesucht, ein Image des Systems zu erstellen, das sich 
mit Daten aus dem Backup ergänzen lässt. Möglichst ohne den VZ dazu längere 
Zeit offline zu stellen.
Ein komplettes image ist schon am schnellsten wiederherzustellen. Beim pi ist 
es auch perfect geeignet eine kaputt SD-Karte zu ersetzen. Das Problem ist die 
DB, hier funktiert dd nicht immer sicher weil während dd noch arbeidet schon 
gesicherte Teile des Dateisystems geändert werden können. Bei logfiles ist das 
uninderesant aber nicht bei einer DB. Bei einen Snapshoot wird das Dateisystem 
eingefroren, alle darauf folgende Zugriffe verändern diesen Snapshot nicht. 

Mir ist auch immer noch nicht klar, warum die DB auf dem Image sich nicht mit 
Daten aus meinem Backup ergänzen/überschreiben lässt.
So weit ich weiß funktioniert das mit keiner Datenbank. Ich sehe 2 Gründe:

1. Die DB im Image ist eventuell kaputt.

2. In der DB werden Indixis geführt, das führt zu kollisionen Zwischen der 
aktuellen DB und den Backup.



Thomas Höpfner  schrieb am Do. 19. Nov. 2020 um 17:36:

Aber egal wie man seine Daten sichert, das Restore muss geübt werden. Eventuell 
ein kleines Script zur Unterstützung erstellen?   
Das Script müsste die alte DB im Image löschen und aus den Backup neu zu 
erstellen. Die Abhängigkeiten (middleware stoppen,...) müsste das Script auch 
erfüllen.





Mit freundlichen Grüßen,

Thomas

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

2020-11-20 Diskussionsfäden Michael Hartmann

Ich muss eingestehen, dass ich abgehängt bin. Ich hatte nach einer für Laien umsetzbaren Möglichkeit gesucht, ein Image des Systems zu erstellen, das sich mit Daten aus dem Backup ergänzen lässt. Möglichst ohne den VZ dazu längere Zeit offline zu stellen.

Mir ist auch immer noch nicht klar, warum die DB auf dem Image sich nicht mit Daten aus meinem Backup ergänzen/überschreiben lässt.

Grüße

Micha

Gesendet: Freitag, 20. November 2020 um 09:23 Uhr
Von: "Thomas Höpfner"
An: "volkszaehler.org - users"
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo,

wieder was gelernt. Daraus lässt sich bestimmt eine Strategie für Backup/Restore entwickeln.

Mit freundlichen Grüßen,

Thomas

-Ursprüngliche Nachricht-
Von: Stefan Walsen
Gesendet: Freitag 20 November 2020 09:11
An: volkszaehler.org - users
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup
Hallo zusammen,

mit LVM kann man auch Snapshots erstellen, und das soll auch auf dem RasPi funktionieren:

https://raspberrypi.stackexchange.com/questions/7159/can-the-raspberry-boot-to-an-lvm-root-partition

Grüße

Stefan

Thomas Höpfner <tho...@thhoe.de> schrieb am Do. 19. Nov. 2020 um 17:36:

Hallo,

ein „image“ vom Dateisystem kann man meiner Meinung nach nicht sicher erstellen. VSS wird meines Wissens auch nur für einzelne Dateien verwendet. Die Zuordnung läuft beim Restore.

Der Gedanke mit den Snapshout könnte vielleicht mit ZFS als Dateisystem funktionieren. Ein Ansatz hierzu: https://www.heise.de/ratgeber/Raspberry-Pi-4-Minimalistisches-NAS-mit-ZFS-Dateiverwaltung-selbst-bauen-4927272.html

Aber egal wie man seine Daten sichert, das Restore muss geübt werden. Eventuell ein kleines Script zur Unterstützung erstellen?
Thomas

Am 19.11.2020 um 07:49 schrieb Christian Eidenmüller <kohl...@gmx.net>:

Ein guter artikel (denke ich zumindest):
https://www.faq-o-matic.net/2009/03/20/warum-muss-eine-datenbank-zum-backup-konsistent-sein/

Gruß
Christian

Gesendet: Mittwoch, 18. November 2020 um 20:49 Uhr
Von: "Michael Hartmann" <hartmann-mi...@web.de>
An: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org>
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo Fritz,

da ich in dbcopy.yaml pk konfiguriert habe sollten doch nur fehlende Daten ergänzt werden. Das funktionert in der anderen Richtung beim täglichen Backup via cronjob doch auch.

Grüße

Micha
Am 18. November 2020 19:27:04 MEZ schrieb Friedrich Kessler <v...@riare.de>:

Hallo,

In der Fehlermeldung steht ja genau drin weshalb die Daten nicht importiert werden – die Daten sind bereits in der DB mit dem gleichen Primare Key.

Import in eine leere DB sollte m.E problemlos funktionieren.

Gruss

Fritz

Von: volkszaehler-users <volkszaehler-users-boun...@demo.volkszaehler.org> on behalf of Michael Hartmann <hartmann-mi...@web.de>
Antworten an: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org>
Datum: Dienstag, 17. November 2020 um 09:57
An: <volkszaehler-users@demo.volkszaehler.org>
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo,

ich habe gestern ein zweiten Versuch mit einem "frischen" DD-Image auf dem "Zweitsystem" gemacht. Das Resultat ist identisch. Beim Ergänzen der Daten aus dem DB-Backup bekomme ich den gleichen Fehler mit abweichenden Daten (s. Textfile im Anhang).

Nun interessiert mich nach wie vor, woran DBCOPY sich da stört. Denn ich habe die Befürchtung, dass sich die Daten auch in eine neue Installation mit leerer DB nicht zurückspielen lassen. Das hätte ich gerne geklärt, bevor ich mir die Mühe mache auf dem Zweitsystem eine identische Installation aufzubauen um von dieser dann ein Image anzufertigen.

Grüße

Micha

Gesendet: Montag, 16. November 2020 um 22:17 Uhr
Von: "Daniel Lauckner" <v...@jahp.de>
An: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org>
Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup

Hallo,

am Montag, 16. November 2020 um 16:45 hat John Doe geschrieben:
> Entweder Du
> spielst das Karten-Image zurück und hast für die Dauer
> Crash-Beginn+Rücksicherung keine Daten (zeitliche Größenordnung
> alles zusammen bis zum Wiederlaufen ca. eine Stunde) oder Du
> installierst ein neues VZ-Image und spielst darin die DB und die vzlogger.conf zurück.

Oder man macht sich ein Image nachdem man mit der Konfiguration fertig
ist und spielt da die DB-Sicherung wieder ein.
Man hat 1x die 10 Minuten Ausfall, bekommt das S

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