MySQL- Sicherung ohne Passwort im Script

15
982
Tumisu / Pixabay

Nach dem ich nun nieder geschrieben hatte, wie ich meine SQL-Datenbanken automatisch sichere, kamen einige gute Anregungen in den Kommentaren. Darauf hin habe ich das System etwas umgestellt. Dazu wurde zu allererst der Storage vom root auf einen User übertragen. Somit konnte ich auch den Cronjob für den User einrichten. Der Eintrag, wie im ersten Artikel “MySQL-Sicherung” in /etc/crontab wurde wieder entfernt. und der Cron neu gestartet.

Als eingeloggter User habe ich dem selbigen mit

crontab -e

folgenden Befehl eingetragen.

0 2 * * * /home/user/MySQLscript.sh

Dann wurde eine ~/.my.cnf

nano ~/.my.cnf

mit entsprechendem Inhalt erstellt. Diese enthält das MySQL root Passwort.

[client]
user=root
password=meinpasswort

“meinpasswort” musste hier natürlich angepasst werden. Nach dem Abspeichern wurden der Datei die Rechte 600 vergeben.

chmod 600 ~/.my.cnf

Im Anschluss habe ich ein neues Script mit dem Inhalt

#!/bin/sh
mysqldump in********** | gzip > /samba_share/backup/in**********/in**********-$(date +%Y-%m-%d).sql.gz
mysqldump cc********** | gzip > /samba_share/backup/cc**********/cc**********-$(date +%Y-%m-%d).sql.gz
mysqldump bc********** | gzip > /samba_share/backup/bc**********/bc**********-$(date +%Y-%m-%d).sql.gz
mysqldump kt********** | gzip > /samba_share/backup/kt**********/kt**********-$(date +%Y-%m-%d).sql.gz
mysqldump wo********** | gzip > /samba_share/backup/wo**********/wo**********-$(date +%Y-%m-%d).sql.gz
mysqldump ne********** | gzip > /samba_share/backup/ne**********/ne**********-$(date +%Y-%m-%d).sql.gz
mysqldump cy********** | gzip > /samba_share/backup/cy**********/cy**********-$(date +%Y-%m-%d).sql.gz
mysqldump pe********** | gzip > /samba_share/backup/pe**********/pe**********-$(date +%Y-%m-%d).sql.gz
mysqldump ma********** | gzip > /samba_share/backup/ma**********/ma**********-$(date +%Y-%m-%d).sql.gz
mysqldump pr********** | gzip > /samba_share/backup/pr**********/pr**********-$(date +%Y-%m-%d).sql.gz
mysqldump ro********** | gzip > /samba_share/backup/ro**********/ro**********-$(date +%Y-%m-%d).sql.gz
mysqldump bcc********* | gzip > /samba_share/backup/bcc*********/bcc*********-$(date +%Y-%m-%d).sql.gz
mysqldump pi********** | gzip > /samba_share/backup/pi**********/pi**********-$(date +%Y-%m-%d).sql.gz

erstellt und dieses mit

chmod +x ~/MySQLscript.sh

ausführbar gemacht. Um die Datenbanken besser auseinander halten zu können, bekamen alle Datenbanken dieses Mal ein separates Verzeichnis.

cd /samba_share/backup
mkdir in********** cc********** bc********** kt********** wo********** ne********** cy********** pe********** ma********** pr********** ro********** bcc********* pi**********

Nun werden die Datenbank-Sicherungen jeden Morgen 2:00 Uhr in von einander getrennten Verzeichnissen komprimiert abgelegt.

Der Servercow-Storage wurde mit der Nextcloud-App “External Storage” in die Cloud eingebunden und die Sicherungen landen so regelmäßig auf meinem Notebook.

15 Kommentare

  1. Erlaube mir drei Anmerkungen:

    Ein Backup-Skript muss nicht mit root-Rechten in der Datenbank laufen. Ich empfehle einen User anzulegen, der nur wenige Rechte im Datenbanksystem hat. Bei mir gibt es einen Backupuser mit den Privilegien SELECT, SHOW DATABASES, LOCK TABLES für jede Datenbank.

    Wenn Du eine neue Datenbank anlegst, musst Du das Backup-Skript anpassen. Da wäre es eleganter, die Namen der Datenbanken direkt bei MySQL abzufragen und zu verwenden. Dazu kann der Aufruf von ‘mysqlshow’ helfen.

    Daraus ergibt sich eine einfache Schleife: ‘ for db in $(mysqlshow -u backup -p PASSWORD | awk ‘! /Databases|–/ {print $2}’)

    Alternativ und vielleicht die beste Lösung ist es, MyDumper zu verwenden: https://github.com/maxbube/mydumper

  2. Moin, sorry, das muß leider sein :

    A) gzip ist veraltet, was das packen von Texten betrifft, da hilft auch die fehlende -9 Option nicht mehr.
    B) was für eine Parallelität ? Die würde auch keinen Vorteil haben, außer das die ganze DB steht, weil allein der dann chaotische DISK IO, der entsteht, weil die interne RAM Cache vom mysqld nicht mehr genutzt werden können, würde das inneffektiv machen.

    C) Datenbanknamen kann man auch direkt aus /var/lib/mysql ziehen, jede db hat ein directory, egal welche engine im Einsatz ist.. nur mal so erwähnt, weil wo die Namen herkommen nicht wichtig ist.
    D) fehlt da offensichtlich der Notfallcheck, daß die db (warum auch immer) blockiert ist und der dump deshalb failed, was dazu führt, daß der Fallbackmechnismus nicht angetriggert wird.
    E) Du merkst nicht mal, daß was failed, weil das Fire&Forgetcode ist -> Fehlerfestellung/behandlung
    F) der eingesetzte mysqldump Befehl ist fachlich falsch eingesetzt, damit ist ein korrektes Backup so gar nicht möglich. “man mysqldump” wäre ein Anfang, ist aber schon fast ne Wissenschaft für sich, daher nimm den hier :

    https://marius.bloggt-in-braunschweig.de/2016/04/29/solution-mysqldump-no-database-selected-when-selecting-the-database/

    Fazit: stark verbesserungswürdig.

    Als Grundlagenidee ok, aber so bitte nicht produktiv einsetzen. Ein Backup muß auch die Bedingung erfüllen, daß man die Daten daraus ohne Aufwand wieder herstellen kann. Weiterhin müssen Fehler einkalkuliert sein, was Überwachung und Eskalation beinhaltet. Da muß man dann das Backup auch mal auf einem Zweitsystem einspielen und sehen obs danach problemlos läuft. Wenn Du eine Shopware oder Magentoinstanz mit Deinem Ansatz sicherst, kann man das Ergebnis vorwegnehmen, weil im Backup schlicht nicht alles drin ist.

    Tipp: C+D zusammen sind Teil der Lösung

    Lektion 2 : crontab -e -u USERNAME

Schreibe einen Kommentar zu Lord_Pinhead Antwort abbrechen

Bitte bestätige diesen Kommentar!
Bitte den Namen hier eingeben

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.