MySQL- Sicherung ohne Passwort im Script

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

folgenden Befehl eingetragen.

Dann wurde eine ~/.my.cnf

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

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

Im Anschluss habe ich ein neues Script mit dem Inhalt

erstellt und dieses mit

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

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.

Autor: Frank Lüttig

Mein Name ist Frank, ich bin 1969 geboren und wohne in Halle (Saale). Ich bin ein technikbegeisterter Linux-User und berichte von Zeit zu Zeit auf intux.de über meine Erfahrungen im Bereich Open Source.

12 Gedanken zu „MySQL- Sicherung ohne Passwort im Script“

  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

    1. A) Welcher konkrete Vorteil für den konkreten Anwendungsfall würde eine andere (welche?) Kompression hier bringen? (Erwäge vor der Antwort auch ihre Nachteile, z.B. „muss erst extra installiert werden = zusätzlicher Angriffsvektor“.)

      1. Da mach ich mir mal den Spaß und schau nach …

        Der letzte Angriffsvektor via BZIP2, was deutlich besser packt als GZIP, war Januar 2017 und dabei mußte man eine manipulierte BZ Datei auspacken und dann gabs auch nur einen DOS des auspackenden Dienstes. Ansonsten geht meine Liste mit Schwachstellen mehrere Jahre zurück und konnte nichts zu Problemen von BZIP2 finden.

        Ergo, keine Bedenken BZIP2 einzusetzen.

        1. Januar 2017 ist immerhin Januar 2017. Wie viel Speicherplatz oder Zeit würde man hier konkret einsparen, um das zu rechtfertigen? „Ist alt“ ist kein Grund.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.