Ich programmiere zugegebener maßen viel und vor allen Dingen auch echt gerne. Ansonsten würde ich wahrscheinlich auch nicht so viel Zeit vor dem PC verbringen. So programmiere ich neben meinem Studium gerade ein kleines privates System, in dem ich allerlei dokumentieren kann, meine GIT-Repositories und deren Commits sehe, meine Steckdosen schalten kann, … -ich schweife ab-.
Das ganze System liegt auf meiner Synology NAS sicher in einem RAID Verbund und werkelt da so vor sich hin. Im Hintergrund läuft eine MariaDB 10, als Datenbank. So kam es dann aber die Tage, dass ich etwas an der Datenbank geschraubt habe -mit glücklicherweise vorigem Backup- und in meiner gnadenlosen Blödheit die Datenbank zerschossen habe. Ohhh Schreck!
Wie bereits angesprochen hatte ich mir zum Glück vorher ein Datenbankdump gezogen, ansonsten wären die Tränen glaube ich in Hülle und Fülle geflossen. Wäre immerhin nicht das erste mal, dass ich versehentlich ne Datenbank zerstöre ;).
Was kann man also dagegen tun?
Drei Möglichkeiten sind mir auf die Schnelle eingefallen.
In regelmäßigen Abständen manuell in die Oberfläche von phpMyAdmin gehen wäre mir zu aufwendig und mal ganz unter uns: Nach spätestens dem Dritten mal vergisst man es dann doch wieder.
Ein Automatismus muss also daher! Wäre da noch die Möglichkeit sich einen Export der DB per PHP zu schreiben. Ich meine, wenn die Daten eh alle dort verarbeitet werden, warum dann nicht alle Datenbankobjekte auslesen und als JSON unterspeichern? War mir dann aber im Endeffekt nach 10min Überlegung und Suche auf Stack Overflow zu viel Arbeit und vor allem zu unsicher.
Die Lösung
Die Lösung liegt eigentlich direkt auf der Hand. Sowohl ein MySql Server, als auch eine MariaDB pflegen es ein kleines Programm mitzuliefern, mit Hilfe dessen man einen Datenbankdump ziehen kann. Schön, dass ich da als Erstes dran denke xD.
Naja. Nach kurzer Suche wurde ich dann fündig. (Hier im Wiki)
Leider hat das Ganze nicht so wirklich geklappt, um nicht zu sagen: Das Script funktioniert schlichtweg nicht!
Mich hat dann aber der Ehrgeiz gepackt und eine geschlagene halbe Stunde hat es gedauert, bis sich herauskristallisiert hat, dass der Pfad “/usr/syno/mysql/bin/mysqldump” schlichtweg falsch ist!
Weiterhin ist das Bash-Script etwas … naja … unpraktikabel anzupassen.
Das Script
Gut. Genug gelesen und um den heißen Brei herum geschwafelt.
Anbei mein Bash Script, welches ihr irgendwo auf eurer Synology NAS, mit dem Namen “mysqlbackup.sh”, abspeichern müsst:
#!/bin/bash
DIR=[BACKUP-ORDER-PFAD]
DATESTAMP=date +%Y%m%d%H%M%S
DB_USER=[SQL-ROOT-USER]
DB_PASS=[SQL-ROOT-PASSWORT]
# Erstelle Ordner, falls dieser nicht existiert
mkdir -p ${DIR}
# erstelle dump tabellen in gzip
FILENAME=${DIR}mysqldump-${DATESTAMP}.gz
/usr/local/mariadb10/bin/mysqldump -u $DB_USER -p$DB_PASS --opt --all-databases --flush-logs | gzip > $FILENAME
Ersetzt einfach [BACKUP-ORDER-PFAD] mit dem Pfad, an dem der Datenbankdump auf eurer Synology NAS geschrieben werden soll. Achtet auf ein führendes und schließendes “/”.
Ersetzt anschließend [SQL-ROOT-USER] und [SQL-ROOT-PASSWORT] durch die Zugangsdaten eines MariaDB Nutzers, der Zugriff auf ALLE Datenbanktabellen hat. Das muss nicht unbedingt der Root-User sein.
Den Pfad herausfinden
Den Pfad zum Bash-Script (später für den Cronjob benötigt) findet ihr heraus, indem ihr zu der entsprechenden mysqlbackup.sh-Datei im Dateiexplorer navigiert und dann über Rechtsklick + Eigenschaften den Pfad anzeigen lasst. Selbiges Spiel können wir spielen, um den Pfad für den Ordner zu finden, in welchem die Backups dann später abgelegt werden sollen. Ergo der zu ersetzende [BACKUP-ORDNER-PFAD] im Script.
Cronjob einrichten
Noch haben wir es nicht ganz geschafft. Wir müssen das Script noch in bestimmten Intervallen automatisch ausführen. Ansonsten hätten wir uns die Mühe ja nicht machen brauchen und gleich die Backup-Funktion von phpMyAdmin nutzen können. Um einen Cronjob einzurichten müsst ihr euch als Admin in DSM einloggen und in den Einstellungen folgende Schritte vollziehen:
Übrigens:
Das Programm “HyperBackup” von Synology hätte das auch ohne den ganzen Firlefanz getan. Installieren, konfigurieren, fertig!
Es hätte so einfach sein können, aber Hyper Backup, wäre dann doch ein wenig zu viel des Guten, für einen einfachen SQL Datenbankdump. Immerhin zieht das Ganze auch wieder Leistung und damit Performance der Synology Nas.
Hi Marvin, super Idee und im Prinzip sehr einfach. Aber...als noob verstehe ich ein paar Sachen nicht.
- Pfadangabe in der mysqldump.sh: "Dir = /volume1/web/xyz-ordner/"
Ein Beispiel wäre da super.
- beim Cronjob schreibst Du im letzten Satz: " sh [PFAD_ZUM_SH_SKRIPT]/mysqlbackup.sh" Aber das script heißt doch mysqldump.sh
Wäre die richtige Pfadangabe /bash? oder /volume1?
Also "sh /volume1/web/xyz-ordner/mysqldump.sh".
Ich habe schon alles ausprobiert, aber es funktioniert leider nicht.
Wäre super, wenn Du mir zurückschreiben könntest :-)
greets Torsten
Hättest Du auch ein Script zum hochladen. Ich würde gerne meine Kodi-DB auf dem einen Nas sichern und auf das andere Nas als Backup hochladen.
Jörg
Hallo Torsten,
leider war ich das Wochenende über nicht aktiv dabei. Ich werde den Artikel heute Abend um deine Anmerkungen erweitern und noch einmal Bescheid geben, sollte der Artikel angepasst worden sein.
Gruß
Hi
Do you think hyperbackup does the same thing...i mean does it also backsup the databases as well?
Hi Danny,
yes HyperBackup is also capable of creating a database backup. Unfortunately you have to restore it via HyperBackup, so you will lose the flexibility to import it into every non Synology database.
Hi Marvin,
super gelöst das Problem.
Habe es jetzt auch in Benutzung.
Muss aber leider sagen, dass die Deklaration von DATESTAMP in deinem Script fehlt.
Ich habe das so gelöst: DATESTAMP=`date '+%Y%m%d%H%M%S'`