MySQL-Datenbanken automatisch sichern mit MySQLDumper und all-inkl als Hoster

Ich hatte hier vor einiger Zeit in einem Artikel über das geniale Tool MySQLDumper zum komfortablen Sichern von MySQL-Datenbanken auf gehostetem Webspace berichtet.

Ich selbst bin seit ca. einem 3/4 Jahr zufriedener Kunde bei all-inkl. Viele positive Berichte im Netz, die preisgünstigen und trotzdem leistungsfähigen Tarife und der bisher immer schnelle und unkomplizierte Support haben mich überzeugt. Ein kleiner Wermutstropfen war dabei bisher, dass beim Anlegen von MySQL-Datenbanken in der all-inkl Administration jeweils nicht nur wie üblich einen neuen Datenbanknamen unter einem vorhandenen Datenbanknutzer erhalten, sondern zu jeder einzelnen Datenbank auch ein neuer Datenbanknutzer angelegt wird. So hat man ggf. 20 MySQL-Datenbanken und die dazugehörigen 20 MySQL Benutzer. Diese Tatsache ist zwar für die weitere Nutzung der Datenbanken unerheblich, aber MySQLDumper ging bisher immer davon aus, dass es wie üblich nur einen Nutzer und mehrere Datenbanken gibt, so dass die Backupverwaltung mit MySQLDumper für all-inkl Kunden mit mehreren Datenbanken bisher etwas mühselig war.

Mittlerweile ist dieses Manko aus der Welt, denn mit der neuen Version (1.23 pre-release) lassen sich mit mein Lieblingstool MySQLdumper nicht nur die verschiedene Datenbanken für einen Datenbankbenutzer auswählen, sondern Konfigurationsdateien für unterschiedliche Datenbankbenutzer anlegen, so dass man auch zwischen diesen einfach hin- und herwechseln kann. Ich habe gleich eine Anleitung für die Einrichtung dieses neuen Features und die Einrichtung automatisierter Backups mit all-inkl als Hoster erstellt.

Update April 2011: Da meine Anleitung etwas in die Jahre gekommen ist, es mittlerweile eine neuere MySQLDumper Version gibt und mein Hostingbedarf über das all-inkl Angebot hinausgewachsen ist, so dass ich dort kein Kunde mehr bin, freue ich mich, dass sich Jens vom kochsiek.org Blog die Mühe gemacht hat eine aktualisierte Version zu erstellen: “MySQLDumper mit Cronjob bei All-Inkl einrichten“. Meine Version ist wohl immer noch verwendbar, aber bei ihm finden sich aktuellere Screenshots. [Ende Update]

Informationen zur generellen Installation und Einrichtung finden sich auf der MySQLDumperwebsite und in dem deutschsprachigen Support Forum, so dass ich darauf nicht eingehe.

Falls man MySQLDumper später für automatische Backups nutzen möchte, sollte man vor dem Anlegen der Konfigurationsdateien das Perlscript passend konfigurieren, da man sonst später bei allen Konfigurationsdateien die Angabe zur Lage der Perldateien ändern muss. D.h. in diesem Fall besser mit dem zweiten Teil der Anleitung beginnen.

 

1. Einrichten mehrerer Konfigurationen in MySQLDumper für all-inkl

 

Zum Anlegen dieser Konfigurationsdateien wechselt man unter dem Menüpunkt Konfiguration …

in das Untermenü Konfigurationsdateien:

Dort lässt sich eine neue Konfigurationsdatei anlegen, indem man einen passenden Namen eingibt und speichert. Allerdings wird dabei die aktuelle Konfiguration übernommen:

Um nun einen anderen Datenbanknutzer anzugeben, muss unter “Datenbanken” (1.) auf Verbindungsparameter “ein-/ausblenden” (2.) geklickt werden:

Unter 1. ist hier der für die gewünschte Datenbank zugehörige Nutzername einzutragen (findet sich in der all-inkl Administration unter dem Menüpunkt Datenbanken und ist identisch mit dem Datenbanknamen). Unter 2. trägt man das zu dieser Datenbank gehörige Passwort ein:

Jetzt speichern wir die Parameter:

Wenn wir jetzt zu den Konfigurationsdateien zurückkehren …

… können wir feststellen, dass bei unserer neuen Konfiguration unter

zu sichernde DBs (PHP): XXXXXXX und unter
zu sichernde DBs (PERL): YYYYYYY

noch verschiedene Datenbanken stehen. Ein weiterer Klick auf “Speichern” sorgt dafür, dass bei beiden dieselbe Datenbank eingetragen ist.

Diese Prozedur führt man für jede Datenbank durch, so dass man am Ende durch einfache Auswahl der passenden Konfiguration im Dropdownmenü sofort den passenden Zugriff auf die gewünschte Datenbank hat:

 

2. Automatisiertes Backup mit dem Perl-Script bei all-inkl

 

Nachdem dies nun problemlos funktioniert, wollte ich unbedingt dafür sorgen, dass das Backup meiner Datenbanken automatisch per Cronjob ausgeführt wird. Hierfür bringt MySQLDumper ein passende Perl Scripte mit, die in dem Ordner “msd_cron” liegen.

Es gibt sowohl in der MySQLDumper Hilfe als auch in dem Beitrag “Features Perl Cronscript (Einstellungen von Konfiguration / Cron)” im MySQLDumper Support Forum ausführliche Informationen zur Einrichtung des Perl Scripts. Zu meiner eigenen Gedächtnisstütze werde ich hier den Einrichtungsvorgang für mich mitprotokollieren.

Wähle im Menü “Backup” …

und klicke auf Backup Perl:

Kopiere die Pfadangabe hinter “Eintrag in crondump.pl für absolute_path_of_configdir” (A)

und öffne das Skript “crondump.pl” (liegt in dem Ordner “msd_cron”) in einem Editor.

Suche die Zeile my $absolute_path_of_configdir=”" und setze den Cursor zwischen die “” und füge den kopierten Pfad ein. Anschließend speicherst Du die geänderte Datei “crondump.pl”.

(An dieser Stelle hatte ich kurzfristig ein paar Schwierigkeiten von den Du bei Interesse weiter unten mehr erfährst.)

Jetzt legst Du einen Ordner mit der Bezeichnung “cgi-bin” im MySQLDumperverzeichnis an.

(Nachtrag: ich will an dieser Stelle auf einige hilfreiche Kommentare weiter unten hinweisen: einerseits scheint es so zu sein, dass der “cgi-bin” Ordner grundsätzlich neu im Hauptverzeichnis der Domain angelegt werden muss. Ein Anlegen in Unterverzeichnissen oder ein Kopieren des Ordners aus einem anderen Verzeichnis in das Hauptverzeichnis scheinen die Ausführung von Perlscript nicht zu ermöglichen. Darüber hinaus gibt es wohl auch Hostingpakete bei denen all-inkl Perl erst aktivieren muss. Genaueres findet ihr in den Kommentaren weiter unten oder indem ihr den all-inkl Support befragt.)

In diesen Ordner kopierst Du das Skript “crondump.pl” sowie die beiden Testskripte “perltest.pl” und “simpletest.pl” per Ascii-Modus (sollte jeder einigermaßen ausgereifte FTP-Client schaffen).

Änder die Dateirechte des Ordners und aller darin befindlichen Skripte per chmod auf 755.

Im MySQLDumper wechselst Du in der “Konfiguration” zum Untermenü “Cronscript”:

Dort trägst Du unter “Pfad der Perskripte” den Pfad zu dem neuen Ordner “cgi-bin” ein:

… und speicherst diese Einstellung …

Jetzt kannst Du auf “Backup” wechseln …

… und dort oben auf “Backup PERL” klicken:

Hier prüfst Du nun die Lauffähigkeit mit 1. “Perl testen”. Wenn die Meldung “Wenn Du das siehst, funktioniert Perl auf Deinem System !” erscheint ist alles in Ordnung.

Mit Hilfe von 2. “Perl-Module testen” kannst Du feststellen, ob alle benötigten Module bei dem Hoster verfügbar sind und funktionieren (ist bei meinem all-inkl Tarif der Fall).

Als letzten Schritt kannst Du über 3. “Perl-Cronscript ausführen” das Perl Backup manuell starten und so manuell testen, ob es funktioniert.

Bisher funktionieren diese Backups bei mir mit meinem all-inkl Webspace mit kleineren Datenbanken zwischen 3 und 5 MB. Es gibt allerdings Meldungen von all-inkl Nutzern bei denen das Perl Script vorzeitig abbricht. Ein kurzer Test mit einer 30 MB großen Datenbank scheiterte zumindest beim Emailversand.

Genauer läßt sich das über die Log-Dateien verfolgen, die Du unter “Log” …

… und “Perl-Log” oder “Perl-Complete Log” einsehen kannst (diese findest Du auch als komprimierte Dateien im Unterordner “/work/log”):

Wenn Perl Script ausführen erfolgreich verlief, testest Du am besten den Link unter B:

Die URL, die aufgerufen wird sieht ungefähr so aus: “http://www.meinedomain.de/cgi-bin/crondump.pl?config= mysqldumper.conf.php”, wobei hier der passende Domainname steht und hinter “…?config=” der Name der Konfigurationsdatei, die für das Backup genutzt werden soll (diese sind in dem Unterordner “/work/config” zu finden und entsprechen dem Namen der jeweiligen Konfiguration plus der Endung “.config.php”).

Die Linkangabe kopierst Du in die Zwischenablage und dann in die Adresszeile Deines Browsers. Nach “Enter” sollte, wenn alles passt, ebenfalls der Backupprozess problemlos ablaufen (ggf. werden Dein Verzeichnisbenutzername und -passwort vorher noch abgefragt). Wenn dieser Test auch erfolgreich verlaufen ist, dann kann Du den passenden Cronjob erstellen. Entweder direkt im Members Bereich bei all-inkl oder, falls keine Cronjobs in dem genutzten Tarif enthalten bzw. keine mehr übrig sind, bei einem externen Dienstleister wie z.B. Cronjob.de .

Einen Cronjob bei all-inkl erstellen

Wenn Dein all-inkl Tarif Cronjobs erlaubt, so kannst Du diese nicht im KAS verwalten sondern im all-inkl Members Bereich.

Dort klickst Du dann auf …

… und gelangst so in folgende Übersicht:

Nach Klick auf “… neuen Cronjob einrichten.” gelangst Du auf die Konfigurationsseite. Dort trägst Du als erstes den Link (wie oben unter B) für den externen Cronjob ein. WICHTIG: für all-inkl musst Du das “http://” am Anfang weglassen !

Da Du Dich natürlich an die Sicherheitsempfehlung des MySQLDumpers gehalten hast, hast Du einen Verzeichnisschutz eingerichtet. Daher musst Du nun den passenden Benutzernamen und das Passwort eintragen, damit der Cronjob durch den Verzeichnisschutz kommt:

Im folgenden kannst Du das Intervall für den Cronjob bestimmen:

ACHTUNG 1: Neueinrichtungen und Änderungen werden teilweise erst nach 30 Minuten aktiv. D.h. wenn Du Deine Startzeit zu kurz ansetzt, wird der Cronjob erst beim nächsten Intervall ausgeführt bzw. mit angepassten Einstellungen ausgeführt):

ACHTUNG 2: Wenn Du das Intervall eines bereits bestehenden Cronjobs ändern willst, musst Du unbedingt darauf achten, dass Du einen Haken in das Kästchen “Aktivieren Sie dieses Kästchen, wenn Sie die Ausführzeit ändern möchten.”, dass dann oberhalb des Blocks eingeblendet wird, setzt. Wenn Du das (wie ich es erstmal getan habe) vergisst, dann ändert sich nix an dem Intervall und Du rätzelst lange herum warum es nicht funktioniert .

Hier kannst Du Dir noch eine Emailbenachrichtung zusenden lassen, die Dich über die ausführung des Cronjobs informiert und alle Ausgaben des Perl-Scrips enthält:

Nun speicherst Du Deine Einstellungen:

Prüft bitte regelmäßig, ob die Backups auch vollständig und im Ernstfall nutzbar sind!!!

Nichts ist schlimmer als sich in falscher Sicherheit zu wiegen!

MySQL-Datenbankbackup per Email zusenden lassen

Falls man sich die Datenbank per Email zusenden lassen will, so läßt sich dies in der “Konfiguration” unter “Email” einrichten:

Hier gibt man an alle nötigen Daten ein. Bei mir funktionierte die Einstellung “SMTP” unter “Mailprogramm”. Sendmail klappte nicht, was aber auch an einer fehlerhaften Pfadangabe liegen könnte (Nachtrag: holger meldete in den Kommentaren, dass bei ihm Sendmail mit folgender Pfadangabe funktioniert: “/usr/sbin/sendmail”):

Wer sich häufiger Backups erstellen lässt, sollte eventuell unter “Konfiguration” > “automatisches Löschen” dafür sorgen, dass nicht zu viele Backups auf dem Server liegen bleiben. Dann auch wenn das Backup per Email versandt wird, so werden die Backupdateien vorher im Ordner “/work/backup” erstellt.

… so, jetzt erhalte ich regelmäßig automatisch die Backups meiner wichtigsten Datenbanken per Email zugesandt … und kann ruhiger schlafen !!!

Allerdings klappt bei mir der Emailversand nicht mit einer Datenbank über 10 MB!

Falls Ihr von MySQLDumper genauso begeistert seid wie ich, denkt an eine kleine Spende für die Entwickler, die eine Menge Zeit, Energie und Nerven in die Entwicklung des Programms und den Support stecken: klick!

Für Interessierte noch eine kurze Beschreibung meines bei der Einrichtung des automatisierten Backups aufgetretenen Problems:

Kurze Erläuterung des bei mir aufgetretenen Problems

Da ich keine besonderen Informationen zur Nutzung von Perl bei all-inkl gefunden hatte, nahm ich an, dass die Scripte überall laufen. Ich erhielt beim Testen der Scripte allerdings immer die Meldung “You don’t have permission to access /xxxxx/msd_cron/perltest.pl on this server.”. Diese Meldung kann durch falsch gesetzte Rechte (CHMOD) entstehen. Nachdem ich diese Fehlerquelle ausgeschlossen hatte, suchte ich nach anderen Fehlerquellen. Da laut Support Forum diese Meldung auch durch einen vorzeitigen Abbruch des Perl Scripts erscheinen kann, wenn der Hoster ein zu knappes Zeitlimit für Perlscripte gesetzt hat und dies in Zusammenhang mit all-inkl zumindest in einem Foreneintrag gemeldet wurde.

Allerdings machten mich zwei Dinge stutzig: Erstens, dass die Fehlermeldung mit dem fehlenden Zugriffsrechten immer sofort erschien und nicht erst nach einer oder mehreren Sekunden und zweitens, dass ich keine Logdateien (“mysqldump_perl.log.gz” und “mysqldump_perl.complete.log.gz”) für das Perlscript im Unterordner “/work/log” finden konnte.

Nach einigem Googeln und Recherchieren kam ich dann auf die Idee doch einen eigenen “cgi-bin” Ordner für die Perl Scripte anzulegen und siehe da, es funktionierte auf einmal !

Ich hatte hier vor einiger Zeit in einem Artikel über das geniale Tool MySQLDumper zum komfortablen Sichern von MySQL-Datenbanken auf gehostetem Webspace berichtet. Ich selbst bin seit ca. einem 3/4 Jahr zufriedener Kunde bei all-inkl. Viele positive Berichte im Netz, die preisgünstigen und trotzdem leistungsfähigen Tarife und der bisher immer schnelle und unkomplizierte Support haben mich überzeugt. Ein kleiner Wermutstropfen war dabei bisher, dass beim Anlegen von MySQL-Datenbanken in der all-inkl Administration jeweils nicht nur wie üblich einen neuen Datenbanknamen unter einem vorhandenen Datenbanknutzer erhalten, sondern zu jeder einzelnen Datenbank auch ein neuer Datenbanknutzer angelegt wird. So hat man ggf. 20 MySQL-Datenbanken und die dazugehörigen 20 MySQL Benutzer. Diese Tatsache ist zwar für die weitere Nutzung der Datenbanken unerheblich, aber MySQLDumper ging bisher immer davon aus, dass es wie üblich nur einen Nutzer und mehrere Datenbanken gibt, so dass die Backupverwaltung mit MySQLDumper für all-inkl Kunden mit mehreren Datenbanken bisher etwas mühselig war. Mittlerweile ist dieses Manko aus der Welt, denn mit der neuen Version (1.23 pre-release) lassen sich mit mein Lieblingstool MySQLdumper nicht nur die verschiedene Datenbanken für einen Datenbankbenutzer auswählen, sondern Konfigurationsdateien für unterschiedliche Datenbankbenutzer anlegen, so dass man auch zwischen diesen einfach hin- und herwechseln kann. Ich habe gleich eine Anleitung für die Einrichtung dieses neuen Features und die Einrichtung automatisierter Backups mit all-inkl als Hoster erstellt. Update April 2011: Da meine Anleitung etwas in die Jahre gekommen ist, es mittlerweile eine neuere MySQLDumper Version gibt und mein Hostingbedarf über das all-inkl Angebot hinausgewachsen ist, so dass ich dort kein Kunde mehr bin, freue ich mich, dass sich Jens vom kochsiek.org Blog die Mühe gemacht hat eine aktualisierte Version zu erstellen: "MySQLDumper mit Cronjob bei All-Inkl einrichten". Meine Version ist wohl immer noch verwendbar, aber bei ihm finden sich aktuellere Screenshots. [Ende Update] Informationen zur generellen Installation und Einrichtung finden sich auf der MySQLDumperwebsite und in dem deutschsprachigen Support Forum, so dass ich darauf nicht eingehe. Falls man MySQLDumper später für automatische Backups nutzen möchte, sollte man vor dem Anlegen der Konfigurationsdateien das Perlscript passend konfigurieren, da man sonst später bei allen Konfigurationsdateien die Angabe zur Lage der Perldateien ändern muss. D.h. in diesem Fall besser mit dem zweiten Teil der Anleitung beginnen.   1. Einrichten mehrerer Konfigurationen in MySQLDumper für all-inkl   Zum Anlegen dieser Konfigurationsdateien wechselt man unter dem Menüpunkt Konfiguration ... in das Untermenü Konfigurationsdateien: Dort lässt sich eine neue Konfigurationsdatei anlegen, indem man einen passenden Namen eingibt und speichert. Allerdings wird dabei die aktuelle Konfiguration übernommen: Um nun einen anderen Datenbanknutzer anzugeben, muss unter "Datenbanken" (1.) auf Verbindungsparameter "ein-/ausblenden" (2.) geklickt werden: Unter 1. ist hier der für die gewünschte Datenbank zugehörige Nutzername einzutragen (findet sich in der all-inkl Administration unter dem Menüpunkt Datenbanken und ist identisch mit dem Datenbanknamen). Unter 2. trägt man das zu dieser Datenbank gehörige Passwort ein: Jetzt speichern wir die Parameter: Wenn wir jetzt zu den Konfigurationsdateien zurückkehren ... ... können wir feststellen, dass bei unserer neuen Konfiguration unter zu sichernde DBs (PHP): XXXXXXX und unter zu sichernde DBs (PERL): YYYYYYY noch verschiedene Datenbanken stehen. Ein weiterer Klick auf "Speichern" sorgt dafür, dass bei beiden dieselbe Datenbank eingetragen ist. Diese Prozedur führt man für jede Datenbank durch, so dass man am Ende durch einfache Auswahl der passenden Konfiguration im Dropdownmenü sofort den passenden Zugriff auf die gewünschte Datenbank hat:   2. Automatisiertes Backup mit dem Perl-Script bei all-inkl   Nachdem dies nun problemlos funktioniert, wollte ich unbedingt dafür sorgen, dass das Backup meiner Datenbanken automatisch per Cronjob ausgeführt wird. Hierfür bringt MySQLDumper ein passende Perl Scripte mit, die in dem Ordner "msd_cron" liegen. Es gibt sowohl in der MySQLDumper Hilfe als auch in dem Beitrag "Features Perl Cronscript (Einstellungen von Konfiguration / Cron)" im MySQLDumper Support Forum ausführliche Informationen zur Einrichtung des Perl Scripts. Zu meiner eigenen Gedächtnisstütze werde ich hier den Einrichtungsvorgang für mich mitprotokollieren. Wähle im Menü "Backup" ... und klicke auf Backup Perl: Kopiere die Pfadangabe hinter "Eintrag in crondump.pl für absolute_path_of_configdir" (A) und öffne das Skript "crondump.pl" (liegt in dem Ordner "msd_cron") in einem Editor. Suche die Zeile my $absolute_path_of_configdir="" und setze den Cursor zwischen die "" und füge den kopierten Pfad ein. Anschließend speicherst Du die geänderte Datei "crondump.pl". (An dieser Stelle hatte ich kurzfristig ein paar Schwierigkeiten von den Du bei Interesse weiter unten mehr erfährst.) Jetzt legst Du einen Ordner mit der Bezeichnung "cgi-bin" im MySQLDumperverzeichnis an. (Nachtrag: ich will an dieser Stelle auf einige hilfreiche Kommentare weiter unten hinweisen: einerseits scheint es so zu sein, dass der "cgi-bin" Ordner grundsätzlich neu im Hauptverzeichnis der Domain angelegt werden muss. Ein Anlegen in Unterverzeichnissen oder ein Kopieren des Ordners aus einem anderen Verzeichnis in das Hauptverzeichnis scheinen die Ausführung von Perlscript nicht zu ermöglichen. Darüber hinaus gibt es wohl auch Hostingpakete bei denen all-inkl Perl erst aktivieren muss. Genaueres findet ihr in den Kommentaren weiter unten oder indem ihr den all-inkl Support befragt.) In diesen Ordner kopierst Du das Skript "crondump.pl" sowie die beiden Testskripte "perltest.pl" und "simpletest.pl" per Ascii-Modus (sollte jeder einigermaßen ausgereifte FTP-Client schaffen). Änder die Dateirechte des Ordners und aller darin befindlichen Skripte per chmod auf 755. Im MySQLDumper wechselst Du in der "Konfiguration" zum Untermenü "Cronscript": Dort trägst Du unter "Pfad der Perskripte" den Pfad zu dem neuen Ordner "cgi-bin" ein: ... und speicherst diese Einstellung ... Jetzt kannst Du auf "Backup" wechseln ... ... und dort oben auf "Backup PERL" klicken: Hier prüfst Du nun die Lauffähigkeit mit 1. "Perl testen". Wenn die Meldung "Wenn Du das siehst, funktioniert Perl auf Deinem System !" erscheint ist alles in Ordnung. Mit Hilfe von 2. "Perl-Module testen" kannst Du feststellen, ob alle benötigten Module bei dem Hoster verfügbar sind und funktionieren (ist bei meinem all-inkl Tarif der Fall). Als letzten Schritt kannst Du über 3. "Perl-Cronscript ausführen" das Perl Backup manuell starten und so manuell testen, ob es funktioniert. Bisher funktionieren diese Backups bei mir mit meinem all-inkl Webspace mit kleineren Datenbanken zwischen 3 und 5 MB. Es gibt allerdings Meldungen von all-inkl Nutzern bei denen das Perl Script vorzeitig abbricht. Ein kurzer Test mit einer 30 MB großen Datenbank scheiterte zumindest beim Emailversand. Genauer läßt sich das über die Log-Dateien verfolgen, die Du unter "Log" ... ... und "Perl-Log" oder "Perl-Complete Log" einsehen kannst (diese findest Du auch als komprimierte Dateien im Unterordner "/work/log"): Wenn Perl Script ausführen erfolgreich verlief, testest Du am besten den Link unter B: Die URL, die aufgerufen wird sieht ungefähr so aus: "http://www.meinedomain.de/cgi-bin/crondump.pl?config= mysqldumper.conf.php", wobei hier der passende Domainname steht und hinter "...?config=" der Name der Konfigurationsdatei, die für das Backup genutzt werden soll (diese sind in dem Unterordner "/work/config" zu finden und entsprechen dem Namen der jeweiligen Konfiguration plus der Endung ".config.php"). Die Linkangabe kopierst Du in die Zwischenablage und dann in die Adresszeile Deines Browsers. Nach "Enter" sollte, wenn alles passt, ebenfalls der Backupprozess problemlos ablaufen (ggf. werden Dein Verzeichnisbenutzername und -passwort vorher noch abgefragt). Wenn dieser Test auch erfolgreich verlaufen ist, dann kann Du den passenden Cronjob erstellen. Entweder direkt im Members Bereich bei all-inkl oder, falls keine Cronjobs in dem genutzten Tarif enthalten bzw. keine mehr übrig sind, bei einem externen Dienstleister wie z.B. Cronjob.de . Einen Cronjob bei all-inkl erstellen Wenn Dein all-inkl Tarif Cronjobs erlaubt, so kannst Du diese nicht im KAS verwalten sondern im all-inkl Members Bereich. Dort klickst Du dann auf ... ... und gelangst so in folgende Übersicht: Nach Klick auf "... neuen Cronjob einrichten." gelangst Du auf die Konfigurationsseite. Dort trägst Du als erstes den Link (wie oben unter B) für den externen Cronjob ein. WICHTIG: für all-inkl musst Du das "http://" am Anfang weglassen ! Da Du Dich natürlich an die Sicherheitsempfehlung des MySQLDumpers gehalten hast, hast Du einen Verzeichnisschutz eingerichtet. Daher musst Du nun den passenden Benutzernamen und das Passwort eintragen, damit der Cronjob durch den Verzeichnisschutz kommt: Im folgenden kannst Du das Intervall für den Cronjob bestimmen: ACHTUNG 1: Neueinrichtungen und Änderungen werden teilweise erst nach 30 Minuten aktiv. D.h. wenn Du Deine Startzeit zu kurz ansetzt, wird der Cronjob erst beim nächsten Intervall ausgeführt bzw. mit angepassten Einstellungen ausgeführt): ACHTUNG 2: Wenn Du das Intervall eines bereits bestehenden Cronjobs ändern willst, musst Du unbedingt darauf achten, dass Du einen Haken in das Kästchen "Aktivieren Sie dieses Kästchen, wenn Sie die Ausführzeit ändern möchten.", dass dann oberhalb des Blocks eingeblendet wird, setzt. Wenn Du das (wie ich es erstmal getan habe) vergisst, dann ändert sich nix an dem Intervall und Du rätzelst lange herum warum es nicht funktioniert :( . Hier kannst Du Dir noch eine Emailbenachrichtung zusenden lassen, die Dich über die ausführung des Cronjobs informiert und alle Ausgaben des Perl-Scrips enthält: Nun speicherst Du Deine Einstellungen: Prüft bitte regelmäßig, ob die Backups auch vollständig und im Ernstfall nutzbar sind!!! Nichts ist schlimmer als sich in falscher Sicherheit zu wiegen! MySQL-Datenbankbackup per Email zusenden lassen Falls man sich die Datenbank per Email zusenden lassen will, so läßt sich dies in der "Konfiguration" unter "Email" einrichten: Hier gibt man an alle nötigen Daten ein. Bei mir funktionierte die Einstellung "SMTP" unter "Mailprogramm". Sendmail klappte nicht, was aber auch an einer fehlerhaften Pfadangabe liegen könnte (Nachtrag: holger meldete in den Kommentaren, dass bei ihm Sendmail mit folgender Pfadangabe funktioniert: “/usr/sbin/sendmail”): Wer sich häufiger Backups erstellen lässt, sollte eventuell unter "Konfiguration" > "automatisches Löschen" dafür sorgen, dass nicht zu viele Backups auf dem Server liegen bleiben. Dann auch wenn das Backup per Email versandt wird, so werden die Backupdateien vorher im Ordner "/work/backup" erstellt. :) ... so, jetzt erhalte ich regelmäßig automatisch die Backups meiner wichtigsten Datenbanken per Email zugesandt ... und kann ruhiger schlafen ;) !!! Allerdings klappt bei mir der Emailversand nicht mit einer Datenbank über 10 MB! Falls Ihr von MySQLDumper genauso begeistert seid wie ich, denkt an eine kleine Spende für die Entwickler, die eine Menge Zeit, Energie und Nerven in die Entwicklung des Programms und den Support stecken: klick! Für Interessierte noch eine kurze Beschreibung meines bei der Einrichtung des automatisierten Backups aufgetretenen Problems: Kurze Erläuterung des bei mir aufgetretenen Problems Da ich keine besonderen Informationen zur Nutzung von Perl bei all-inkl gefunden hatte, nahm ich an, dass die Scripte überall laufen. Ich erhielt beim Testen der Scripte allerdings immer die Meldung "You don't have permission to access /xxxxx/msd_cron/perltest.pl on this server.". Diese Meldung kann durch falsch gesetzte Rechte (CHMOD) entstehen. Nachdem ich diese Fehlerquelle ausgeschlossen hatte, suchte ich nach anderen Fehlerquellen. Da laut Support Forum diese Meldung auch durch einen vorzeitigen Abbruch des Perl Scripts erscheinen kann, wenn der Hoster ein zu knappes Zeitlimit für Perlscripte gesetzt hat und dies in Zusammenhang mit all-inkl zumindest in einem Foreneintrag gemeldet wurde. Allerdings machten mich zwei Dinge stutzig: Erstens, dass die Fehlermeldung mit dem fehlenden Zugriffsrechten immer sofort erschien und nicht erst nach einer oder mehreren Sekunden und zweitens, dass ich keine Logdateien ("mysqldump_perl.log.gz" und "mysqldump_perl.complete.log.gz") für das Perlscript im Unterordner "/work/log" finden konnte. Nach einigem Googeln und Recherchieren kam ich dann auf die Idee doch einen eigenen "cgi-bin" Ordner für die Perl Scripte anzulegen und siehe da, es funktionierte auf einmal :) !

Tagged as: Backup, Homepage, Hosting, MySQL, MySQLdumper, Sicherheit, Software, Umzug