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
|
1 |
crontab -e |
folgenden Befehl eingetragen.
|
1 |
0 2 * * * /home/user/MySQLscript.sh |
Dann wurde eine ~/.my.cnf
|
1 |
nano ~/.my.cnf |
mit entsprechendem Inhalt erstellt. Diese enthält das MySQL root Passwort.
|
1 2 3 |
[client] user=root password=meinpasswort |
„meinpasswort“ musste hier natürlich angepasst werden. Nach dem Abspeichern wurden der Datei die Rechte 600 vergeben.
|
1 |
chmod 600 ~/.my.cnf |
Im Anschluss habe ich ein neues Script mit dem Inhalt
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
#!/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
|
1 |
chmod +x ~/MySQLscript.sh |
ausführbar gemacht. Um die Datenbanken besser auseinander halten zu können, bekamen alle Datenbanken dieses Mal ein separates Verzeichnis.
|
1 |
cd /samba_share/backup |
|
1 |
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.
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
Never change a running Dingens. MyDumper macht im Prinzip auch nichts richtiger als mysqldump.
s/change/touch/
MyDumper parallelisiert das Backup und macht es damit deutlich schneller als mysqldump, was zu weniger Locks auf der Datenbank führt.
Das würdest du in einem Script auch hinbekommen, Parallelität kann ja sogar die poplige Linuxshell (bis zu einem gewissen Grad).
Mehrere Datenbanken parallel zu exportieren, ist einfach; eine einzelne Datenbank und Tabellen(teile) parallel exportieren nicht.
Danke für die Tipps, Dirk. ????
Sehr gerne!
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
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“.)
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.
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.
Mit bzip2 bist du aber auch nicht mehr ganz auf der Höhe. (https://www.kernel.org/happy-new-year-and-good-bye-bzip2.html)
Die coolen Kids nutzen LZMA (https://de.wikipedia.org/wiki/Lempel-Ziv-Markow-Algorithmus) in Form von: https://en.wikipedia.org/wiki/Xz
Siehe auch: Statistiken (https://catchchallenger.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO)
Nichts zu danken, tschüss!
In meinen alten Mails deinen Kommentar gefunden und mal getestet, bringt in einer Joomla DB knapp 5% weniger Dumpsize. Danke für die Info, das kannte ich bis dato auch nicht.
Gegenfrage: Was spricht gegen eine Loginfile die nicht lesbar ist für den Otto Normal User -> https://opensourcedbms.com/dbms/passwordless-authentication-using-mysql_config_editor-with-mysql-5-6/
[…] Backup der Datenbank eingespielt (zum Glück werden Backups der Datenbanken, wie im Artikel „MySQL- Sicherung ohne Passwort im Script“ beschrieben, täglich automatisch angelegt). Nach dem Einspielen stellte sich heraus, dass […]