[vz-users] Fragen zur Datensicherung

Tue Nov 3 15:34:00 CET 2015

Hi,

ich hab das Script incremental_db_backup.sh mal etwas aufgebohrt, 
vielleicht kann es jemand gebrauchen. Es kann jetzt folgendes:

1. Checken ob der PC läuft und ggfs. booten
2. Checken ob MySQL auf dem PC läuft und ggfs. starten
3. mittels DBCopy die Daten inkrementell vom Raspi in die MySQL-DB des 
PCs schieben
4. MySQL und PC wieder runterfahren, falls diese vorher unten waren.

Das Script läuft seit einigen Tage erfolgreich cron gestartet und jetzt 
hab ich ein tägliches Backup der Volkszähler-Daten :-)
Ein log wird nach /var/log/dbcopy/ geschrieben (eventuell vorher anlegen).
Eventuell muß man auf dem Raspi noch wakeonlan installieren. Auf alle 
Fälle muß man am Anfang des Script einige Sachen konfigurieren, steht 
alles drin.

Das System wird mittels leicht angepaßtem sys_backup.sh auf eine am 
Raspi hängende Festplatte gesichert. Ich glaube, das Script war auch mal 
in einem älteren Raspi-Image.

Grüße
Sirko

Am 29.10.2015 um 09:54 schrieb Sirko:
> Hi,
>
> ich nutze auch dbcopy, weil soweit ich weiß mit mysqldump keine 
> inkrementellen Backups gemacht werden können.
> Allerdings waren die dbcopy-Sicherungen eher unregelmäßig und so sind 
> mir ca. 3 Wochen Daten verloren gegangen, als meinem Raspi vor 2 
> Wochen der endgültige SD-Tod ereilt hat.
>
> Bei mir läuft einfach auf meinem Desktop-Rechner ein MySQL als 
> Ziel-DB. Von dort hab ich dann einen Dump gezogen und im Raspi 
> importiert, um die DAten auf einenr neuen SD wiederherzustellen.
>
> Als (hoffentlich in Zukunft täglich laufendes) BackupScript hab ich 
> einfach die Zeilen:
>
> #!/bin/bash
> #
> ##############
> # this script uses dbcopy https://github.com/andig/dbcopy
> # to incrementally backup volkszaehler data to another
> # database
> #
> #
> ##############
>
> # test for running mysql-DB
> connection_error=`nc -z -w5 192.168.178.99 3306;echo $?`
> #echo $connection_error
>
> if [ $connection_error -gt 0 ]
>         then
>                 echo "DB is down, exiting"
>         else
>                 sudo php 
> /var/www/volkszaehler.org/misc/tools/dbcopy.php backup -c 
> /var/www/volkszaehler.org/misc/tools/dbcopy.json
>
> fi
>
> 192.168.178.99 ist dabei die IP meines Desktop-Rechners, die 
> /var/www/volkszaehler.org/misc/tools/dbcopy.jsonmuß natürlich auch 
> richtig konfiguriert werden.
>
> Als Rückmeldung an Andreas: was mir immer auffällt (aber keine 
> Probleme macht), sind die "Division by zero" Meldungen:
> pi at raspberrypi ~ $ bin/incremental_db_backup.sh
> Dropping FK FK_B77949FF72F5A1AA on aggregate
> entities: copying 11 rows (overwrite)
>  11/11 [============================] 100%
>
> properties: copying 95 rows (overwrite)
>  95/95 [============================] 100%
>
> entities_in_aggregator: copying 0 rows (overwrite)
>     0 [>---------------------------]PHP Warning: Division by zero in 
> /var/www/volkszaehler.org/vendor/symfony/console/Symfony/Component/Console/Helper/ProgressBar.php 
> on line 400
> PHP Warning:  Division by zero in 
> /var/www/volkszaehler.org/vendor/symfony/console/Symfony/Component/Console/Helper/ProgressBar.php 
> on line 401
>     0 [>---------------------------]
>
> data: copying 34103 rows (partial copy)
>  [============================] 100%   2 mins/2 mins 34111 rows
>
> aggregate: skipping
> Creating FK FK_B77949FF72F5A1AA on aggregate
>
>
> Allerdings hab ich einen Feature-Request. Währen ich irgendwas an der 
> Raspi-DB mache, wie z.B. einen Index erstellen oder ein mysqldump, 
> wird die MYSQL-DB blockiert und mir gehen Daten verloren, ein Index 
> bauen dauert schonmal 3,5 Stunden.
> Ich habe daher temporär einfach die Middleware umgestellt, daß aller 
> Daten an den Desktop-Rechner gehen, während ich an der MYSQL-DB des 
> Raspis rumspiele. Das funktioniert auch gut. Um mir jetzt aber wieder 
> das Dump-Ziehen vom Desktop und Einspielen in den Raspi zu sparen (was 
> ja auch wieder ewig dauern würde), habe ich das dbcopy umgedreht 
> (source und target in der dbcopy.conf vertauscht) und die in der 
> Zwischenzeit angefallenen Datensätze auf den Raspi übertragen. Das 
> funktioniert auch gut.
>
> Jetzt zum Feature-Request: ich mußte im dbcopy rumpfuschen, damit es 
> mir auf dem Raspi nicht die FKs droppt, weil das Erstellen derselben 
> nach dem dbcopy wieder ewig gedauert hätte.
> Ich hätte daher gern einen Schalter am dbcopy, mit welchem man das 
> Droppen der FKs unterbinden kann. Wäre das möglich, Andreas?
>
> Grüße
> Sirko
>
> Am 29.10.2015 um 08:11 schrieb Andreas Götz:
>> Hi Daniel,
>>
>> Funktioniert dbcopy für Dich? Hab wenig Rückmeldung bekommen...
>>
>> Viele Grüße, Andreas
>>
>>
>>> Am 29.10.2015 um 07:43 schrieb Daniel Lauckner <mailing at jahp.de>:
>>>
>>>> Am Dienstag, 27. Oktober 2015 um 22:37 schrieb Theo:
>>>> Darf ich fragen welches php Script mysql-backup du verwendest?
>>> ~/bin/mysql-backup
>>> Liegt im aktuellen Image hoffentlich noch an der selben Stelle.
>>>
>>>> Würde nicht ein einfaches per cron job gestartetes Shell
>>>> script in dem mysqldump ausgeführt wird reichen?
>>> Ja.
>>>
>>>> Oder liegt das
>>>> daran das ich damit immer nur ein und die selbe Sicherungsdatei
>>>> erstelle und somit immer nur das letzte Backup zur Verfügung habe?
>>> Das php-Script erstellt eine neue Datei mit Datum im Namen.
>>>
>>> Schönheitsfehler vom mysqldump auf dem Raspi ist halt das es die
>>> Datenbank zu sehr stresst und in Folge der vzlogger aus dem
>>> Tritt kommt.
>>>
>>> Deswegen mein Wechsel zu dbcopy.
>>>
>>>> Ich habe hier https://wiki.ubuntuusers.de/MySQL/Backup [...]
>>>> etwas gefunden, da wird ganz
>>>> unten auch ein script vorgestellt mit dem man auch inkrementelle
>>>> Sicherungen anfertigen kann.
>>> Ob bzr eine Alternative ist kann ich leider nicht einschätzen.
>>>
>>>
>>>> Mir geht es darum ob das prinzipiell der richtige Weg ist.
>>> Regelmäßige inkrementelle Sicherung und gelegentlicher Vollabzug
>>> der DB ist fast schon das Optimum.
>>>
>>>
>>> mfg Daniel
>>>
>>>
>>> ---
>>> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
>>> https://www.avast.com/antivirus
>>>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: backup_scripts.zip
Type: application/octet-stream
Size: 2438 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20151103/2682b63c/attachment.obj>