Datenbank-Backup mit dem MySQLDumper

Ich hab heute mal eine „hübsche“ Backup & Restore Lösung gesucht, mit der ich automatisiert DB-Backups machen kann und in einer Weboberfläche die einzelnen Backups auch wiederherstellen kann.

Diese Idee hatte ich offensichtlich nicht alleine. Nach kurzer Suche stieß ich auf den MySQLDumper. Dieser ermöglicht all die gesuchten Features und noch ein wenig mehr. Ich hab hier mal einen kleinen Auszug der aktuellen Version 1.24 zusammengestellt:

  • Dialoggestützte Installation
  • Backup per PHP und Perl möglich (gerade wichtig bei Script-Timeouts in großen Datenbanken)
  • Benachrichtigung per E-Mail über ein erfolgtes Backup (da kann man sich sogar das Backupfile zusätzlich im Anhang schicken lassen)
  • Multi-Part-Backups für große Datenbanken möglich
  • Kopieren der Backups auf bis zu 3 FTP-Server
  • eigene SQL-Befehle vor und nach einem Backup datenbankbezogen einstellbar
  • hübsches Webinterface

Natürlich bietet der MySQLDumper noch weitere Dinge, aber da könnt ihr euch auch einfach auf der Funktionsübersicht dazu informieren.

Best Practices im eigenen Einsatz

Bei einem unserer Kundenserver hab ich den MySQLDumper jetzt mal installiert und einen Cronjob aufgesetzt, der allmorgentlich ein DB-Backup von allen Datenbanken anlegt. Als Einstellungen hab ich folgende getroffen:

  • E-Mail-Benachrichtigung: ja
  • Backup aller Datenbanken
  • FTP-Server werde ich dann morgen einrichten, nachdem ich morgen mal das Restore testen werde

Im Vorfeld hab ich noch einen eigenen Nutzer für den MySQLDumper angelegt in der Datenbank, damit dort nichts schlimmes passieren kann. Also grundsätzlich darf der Nutzer nur LOCK TABLES und SELECT Statements absetzen. Außerdem werde ich noch prüfen, ob er für den Restore-Vorgang noch weitere Rechte benötigt. Diese Rechte hab ich dann global gesetzt, damit ich nicht für jeden neue Kundendatenbank etwas tun muss. Der MySQLDumper sucht sich nämlich selbständig alle verfügbaren Datenbanken.

Alles in allem ein gutes Tool. Ob es in einem Live-Szenario durchhalten wird, wird sich zeigen. Es macht aber bisher einen sehr guten Eindruck.

Habt Ihr schon irgendwelche Erfahrungen mit dem MySQLDumper? Egal ob gute oder schlechte…dann kommentiert diesen Beitrag doch bitte.

7 Gedanken zu „Datenbank-Backup mit dem MySQLDumper

  1. Schöner Artikel. 😉
    Anmerkung: für die Wiederherstellung benötigt der MySQL-User noch Rechte für CREATE und INSERT. Wenn Du Felder in der Defintion im SQLBrowser verändern willst, wäre das Recht für ALTER auch notwendig.

  2. Ja, die Rechte für CREATE und INSERT hab ich ebenfalls gegeben. Allerdings hab ich kein ALTER erlaubt, weil ich für Veränderungen an der Datenbank immer nur phpMyAdmin oder Konsole verwende. Ich will den MySQLDumper eigentlich vorrangig für Backup und Restore nutzen.

  3. Also die Ausführung per Cronjob hat wunderbar geklappt. Aber die neu angelegte Datenbank wurde nicht automatisch mit gesichert. Sie ist im MySQLDumper nicht ersichtlich, obwohl der DB-Nutzer des MySQLDumper diese Datenbank sehen kann…also im phpMyAdmin kann er darauf zugreifen. Scheinbar funktioniert das neueinlesen nicht korrekt. Das ist schade, weil ich dann erneut neue Datenbanken manuell dem Backup-Prozess zuführen muss 🙁

  4. Wenn neue Datenbanken hinzukommen, muss man im Dumper einmal auf „Datenbanken neu laden“ klicken und die Konfiguration einmal abspeichern, damit er „Wind“ davon bekommt, dass sich etwas geändert hat. Wenn Du im Dumper selbst neue Datenbanken anlegst, merkt er es natürlich sofort. Wenn aber von außerhalb Änderungen eintreten, muss man es dem Dumper mitteilen.

    Dieser Umstand ist den Hostern gezollt, die den MySQL-Usern ihrer Kunden nicht das Recht für SHOW DATABASES einräumen. In künftigen Versionen wollen wir hier aber Abhilfe schaffen und ein optionales Neu-Erkennen aller Datenbanken ermöglichen. Erste interne Umstrukturierungen sind in der Entwicklerversion bereits getätigt. Wir müssen ja auch noch etwas zum Verbessern haben. 😉

  5. Okay, das hatte ich gemacht (heute Morgen). Allerdings wurde da die neue Datenbank nicht angezeigt. Nach erneutem Login (jetzt gerade) wurde dann die Datenbank angezeigt. Ich hab dann gespeichert.

    Was mir auch auffiel: es werden keine E-Mails verschickt von dem Perl-Skript. Ich verwende die Variante mit sendmail und diverse Applikationen auf dem Server versenden ebenfalls mit sendmail. Es wird wahrscheinlich am Perl liegen, denn das Backup per PHP verschickt ordnungsgemäß. Das ist nur ein kleines Manko, aber bei der Verwaltung von mehreren Servern wäre es schon schön.

    BTW: Gibt es die Möglichkeit mehrere Server mit einer MySQLDumper-Instanz zu verwalten? Bei phpMyAdmin finde ich das ganz toll 😉
    Damit es auch noch etwas zu verbessern gibt…oder regelt das die Konfiguration?

  6. Das entwickelt sich langsam zu einem Support-Thread. Komme dazu besser in unser Support-Board unter http://forum.mysqldumper.de . Dort sind alle Fragen bereits ausführlich beantwortet.
    Perl und Email: http://forum.mysqldumper.de/post7705.html#t7705
    Mehrere MySQL-User und/oder Server können über verschiedene Konfigurationsprofile innerhalb einer MSD-Installation verwaltet werden. Nach dem Anlegen einer neuen Konfigurationsdatei kann man alle Angaben zu Host und User individuell anpassen. Beim Aufruf des Perkskripts übergibt man die zu benutzende Konfigurationsdatei als Parameter.

Kommentare sind geschlossen.