MySQLDumper mit Cronjob bei All-Inkl einrichten

Nils Schulte am Hülse hat hier mal beschrieben, wie man den MySQLDumper beim in Deutschland mittlerweile doch recht bekannten Hoster All-Inkl.com so einrichtet, dass man automatisch per Cronjob seine Datenbanken gesichert bekommt.

Da Nils‘ Eintrag jedoch von Mai 2007 ist, basiert diese Anleitung auf der Version 1.23 pre-release des Dumpers.

Eine echte Version 1.23 hat es nie gegeben, aus dem Release Candidate Stadium ist der Dumper nie rausgekommen.
Am 18.09.2009 wurde dafür dann die stabile Version 1.24 des Dumpers veröffentlicht. Ein Preview Video der nächsten geplanten Version 1.25 kann man sich hier anschauen. Die Entwicklung geht also voran!

Da die bisherige Anleitung also schon etwas in die Jahre gekommen ist (aber nichts desto trotz immer noch gültig ist), will ich hier mal versuchen, das Prozedere für die Version 1.24 mit ein paar Screenshots und Anmerkungen zu aktualisieren.

Zunächst einige Vorbemerkungen.

Der MySQLDumper ist gedacht für Anwender, die keinen eigenen Webserver haben, sondern sich mit mehreren anderen Usern einen Server teilen (shared hosting). Der eigentliche Server selbst wird durch den Hoster verwaltet und administriert. Der Endanwender (Du!) hat per FTP Zugriff auf den Teil des Servers, der für ihn freigeschaltet ist. Zusätzlich kann man sich noch in einem Verwaltungsbereich (bei All-Inkl heißt das KAS – Kundenadministrationssystem) anmelden, über den man z.B. Email-Konten, MySQL Datenbanken oder FTP-Zugänge konfigurieren kann (je nach gewähltem Tarif).

Nehmen wir mal an, jemand hat sich bei All-Inkl ein Webhosting Paket im Tarif All-Inkl Privat Plus eingerichtet. Wir nehmen das an, weil ich genau diesen Tarif habe. Da bekommt man für relativ kleines Geld u.a. folgende Leistungen

– 10 GB Speicherplatz (der für den eigentlichen Webspace, die angelegten MySQL Datenbanken und die eingerichteten EMail Postfächer gemeinsam genutzt wird)
– bis zu 25 MySQL Datenbanken
– PHP und Perl Unterstützung
– bis zu 5 Cronjobs

Hier kann man dann z.B. ein – sagen wir mal – Blog installieren. Nennen wir es mal kochsiek.org. Dieses Blog basiert auf der Software WordPress, einer kostenlosen PHP-Anwendung. Solche Anwendungen bestehen immer aus zwei Teilen. Einmal den Dateien auf dem Webspace, die man per FTP in das entsprechende Verzeichnis hochlädt, das aufgerufen wird, wenn jemand die entsprechende Domain in seinem Webbrowser eintippt. Und zum anderen aus einer Datenbank, in der die Inhalte gespeichert werden (hier: MySQL). Das gleiche Prinzip gilt auch für Foren (z.B. phpBB, vBulletin, IP.Board, Woltlab Burning Board, …), Wikis, CMS-Systeme (z.B. Joomla, Typo3, …) und viele weiteren Anwendungen, die man als Privat- und Hobbyanwender auf seiner kleinen Homepage vielleicht nutzen möchte. Viele dieser Programme sind kostenfrei.

Diese Zweigeteiltheit hat zur Folge, dass die Webseite vom Aufbau her immer gleich ist, die Inhalte aber sehr schnell und aktuell geändert werden können, ohne dass man dafür eine Ausbildung zum Webdesigner haben muss und/oder fließend HTML programmieren können muss.
Die Software erzeugt aus dem feststehenden Gerüst und den variablen Einträgen der Datenbank also immer wieder neue HTML-Seiten, die vom Browser angezeigt werden. So einfach funktioniert jedes Forum oder Blog.

Bei All-Inkl (wie bei anderen Anbietern auch) gibt es sogar die Möglichkeit, die Installation einer solchen Software automatisch über das KAS zu machen. Man muss sich dann weder über das Hochladen der Dateien per FTP noch über das Anlegen einer Datenbank Gedanken machen, sondern kann nach kurzer Zeit die Webseite des z.B. Blogs einfach aufrufen.

Wir bleiben mal bei unserem Beispiel Blog. Die Software ist also installiert, eine MySQL Datenbank ist eingerichtet und füllt sich durch die ersten Artikel langsam mit Leben. Mit steigender Anzahl an Einträgen kommt einem bald die Frage Was passiert eigentlich, wenn der Server mal ausfällt und alles ist auf einmal weg? in den Sinn. Der Gedanke Sicherheit in Form eines Backups formt sich langsam im Cerebrum.

Beim Backup muss man wie bei der Installation und der Nutzung des Blogs zwei Dinge beachten. Einmal die Dateien auf dem FTP-Server und einmal die davon losgelöste MySQL Datenbank. Im folgenden soll es nur um die Datenbank gehen. Wer Interesse hat, seine FTP-Daten auch zu sichern und dafür Ansätze sucht, kann sich mal diesen Thread im MySQLDumper Support Forum anschauen. Viele Hoster bieten auch automatische Backups in irgend einer Form an. All-Inkl sichert den Webspace in 14tägigen Abständen, lässt dabei jedoch große Dateien wie .zip, .mp3 u.ä. aussen vor.

Ich persönlich sichere auch meine FTP Daten in unregelmäßigen Abständen auf einer lokalen Festplatte, damit meinen Sicherheitsanforderungen genüge getan ist.

Aber hier soll es ja um die Datenbanken und den Dumper gehen.

Der Kasus Knaxus bei All-Inkl nun ist, dass es pro angelegter MySQL Datenbank einen eigenen Datenbank-Benutzer gibt. Normalerweise ist es so, dass es einen Datenbank-Benutzer gibt, und diesem Benutzer Rechte zum Zugriff auf eine oder mehrere Datenbanken gegeben werden.

Ich habe hier also eine Datenbank für das Blog und eine für eine Joomla-Webseite eingerichtet und möchte nun beide jede Nacht automatisch vom Dumper sichern lassen und mir per Email zusenden lassen. Wie mache ich das?

Als erstes muss der Dumper mal installiert werden.

Auf der Webseite www.mysqldumper.de klickt man zunächst auf Download.

Man gelangt zur SourceForge Seite, bei der die Entwicklung des quelloffenen Dumpers verwaltet wird.
Hier einfach auf den großen grünen Button zum Download drücken. Damit ist gewährleistet, dass man immer die aktuellste stabile Version bekommt.

Ich nutze als Webbrowser FireFox, der mir zum Download folgendes Fenster anbietet.

Die so heruntergeladene Datei entpacke ich auf meiner lokalen Festplatte. Heraus kommt das Verzeichnis msd1.24stable.

Den Inhalt dieses Verzeichnisses übertrag ich jetzt mit meinem FTP Programm (ich nutze FileZilla) in ein neues Verzeichnis auf meinen Webspace. Dabei muss ich natürlich wissen, wie ich mit meinem Browser dieses neue Verzeichnis aufrufen kann.

Da ich mehrere Domains habe, habe ich auf dem FTP-Server ein Verzeichnis /domain angelegt. In diesem Verzeichnis liegen mehrere Unterverzeichnisse, für jede Domain ein eigenes. Also gibt es auch das Verzeichnis /domain/kochsiek_org. Das Blog ist erreichbar unter http://kochsiek.org/blog und ich möchte, dass der Dumper unter der Adresse http://kochsiek.org/blog/msd aufgerufen werden kann. Also erstelle ich mit meinem FTP Programm als erstes mal das Verzeichnis /domain/kochsiek_org/blog/msd.

Und wo ich schon dabei bin, erstelle ich gleich noch die Verzeichnisse

/domain/kochsiek_org/blog/msd/work
/domain/kochsiek_org/blog/msd/work/backup
/domain/kochsiek_org/blog/msd/work/config
/domain/kochsiek_org/blog/msd/work/log

Das mache ich, weil der PHP-User bei All-Inkl diese Verzeichnisse nicht selbst während des Installationsprozesses erstellen darf und ich das eh‘ manuell machen müsste.

Bei der Gelegenheit geben wir dem work Verzeichnis inkl. der darin enthaltenen Unterverzeichnisse die CHMOD Rechte 777, damit diese Verzeichnisse auchbeschreibbar sind. Wie das geht hängt vom jeweiligen FTP Programm ab. Für FileZilla beschreibe ich das jetzt mal. Wie man sich zum FTP Server verbindet sollte bekannt sein.

Verzeichnis msd anlegen durch Rechtsklick in das Verzeichnis /domain/kochsiek_org/blog

Und eingeben des Namens des Unterverzeichnisses.

Auf die gleiche Weise werden die o.g. Unterverzeichnisse angelegt, so dass die Verzeichnisstruktur anschließend so aussieht.

Mit einem Rechtsklick auf das Verzeichnis work kann man den Punkt Dateiattribute auswählen, und man erhält folgendes Fenster, in dem man den Wert 777 eingibt und den Haken bei Unterverzeichnisse einbeziehen setzt.

Soweit, so gut.

Nun kann man die zuvor heruntergeladenen und entpackten Dateien in das Verzeichnis msd hochladen.

Der Datei /msd/config.php gibt man auf die selbe Weise ebenfalls die Berechtigung 777 wie zuvor dem Verzeichnis /msd/work.

Damit sieht das Verzeichnis dann so aus.

Jetzt wechsle ich schnell ins KAS von All-Inkl und lege dort unter Tools / Verzeichnisschutz eine Passwortabfrage für das Verzeichnis /domain/kochsiek_org/blog/msd an.

Hier klicke ich dann auf

Ich wähle das Verzeichnis aus, das ich schützen will, gebe einen Benutzernamen und ein Passwort an und klicke auf speichern.

Wenn ich jetzt die Adresse http://kochsiek.org/blog/msd aufrufe, kommt die Abfrage nach Benutzer und Passwort.

Nach Eingabe der korrekten Daten kommt die Installations-Startseite des Dumpers, auf der man als erstes die Sprache auswählen kann. Ich nehme mal Deutsch und klicke auf Installation.

Als nächstes muss der Host des MySQL Servers, ein Datenbankbenutzer und ein Passwort angegeben werden. Jetzt habe ich ja sowohl eine Datenbank für das Blog und für eine Joomla-Webseite – mit jeweils einem eigenen Benutzer dafür.

Ich nehme für die Dumper-Installation erst mal den ersten Datenbankbenutzer, den ich finde.

Sobald ich auf zu MySQL verbinden klicke, versucht der Dumper eine Verbindung mit dem angegebenen Benutzer herzustellen und zu schauen, auf welche Datenbanken dieser Benutzer so alles Zugriff hat. Im Falle von All-Inkl sind das immer nur zwei, einmal eine Systemdatenbank information_schema und die Datenbank, um die es mir geht und die den selben Namen hat wie der Datenbankbenutzer. In meinem Fall also d00aa06f.

Jetzt noch schnell auf speichern und Installation fortsetzen klicken.

Weil ich bereits im Vorfeld einige Verzeichnisse angelegt und diese und die Datei config.php entsprechend berechtigt habe, geht der Rest automatisch. Als nächstes begrüßt mich der MySQLDumper Home-Bildschirm.

Es wurde nun eine Konfigurationsdatei mysqldumper angelegt. Diese kann im linken Menü unter ausgewählt werden. In dieser Konfiguration befinde ich mich als grade aktuell. Da ich jedoch zwei Datenbanken verwalten möchte, in der Konfiguration jedoch nur einen Benutzer und damit eine Datenbank angeben kann, muss ich mir etwas einfallen lassen.

Die Entwickler des Dumpers haben mich mit meinem Problem nicht alleine gelassen und die Möglichkeit geschaffen, mehrere Konfigurationsdateien anzulegen. Ich benötige also pro Datenbank eine eigene Konfigurationsdatei.

Die Standard-Konfiguration mysqldumper kann man dabei jedoch nicht entfernen. Da der Datenbankname auch wenig aussagekräftig ist, würde ich lieber eine Konfiguration haben, die Blog heißt. Umbenennen kann ich den Standard leider auch nicht, also muss ich ihn kopieren.

Dazu gehe ich im Dumper Hauptmenü auf Konfiguration

Klicke im sich dann aufbauenden Menü auf Konfigurationsdateien

Trage dann bei Eine neue Konfigurationsdatei anlegen den gewünschten Namen ein und klicke auf Speichern.

Das korrekte Anlege der Datei wird mit der Meldung

bestätigt. In der Übersicht der Konfigurationsdateien taucht nun die neue Datei namens Blog auf.

Und ich kann sie auf der linken Seite unter dem Hauptmenü neben der Standard-Konfiguration auswählen.

Noch sind beide Konfigurationen 1:1 gleich.

Über den Menüpunkt Konfiguration / Allgemein nehme ich nun einige Einstellungen vor.
Als erstes lasse ich die Speichergrenze automatisch ermitteln. Das ist von Server zu Server unterschiedlich. Als nächstes ändere ich die Standard-Werte für die Geschwindigkeitskontrolle. Statt 100 bis 50.000 gebe ich 20.000 bis 100.000 ein. Damit kommt mein Server bei All-Inkl gut zurecht. Falls mal etwas nicht klappen sollte, kann man diese Werte zum Test schrittweise anpassen. Im Bereich Wiederherstellung aktiviere ich noch die Option im Fehlerfall fortfahren und Fehler protokollieren.

Anschließend den Klick auf Speichern nicht vergessen!

Im Bereich Konfiguration / Auto Löschen gebe ich noch an, dass immer nur die letzten 3 Backups gespeichert werden sollen und ältere automatisch gelöscht werden, um nicht unnötig den Server zuzumüllen.

Wenn die Backups direkt auf dem Webserver gespeichert werden, bringt der ganze Aufwand nichts, wenn der komplette Server oder dessen Festplatte kaputt geht. Ich möchte mir also die Backups vom Dumper per Email schicken lassen. Dazu gebe ich unter Konfiguration / E-Mail-Benachrichtigung an, dass ich eine Mail nach der Sicherung erhalten möchten. Ich trage ein, an welche Empfänger-Adresse gehen soll und auch, mit welcher Absender-Adresse die Mail geschickt werden soll. Das ist ganz hilfreich, wenn man sich z.B. in Outlook eine Regel definiert, aufgrund derer eine ankommende Mail von einem bestimmten Absender automatisch in einen Unterordner verschoben werden soll. Ich wähle also als Absender der E-Mail die Adresse mysqldumper_blog@kochsiek.org aus. Diese Adresse gibt es nicht, es soll ja auch nur der Absender sein.
Zusätzlich lasse ich die erzeugte Backupdatei an die Email anhängen und gebe vor, dass diese bis zu 10 MB groß sein darf (die Backupdatei wird im gepackten Zustand mit GZip erstellt).
Die Einstellungen zum Mailprogramm lasse ich so wie im Standard bestehen, das funktioniert.

Man kann die Backupdatei auch noch an bis zu 3 verschiedene FTP-Server verschicken (in der nächsten Dumper Version sogar an noch mehr). Das beschreibe ich hier jetzt mal nicht so ausführlich.

Unter Konfiguration / Cronscript müssen wir noch etwas ändern, da bei All-Inkl Perlscripte nicht in jedem Verzeichnis ausgeführt werden dürfen, sondern nur aus einem Verzeichnis mit Namen cgi-bin heraus. Ich gebe also als Pfad der Perlscripte statt msd_cron/ das Verzeichnis /cgi-bin/ an. Dabei ist zu beachten, dass sowohl am Anfang als auch am Ende ein / stehen muss. Als Kommentar gebe ich noch Blog ein, damit ich später auch noch weiß, was in der Backupdatei denn drin ist.

Das Verzeichnis cgi-bin gibt es aber doch gar nicht! Richtig. Falls es – wie in meinem Beispielfall – nicht vorhanden ist, muss es natürlich per FTP angelegt werden (siehe weiter oben). Das Verzeichnis lege ich auf der selben Ebene an, auf der auch das /blog/ liegt, also unter /domain/kochsiek_org/cgi-bin. Als Besonderheit ist hier darauf zu achten, dass sowohl das Verzeichnis als auch die Dateien (die ich da gleich reinkopieren werde) die CHMOD Rechte 755 haben müssen. Auch wie das eingestellt wird, wurde schon weiter oben beschrieben.

Als nächstes muss ich die 3 Dateien aus dem Verzeichnis msd_cron bearbeiten. Ok, wirklich bearbeitet wird nur eine einzige, nämlich die crondump.pl
Ich lade diese Datei zusammen mit den beiden anderen (simpletest.pl und perltest.pl) wieder runter und öffne die crondump.pl mit einem Texteditor (Achtung: Word ist keiner!). Ich nutze dazu Notepad++.
Recht weit am Anfang der Datei gibt es eine Variable, die ich noch setzen muss. Direkt über der Variablen ist auch noch mal erklärt, wie das aussehen sollte.

Hier muss ich also zwischen die beiden “ “ etwas eintragen. Aber was?
Das steht auf der Backup-Seite des Dumpers, wenn man in den Backup-Perl Modus wechselt. Also erst links im Menü auf Backup klicken und dann rechts oben auf Backup PERL. Dann erscheint etwas weiter unten genau das, was ich in der crondump.pl bei absolute_path_of_configdir eintragen muss.

Das geht am Besten mit copy & paste. Dabei darauf achten, dass wirklich alle Zeichen in dieser Zeile, inkl. der beiden / am Anfang und Ende mit kopiert und eingefügt werden.

Jetzt die Datei lokal abspeichern und per FTP (im ASCII oder AUTO Modus) in das Verzeichnis /cgi-bin/ hochladen. Den drei Dateien dann noch die CHMOD Rechte 755 verpassen, das war’s.

Jetzt kann ich manuell zum Test auf den Button Perl-Cronscript ausführen klicken. Nach kurzer Zeit erscheint das Log des Aufrufes, welche Tabellen optimiert und gesichert wurden, an wen die Email verschickt wurde, wie lange der ganze Zauber gedauert hat.

Diese Art des Backups funktioniert übrigens nur solange, wie der Perl-Timeout des Servers nicht erreicht wird. Bei All-Inkl sind das meist zwischen 6 und 12 Sekunden. Für kleinere Datenbanken, die komprimiert nur 4-5 MB ergeben, reicht das aus. Wenn in der Datenbank allerdings so viele Datensätze stehen, dass zum Sichern mehr Zeit benötigt wird, als der Server zur Verfügung stellt, dann bricht das Script einfach ab. Das Backup ist dann unvollständig! Man muss also darauf achten, dass am Ende der Log-Meldungen irgendwann mal ein #EOS (End of script) steht. Nur dann kann man sicher sein, dass dieses Backup im Notfall auch alle Datensätze enthält, die in der Datenbank gespeichert sind.
Durch eine freundliche Anfrage beim All-Inkl Support kann man versuchen, das Limit für seinen Server etwas hochsetzen zu lassen, das wird höchstwahrscheinlich gemacht werden, jedoch nicht bis ins Unendliche.

Warum denn mögen jetzt einige fragen? Der Dumper ist doch gerade dafür da, das PHP Timeout zu umgehen und macht das doch auch wunderbar. Korrekt, das PHP Timeout! Bei Perl greift jedoch ein anderes Limit, das mit den 30 Sekunden von PHP nichts zu tun hat. Und hier liegt auch der Hund begraben, weshalb es PHP und Perl Backup-Funktionen gibt.
Das Backup mit PHP verwendet rekursive Selbstaufrufe mit Hilfe von Javascript. Das kann aber nur von einem Browser ausgeführt werden.
Das Backup mit Perl benötigt keinen Browser (was ja auch Sinn macht, denn für einen Cronjob, der Nachts um 4 Uhr läuft, steht auch auch kein Browserfenster zur Verfügung). Hier funktioniert das Austricksen des Timeouts mittels Javascript-Selbstaufrufen eben nicht. Und wenn das Timeout erreicht ist, ist halt Schluß.

Wer einen (Windows) Rechner zur Verfügung hat, der 24/7 eingeschaltet und mit dem Internet verbunden ist, kann sich das Programm WinTrigger anschauen, das auf der MySQLDumper Webseite im Downloadbereich zu finden ist. Hier wird eine Browserinstanz durch einen geplanten Task mit der Dumper-Konfiguration aufgerufen und macht so ein PHP Backup zur eingestellten Zeit.

Ich hatte ja weiter oben erwähnt, dass ich noch eine Datenbank gerne mit Hilfe eines Cronjobs sichern möchte. Da ich die Konfigurationsdatei Blog jetzt schon so schön bearbeitet habe, ist es recht einfach, für die Joomla Datenbank einfach eine neue Konfigurationsdatei auf Basis dieser Blog-Datei zu erstellen.
Wie zuvor schon geschrieben wähle ich die Blog Konfigurationsdatei links aus, gehe über das Menü Konfiguration / Konfigurationsdateien und speichere die grade aktuelle Datei Blog unter einem neuen Namen – nämlich Joomla – ab.

Die Konfiguration Joomla ist jetzt wieder eine 1:1 Kopie der Konfiguration Blog. Sie kann links im Menü ausgewählt werden. Über Konfiguration / Datenbanken kann man nun einen anderen Datenbankbenutzer und ein anderes Passwort eintragen. Dazu muss man zunächst auf Verbindungsparameter ein-/ausblenden klicken.

Im sich dann öffnenden Bereich trage ich den anderen User und das entsprechende Passwort ein und klicke auf Speichern.

Auch hier wird das Backup per Email an mich gesendet. Da ich mir aber eine Outlook Regel definieren möchte, die Mails nach Absendern sortiert in einen anderen Ordner packt, gebe ich als Absender-Adresse mysqldumper_joomla@kochsiek.org an.

Bei den Cronscript Einstellungen tausche ich den Kommentar ebenfalls aus.

Jetzt habe ich also für zwei Datenbanken jeweils eine eigene Konfigurationsdatei angelegt und kann diese im Menü links auswählen. Dabei weiß ich durch den Namen immer, in welcher Datenbank ich mich gerade befinde, ohne mich durch die kryptische da65ce87 – Benennung der Datenbanken irritieren zu lassen.

Wer bis hier durchgehalten hat: Respekt!

Jetzt geht’s nur noch darum, die so eingestellten Backups auch per Cronjob zeitgesteuert zu automatisieren.

Dazu wechseln wir wieder ins KAS von All-Inkl. Im Menü steht unter Tools / Cronjobs die Übersicht der – hey! – Cronjobs zur Verfügung.
Früher hat sich die Cronjob-Einrichtung bei All-Inkl an anderer Stelle versteckt (in der sog. MembersArea). Mittlerweile erreicht man sie aber über das KAS.

Hier klicke ich auf

und lande auf einer Maske, in der ich folgendes eingebe

Es soll also jeden Tag um 4 Uhr das Perl-Script mit der Konfigurationsdatei Blog aufgerufen werden.

Für das Backup der anderen Datenbank muss ich einen eigenen Cronjob anlegen. Der unterscheidet sich im Grunde nur durch die andere Konfigurationsdatei am Ende des Aufrufes vom ersten.

Man sollte ruhig ein paar Minuten Zeit zwischen einzelnen Cronjob Aufrufen verstreichen lassen und nicht gleich 5 Datenbanken alle gleichzeitig um 4 Uhr sichern. Das belastet den Server nur unnötig.

Wer bei seinem All-Inkl Paket keinen Cronjob inklusive hat und auch keinen bezahlen möchte, kann sich mal Anbieter wie z.B. Cronjob.de anschauen.

Über Kommentare oder Hinweise auf Fehlendes, Falsches oder nicht ausführlich genug dargestellte Zusammenhänge freue ich mich natürlich sehr.

(Update 25.07.2011 15:19 Uhr) Um das Cronscript des Dumpers auch aus anderen Verzeichnissen als /cgi-bin ausführen zu können (also beispielsweise aus dem Standard-Verzeichnis des Dumpers, /msd_cron) mus in dem Verzeichnis, wo die Perl Skripte drin sind eine .htaccess Datei mit dem Inhalt

#cgi ausserhalb von /cgi-bin ausführen
Options Indexes FollowSymLinks Includes ExecCGI MultiViews

eingefügt werden.

(Update 28.07.2011 14:34 Uhr) In dem Fall darf allerdings der Pfad zum Cronscript nicht mit „/“ beginnen, also nur „msd_cron/“ …