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/“ …

Dieser Beitrag wurde unter Internetz abgelegt und mit , , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

55 Antworten zu MySQLDumper mit Cronjob bei All-Inkl einrichten

  1. Pingback: Tweets that mention MySQLDumper mit Cronjob bei All-Inkl einrichten « kochsiek.org -- Topsy.com

  2. axel sagt:

    Ich sage nur Dankeschön, für Deine Mühe!
    Nach einigen Stunden des Herumprobierens und Telefonierens mit All-Inkl. läuft jetzt alles. Möchte noch einmal darauf hinweisen, wie wichtig CHMOD 755 für /cgi-bin/ und alle darin enthaltenen Files ist. Ich hatte gedacht, je höher, desto besser, doch mit 777 ging gar nichts.

    Einem entspannten und sorgenfreien Arbeiten steht nun nichts mehr im Wege.

    Gruß Axel

  3. Sven sagt:

    Vielen Dank für die ausführliche Anleitung, hat mir ne Menge eigenes Ausprobieren und Suchen erspart. Hat alles bestens geklappt.

  4. Robert sagt:

    Hallo,

    besten Dank für die tolle Anleitung, genau sowas hab ich gesucht, hat mir sehr geholfen :-).

  5. Angus sagt:

    Vielen herzlichen Dank! Die Seite hat meine verlorenen 10 Stunden binnen von Sekunden (naja 30 min. waren es dann doch) wieder wettgemacht!

  6. Auch von meiner Seite, ein Dankeschön. Habe das nun bei mir auch hinbekommen.

    Grüße,
    Sergiu

  7. Carsten sagt:

    Vielen Dank. Super Anleitung auch für unterdurchschnittlich Begabte…

  8. Rudi sagt:

    Für das Tutorial kann ich nur eine 1 mit * vergeben. Vielen Dank für die Erstellung. Da ich eher vorsichtig bin habe ich auch gleich mit „Wiederherstellung“ das Zurückspielen von 2 Datenbanken real ausprobiert (SMF-Forum mit 60 KB, 2 sec. und Wiki, 240 KB 4 min). Funktioniert einwandfrei.

    Beste Grüße
    Rudi

  9. Santosh sagt:

    Vielen Dank für deine Mühe und dieser ausführlichen Anleitung. Danach hat endlich alles funktioniert. Hat mir echt gut geholfen. 🙂

  10. Pingback: MySQL-Datenbanken automatisch sichern mit MySQLDumper und all-inkl als Hoster » PERL, MySQLDumper, Datenbanken, Cronjob, Konfiguration, Datenbank » Nils Schulte am Hülse

  11. Matthias sagt:

    Moin! Erstmal vielen Dank für die Anleitung. Wenn ich das Backup per PEARL von Hand ausführe klappt alles wunderbar. Nur in der Mail vom all-inkl Cron bekomme ich in der Mail den Internal Server Error angezeigt. Einer eine Idee woran das liegen könnte? Vielen Dank!

  12. Jens sagt:

    @Matthias: Wie ist der Cron denn aufgesetzt? Ist das Verzeichnis mit einer .htaccess Datei geschützt? Vielleicht gibt’s irgendwo einen Tippfehler. Wenn das alles nichts bringt, würde ich mal den Support von All-Inkl darauf ansetzen und in die Server Error Logs schauen lassen.

  13. Matthias sagt:

    @Jens: Hab den Cron per KAS bei all-inkl eingerichtet. Dieser Cron liegt auf Server X. Cron greift dann einfach auf http://www.x.de/cgi-bin/crondump.pl?config=mysqldumper zu. Nutze für diese eine Seite die Standardkonfiguration vom Dumper, deshalb der Name. cgi-bin auf x.de ist nicht htaccess geschützt. Dieser soll dann im KAS eingestellt auf backups@Y.de die Mail senden. Mach ich was falsch?

  14. Jens sagt:

    Normalerweise sollte das funktionieren.
    Bekomst Du denn einfach nur keine Mail, aber das Backup wird vom Cronjob gemacht?
    Oder kommt gar nichts?

  15. Pingback: alexunil Ltd. » Blog Archive » Automatisches Backup mehrerer Datenbanken beim hoster all-inkl.com

  16. Avenger sagt:

    Ich habe den automatischen Backup via MySQLDumper und PERL-Script bei all-inkl einrichten können.

    Nachdem eine DB offenbar zu groß war, so dass das PERL-Skript in einen Timeout lief, und der Backup micht funktionierte, habe ich das mal weiter untersucht…

    Durch Analyse das

    Und bin letzten Endes bei der Frage angelangt: warum, um alles in der Welt, diese umständlichen Klimmzüge mit PERL???

    Denn man kann den automatischen MySQL-Dump auch sehr einfach der PHP-Version von MySQL-Dumper einrichten!

    Mit

    http://www.meine-domain.de/mysqldumper/dump.php?comment=Mein_Kommentar&config=mysqldumper&sel_dump_encoding=35

    kann man den Backup problemlos starten, mit eMail-Versand usw….

    Etwas tricky ist der Parameter „sel_dump_encoding“…

    („sel_dump_encoding=35“ z.B. wählt die utf-8 Kodierung)

    Wenn man andere Kodierungen hat, kann man deren numerischen Wert aus folgender Tabelle ablesen:

    Charset Description Default collation

    1 armscii8 ARMSCII-8 Armenian
    2 ascii US ASCII
    3 big5 Big5 Traditional Chinese
    4 binary Binary pseudo charset
    5 cp1250 Windows Central European
    6 cp1251 Windows Cyrillic
    7 cp1256 Windows Arabic
    8 cp1257 Windows Baltic
    9 cp850 DOS West European
    10 cp852 DOS Central European
    11 cp866 DOS Russian
    12 cp932 SJIS for Windows Japanese
    13 dec8 DEC West European
    14 euckr EUC-KR Korean
    15 gb2312 GB2312 Simplified Chinese
    16 gbk GBK Simplified Chinese
    17 geostd8 GEOSTD8 Georgian
    18 greek ISO 8859-7 Greek
    19 hebrew ISO 8859-8 Hebrew
    20 hp8 HP West European
    21 keybcs2 DOS Kamenicky Czech-Slovak
    22 koi8r KOI8-R Relcom Russian
    23 koi8u KOI8-U Ukrainian
    24 latin1 cp1252 West European
    25 latin2 ISO 8859-2 Central European
    26 latin5 ISO 8859-9 Turkish
    27 latin7 ISO 8859-13 Baltic
    28 macce Mac Central European
    29 macroman Mac West European
    30 sjis Shift-JIS Japanese
    31 swe7 7bit Swedish
    32 tis620 TIS620 Thai
    33 ucs2 UCS-2 Unicode
    34 ujis EUC-JP Japanese
    35 utf8 UTF-8 Unicode

    Bei „comment“ muss man auch aufpassen, dass da kein Leerzeichen enthalten ist (auch „%20“ oder andere URL-Kodierung als Ersatz hilft da nicht!), da die all-inkl-Cronjob-Definition dann die URL nicht akzeptiert.

  17. Jens sagt:

    @Avenger
    Ich habe das mal testweise auch so eingerichtet. Bei mir wird jedoch kein kompletter Dump erzeugt. Der Cronjob bringt als Fehlermeldung

    The requested URL /inc/mails/dump.php was not found on this server.

    Wundern tut mich das jedoch nicht, da das PHP Script des Dumpers zum Umgehen des Timeouts ja mit Selbstaufrufen arbeitet. Diese sind durch Javascript realisiert. Javascript wird jedoch in der lokalen Browserinstanz ausgeführt. Bei einem Cronjob kann dies also gar nicht korrekt funktionieren.

    Wenn Du Dein so erzeugtes Backup entpackst, steht am Ende der .SQL Datei ein „#EOB“?

    Solche Sachen gehören jedoch eigentlich nicht hier hin, sondern eher in das Support Forum des Dumpers unter http://forum.mysqldumper.de

  18. Xian sagt:

    Auch von mir ein herzliches Dankeschön. Dein Tutorial war eine große Hilfe bei der Fehlerfindung und hat mir auch einige neue Kniffe gezeigt.

    Vielen Dank,
    Christian

  19. uv22e sagt:

    Eine kleine Ergänzung: Wird unter Konfigurationsdateien bei all-inkl.com eine neue Konfiguration angelegt, übernimmt msd automatisch die datenbank von msd, wie auch an diesem Screenshot zu sehen ist:

    http://kochsiek.org/blog/wp-content/uploads/2010/05/Dumper_Tut_023.jpg

    später muss man dann die DB entsprechend unter dem Menüpunkt „Datenbanken“ wieder ändern. Dabei muss man zwei mal unter Datenbanken abspeichern, also ins Menü, raus aus dem Menü und wieder rein und speichern. Andernfalls werden die Daten nicht übernommen.

  20. uv22e sagt:

    sorry, wurde ja einen Schritt weiter unten erklärt.

  21. uv22e sagt:

    aber ich muss sagen, dass ich beim Aufrufen von

    domain.de/cgi-bin/crondump.pl?config=meine_config

    immer einen internal server error bekomme.

    Warum?

  22. Jens sagt:

    @uv22e: Schwer zu sagen, woran das liegt … Hast Du Dich schon mal im Support-Forum des Dumpers gemeldet?

    http://forum.mysqldumper.de

  23. Alex sagt:

    Wenn ich im Dumper auf „Backup“ „Backup PERL“ „Perl-Cronscript ausführen“ klicke, komm ich nur zu meiner HP statt wie oben beschrieben ein log, eine email erhalte ich auch nicht.

    >>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.>>

  24. Marco sagt:

    Erst einmal vielen Dank für diese Anleitung, mein Problem ist jetzt das meine db 160MB groß ist, da werde ich auch nicht weiter kommen wenn allincl die PERL Zeit hoch setzt. Gib es irgendwie die möglichkeit die db zu splitten so das immer nur Teile der db nacheinander gesichert werden ?

  25. Jens sagt:

    Hallo Marco!
    Man könnte theoretisch hingehen und für die selbe DB mehrere Konfigurationsprofile anlegen. Dann kann man als Tabellen-Präfix die einzelnen Tabellennamen angeben und so jeweils die Tabellen einzeln sichern. Dann braucht man aber auch für jede Tabelle einen eigenen Cronjob. Sehr praktikabel ist das nicht.
    Im Normalfall ist es aber auch so, dass die meisten Daten immer in einer Tabelle drinstehen, in einem Forum z.B. in der posts Tabelle. Hier wird man wohl schon alleine dort an das Perl-Timeout Limit stoßen.
    Im Grunde hilft da nur das Programm Wintrigger. Damit kann man das PHP Backup zeitgesteuert aufrufen. Dafür muss man natürlich einen (Windows-) Rechner haben, der zur fraglichen Backupzeit eingeschaltet ist.

    So gut All-Inkl.com auch sein mag – bei den Perl-Laufzeiten sind sie halt sehr restriktiv.
    Evtl. hilft die freundliche Nachfrage, ob das Limit nicht doch etwas (mehr) heraufgesetzt wird.

  26. Thomas sagt:

    Hallo Jens,

    zuerst einmal danke für das super Tutorial!

    Bei mir funktioniert die eMail-Zusendung des Backup-File bei all-inkl allerdings nur, wenn ich bei der all-inkl-Cronjoberstellung bzw. Editierung unter „Erweiterte Einstellungen“ die eMail-Adresse weglasse, weil diese wird ja schon über den MySQLDumper angesprochen. Das „doppelte“ Ansprechen führt offensichtlich dazu, dass nichts passiert…dies als ergänzender Hinweis für alle all-inkl’er…

    Zu empfehlen ist auch, dem cgi-bin-Verzeichnis ein Verzeichnisschutz zu verpassen!

    So long,
    viele Grüsse

  27. Jens sagt:

    Hallo Thomas,

    die E-Mail Adresse, die man bei der Cronjob-Einstellung angibt, ist für die Zusendung der Ausgabe des Cronjobs, also des Logs, welches vom Dumper generiert wird.
    Die Mail mit dem Backup als Anhang ist davon komplett unabhängig. Bei korrekter Konfiguration sollte man also zwei Mails bekommen, eine vom Dumper mit dem Backup als Anhang und eine vom Crondaemon mit der Ausgabe des Logs.

  28. Thomas sagt:

    Hallo Jens,

    danke für die umgehende Stellungnahme! Hab´s nochmals ausprobiert, leider funktionier´s bei mir nur, ohne die eMail-Adresse für das Log (?). Die Konfiguration ist aber stimmig (auch nochmals überprüft), ansonsten würde ja auch der „Rest“ nicht funktionieren…

    Ab dafür – Hauptsache es klappt.

    Nochmals danke für das wirklich gute Tutorial – bin eben erst mit einer Kunden-Domain zu all-inkl umgezogen und es hat mir sehr in Bezug auf die dortigen Cronjobs geholfen; den MySQLDumper habe ich auf einem Root-Server schon im Einsatz, sprich dazu war mir alles bekannt.

    Werde deshalb Deinen Beitrag hier in Kürze auf meiner Website verlinken.

  29. Pingback: Datensicherung JTL-Shop (Strategie)

  30. Michael sagt:

    Moin, super Anleitung.
    Das Manuelle Sichern funzt einwandfrei auch so das ich ne Mail bekomme nur beim einrichten des Cron happert es.
    Ich habe alles in die crondump.pl eingtragen so wie es beim Backup Perl steht.
    wenn ich nun auf Perl,Conscript testen gehe bekomme ich folgende Fehlermeldung :You don’t have permission to access /msd/msd_cron/perltest.pl on this server.

    Wieso ist das so wie es ist 😉
    Muß ich noch irgendwo ein Passwort eingeben

  31. Michael sagt:

    Hat sich erledigt,
    ich hatte ein Fehler beim cgi_bin Verzeichnis.

    Funzt alles einwandfrei

    Danke

  32. Rainer sagt:

    Danke für die sehr gute Anleitung, Hat ohne Komplikationen bei all-inkl.de funktioniert.

  33. Michael sagt:

    Vielen Dank für die gute Arbeit.
    Auch im Mai 2012 ist alles noch aktuell und funktioniert einwandfrei.

    Eine kleine Anregung zum Artikel:
    Die Verwendung von Zwischenüberschriften würde die Lesbarkeit noch etwas erhöhen. Z. B.

    MSD Download
    MSD Installation
    Dateirechte vergeben
    Verzeichnisschutz anlegen
    Konfiguration
    […]

  34. Matthias sagt:

    Super, vielen Dank für die tolle Anleitung!
    Funktioniert alles einwandfrei und nun habe ich eine sehr komfortable und einfache Verwaltung meiner Datenbank.

  35. Max sagt:

    Ich bedanke mich auch für die Anleitung. Ich brauch zwar wahrscheinlich den Cronjob nicht, aber deine ausführliche Anleitung für MySQLDumper wird mir mit Sicherheit meinen bevorstehenden Umzug mit einem anderen Blog erleichtern.
    Gruß, Max

  36. Marcel sagt:

    Danke für diese tolle Anleitung. Sieht sehr übersichtlich aus. Jetzt muss ich mich nur noch ans Eingemachte machen. 🙂

  37. Mattes sagt:

    Klappt auch mit der Version 1.24.4 ganz hervorragend 🙂

    Also, danke auch von mir für die klasse Anleitung!

    Mattes.

  38. tomtom sagt:

    two thumbs up!

  39. Kathryn sagt:

    Wow, herzlichen Dank auch von mir, das ist ja super einfach einzurichten!

  40. B. Horn sagt:

    Danke für die ausführliche Anleitung! Mit 6 Datenbanken bei all-inkl war der manuelle Backup nachher zu müßig. Automatisches Backup klappt nach dieser Anleitung wunderbar!

  41. Oliver Mast sagt:

    Prima Anleitung danke!

    Ich rufe meine beiden Konfigurationen genauso auf wie Du beschreibst, allerdings wird immer nur die Standard Konfiguration ausgeführt, egal welches der beiden Cronjobs ich starte. (config=konfi_1.conf bzw. confi=konfi_2.conf)

    Jemand ne Idee? Danke Olli

  42. Jens sagt:

    Also, „config=konfi_1.conf“ ist ja eh‘ nicht korrekt. Korrekt wäre „config=konfi_1“ …

  43. SF sagt:

    bei mir geht das nicht.
    Ich komm genau bis zum Schritt PERL-CRONSCRIPT AUSFÜHREN (wo man das testet). Weiter gehts nicht, es kommt ein Fehler. Ich vermute es liegt am cgi-bin-Ordner.

    Ich habe msd im root installiert. folglich auch cgi-bin im root angelegt. Alle Rechte sind korrekt, Dateien sind auch oben.

    Was mach ich falsch?!?

  44. SF sagt:

    genauerer Fehler:

    wenn ich in der Konfiguration /cgi-bin/ eingebe, kommt der Fehler:
    Internal Server Error

    The server encountered an internal error or misconfiguration and was unable to complete your request.

    Wenn ich es beim ursprünglichen msd_cron/ belasse, dann kommt dieser Fehler:
    Forbidden

    You don’t have permission to access /msd_cron/crondump.pl on this server.

    Was sagt mir das?!?

  45. Super, danke dir. Funktioniert bei mir unter all-inkl. einwandfrei. schauen ob ich es unter den anderen anbietern auch hinbekomme 😀

  46. Jan D. sagt:

    Vielen Dank für diese tolle Anleitung! 🙂

  47. Niko sagt:

    Herzlichen Dank!

    Eine sehr gute Beschreibung, die sogar für einen Rookie absolut verständlich ist!

  48. Tastenplayer sagt:

    Vielen Dank für die überaus gute Beschreibung. Dank dieser Anleitung habe ich es endlich geschafft, dass bei dem Backup der korrekte Absender in der E-Mail erscheint.
    Von dieser Materie verstehe ich nicht allzu viel. Habe trotzdem jetzt alles verstanden.

    Freundliche Grüsse Jutta Koliofotis

  49. Tastenplayer sagt:

    Ich habe vergessen zu erwähnen, dass bei mir nur eine E-Mail ankommt. Ob in der neusten dumper Version auch zwei ausgegeben werden müssen weiss ich nicht.

    MSD (Perl) – Backup of DB usr_web597_1

  50. Tastenplayer sagt:

    Leider kann ich ja die vorherige Antwort nicht löschen.

    Es ist so, dass ich ein E-Mail erhalte mit dem Backup und leider noch ein E-Mail von meinem Server, dass mein E-Mail nicht zugestellt werden konnte, da falsche Adresse!?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.