subject:"\[vz\-users\] DB Backup auf NAS via sqlite"

Ich starte dbcopy über den Aufruf, wie er im Wiki beschrieben ist: 
/var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
/etc/dbcopy_sqlite_restore.yaml

 

That’s all! Mehr mache ich nicht!

 

Ihr setzt leider zu viele Vorkenntnisse voraus.

 

Grüße

 

Micha

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
Andreas Goetz
Gesendet: Mittwoch, 30. Dezember 2020 19:55
An: volkszaehler.org - users
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

 

Von draussen kann niemand sagen was Du da treibst:

 

*   dbcopy abstellen, count(data) über Zeit anschauen -> ändert sich was? 
dann ists nicht dbcopy
*   dbcopy anschauen: wie startest du das? -> laufen da mehrere parallel? 
dann kommen sie sich ins Gehege

 

usw. Immer eine Fehlerquelle nach der anderen ausschließen.

 

Viele Grüße, Andreas

 





On 30. Dec 2020, at 19:32, Michael Hartmann  wrote:

 

Wie kann ich die offenen DB Verbindungen ermitteln?

Da das Testsystem keine Sensorik hat, empfängt VZlogger auch keine Messwerte. 
Ergo sollten auch keine weiteren zugriffe aufvdie DV erfolgen oder?

Am 30. Dezember 2020 19:14:54 MEZ schrieb Andreas Goetz :

Die Frage stellt sich nicht da die Datensätze vollständig mit ID eingefügt 
werden. Genau deshalb triffst Du ja anscheinend auf die Duplikate.

 

Mach Dir doch mal den Spass und schau wieviele offene DB Connections es gibt 
wenn der Fehler mal wieder auftritt (falls sqlite sowas anzeigen- da in ich 
nicht sicher bei dem Dateimechnismus). 

 

Viele Grüße, Andreas

 





On 30. Dec 2020, at 19:12, Thomas Höpfner  wrote:

 

Hallo Andreas,


Am 30.12.2020 um 18:33 schrieb Andreas Goetz < <mailto:cpui...@gmail.com> 
cpui...@gmail.com>:



Bisher hatte niemand ähnliche Probleme wie Du. Da sich dbcopy immer den 
„höchsten“ Datensatz aus dem Index sucht würde ich ausschliessen dass dabei 
doppelt geschrieben werden kann. Es sei denn, dbcopy wäre nicht das einzige 
Programm dass in die DB schreibt...

 

Viele Grüße, Andreas 

 

Was passiert wenn man Daten löscht und mit

 

TRUNCATE TABLE data
 
danach aufräumt? Dabei könnte doch der nächste AUTOINCREMENT kleiner sein wie 
der höchste vergebene. 
 
Thomas 

 


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

Re: [vz-users] DB Backup auf NAS via sqlite

Von draussen kann niemand sagen was Du da treibst:

dbcopy abstellen, count(data) über Zeit anschauen -> ändert sich was? dann ists 
nicht dbcopy
dbcopy anschauen: wie startest du das? -> laufen da mehrere parallel? dann 
kommen sie sich ins Gehege

usw. Immer eine Fehlerquelle nach der anderen ausschließen.

Viele Grüße, Andreas


> On 30. Dec 2020, at 19:32, Michael Hartmann  wrote:
> 
> Wie kann ich die offenen DB Verbindungen ermitteln?
> 
> Da das Testsystem keine Sensorik hat, empfängt VZlogger auch keine Messwerte. 
> Ergo sollten auch keine weiteren zugriffe aufvdie DV erfolgen oder?
> 
> Am 30. Dezember 2020 19:14:54 MEZ schrieb Andreas Goetz :
> Die Frage stellt sich nicht da die Datensätze vollständig mit ID eingefügt 
> werden. Genau deshalb triffst Du ja anscheinend auf die Duplikate.
> 
> Mach Dir doch mal den Spass und schau wieviele offene DB Connections es gibt 
> wenn der Fehler mal wieder auftritt (falls sqlite sowas anzeigen- da in ich 
> nicht sicher bei dem Dateimechnismus). 
> 
> Viele Grüße, Andreas
> 
> 
>> On 30. Dec 2020, at 19:12, Thomas Höpfner > > wrote:
>> 
>> Hallo Andreas,
>> 
>>> 
>>> Am 30.12.2020 um 18:33 schrieb Andreas Goetz >> >:
>>> 
>>> 
>>> Bisher hatte niemand ähnliche Probleme wie Du. Da sich dbcopy immer den 
>>> „höchsten“ Datensatz aus dem Index sucht würde ich ausschliessen dass dabei 
>>> doppelt geschrieben werden kann. Es sei denn, dbcopy wäre nicht das einzige 
>>> Programm dass in die DB schreibt...
>>> 
>>> Viele Grüße, Andreas 
>> 
>> Was passiert wenn man Daten löscht und mit
>> 
>> TRUNCATE TABLE data
>> 
>> danach aufräumt? Dabei könnte doch der nächste AUTOINCREMENT kleiner sein 
>> wie der höchste vergebene. 
>> 
>> Thomas 
> 
> 
> -- 
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: [vz-users] DB Backup auf NAS via sqlite

Wie kann ich die offenen DB Verbindungen ermitteln?

Da das Testsystem keine Sensorik hat, empfängt VZlogger auch keine Messwerte. 
Ergo sollten auch keine weiteren zugriffe aufvdie DV erfolgen oder?

Am 30. Dezember 2020 19:14:54 MEZ schrieb Andreas Goetz :
>Die Frage stellt sich nicht da die Datensätze vollständig mit ID
>eingefügt werden. Genau deshalb triffst Du ja anscheinend auf die
>Duplikate.
>
>Mach Dir doch mal den Spass und schau wieviele offene DB Connections es
>gibt wenn der Fehler mal wieder auftritt (falls sqlite sowas anzeigen-
>da in ich nicht sicher bei dem Dateimechnismus). 
>
>Viele Grüße, Andreas
>
>
>> On 30. Dec 2020, at 19:12, Thomas Höpfner  wrote:
>> 
>> Hallo Andreas,
>> 
>>> 
>>> Am 30.12.2020 um 18:33 schrieb Andreas Goetz >:
>>> 
>>> 
>>> Bisher hatte niemand ähnliche Probleme wie Du. Da sich dbcopy immer
>den „höchsten“ Datensatz aus dem Index sucht würde ich ausschliessen
>dass dabei doppelt geschrieben werden kann. Es sei denn, dbcopy wäre
>nicht das einzige Programm dass in die DB schreibt...
>>> 
>>> Viele Grüße, Andreas 
>> 
>> Was passiert wenn man Daten löscht und mit
>> 
>> TRUNCATE TABLE data
>> 
>> danach aufräumt? Dabei könnte doch der nächste AUTOINCREMENT kleiner
>sein wie der höchste vergebene. 
>> 
>> Thomas 

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

Re: [vz-users] DB Backup auf NAS via sqlite

Hallo Andreas,

ich habe das Problem nicht, möchte es aber verstehen.

> Am 30.12.2020 um 19:17 schrieb Andreas Goetz :
> 
> Die Frage stellt sich nicht da die Datensätze vollständig mit ID eingefügt 
> werden. Genau deshalb triffst Du ja anscheinend auf die Duplikate.

Ok, währe scheinbar zu einfach als Erklärung. 

Mit freundlichen Grüßen 

thomas


> Mach Dir doch mal den Spass und schau wieviele offene DB Connections es gibt 
> wenn der Fehler mal wieder auftritt (falls sqlite sowas anzeigen- da in ich 
> nicht sicher bei dem Dateimechnismus). 
> 
> Viele Grüße, Andreas
> 
> 
>> On 30. Dec 2020, at 19:12, Thomas Höpfner  wrote:
>> 
>> Hallo Andreas,
>> 
>>> 
 Am 30.12.2020 um 18:33 schrieb Andreas Goetz :
 
>>> 
>>> Bisher hatte niemand ähnliche Probleme wie Du. Da sich dbcopy immer den 
>>> „höchsten“ Datensatz aus dem Index sucht würde ich ausschliessen dass dabei 
>>> doppelt geschrieben werden kann. Es sei denn, dbcopy wäre nicht das einzige 
>>> Programm dass in die DB schreibt...
>>> 
>>> Viele Grüße, Andreas 
>> 
>> Was passiert wenn man Daten löscht und mit
>> 
>> TRUNCATE TABLE data
>> 
>> danach aufräumt? Dabei könnte doch der nächste AUTOINCREMENT kleiner sein 
>> wie der höchste vergebene. 
>> 
>> Thomas 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: [vz-users] DB Backup auf NAS via sqlite

Stosse ich dbcopy erneut an, steigt es mit dem nächsten duplicate aus und so 
weiter und so fort.

Am 30. Dezember 2020 19:03:06 MEZ schrieb Daniel Lauckner :
>Hallo,
>
>
>am Mittwoch, 30. Dezember 2020 um 18:31 hat Andreas Goetz geschrieben:
>> Bisher hatte niemand ähnliche Probleme wie Du.
>
>Doch, die Meldung hatte ich auch schon.
>Hab sie immer ignoriert und dbcopy nochmal angestoßen. 
>
>
>mfg Daniel

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

Re: [vz-users] DB Backup auf NAS via sqlite

Die Frage stellt sich nicht da die Datensätze vollständig mit ID eingefügt 
werden. Genau deshalb triffst Du ja anscheinend auf die Duplikate.

Mach Dir doch mal den Spass und schau wieviele offene DB Connections es gibt 
wenn der Fehler mal wieder auftritt (falls sqlite sowas anzeigen- da in ich 
nicht sicher bei dem Dateimechnismus). 

Viele Grüße, Andreas

> On 30. Dec 2020, at 19:12, Thomas Höpfner  wrote:
> 
> Hallo Andreas,
> 
>> 
>> Am 30.12.2020 um 18:33 schrieb Andreas Goetz > >:
>> 
>> 
>> Bisher hatte niemand ähnliche Probleme wie Du. Da sich dbcopy immer den 
>> „höchsten“ Datensatz aus dem Index sucht würde ich ausschliessen dass dabei 
>> doppelt geschrieben werden kann. Es sei denn, dbcopy wäre nicht das einzige 
>> Programm dass in die DB schreibt...
>> 
>> Viele Grüße, Andreas 
> 
> Was passiert wenn man Daten löscht und mit
> 
> TRUNCATE TABLE data
> 
> danach aufräumt? Dabei könnte doch der nächste AUTOINCREMENT kleiner sein wie 
> der höchste vergebene. 
> 
> Thomas

Re: [vz-users] DB Backup auf NAS via sqlite

Hallo Andreas,

> 
> Am 30.12.2020 um 18:33 schrieb Andreas Goetz :
> 
> Bisher hatte niemand ähnliche Probleme wie Du. Da sich dbcopy immer den 
> „höchsten“ Datensatz aus dem Index sucht würde ich ausschliessen dass dabei 
> doppelt geschrieben werden kann. Es sei denn, dbcopy wäre nicht das einzige 
> Programm dass in die DB schreibt...
> 
> Viele Grüße, Andreas 

Was passiert wenn man Daten löscht und mit

TRUNCATE TABLE data

danach aufräumt? Dabei könnte doch der nächste AUTOINCREMENT kleiner sein wie 
der höchste vergebene. 

Thomas 



smime.p7s
Description: S/MIME cryptographic signature

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-30 Diskussionsfäden Daniel Lauckner

Hallo,


am Mittwoch, 30. Dezember 2020 um 18:31 hat Andreas Goetz geschrieben:
> Bisher hatte niemand ähnliche Probleme wie Du.

Doch, die Meldung hatte ich auch schon.
Hab sie immer ignoriert und dbcopy nochmal angestoßen. 


mfg Daniel

Re: [vz-users] DB Backup auf NAS via sqlite

Hallo Andreas,


> Am 30.12.2020 um 18:45 schrieb Andreas Goetz :
> 
> 
> Das muss sie auch, da auf id ein Unique Index ist.

Ich weiß, aber Micha hat das Problem das genau diese scheinbar doppelt vorkommt.

Mit freundlichen Grüßen 

Thomas 


> 
>>> Am 30.12.2020 um 18:36 schrieb Thomas Höpfner :
>>> 
>> Hallo Micha,
>> 
>> eine passende Select Anweisung:
>> 
>> SELECT id, COUNT(id) AS cnt
>> FROM data
>> GROUP BY id
>> HAVING cnt > 1
>> 
>> Zeigt bei mir NULL an.
>> 
>> Thomas 
>> 
>> 
>> 
>>>> Am 30.12.2020 um 18:29 schrieb Michael Hartmann :
>>>> 
>>> Hallo Andreas,
>>> 
>>> Da bin ich nicht ganz sicher ob dbcopy nicht versucht Daten doppelt zu 
>>> schreiben...
>>> 
>>> Ich will mal versuchen, ob es mir mit meine begrenzten DB-Kenntnissen 
>>> gelingt die vermeintlichen Doubletten in der DB des Produktivsystems 
>>> aufzuspüren.
>>> 
>>> Grüße Micha
>>> 
>>> Am 29. Dezember 2020 09:06:21 MEZ schrieb Andreas Goetz :
>>>> 
>>>> Vielleicht solltest Du mal überlegen wo diese Einträge eigentlich her 
>>>> kommen? Von DBCopy werden sie vmtl nicht erzeugt...
>>>> 
>>>> Viele Grüße, Andreas
>>>> 
>>>> 
>>>>>> Am 29.12.2020 um 07:55 schrieb Michael Hartmann :
>>>>>> 
>>>>> 
>>>>> Hallo Thomas,
>>>>>  
>>>>> anbei drei Screenshots von drei unmittelbar aufeinanderfolgenden Aufrufen 
>>>>> mit den Fehlermeldungen bei denen dbcopy aussteigt. Wie man sieht, ist es 
>>>>> jedes Mal ein Datum mit höherer ID an denen sich dbcopy aufhängt.
>>>>>  
>>>>> Grüße
>>>>>  
>>>>> Micha
>>>>>  
>>>>> Von: volkszaehler-users 
>>>>> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
>>>>> Thomas Höpfner
>>>>> Gesendet: Montag, 28. Dezember 2020 22:27
>>>>> An: volkszaehler.org - users
>>>>> Betreff: Re: [vz-users] DB Backup auf NAS via sqlite
>>>>>  
>>>>> Hallo Micha,
>>>>>  
>>>>> ist dein Testsystem noch aktiv?
>>>>> Kannst du einen Screenshot von der Fehlermeldung machen? Am besten 2 kurz 
>>>>> hintereinander. 
>>>>> Eventuell habe ich einen Workaround. 
>>>>> 
>>>>> Thomas 
>>>>>  
>>>>> Am 28.12.2020 um 20:43 schrieb Michael Hartmann :
>>>>> 
>>>>> Hallo Thomas,
>>>>> 
>>>>> Ich habe auch keine Idee mehr. Egal ob aus einer parallelen DB via mysql 
>>>>> oder über sqlite es läuft beim restore immer auf duplicate entries bei 
>>>>> denen dbcopy aussteigt.
>>>>> 
>>>>> Grüße
>>>>> 
>>>>> Micha
>>>>> 
>>>>> P.S.: Um das share egal ob nun via cifs oder nfs eingebunden nach reboot 
>>>>> verfügbar zu haben musste ich autofs installieren. Über einen Eintrag in 
>>>>> fstab lief es nicht. Obwohl der korrekt war.
>>>>> 
>>>>> Am 28. Dezember 2020 17:04:57 MEZ schrieb "Thomas Höpfner" 
>>>>> :
>>>>> Hallo Micha,
>>>>>  
>>>>> warum das bei dir nicht funktioniert ist mir ein Rätsel. Ohne 
>>>>> funktionierendes Backup ist es auch nicht gut, hatte ich aber auch ein 
>>>>> paar Jahre. 
>>>>>  
>>>>> Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten 
>>>>> Backups für den VZ.
>>>>>  
>>>>> Grüße
>>>>>  
>>>>> Micha
>>>>>  
>>>>>  
>>>>> Bei mir funktioniert es zuverlässig. 
>>>>>  
>>>>> Thomas 
>>>>> 
>>>>> -- 
>>>>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>>>>> <2020-12-29 07_51_21-pi@SmartMeterTS_sqlite_restore3.png>
>>>>> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore.png>
>>>>> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore_2.png>
>>> 
>>> -- 
>>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.


smime.p7s
Description: S/MIME cryptographic signature

Re: [vz-users] DB Backup auf NAS via sqlite

Das muss sie auch, da auf id ein Unique Index ist.

> Am 30.12.2020 um 18:36 schrieb Thomas Höpfner :
> 
> Hallo Micha,
> 
> eine passende Select Anweisung:
> 
> SELECT id, COUNT(id) AS cnt
> FROM data
> GROUP BY id
> HAVING cnt > 1
> 
> Zeigt bei mir NULL an.
> 
> Thomas 
> 
> 
> 
>>> Am 30.12.2020 um 18:29 schrieb Michael Hartmann :
>>> 
>> Hallo Andreas,
>> 
>> Da bin ich nicht ganz sicher ob dbcopy nicht versucht Daten doppelt zu 
>> schreiben...
>> 
>> Ich will mal versuchen, ob es mir mit meine begrenzten DB-Kenntnissen 
>> gelingt die vermeintlichen Doubletten in der DB des Produktivsystems 
>> aufzuspüren.
>> 
>> Grüße Micha
>> 
>> Am 29. Dezember 2020 09:06:21 MEZ schrieb Andreas Goetz :
>>> 
>>> Vielleicht solltest Du mal überlegen wo diese Einträge eigentlich her 
>>> kommen? Von DBCopy werden sie vmtl nicht erzeugt...
>>> 
>>> Viele Grüße, Andreas
>>> 
>>> 
>>>>> Am 29.12.2020 um 07:55 schrieb Michael Hartmann :
>>>>> 
>>>> 
>>>> Hallo Thomas,
>>>>  
>>>> anbei drei Screenshots von drei unmittelbar aufeinanderfolgenden Aufrufen 
>>>> mit den Fehlermeldungen bei denen dbcopy aussteigt. Wie man sieht, ist es 
>>>> jedes Mal ein Datum mit höherer ID an denen sich dbcopy aufhängt.
>>>>  
>>>> Grüße
>>>>  
>>>> Micha
>>>>  
>>>> Von: volkszaehler-users 
>>>> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
>>>> Thomas Höpfner
>>>> Gesendet: Montag, 28. Dezember 2020 22:27
>>>> An: volkszaehler.org - users
>>>> Betreff: Re: [vz-users] DB Backup auf NAS via sqlite
>>>>  
>>>> Hallo Micha,
>>>>  
>>>> ist dein Testsystem noch aktiv?
>>>> Kannst du einen Screenshot von der Fehlermeldung machen? Am besten 2 kurz 
>>>> hintereinander. 
>>>> Eventuell habe ich einen Workaround. 
>>>> 
>>>> Thomas 
>>>>  
>>>> Am 28.12.2020 um 20:43 schrieb Michael Hartmann :
>>>> 
>>>> Hallo Thomas,
>>>> 
>>>> Ich habe auch keine Idee mehr. Egal ob aus einer parallelen DB via mysql 
>>>> oder über sqlite es läuft beim restore immer auf duplicate entries bei 
>>>> denen dbcopy aussteigt.
>>>> 
>>>> Grüße
>>>> 
>>>> Micha
>>>> 
>>>> P.S.: Um das share egal ob nun via cifs oder nfs eingebunden nach reboot 
>>>> verfügbar zu haben musste ich autofs installieren. Über einen Eintrag in 
>>>> fstab lief es nicht. Obwohl der korrekt war.
>>>> 
>>>> Am 28. Dezember 2020 17:04:57 MEZ schrieb "Thomas Höpfner" 
>>>> :
>>>> Hallo Micha,
>>>>  
>>>> warum das bei dir nicht funktioniert ist mir ein Rätsel. Ohne 
>>>> funktionierendes Backup ist es auch nicht gut, hatte ich aber auch ein 
>>>> paar Jahre. 
>>>>  
>>>> Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten 
>>>> Backups für den VZ.
>>>>  
>>>> Grüße
>>>>  
>>>> Micha
>>>>  
>>>>  
>>>> Bei mir funktioniert es zuverlässig. 
>>>>  
>>>> Thomas 
>>>> 
>>>> -- 
>>>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>>>> <2020-12-29 07_51_21-pi@SmartMeterTS_sqlite_restore3.png>
>>>> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore.png>
>>>> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore_2.png>
>> 
>> -- 
>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: [vz-users] DB Backup auf NAS via sqlite

Hallo Micha,

eine passende Select Anweisung:

SELECT id, COUNT(id) AS cnt
FROM data
GROUP BY id
HAVING cnt > 1

Zeigt bei mir NULL an.

Thomas 



> Am 30.12.2020 um 18:29 schrieb Michael Hartmann :
> 
> Hallo Andreas,
> 
> Da bin ich nicht ganz sicher ob dbcopy nicht versucht Daten doppelt zu 
> schreiben...
> 
> Ich will mal versuchen, ob es mir mit meine begrenzten DB-Kenntnissen gelingt 
> die vermeintlichen Doubletten in der DB des Produktivsystems aufzuspüren.
> 
> Grüße Micha
> 
> Am 29. Dezember 2020 09:06:21 MEZ schrieb Andreas Goetz :
>> 
>> Vielleicht solltest Du mal überlegen wo diese Einträge eigentlich her 
>> kommen? Von DBCopy werden sie vmtl nicht erzeugt...
>> 
>> Viele Grüße, Andreas
>> 
>> 
>>>> Am 29.12.2020 um 07:55 schrieb Michael Hartmann :
>>>> 
>>> 
>>> Hallo Thomas,
>>>  
>>> anbei drei Screenshots von drei unmittelbar aufeinanderfolgenden Aufrufen 
>>> mit den Fehlermeldungen bei denen dbcopy aussteigt. Wie man sieht, ist es 
>>> jedes Mal ein Datum mit höherer ID an denen sich dbcopy aufhängt.
>>>  
>>> Grüße
>>>  
>>> Micha
>>>  
>>> Von: volkszaehler-users 
>>> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
>>> Thomas Höpfner
>>> Gesendet: Montag, 28. Dezember 2020 22:27
>>> An: volkszaehler.org - users
>>> Betreff: Re: [vz-users] DB Backup auf NAS via sqlite
>>>  
>>> Hallo Micha,
>>>  
>>> ist dein Testsystem noch aktiv?
>>> Kannst du einen Screenshot von der Fehlermeldung machen? Am besten 2 kurz 
>>> hintereinander. 
>>> Eventuell habe ich einen Workaround. 
>>> 
>>> Thomas 
>>>  
>>> Am 28.12.2020 um 20:43 schrieb Michael Hartmann :
>>> 
>>> Hallo Thomas,
>>> 
>>> Ich habe auch keine Idee mehr. Egal ob aus einer parallelen DB via mysql 
>>> oder über sqlite es läuft beim restore immer auf duplicate entries bei 
>>> denen dbcopy aussteigt.
>>> 
>>> Grüße
>>> 
>>> Micha
>>> 
>>> P.S.: Um das share egal ob nun via cifs oder nfs eingebunden nach reboot 
>>> verfügbar zu haben musste ich autofs installieren. Über einen Eintrag in 
>>> fstab lief es nicht. Obwohl der korrekt war.
>>> 
>>> Am 28. Dezember 2020 17:04:57 MEZ schrieb "Thomas Höpfner" 
>>> :
>>> Hallo Micha,
>>>  
>>> warum das bei dir nicht funktioniert ist mir ein Rätsel. Ohne 
>>> funktionierendes Backup ist es auch nicht gut, hatte ich aber auch ein paar 
>>> Jahre. 
>>>  
>>> Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten Backups 
>>> für den VZ.
>>>  
>>> Grüße
>>>  
>>> Micha
>>>  
>>>  
>>> Bei mir funktioniert es zuverlässig. 
>>>  
>>> Thomas 
>>> 
>>> -- 
>>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>>> <2020-12-29 07_51_21-pi@SmartMeterTS_sqlite_restore3.png>
>>> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore.png>
>>> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore_2.png>
> 
> -- 
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.


smime.p7s
Description: S/MIME cryptographic signature

Re: [vz-users] DB Backup auf NAS via sqlite

Bisher hatte niemand ähnliche Probleme wie Du. Da sich dbcopy immer den 
„höchsten“ Datensatz aus dem Index sucht würde ich ausschliessen dass dabei 
doppelt geschrieben werden kann. Es sei denn, dbcopy wäre nicht das einzige 
Programm dass in die DB schreibt...

Viele Grüße, Andreas 

> Am 30.12.2020 um 18:28 schrieb Michael Hartmann :
> 
> Hallo Andreas,
> 
> Da bin ich nicht ganz sicher ob dbcopy nicht versucht Daten doppelt zu 
> schreiben...
> 
> Ich will mal versuchen, ob es mir mit meine begrenzten DB-Kenntnissen gelingt 
> die vermeintlichen Doubletten in der DB des Produktivsystems aufzuspüren.
> 
> Grüße Micha
> 
> Am 29. Dezember 2020 09:06:21 MEZ schrieb Andreas Goetz :
>> 
>> Vielleicht solltest Du mal überlegen wo diese Einträge eigentlich her 
>> kommen? Von DBCopy werden sie vmtl nicht erzeugt...
>> 
>> Viele Grüße, Andreas
>> 
>> 
>>>> Am 29.12.2020 um 07:55 schrieb Michael Hartmann :
>>>> 
>>> 
>>> Hallo Thomas,
>>>  
>>> anbei drei Screenshots von drei unmittelbar aufeinanderfolgenden Aufrufen 
>>> mit den Fehlermeldungen bei denen dbcopy aussteigt. Wie man sieht, ist es 
>>> jedes Mal ein Datum mit höherer ID an denen sich dbcopy aufhängt.
>>>  
>>> Grüße
>>>  
>>> Micha
>>>  
>>> Von: volkszaehler-users 
>>> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
>>> Thomas Höpfner
>>> Gesendet: Montag, 28. Dezember 2020 22:27
>>> An: volkszaehler.org - users
>>> Betreff: Re: [vz-users] DB Backup auf NAS via sqlite
>>>  
>>> Hallo Micha,
>>>  
>>> ist dein Testsystem noch aktiv?
>>> Kannst du einen Screenshot von der Fehlermeldung machen? Am besten 2 kurz 
>>> hintereinander. 
>>> Eventuell habe ich einen Workaround. 
>>> 
>>> Thomas 
>>>  
>>> Am 28.12.2020 um 20:43 schrieb Michael Hartmann :
>>> 
>>> Hallo Thomas,
>>> 
>>> Ich habe auch keine Idee mehr. Egal ob aus einer parallelen DB via mysql 
>>> oder über sqlite es läuft beim restore immer auf duplicate entries bei 
>>> denen dbcopy aussteigt.
>>> 
>>> Grüße
>>> 
>>> Micha
>>> 
>>> P.S.: Um das share egal ob nun via cifs oder nfs eingebunden nach reboot 
>>> verfügbar zu haben musste ich autofs installieren. Über einen Eintrag in 
>>> fstab lief es nicht. Obwohl der korrekt war.
>>> 
>>> Am 28. Dezember 2020 17:04:57 MEZ schrieb "Thomas Höpfner" 
>>> :
>>> Hallo Micha,
>>>  
>>> warum das bei dir nicht funktioniert ist mir ein Rätsel. Ohne 
>>> funktionierendes Backup ist es auch nicht gut, hatte ich aber auch ein paar 
>>> Jahre. 
>>>  
>>> Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten Backups 
>>> für den VZ.
>>>  
>>> Grüße
>>>  
>>> Micha
>>>  
>>>  
>>> Bei mir funktioniert es zuverlässig. 
>>>  
>>> Thomas 
>>> 
>>> -- 
>>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>>> <2020-12-29 07_51_21-pi@SmartMeterTS_sqlite_restore3.png>
>>> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore.png>
>>> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore_2.png>
> 
> -- 
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: [vz-users] DB Backup auf NAS via sqlite

Hallo Andreas,

Da bin ich nicht ganz sicher ob dbcopy nicht versucht Daten doppelt zu 
schreiben...

Ich will mal versuchen, ob es mir mit meine begrenzten DB-Kenntnissen gelingt 
die vermeintlichen Doubletten in der DB des Produktivsystems aufzuspüren.

Grüße Micha

Am 29. Dezember 2020 09:06:21 MEZ schrieb Andreas Goetz :
>Vielleicht solltest Du mal überlegen wo diese Einträge eigentlich her
>kommen? Von DBCopy werden sie vmtl nicht erzeugt...
>
>Viele Grüße, Andreas
>
>
>> Am 29.12.2020 um 07:55 schrieb Michael Hartmann
>:
>> 
>> 
>> Hallo Thomas,
>>  
>> anbei drei Screenshots von drei unmittelbar aufeinanderfolgenden
>Aufrufen mit den Fehlermeldungen bei denen dbcopy aussteigt. Wie man
>sieht, ist es jedes Mal ein Datum mit höherer ID an denen sich dbcopy
>aufhängt.
>>  
>> Grüße
>>  
>> Micha
>>  
>> Von: volkszaehler-users
>[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag
>von Thomas Höpfner
>> Gesendet: Montag, 28. Dezember 2020 22:27
>> An: volkszaehler.org - users
>> Betreff: Re: [vz-users] DB Backup auf NAS via sqlite
>>  
>> Hallo Micha,
>>  
>> ist dein Testsystem noch aktiv?
>> Kannst du einen Screenshot von der Fehlermeldung machen? Am besten 2
>kurz hintereinander. 
>> Eventuell habe ich einen Workaround. 
>> 
>> Thomas 
>>  
>> Am 28.12.2020 um 20:43 schrieb Michael Hartmann
>:
>> 
>> Hallo Thomas,
>> 
>> Ich habe auch keine Idee mehr. Egal ob aus einer parallelen DB via
>mysql oder über sqlite es läuft beim restore immer auf duplicate
>entries bei denen dbcopy aussteigt.
>> 
>> Grüße
>> 
>> Micha
>> 
>> P.S.: Um das share egal ob nun via cifs oder nfs eingebunden nach
>reboot verfügbar zu haben musste ich autofs installieren. Über einen
>Eintrag in fstab lief es nicht. Obwohl der korrekt war.
>> 
>> Am 28. Dezember 2020 17:04:57 MEZ schrieb "Thomas Höpfner"
>:
>> Hallo Micha,
>>  
>> warum das bei dir nicht funktioniert ist mir ein Rätsel. Ohne
>funktionierendes Backup ist es auch nicht gut, hatte ich aber auch ein
>paar Jahre. 
>>  
>> Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten
>Backups für den VZ.
>>  
>> Grüße
>>  
>> Micha
>>  
>>  
>> Bei mir funktioniert es zuverlässig. 
>>  
>> Thomas 
>> 
>> -- 
>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>> <2020-12-29 07_51_21-pi@SmartMeterTS_sqlite_restore3.png>
>> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore.png>
>> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore_2.png>

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

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-29 Diskussionsfäden Thomas Höpfner

Hallo Micha,



dann könnte mein workaround funktionieren:



rufe einmal dbcopy auf, wenn es mit fehler abbricht gib als nächstes folgendes 
ein:



:~# while [ $? -gt 0 ];do  ; done



Das ist ein Script das dbcopy solange stardet bis es den Fehler 0 zurückgibt. 
Deshalb muss es direckt nach einer Fehlermeldung gestardet werden.

Als einmaliger workarount eventuell machbar  aber für die Zukunft sollte die 
Ursache gefunden werden. Da stimme ich Andreas voll zu.

Als Ansatz dient eventuell der Timestamp, der ist nähmlich nicht immer größer.



1. Screenshot

 timestamp: Tue Dec  8 14:19:53 UTC 2020

 channel_id: 15

 id (key PRIMARY): 14611172  



2. Screenshot

 timestemp: Wed Dec  9 17:51:05 UTC 2020

 channel_id: 3

 id (key PRIMARY): 14635746



3. Screenshot

 timestemp: Wed Dec  9 17:50:00 UTC 2020

 channel_id: 3

 id (key PRIMARY): 14635755



Für mich stellt sich die Frage, warum ist vom 3. Kanal ein älterer Wert mit 
höherer id vorhanden?
Das ist aber nur ein Indiz für den Fehler, das bleibt die scheinbar doppelt 
vorhandene id , und die wird von der Datenbank vergeben.
Ich habe irgendwo gelesen, das MySQL relativ fehlertolerant ist. Das heißt, der 
Fehler kann unbemerkt in der originalen DB sein und ist im Backup gesichert.
Das ist aber reine Spekulation von mir.

Mit freundlichen Grüßen,

Thomas 





-Ursprüngliche Nachricht-
Von: Andreas Goetz 
Gesendet: Dienstag 29 Dezember 2020 09:06
An: volkszaehler.org - users 
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

Vielleicht solltest Du mal überlegen wo diese Einträge eigentlich her kommen? 
Von DBCopy werden sie vmtl nicht erzeugt...

Viele Grüße, Andreas


Am 29.12.2020 um 07:55 schrieb Michael Hartmann :

Hallo Thomas,

 
anbei drei Screenshots von drei unmittelbar aufeinanderfolgenden Aufrufen mit 
den Fehlermeldungen bei denen dbcopy aussteigt. Wie man sieht, ist es jedes Mal 
ein Datum mit höherer ID an denen sich dbcopy aufhängt.

 
Grüße

 
Micha

 
Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Montag, 28. Dezember 2020 22:27
An: volkszaehler.org - users
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

 
Hallo Micha,

 
ist dein Testsystem noch aktiv?

Kannst du einen Screenshot von der Fehlermeldung machen? Am besten 2 kurz 
hintereinander. 

Eventuell habe ich einen Workaround. 

Thomas 

 
Am 28.12.2020 um 20:43 schrieb Michael Hartmann :

Hallo Thomas,

Ich habe auch keine Idee mehr. Egal ob aus einer parallelen DB via mysql oder 
über sqlite es läuft beim restore immer auf duplicate entries bei denen dbcopy 
aussteigt.

Grüße

Micha

P.S.: Um das share egal ob nun via cifs oder nfs eingebunden nach reboot 
verfügbar zu haben musste ich autofs installieren. Über einen Eintrag in fstab 
lief es nicht. Obwohl der korrekt war.

Am 28. Dezember 2020 17:04:57 MEZ schrieb "Thomas Höpfner" :

Hallo Micha,

 
warum das bei dir nicht funktioniert ist mir ein Rätsel. Ohne funktionierendes 
Backup ist es auch nicht gut, hatte ich aber auch ein paar Jahre. 

 
Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten Backups für 
den VZ.

 
Grüße

 
Micha

 
 
Bei mir funktioniert es zuverlässig. 

 
Thomas 


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

<2020-12-29 07_51_21-pi@SmartMeterTS_sqlite_restore3.png>
<2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore.png>
<2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore_2.png>

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-29 Diskussionsfäden Andreas Goetz

Vielleicht solltest Du mal überlegen wo diese Einträge eigentlich her kommen? 
Von DBCopy werden sie vmtl nicht erzeugt...

Viele Grüße, Andreas


> Am 29.12.2020 um 07:55 schrieb Michael Hartmann :
> 
> 
> Hallo Thomas,
>  
> anbei drei Screenshots von drei unmittelbar aufeinanderfolgenden Aufrufen mit 
> den Fehlermeldungen bei denen dbcopy aussteigt. Wie man sieht, ist es jedes 
> Mal ein Datum mit höherer ID an denen sich dbcopy aufhängt.
>  
> Grüße
>  
> Micha
>  
> Von: volkszaehler-users 
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
> Thomas Höpfner
> Gesendet: Montag, 28. Dezember 2020 22:27
> An: volkszaehler.org - users
> Betreff: Re: [vz-users] DB Backup auf NAS via sqlite
>  
> Hallo Micha,
>  
> ist dein Testsystem noch aktiv?
> Kannst du einen Screenshot von der Fehlermeldung machen? Am besten 2 kurz 
> hintereinander. 
> Eventuell habe ich einen Workaround. 
> 
> Thomas 
>  
> Am 28.12.2020 um 20:43 schrieb Michael Hartmann :
> 
> Hallo Thomas,
> 
> Ich habe auch keine Idee mehr. Egal ob aus einer parallelen DB via mysql oder 
> über sqlite es läuft beim restore immer auf duplicate entries bei denen 
> dbcopy aussteigt.
> 
> Grüße
> 
> Micha
> 
> P.S.: Um das share egal ob nun via cifs oder nfs eingebunden nach reboot 
> verfügbar zu haben musste ich autofs installieren. Über einen Eintrag in 
> fstab lief es nicht. Obwohl der korrekt war.
> 
> Am 28. Dezember 2020 17:04:57 MEZ schrieb "Thomas Höpfner" :
> Hallo Micha,
>  
> warum das bei dir nicht funktioniert ist mir ein Rätsel. Ohne 
> funktionierendes Backup ist es auch nicht gut, hatte ich aber auch ein paar 
> Jahre. 
>  
> Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten Backups 
> für den VZ.
>  
> Grüße
>  
> Micha
>  
>  
> Bei mir funktioniert es zuverlässig. 
>  
> Thomas 
> 
> -- 
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> <2020-12-29 07_51_21-pi@SmartMeterTS_sqlite_restore3.png>
> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore.png>
> <2020-12-29 07_47_52-pi@SmartMeterTS_sqlite_restore_2.png>

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-28 Diskussionsfäden Daniel Lauckner

Hallo,


am Dienstag, 29. Dezember 2020 um 07:55 hat Michael Hartmann geschrieben:
> Wie man
> sieht, ist es jedes Mal ein Datum mit höherer ID an denen sich dbcopy 
> aufhängt.

Hab ich dich nicht mal explizit danach gefragt ob immer der selbe 
Eintrag angemeckert wird und du hast es bestätigt?


mfg Daniel

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-28 Diskussionsfäden Thomas Höpfner

Hallo Micha,

ist dein Testsystem noch aktiv?
Kannst du einen Screenshot von der Fehlermeldung machen? Am besten 2 kurz 
hintereinander. 
Eventuell habe ich einen Workaround. 

Thomas 

> Am 28.12.2020 um 20:43 schrieb Michael Hartmann :
> 
> Hallo Thomas,
> 
> Ich habe auch keine Idee mehr. Egal ob aus einer parallelen DB via mysql oder 
> über sqlite es läuft beim restore immer auf duplicate entries bei denen 
> dbcopy aussteigt.
> 
> Grüße
> 
> Micha
> 
> P.S.: Um das share egal ob nun via cifs oder nfs eingebunden nach reboot 
> verfügbar zu haben musste ich autofs installieren. Über einen Eintrag in 
> fstab lief es nicht. Obwohl der korrekt war.
> 
> Am 28. Dezember 2020 17:04:57 MEZ schrieb "Thomas Höpfner" :
>> 
>> Hallo Micha,
>> 
>> warum das bei dir nicht funktioniert ist mir ein Rätsel. Ohne 
>> funktionierendes Backup ist es auch nicht gut, hatte ich aber auch ein paar 
>> Jahre. 
>> 
>>> Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten Backups 
>>> für den VZ.
>>>  
>>> Grüße
>>>  
>>> Micha
>>> 
>> 
>> Bei mir funktioniert es zuverlässig. 
>> 
>> Thomas 
> 
> -- 
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.


smime.p7s
Description: S/MIME cryptographic signature

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-28 Diskussionsfäden Michael Hartmann

Hallo Thomas,

Ich habe auch keine Idee mehr. Egal ob aus einer parallelen DB via mysql oder 
über sqlite es läuft beim restore immer auf duplicate entries bei denen dbcopy 
aussteigt.

Grüße

Micha

P.S.: Um das share egal ob nun via cifs oder nfs eingebunden nach reboot 
verfügbar zu haben musste ich autofs installieren. Über einen Eintrag in fstab 
lief es nicht. Obwohl der korrekt war.

Am 28. Dezember 2020 17:04:57 MEZ schrieb "Thomas Höpfner" :
>Hallo Micha,
>
>warum das bei dir nicht funktioniert ist mir ein Rätsel. Ohne
>funktionierendes Backup ist es auch nicht gut, hatte ich aber auch ein
>paar Jahre. 
>
>> Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten
>Backups für den VZ.
>>  
>> Grüße
>>  
>> Micha
>> 
>
>Bei mir funktioniert es zuverlässig. 
>
>Thomas 

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

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-28 Diskussionsfäden Michael Hartmann

Hallo Daniel,

ich bitte meine Unwissenheit zu entschuldigen: was ist ein SQL Dump?

Fragt sich,

Micha

Am 28. Dezember 2020 17:18:06 MEZ schrieb Daniel Lauckner :
>Hallo,
>
>
>am Sonntag, 27. Dezember 2020 um 12:55 hat Michael Hartmann
>geschrieben:
>> Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten
>Backups für den VZ.
>
>Hast du auch mal einen SQL-Dump versucht?
>
>
>mfg Daniel

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

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-28 Diskussionsfäden Daniel Lauckner

Hallo,


am Sonntag, 27. Dezember 2020 um 12:55 hat Michael Hartmann geschrieben:
> Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten Backups 
> für den VZ.

Hast du auch mal einen SQL-Dump versucht?


mfg Daniel

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-28 Diskussionsfäden Thomas Höpfner

Hallo Micha,

warum das bei dir nicht funktioniert ist mir ein Rätsel. Ohne funktionierendes 
Backup ist es auch nicht gut, hatte ich aber auch ein paar Jahre. 

> Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten Backups 
> für den VZ.
>  
> Grüße
>  
> Micha
> 

Bei mir funktioniert es zuverlässig. 

Thomas 

smime.p7s
Description: S/MIME cryptographic signature

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-27 Diskussionsfäden Michael Hartmann

Hallo,

 

da ich hier mit cifs aus ungeklärten Gründe nicht weiterkomme, habe ich das 
share nun via nfs eingebunden. Jetzt funktioniert auch das sqlite backup direkt 
auf das share.

 

Nur beim restore des backups auf das testsystem steigt dbcopy wieder mit 
duplicate entries aus. Wie seinerzeit bei Versuch das restore aus der mysql DB 
Kopie auf meiner Sysnology durchzuführen.

 

Somit gibt es scheinbar keine Möglichkeit eines zuverlässigen Daten Backups für 
den VZ.

 

Grüße

 

Micha

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Samstag, 5. Dezember 2020 13:47
An: volkszaehler.org - users
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

 

Hallo Micha,

 

probiere nfs anstelle cifs.

Thomas 

 

 





Am 05.12.2020 um 11:13 schrieb Michael Hartmann :



Hallo,

 

nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das 
Testsystem zu transferieren versuche ich nun den Weg über sqlite.

 

Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite Backup 
auf dem Produktivsystem erstellt und dieses dann auf das NAS verschoben. Dieses 
Backup konnte ich direkt vom NAS auf das Testsystem einspielen, wo mir im 
Anschluss alle Daten im Frontend zu Verfügung stehen.

 

Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS zu 
fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem gemountet:

 

//192.168.178.24/SmartMeter /mnt/VZ_share cifs 
username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770 
0 0

 

Anschließen kann der user pi alle Dateioperation auf dem share ausüben 
(löschen, verschieben, umbenennen,…)

 

pi@SmartMeter:/mnt/VZ_share $ ls -l

insgesamt 4917152

-rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz

-rwxrwx--- 1 pi root 1757275296 Dez  1 06:07 VZ-Backup_2020-12-01_0300.img.gz

-rwxrwx--- 1 pi root  202543104 Nov 29 12:07 VZ_DB_Backup.db3

-rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 VZ-Image_2020-11-21_blank_DB.img.gz

 

Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei!

 

pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
/etc/dbcopy_sqlite.yaml

 

In AbstractSQLiteDriver.php line 39:

 

  An exception occurred while executing 'DELETE FROM entities':

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

In Exception.php line 18:

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

In PDOConnection.php line 125:

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] 
[...]

 

Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares 
ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen 
Unterschied.

 

Hat dazu jemand eine Idee?

 

Grüße

 

Micha

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-07 Diskussionsfäden Michael Hartmann

Hallo John,

der user pi kann, so wie das share aktuell eingebunden ist alle Dateioperationen durchführen! Lediglich dbcopy liefert die Fehlermeldung das die DB gelocked sei...

Grüße

Micha

Gesendet: Montag, 07. Dezember 2020 um 14:16 Uhr
Von: "John Doe"
An: volkszaehler-users@demo.volkszaehler.org
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

Hallo Michael, versuch den mount von Deinem Raspi auf die DS mal so:

sudo mount -t cifs //DS-IP/Freigabe /media/mount-point -o user=admin,vers=1.0

Ich habe mit der Protokollversion (1.0) einige Zeit probiert, aber das Kopieren einiger GB auf den share läuft bei mir einwandfrei.

Grüße

JD.

Sent: Saturday, December 05, 2020 at 3:32 PM
From: "Michael Hartmann"
To: "'volkszaehler.org - users'"
Subject: Re: [vz-users] DB Backup auf NAS via sqlite

Die Variante ohne filemode, dirmode habe ich auch schon erfolglos durch :-/.

Grüße

Micha

Von: volkszaehler-users [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von ?tobias.l...@me.com?
Gesendet: Samstag, 5. Dezember 2020 15:18
An: volkszaehler.org - users
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

Hallo,

Kann ich dir gar nicht mehr sagen. Probiere es doch einfach mal.

Der einzige Unterschied der mir jetzt noch auffällt ist, dass ich in der fstab das share ohne filemode und ohne dir öde angegeben habe.

Muss aber gestehen das ich da absut kein Fachmann für bin.

Gruß Tobias

Von meinem Huawei-Telefon gesendet

Ursprüngliche Nachricht
Von: Michael Hartmann
Datum: Sa., 5. Dez. 2020, 15:09
An: "'volkszaehler.org - users'"
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

Hallo Tobias,

ja ein DS213j. Leider hat das Deaktivieren dieser Option es auch nicht gebracht. Erfordert es einen Neustart der Diskstation um wirksam zu werden?

Grüße

Micha

Von: volkszaehler-users [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von ?tobias.l...@me.com?
Gesendet: Samstag, 5. Dezember 2020 12:29
An: volkszaehler.org - users
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

Hallo,

Handelt es sich bei dem NAS um eine Synology? Ich hatte das selbe Problem nämlich auch. Wen ja schau mal unter Systemsteuerung/dateidienste/smb/erweiterte Einstellungen. Da gibt es bei mir einen Punkt der nennt sich opportunistic locking aktivieren. Da war bei mir standardmäßig der Haken drin. Nach dem ich diesen entfernt hatte ging es bei mir. Hatte ich irgendwie ergooglet weiß aber nicht mehr wo.

Gruß Tobias

Ursprüngliche Nachricht
Von: Michael Hartmann
Datum: Sa., 5. Dez. 2020, 11:12
An: "'volkszaehler.org - users'"
Betreff: [vz-users] DB Backup auf NAS via sqlite

Hallo,

nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das Testsystem zu transferieren versuche ich nun den Weg über sqlite.

Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite Backup auf dem Produktivsystem erstellt und dieses dann auf das NAS verschoben. Dieses Backup konnte ich direkt vom NAS auf das Testsystem einspielen, wo mir im Anschluss alle Daten im Frontend zu Verfügung stehen.

Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS zu fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem gemountet:

//192.168.178.24/SmartMeter /mnt/VZ_share cifs username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770 0 0

Anschließen kann der user pi alle Dateioperation auf dem share ausüben (löschen, verschieben, umbenennen,…)

pi@SmartMeter:/mnt/VZ_share $ ls -l

insgesamt 4917152

-rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz

-rwxrwx--- 1 pi root 1757275296 Dez 1 06:07 VZ-Backup_2020-12-01_0300.img.gz

-rwxrwx--- 1 pi root 202543104 Nov 29 12:07 VZ_DB_Backup.db3

-rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 VZ-Image_2020-11-21_blank_DB.img.gz

Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei!

pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy_sqlite.yaml

In AbstractSQLiteDriver.php line 39:

An exception occurred while executing 'DELETE FROM entities':

SQLSTATE[HY000]: General error: 5 database is locked

In Exception.php line 18:

SQLSTATE[HY000]: General error: 5 database is locked

In PDOConnection.php line 125:

SQLSTATE[HY000]: General error: 5 database is locked

copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...]

Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen Unterschied.

Hat dazu jemand eine Idee?

Grüße

Micha

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-07 Diskussionsfäden John Doe

Hallo Michael, versuch den mount von Deinem Raspi auf die DS mal so:

sudo mount -t cifs //DS-IP/Freigabe /media/mount-point -o user=admin,vers=1.0

Ich habe mit der Protokollversion (1.0) einige Zeit probiert, aber das Kopieren einiger GB auf den share läuft bei mir einwandfrei.

Grüße

JD.

Sent: Saturday, December 05, 2020 at 3:32 PM
From: "Michael Hartmann"
To: "'volkszaehler.org - users'"
Subject: Re: [vz-users] DB Backup auf NAS via sqlite

Die Variante ohne filemode, dirmode habe ich auch schon erfolglos durch :-/.

Grüße

Micha

Hallo,

Kann ich dir gar nicht mehr sagen. Probiere es doch einfach mal.

Der einzige Unterschied der mir jetzt noch auffällt ist, dass ich in der fstab das share ohne filemode und ohne dir öde angegeben habe.

Muss aber gestehen das ich da absut kein Fachmann für bin.

Gruß Tobias

Von meinem Huawei-Telefon gesendet

Ursprüngliche Nachricht
Von: Michael Hartmann
Datum: Sa., 5. Dez. 2020, 15:09
An: "'volkszaehler.org - users'"
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

Hallo Tobias,

ja ein DS213j. Leider hat das Deaktivieren dieser Option es auch nicht gebracht. Erfordert es einen Neustart der Diskstation um wirksam zu werden?

Grüße

Micha

Hallo,

Gruß Tobias

Ursprüngliche Nachricht
Von: Michael Hartmann
Datum: Sa., 5. Dez. 2020, 11:12
An: "'volkszaehler.org - users'"
Betreff: [vz-users] DB Backup auf NAS via sqlite

Hallo,

nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das Testsystem zu transferieren versuche ich nun den Weg über sqlite.

Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS zu fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem gemountet:

//192.168.178.24/SmartMeter /mnt/VZ_share cifs username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770 0 0

Anschließen kann der user pi alle Dateioperation auf dem share ausüben (löschen, verschieben, umbenennen,…)

pi@SmartMeter:/mnt/VZ_share $ ls -l

insgesamt 4917152

-rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz

-rwxrwx--- 1 pi root 1757275296 Dez 1 06:07 VZ-Backup_2020-12-01_0300.img.gz

-rwxrwx--- 1 pi root 202543104 Nov 29 12:07 VZ_DB_Backup.db3

-rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 VZ-Image_2020-11-21_blank_DB.img.gz

Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei!

pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy_sqlite.yaml

In AbstractSQLiteDriver.php line 39:

An exception occurred while executing 'DELETE FROM entities':

SQLSTATE[HY000]: General error: 5 database is locked

In Exception.php line 18:

SQLSTATE[HY000]: General error: 5 database is locked

In PDOConnection.php line 125:

SQLSTATE[HY000]: General error: 5 database is locked

copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...]

Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen Unterschied.

Hat dazu jemand eine Idee?

Grüße

Micha

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-05 Diskussionsfäden ‪tobias . lehr

Hallo, Kann ich dir gar nicht mehr sagen. Probiere es doch einfach mal. Der einzige Unterschied der mir jetzt noch auffällt ist, dass ich in der fstab das share ohne filemode und ohne dir öde angegeben habe. Muss aber gestehen das ich da absut kein Fachmann für bin. Gruß TobiasVon meinem Huawei-Telefon gesendet Ursprüngliche Nachricht Von: Michael Hartmann Datum: Sa., 5. Dez. 2020, 15:09An: "'volkszaehler.org - users'" Betreff: Re: [vz-users] DB Backup auf NAS via sqliteHallo Tobias, ja ein DS213j. Leider hat das Deaktivieren dieser Option es auch nicht gebracht. Erfordert es einen Neustart der Diskstation um wirksam zu werden? Grüße Micha Von: volkszaehler-users [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von ?tobias.l...@me.com?Gesendet: Samstag, 5. Dezember 2020 12:29An: volkszaehler.org - usersBetreff: Re: [vz-users] DB Backup auf NAS via sqlite Hallo, Handelt es sich bei dem NAS um eine Synology? Ich hatte das selbe Problem nämlich auch. Wen ja schau mal unter Systemsteuerung/dateidienste/smb/erweiterte Einstellungen. Da gibt es bei mir einen Punkt der nennt sich opportunistic locking aktivieren. Da war bei mir standardmäßig der Haken drin. Nach dem ich diesen entfernt hatte ging es bei mir. Hatte ich irgendwie ergooglet weiß aber nicht mehr wo. Gruß Tobias Ursprüngliche Nachricht Von: Michael Hartmann Datum: Sa., 5. Dez. 2020, 11:12An: "'volkszaehler.org - users'" Betreff: [vz-users] DB Backup auf NAS via sqliteHallo, nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das Testsystem zu transferieren versuche ich nun den Weg über sqlite. Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite Backup auf dem Produktivsystem erstellt und dieses dann auf das NAS verschoben. Dieses Backup konnte ich direkt vom NAS auf das Testsystem einspielen, wo mir im Anschluss alle Daten im Frontend zu Verfügung stehen. Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS zu fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem gemountet: //192.168.178.24/SmartMeter /mnt/VZ_share cifs username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770 0 0 Anschließen kann der user pi alle Dateioperation auf dem share ausüben (löschen, verschieben, umbenennen,…) pi@SmartMeter:/mnt/VZ_share $ ls -linsgesamt 4917152-rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz-rwxrwx--- 1 pi root 1757275296 Dez 1 06:07 VZ-Backup_2020-12-01_0300.img.gz-rwxrwx--- 1 pi root 202543104 Nov 29 12:07 VZ_DB_Backup.db3-rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 VZ-Image_2020-11-21_blank_DB.img.gz Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei! pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy_sqlite.yaml In AbstractSQLiteDriver.php line 39: An exception occurred while executing 'DELETE FROM entities': SQLSTATE[HY000]: General error: 5 database is locked In Exception.php line 18: SQLSTATE[HY000]: General error: 5 database is locked In PDOConnection.php line 125: SQLSTATE[HY000]: General error: 5 database is locked copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen Unterschied. Hat dazu jemand eine Idee? Grüße Micha

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-05 Diskussionsfäden ‪tobias . lehr

Hallo,Handelt es sich bei dem NAS um eine Synology? Ich hatte das selbe Problem nämlich auch. Wen ja schau mal unter Systemsteuerung/dateidienste/smb/erweiterte Einstellungen. Da gibt es bei mir einen Punkt der nennt sich opportunistic locking aktivieren. Da war bei mir standardmäßig der Haken drin. Nach dem ich diesen entfernt hatte ging es bei mir. Hatte ich irgendwie ergooglet weiß aber nicht mehr wo.Gruß Tobias Ursprüngliche Nachricht Von: Michael Hartmann Datum: Sa., 5. Dez. 2020, 11:12An: "'volkszaehler.org - users'" Betreff: [vz-users] DB Backup auf NAS via sqliteHallo, nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das Testsystem zu transferieren versuche ich nun den Weg über sqlite. Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite Backup auf dem Produktivsystem erstellt und dieses dann auf das NAS verschoben. Dieses Backup konnte ich direkt vom NAS auf das Testsystem einspielen, wo mir im Anschluss alle Daten im Frontend zu Verfügung stehen. Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS zu fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem gemountet: //192.168.178.24/SmartMeter /mnt/VZ_share cifs username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770 0 0 Anschließen kann der user pi alle Dateioperation auf dem share ausüben (löschen, verschieben, umbenennen,…) pi@SmartMeter:/mnt/VZ_share $ ls -linsgesamt 4917152-rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz-rwxrwx--- 1 pi root 1757275296 Dez 1 06:07 VZ-Backup_2020-12-01_0300.img.gz-rwxrwx--- 1 pi root 202543104 Nov 29 12:07 VZ_DB_Backup.db3-rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 VZ-Image_2020-11-21_blank_DB.img.gz Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei! pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy_sqlite.yaml In AbstractSQLiteDriver.php line 39: An exception occurred while executing 'DELETE FROM entities': SQLSTATE[HY000]: General error: 5 database is locked In Exception.php line 18: SQLSTATE[HY000]: General error: 5 database is locked In PDOConnection.php line 125: SQLSTATE[HY000]: General error: 5 database is locked copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen Unterschied. Hat dazu jemand eine Idee? Grüße Micha

Re: [vz-users] DB Backup auf NAS via sqlite

Die Variante ohne filemode, dirmode habe ich auch schon erfolglos durch :-/.

 

Grüße

 

Micha

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
?tobias.l...@me.com?
Gesendet: Samstag, 5. Dezember 2020 15:18
An: volkszaehler.org - users
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

 

Hallo, 

 

Kann ich dir gar nicht mehr sagen. Probiere es doch einfach mal. 

 

Der einzige Unterschied der mir jetzt noch auffällt ist, dass ich in der fstab 
das share ohne filemode und ohne dir öde angegeben habe. 

 

Muss aber gestehen das ich da absut kein Fachmann für bin. 

 

Gruß Tobias

Von meinem Huawei-Telefon gesendet



 Ursprüngliche Nachricht 
Von: Michael Hartmann 
Datum: Sa., 5. Dez. 2020, 15:09
An: "'volkszaehler.org - users'" 
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

Hallo Tobias,

 

ja ein DS213j. Leider hat das Deaktivieren dieser Option es auch nicht 
gebracht. Erfordert es einen Neustart der Diskstation um wirksam zu werden?

 

Grüße

 

Micha

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
?tobias.l...@me.com?
Gesendet: Samstag, 5. Dezember 2020 12:29
An: volkszaehler.org - users
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

 


Hallo,

 

Handelt es sich bei dem NAS um eine Synology? Ich hatte das selbe Problem 
nämlich auch. Wen ja schau mal unter 
Systemsteuerung/dateidienste/smb/erweiterte Einstellungen. Da gibt es bei mir 
einen Punkt der nennt sich opportunistic locking aktivieren. Da war bei mir 
standardmäßig der Haken drin. Nach dem ich diesen entfernt hatte ging es bei 
mir. Hatte ich irgendwie ergooglet weiß aber nicht mehr wo.

 

Gruß Tobias



 Ursprüngliche Nachricht 
Von: Michael Hartmann 
Datum: Sa., 5. Dez. 2020, 11:12
An: "'volkszaehler.org - users'" 
Betreff: [vz-users] DB Backup auf NAS via sqlite

Hallo,

 

nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das 
Testsystem zu transferieren versuche ich nun den Weg über sqlite.

 

Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite Backup 
auf dem Produktivsystem erstellt und dieses dann auf das NAS verschoben. Dieses 
Backup konnte ich direkt vom NAS auf das Testsystem einspielen, wo mir im 
Anschluss alle Daten im Frontend zu Verfügung stehen.

 

Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS zu 
fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem gemountet:

 

//192.168.178.24/SmartMeter /mnt/VZ_share cifs 
username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770 
0 0

 

Anschließen kann der user pi alle Dateioperation auf dem share ausüben 
(löschen, verschieben, umbenennen,…)

 

pi@SmartMeter:/mnt/VZ_share $ ls -l

insgesamt 4917152

-rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz

-rwxrwx--- 1 pi root 1757275296 Dez  1 06:07 VZ-Backup_2020-12-01_0300.img.gz

-rwxrwx--- 1 pi root  202543104 Nov 29 12:07 VZ_DB_Backup.db3

-rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 VZ-Image_2020-11-21_blank_DB.img.gz

 

Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei!

 

pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
/etc/dbcopy_sqlite.yaml

 

In AbstractSQLiteDriver.php line 39:

 

  An exception occurred while executing 'DELETE FROM entities':

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

In Exception.php line 18:

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

In PDOConnection.php line 125:

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] 
[...]

 

Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares 
ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen 
Unterschied.

 

Hat dazu jemand eine Idee?

 

Grüße

 

Micha

Re: [vz-users] DB Backup auf NAS via sqlite

Hallo Tobias,

 

ja ein DS213j. Leider hat das Deaktivieren dieser Option es auch nicht 
gebracht. Erfordert es einen Neustart der Diskstation um wirksam zu werden?

 

Grüße

 

Micha

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
?tobias.l...@me.com?
Gesendet: Samstag, 5. Dezember 2020 12:29
An: volkszaehler.org - users
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

 


Hallo,

 

Handelt es sich bei dem NAS um eine Synology? Ich hatte das selbe Problem 
nämlich auch. Wen ja schau mal unter 
Systemsteuerung/dateidienste/smb/erweiterte Einstellungen. Da gibt es bei mir 
einen Punkt der nennt sich opportunistic locking aktivieren. Da war bei mir 
standardmäßig der Haken drin. Nach dem ich diesen entfernt hatte ging es bei 
mir. Hatte ich irgendwie ergooglet weiß aber nicht mehr wo.

 

Gruß Tobias



 Ursprüngliche Nachricht 
Von: Michael Hartmann 
Datum: Sa., 5. Dez. 2020, 11:12
An: "'volkszaehler.org - users'" 
Betreff: [vz-users] DB Backup auf NAS via sqlite

Hallo,

 

nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das 
Testsystem zu transferieren versuche ich nun den Weg über sqlite.

 

Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite Backup 
auf dem Produktivsystem erstellt und dieses dann auf das NAS verschoben. Dieses 
Backup konnte ich direkt vom NAS auf das Testsystem einspielen, wo mir im 
Anschluss alle Daten im Frontend zu Verfügung stehen.

 

Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS zu 
fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem gemountet:

 

//192.168.178.24/SmartMeter /mnt/VZ_share cifs 
username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770 
0 0

 

Anschließen kann der user pi alle Dateioperation auf dem share ausüben 
(löschen, verschieben, umbenennen,…)

 

pi@SmartMeter:/mnt/VZ_share $ ls -l

insgesamt 4917152

-rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz

-rwxrwx--- 1 pi root 1757275296 Dez  1 06:07 VZ-Backup_2020-12-01_0300.img.gz

-rwxrwx--- 1 pi root  202543104 Nov 29 12:07 VZ_DB_Backup.db3

-rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 VZ-Image_2020-11-21_blank_DB.img.gz

 

Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei!

 

pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
/etc/dbcopy_sqlite.yaml

 

In AbstractSQLiteDriver.php line 39:

 

  An exception occurred while executing 'DELETE FROM entities':

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

In Exception.php line 18:

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

In PDOConnection.php line 125:

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] 
[...]

 

Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares 
ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen 
Unterschied.

 

Hat dazu jemand eine Idee?

 

Grüße

 

Micha

Re: [vz-users] DB Backup auf NAS via sqlite

Wenn ich täglich ein lokales Backup der DB mache um dieses dann auf das NAS zu 
kopieren, habe ich halt weitere Schreibzyklen und den damit einhergehenden 
Verschleiß der SD-Karte.

 

Grüße

 

Micha

 

Von: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Thomas 
Höpfner
Gesendet: Samstag, 5. Dezember 2020 13:22
An: volkszaehler.org - users
Betreff: Re: [vz-users] DB Backup auf NAS via sqlite

 

Nötig ist es, weil local schreiben auf die SD nicht die beste Idee ist.

Thomas 

 





Am 05.12.2020 um 12:29 schrieb Andreas Goetz :



Aber warum ist das nötig? Lokal schreiben und dann rüber kopieren? Nicht 
elegant, aber umgeht das Problem.

 

Viele Grüße, Andreas 





Am 05.12.2020 um 12:24 schrieb Thomas Höpfner :

Micha möchte das Backup auf das Share schreiben.

Thomas





Am 05.12.2020 um 12:21 schrieb Andreas Goetz :



Warum musst Du die DB über ein Share restaurieren? Kopier die Datei doch 
einfach auf das Zielsystem?

 

Viele Grüße, Andreas 





Am 05.12.2020 um 11:12 schrieb Michael Hartmann :



Hallo,

 

nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das 
Testsystem zu transferieren versuche ich nun den Weg über sqlite.

 

Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite Backup 
auf dem Produktivsystem erstellt und dieses dann auf das NAS verschoben. Dieses 
Backup konnte ich direkt vom NAS auf das Testsystem einspielen, wo mir im 
Anschluss alle Daten im Frontend zu Verfügung stehen.

 

Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS zu 
fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem gemountet:

 

//192.168.178.24/SmartMeter /mnt/VZ_share cifs 
username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770 
0 0

 

Anschließen kann der user pi alle Dateioperation auf dem share ausüben 
(löschen, verschieben, umbenennen,…)

 

pi@SmartMeter:/mnt/VZ_share $ ls -l

insgesamt 4917152

-rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz

-rwxrwx--- 1 pi root 1757275296 Dez  1 06:07 VZ-Backup_2020-12-01_0300.img.gz

-rwxrwx--- 1 pi root  202543104 Nov 29 12:07 VZ_DB_Backup.db3

-rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 VZ-Image_2020-11-21_blank_DB.img.gz

 

Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei!

 

pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
/etc/dbcopy_sqlite.yaml

 

In AbstractSQLiteDriver.php line 39:

 

  An exception occurred while executing 'DELETE FROM entities':

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

In Exception.php line 18:

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

In PDOConnection.php line 125:

 

  SQLSTATE[HY000]: General error: 5 database is locked

 

 

copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] 
[...]

 

Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares 
ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen 
Unterschied.

 

Hat dazu jemand eine Idee?

 

Grüße

 

Micha

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-05 Diskussionsfäden Thomas Höpfner

Hallo Micha,

probiere nfs anstelle cifs.

Thomas 



> Am 05.12.2020 um 11:13 schrieb Michael Hartmann :
> 
> 
> Hallo,
>  
> nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das 
> Testsystem zu transferieren versuche ich nun den Weg über sqlite.
>  
> Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite Backup 
> auf dem Produktivsystem erstellt und dieses dann auf das NAS verschoben. 
> Dieses Backup konnte ich direkt vom NAS auf das Testsystem einspielen, wo mir 
> im Anschluss alle Daten im Frontend zu Verfügung stehen.
>  
> Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS zu 
> fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem gemountet:
>  
> //192.168.178.24/SmartMeter /mnt/VZ_share cifs 
> username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770
>  0 0
>  
> Anschließen kann der user pi alle Dateioperation auf dem share ausüben 
> (löschen, verschieben, umbenennen,…)
>  
> pi@SmartMeter:/mnt/VZ_share $ ls -l
> insgesamt 4917152
> -rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz
> -rwxrwx--- 1 pi root 1757275296 Dez  1 06:07 VZ-Backup_2020-12-01_0300.img.gz
> -rwxrwx--- 1 pi root  202543104 Nov 29 12:07 VZ_DB_Backup.db3
> -rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 
> VZ-Image_2020-11-21_blank_DB.img.gz
>  
> Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei!
>  
> pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
> /etc/dbcopy_sqlite.yaml
>  
> In AbstractSQLiteDriver.php line 39:
>  
>   An exception occurred while executing 'DELETE FROM entities':
>  
>   SQLSTATE[HY000]: General error: 5 database is locked
>  
>  
> In Exception.php line 18:
>  
>   SQLSTATE[HY000]: General error: 5 database is locked
>  
>  
> In PDOConnection.php line 125:
>  
>   SQLSTATE[HY000]: General error: 5 database is locked
>  
>  
> copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] 
> [...]
>  
> Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares 
> ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen 
> Unterschied.
>  
> Hat dazu jemand eine Idee?
>  
> Grüße
>  
> Micha
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-05 Diskussionsfäden Daniel Lauckner

Hallo,


am Samstag, 5. Dezember 2020 um 12:25 hat Andreas Goetz geschrieben:
> Aber warum ist das nötig? Lokal schreiben und dann rüber kopieren?
> Nicht elegant, aber umgeht das Problem.

Das eigentlich Problem war das Rückspielen der DB aus dem NAS auf den 
Rpi mit dbcopy nicht funktionierte. SQLite ist schon der Workaround.


mfg Daniel

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-05 Diskussionsfäden Thomas Höpfner

Nötig ist es, weil local schreiben auf die SD nicht die beste Idee ist.

Thomas 


> Am 05.12.2020 um 12:29 schrieb Andreas Goetz :
> 
> 
> Aber warum ist das nötig? Lokal schreiben und dann rüber kopieren? Nicht 
> elegant, aber umgeht das Problem.
> 
> Viele Grüße, Andreas 
> 
>>> Am 05.12.2020 um 12:24 schrieb Thomas Höpfner :
>>> 
>> Micha möchte das Backup auf das Share schreiben.
>> 
>> Thomas
>> 
 Am 05.12.2020 um 12:21 schrieb Andreas Goetz :
 
>>> 
>>> Warum musst Du die DB über ein Share restaurieren? Kopier die Datei doch 
>>> einfach auf das Zielsystem?
>>> 
>>> Viele Grüße, Andreas 
>>> 
> Am 05.12.2020 um 11:12 schrieb Michael Hartmann :
> 
 
 Hallo,
  
 nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf 
 das Testsystem zu transferieren versuche ich nun den Weg über sqlite.
  
 Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite 
 Backup auf dem Produktivsystem erstellt und dieses dann auf das NAS 
 verschoben. Dieses Backup konnte ich direkt vom NAS auf das Testsystem 
 einspielen, wo mir im Anschluss alle Daten im Frontend zu Verfügung stehen.
  
 Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS 
 zu fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem 
 gemountet:
  
 //192.168.178.24/SmartMeter /mnt/VZ_share cifs 
 username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770
  0 0
  
 Anschließen kann der user pi alle Dateioperation auf dem share ausüben 
 (löschen, verschieben, umbenennen,…)
  
 pi@SmartMeter:/mnt/VZ_share $ ls -l
 insgesamt 4917152
 -rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 
 VZ-Backup_2020-11-15_0300.img.gz
 -rwxrwx--- 1 pi root 1757275296 Dez  1 06:07 
 VZ-Backup_2020-12-01_0300.img.gz
 -rwxrwx--- 1 pi root  202543104 Nov 29 12:07 VZ_DB_Backup.db3
 -rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 
 VZ-Image_2020-11-21_blank_DB.img.gz
  
 Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei!
  
 pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
 /etc/dbcopy_sqlite.yaml
  
 In AbstractSQLiteDriver.php line 39:
  
   An exception occurred while executing 'DELETE FROM entities':
  
   SQLSTATE[HY000]: General error: 5 database is locked
  
  
 In Exception.php line 18:
  
   SQLSTATE[HY000]: General error: 5 database is locked
  
  
 In PDOConnection.php line 125:
  
   SQLSTATE[HY000]: General error: 5 database is locked
  
  
 copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] 
 [...]
  
 Ich habe schon sämtliche, mir bekannten Optionen für das mounten des 
 shares ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht 
 keinen Unterschied.
  
 Hat dazu jemand eine Idee?
  
 Grüße
  
 Micha
 


smime.p7s
Description: S/MIME cryptographic signature

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-05 Diskussionsfäden Andreas Goetz

Aber warum ist das nötig? Lokal schreiben und dann rüber kopieren? Nicht 
elegant, aber umgeht das Problem.

Viele Grüße, Andreas 

> Am 05.12.2020 um 12:24 schrieb Thomas Höpfner :
> 
> Micha möchte das Backup auf das Share schreiben.
> 
> Thomas
> 
>>> Am 05.12.2020 um 12:21 schrieb Andreas Goetz :
>>> 
>> 
>> Warum musst Du die DB über ein Share restaurieren? Kopier die Datei doch 
>> einfach auf das Zielsystem?
>> 
>> Viele Grüße, Andreas 
>> 
 Am 05.12.2020 um 11:12 schrieb Michael Hartmann :
 
>>> 
>>> Hallo,
>>>  
>>> nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf 
>>> das Testsystem zu transferieren versuche ich nun den Weg über sqlite.
>>>  
>>> Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite 
>>> Backup auf dem Produktivsystem erstellt und dieses dann auf das NAS 
>>> verschoben. Dieses Backup konnte ich direkt vom NAS auf das Testsystem 
>>> einspielen, wo mir im Anschluss alle Daten im Frontend zu Verfügung stehen.
>>>  
>>> Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS 
>>> zu fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem 
>>> gemountet:
>>>  
>>> //192.168.178.24/SmartMeter /mnt/VZ_share cifs 
>>> username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770
>>>  0 0
>>>  
>>> Anschließen kann der user pi alle Dateioperation auf dem share ausüben 
>>> (löschen, verschieben, umbenennen,…)
>>>  
>>> pi@SmartMeter:/mnt/VZ_share $ ls -l
>>> insgesamt 4917152
>>> -rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 
>>> VZ-Backup_2020-11-15_0300.img.gz
>>> -rwxrwx--- 1 pi root 1757275296 Dez  1 06:07 
>>> VZ-Backup_2020-12-01_0300.img.gz
>>> -rwxrwx--- 1 pi root  202543104 Nov 29 12:07 VZ_DB_Backup.db3
>>> -rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 
>>> VZ-Image_2020-11-21_blank_DB.img.gz
>>>  
>>> Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei!
>>>  
>>> pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
>>> /etc/dbcopy_sqlite.yaml
>>>  
>>> In AbstractSQLiteDriver.php line 39:
>>>  
>>>   An exception occurred while executing 'DELETE FROM entities':
>>>  
>>>   SQLSTATE[HY000]: General error: 5 database is locked
>>>  
>>>  
>>> In Exception.php line 18:
>>>  
>>>   SQLSTATE[HY000]: General error: 5 database is locked
>>>  
>>>  
>>> In PDOConnection.php line 125:
>>>  
>>>   SQLSTATE[HY000]: General error: 5 database is locked
>>>  
>>>  
>>> copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] 
>>> [...]
>>>  
>>> Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares 
>>> ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen 
>>> Unterschied.
>>>  
>>> Hat dazu jemand eine Idee?
>>>  
>>> Grüße
>>>  
>>> Micha
>>>

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-05 Diskussionsfäden Thomas Höpfner

Micha möchte das Backup auf das Share schreiben.

Thomas

> Am 05.12.2020 um 12:21 schrieb Andreas Goetz :
> 
> 
> Warum musst Du die DB über ein Share restaurieren? Kopier die Datei doch 
> einfach auf das Zielsystem?
> 
> Viele Grüße, Andreas 
> 
>>> Am 05.12.2020 um 11:12 schrieb Michael Hartmann :
>>> 
>> 
>> Hallo,
>>  
>> nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das 
>> Testsystem zu transferieren versuche ich nun den Weg über sqlite.
>>  
>> Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite Backup 
>> auf dem Produktivsystem erstellt und dieses dann auf das NAS verschoben. 
>> Dieses Backup konnte ich direkt vom NAS auf das Testsystem einspielen, wo 
>> mir im Anschluss alle Daten im Frontend zu Verfügung stehen.
>>  
>> Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS 
>> zu fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem 
>> gemountet:
>>  
>> //192.168.178.24/SmartMeter /mnt/VZ_share cifs 
>> username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770
>>  0 0
>>  
>> Anschließen kann der user pi alle Dateioperation auf dem share ausüben 
>> (löschen, verschieben, umbenennen,…)
>>  
>> pi@SmartMeter:/mnt/VZ_share $ ls -l
>> insgesamt 4917152
>> -rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz
>> -rwxrwx--- 1 pi root 1757275296 Dez  1 06:07 VZ-Backup_2020-12-01_0300.img.gz
>> -rwxrwx--- 1 pi root  202543104 Nov 29 12:07 VZ_DB_Backup.db3
>> -rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 
>> VZ-Image_2020-11-21_blank_DB.img.gz
>>  
>> Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei!
>>  
>> pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
>> /etc/dbcopy_sqlite.yaml
>>  
>> In AbstractSQLiteDriver.php line 39:
>>  
>>   An exception occurred while executing 'DELETE FROM entities':
>>  
>>   SQLSTATE[HY000]: General error: 5 database is locked
>>  
>>  
>> In Exception.php line 18:
>>  
>>   SQLSTATE[HY000]: General error: 5 database is locked
>>  
>>  
>> In PDOConnection.php line 125:
>>  
>>   SQLSTATE[HY000]: General error: 5 database is locked
>>  
>>  
>> copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] 
>> [...]
>>  
>> Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares 
>> ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen 
>> Unterschied.
>>  
>> Hat dazu jemand eine Idee?
>>  
>> Grüße
>>  
>> Micha
>> 


smime.p7s
Description: S/MIME cryptographic signature

Re: [vz-users] DB Backup auf NAS via sqlite

2020-12-05 Diskussionsfäden Andreas Goetz

Warum musst Du die DB über ein Share restaurieren? Kopier die Datei doch 
einfach auf das Zielsystem?

Viele Grüße, Andreas 

> Am 05.12.2020 um 11:12 schrieb Michael Hartmann :
> 
> 
> Hallo,
>  
> nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das 
> Testsystem zu transferieren versuche ich nun den Weg über sqlite.
>  
> Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite Backup 
> auf dem Produktivsystem erstellt und dieses dann auf das NAS verschoben. 
> Dieses Backup konnte ich direkt vom NAS auf das Testsystem einspielen, wo mir 
> im Anschluss alle Daten im Frontend zu Verfügung stehen.
>  
> Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS zu 
> fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem gemountet:
>  
> //192.168.178.24/SmartMeter /mnt/VZ_share cifs 
> username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770
>  0 0
>  
> Anschließen kann der user pi alle Dateioperation auf dem share ausüben 
> (löschen, verschieben, umbenennen,…)
>  
> pi@SmartMeter:/mnt/VZ_share $ ls -l
> insgesamt 4917152
> -rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz
> -rwxrwx--- 1 pi root 1757275296 Dez  1 06:07 VZ-Backup_2020-12-01_0300.img.gz
> -rwxrwx--- 1 pi root  202543104 Nov 29 12:07 VZ_DB_Backup.db3
> -rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 
> VZ-Image_2020-11-21_blank_DB.img.gz
>  
> Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei!
>  
> pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c 
> /etc/dbcopy_sqlite.yaml
>  
> In AbstractSQLiteDriver.php line 39:
>  
>   An exception occurred while executing 'DELETE FROM entities':
>  
>   SQLSTATE[HY000]: General error: 5 database is locked
>  
>  
> In Exception.php line 18:
>  
>   SQLSTATE[HY000]: General error: 5 database is locked
>  
>  
> In PDOConnection.php line 125:
>  
>   SQLSTATE[HY000]: General error: 5 database is locked
>  
>  
> copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] 
> [...]
>  
> Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares 
> ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen 
> Unterschied.
>  
> Hat dazu jemand eine Idee?
>  
> Grüße
>  
> Micha
>

[vz-users] DB Backup auf NAS via sqlite