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

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

all-inkl.com webhostingIch 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 …

mysqld 0konfig

in das Untermenü Konfigurationsdateien:

mysqld 1konfig

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

mysqld 2konfig

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

mysqld 12konfig

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:

mysqld 13konfig

Jetzt speichern wir die Parameter:

mysqld 14konfig

Wenn wir jetzt zu den Konfigurationsdateien zurückkehren …

mysqld 1konfig

… 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:

mysqld 15konfig

 

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

mysqld 5backup

und klicke auf Backup Perl:

mysqld 6backup

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

mysqld 7backup

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“:

mysqld 3conscrkonfig

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

mysqld 4conscrkonfig

… und speicherst diese Einstellung …

mysqld 14konfig

Jetzt kannst Du auf „Backup“ wechseln …

mysqld 5backup

… und dort oben auf „Backup PERL“ klicken:

mysqld 6backup

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.

mysqld 7backup

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

mysqld 8log

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

mysqld 9log

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

mysqld 7backup

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.

all-inkl cron010menu

Dort klickst Du dann auf …

all-inkl cron020einrichten

… und gelangst so in folgende Übersicht:

all-inkl cron030einrichten

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 !

all-inkl cron040einrichten

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:

all-inkl cron050einrichten

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

all-inkl cron050timing

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:

all-inkl cron050email

Nun speicherst Du Deine Einstellungen:

all-inkl cron050speichern

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:

mysqld 22email

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”):

mysqld 23email

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 🙂 !

72 Kommentare zu „MySQL-Datenbanken automatisch sichern mit MySQLDumper und all-inkl als Hoster“

  1. Sowohl bei All-inkl. als auch beim MySqlDumper forum war der Support excellent – vielleicht ist eine Email an allinkl. einen Versuch wert.

    Viel Erfolg

  2. hallo nils,
    danke für die anleitung. funktioniert prima!

    bei mir läuft die benachrichtigung per mail übrigens auch mit sendmail. pfad hierfür:

    „/usr/sbin/sendmail“

    ahoi holmer

  3. Hallo,

    erstmal danke für die Anleitung. Stand vor den selben Grundvoraussetzungen (all-inkl und mysqldumper). Hab meiner Meinung nach auch alles so gemacht wie beschrieben.

    Test Perl, Test Perl-Modul funktionieren bei mir auch aber das Cron-Script steuert einen Download an. Cronjob von all-inkl aus führt auch nicht zum gewünschtem Back Up.

    Vielen Dank für eine Antwort

    Michael

  4. Hallo Michael,

    hmmm, ist ja schon 1/4 Jahr her seit ich das gemacht habe und seitdem habe ich nix mehr machen müssen … erwarte also keine Expertenantwort 😳

    Wenn das Betätigen des Buttons „Perl-Cronscript ausführen“ einen Downloadvorgang auslöst, bedeutet das, das das Script vom Server nicht als Perl-Script gewertet wird, sondern als x-beliebige Datei und daher wird bei Anforderung dieser Datei ein Download ausgelöst.

    Ich hatte das Anfangs auch, als ich noch dachte es wäre gleichgültig wo man bei all-inkl seine Perl-Scripte abspeichert (diese Info habe ich wohl fälschlicherweise irgendwo im Internet aufgeschnappt und geglaubt). Leider hatte ich damals dazu keine wirklichen Infos von Seiten all-inkl’s gefunden. Es klappte aber plötzlich als ich versuchsweise einen Ordner mit der Bezeichnung “cgi-bin” im Hauptverzeichnis erstellt habe und das Perl-Script dort abgespeichert habe.

    Meine Frage also an Dich: Hast Du Dein Script in einem Ordner namens “cgi-bin” (ggf. auch im Hauptverzeichnis der Domain) abgespeichert?

  5. Hallo Nils,

    lieber „keine Expertenantwort“ als gar keine.
    Zu deiner Frage:

    ich hatte einen Unterordner namens cgi-bin in den originalen mysqldumper Ordner gelegt. Damit kam das oben beschriebene Problem. Auch das Verschieben in den vorhandenen cgi-bin Ordner von all-inkl (im Hauptverzeichnis) ändert an dem Download Pop up nichts.

    Muss ich da noch was bei all-inkl freischalten lassen?

    Gruß

    Michael

  6. Da bin ich leider mit meinem Latein am Ende.

    Ich selbst habe nichts bei all-inkl freischalten lassen. Aber da meiner Erfahrung nach der Support sehr gut ist, würde ich dort ruhig mal anfragen. Falls das nicht hilft, würde ich mich an das MySQLDumper Forum wenden. Da gibt es sicher fachkundigere Helfer als mich.

    Ich drück Dir die Daumen, dass es klappt und würde mich freuen, wenn Du mir die Lösung Deines Problems (ich glaub mal einfach daran, dass es eine gibt) als Nachricht hinterlässt.

    PS.: Manchmal sind es ja schon Kleinigkeiten, die etwas verhindern. Ich würde es auch nochmal mit einer Neuanlage des cgi-bin Ordners im Hauptverzeichnis versuchen (also ohne Verschieben) und dort das Script reinkopieren. Dabei fällt mir ein: Hast Du beim Verschieben auch die Einstellungen im Dumper geändert (Pfad der Perlskripte)?
    Außerdem würde ich versuchsweise es auch nochmal mit der Dateiendung .cgi statt .pl probieren (Einstellung dann auch in MySQLDumper ändern).

  7. Hatte alles ausprobiert .pl -> .cgi etc.

    Ein Neuanlegen führte dann zum Erfolg.
    Tja, die Wege von IT sind manchmal unergründlich 😉

    Trotzdem vielen Dank.

    Ciao

    Michael

  8. Danke für die hervorragende Anleitung. Den bisher schnellen, freundlichen und immer kompetenten Service von all-inkl.com kann ich bestätigen. Wirklich eine Erholung, wenn man sich 1 Jahr lang 1blu gefühlt hat…

  9. Hallo miteinander,

    das ist ja eine prächtige Beschreibung für den Problemlösungsweg.
    Aber mal eine Verständnisfrage:
    wenn man wie beschrieben unter dem mysqldumper das Verzeichnis /cgi-bin/ mit den *.pl-Dateien anlegt, ist dann der Pfad für den Aufruf im externen Cronjob wie oben im Beispiel
    “http://www.meinedomain.de/cgi-bin/crondump.pl?config= mysqldumper.conf.php”
    richtig?

    Müsste der nicht so aussehen: … ??

    “http://www.meinedomain.de/mysqldumper/cgi-bin/crondump.pl?config= mysqldumper.conf.php”

    Oder mach ich hier einen Gedankenfehler ?

    Gruß
    Werner

  10. Hallo zusammen,

    erst einmal ein dickes Danke für die perfekte Beschreibung!

    Bei mir hat das erwähnte Verzeichnis /cgi-bin/ unter dem mysqldumper-Verzeichnis nicht funktioniert. Erst als ich die drei Dateien in das (bereits vorhandene) /cgi-bin/ unter dem Hauptverzeichnis kopiert habe (sowie es ja im restlichen Text eigentlich auch dargestellt wird) hat alles wunderbar geklappt.

    LG,
    Egon

  11. Hi!

    Versuche gerade das hinzubekommen bzgl. Cronjobs.

    Stoße jetzt auf zwei Varianten von Problemen.

    1. Wenn ich den cgi-bin Ordner im mysql_dumper Verzeichnis anspreche, bekomme ich eine Fehlermeldung:
    You don’t have permission to access /mysql_dumper/cgi-bin/simpletest.pl on this server

    2. Wenn ich den cgi-bin Ordner im root Verzeichnis verwende, geht bei mir das Download-Fenster auf.

    Schade es war alles so super erklärt und ich dachte, es läuft alles easy.

    Hat noch jemand einen Tipp?

    @ Michael
    Ein Neuanlegen von was und wo hat bei dir zum Erfolg geführt?

    Gruß

    Smartsoul

  12. Okay hat sich erledigt!

    Meine Files und Ordner waren nicht genau auf 755-Rechte eingestellt.

    Nobody is perfect und ich schon lange nicht! 😉

    Gruß

    Smartsoul

  13. Bin grade im Urlaub mit nur begrenztem Internetzugang, daher meine verzögerte Antwort.

    @Werner

    Du hast im Grunde Recht. Allerdings gehe ich mittlerweile davon aus, dass Perlscripte bei all-inkl nur in einem eigens dafür angelegten „cgi-bin“ Ordner im Hauptverzeichnis der jeweiligen Domain ausgeführt werden. Ich werde bei Gelegenheit die Anleitung nochmal überprüfen und die Info einarbeiten … aber erst nach meinem Urlaub 😉 !

    @Smartsoul

    Danke für die Blumen! 🙂

    Allerdings weiß ich von keinen Videos 😕 … falls Du die Screencasts auf der MySQLDumperseite meinst, dann sind die nicht von mir.

  14. Ja, die meinte ich wohl! Musst dir den Strauß ja nicht ins Fenster stellen.

    Zu all-inkl.com möchte ich noch erwähnen, dass die Pfadangabe für sendmail, zumindest in meinem Account, /usr/sbin/sendmail -t (man beachte den Parameter) heißen muss, damit der E-Mail Versand auch unter Perl funktioniert.

    Und …
    Bei mir hat es auch nur mit den Perlscripts im Standard cgi-bin Verzeichnis funktioniert.

    Gruß und noch einen schönen Urlaub 🙂

    Smartsoul

  15. Super Anleitung.

    Musste nur noch bei unserem all-inkl.-Modell das DBI::mysql Perl-Modul nachladen lassen. Aber bei all-inkl. geht sowas ja immer fix.
    Nun läuft alles soweit…
    Bis auf…jetzt kommt’s…Timeout-Probleme bei einer bestimmten Tabelle, da unsere DB 37MB (knapp 9MB gzip) groß ist. Und das häuptsächlich auf dieser einen Tabelle (Ihr ahnt schon: die Beiträge eines Forums).

    Jetzt muss ich schon wieder all-inkl. anhauen, ob sie das Perl-Timeout nicht evtl. heraufsetzen.
    Frage mich nur bis zu welcher Größe das dann gut geht.

    Trotzdem wollte ich kurz mein Lob und Dank ausprechen.

    Grüße 🙂

  16. Hi, ich nutze seit Jahren All ink, so dass ich davon aus ging, dass die meisten Hoster wie all inkl sind, aber 1blu konnte mich (wollte mal eine andere ip bzgl. seo) überzeugen, dass all ink leider einer der weniger Klasse-Hoster ist.

    Wieso ich kommentiere?
    1. Ich habe Deine tolle Anleitung genossen und habe Sie auch so laufen gehabt, aber das TIMEPUT-Problem von All ink wird alle treffen mit einer großen Datenbank! Oder haben die was geändert?
    2. Die Lösung von All inkl. ist auch ok (habe das backup zwei Mal gebraucht und konnte es mit phpmyadmin problemlos einspielen):
    http://all-inkl.com/anleitungen/datenbank/phpscripte/db_backup_anlegen.html?PHPSESSID=2ebd53888eb081b3121c35a5c6e3a103
    http://all-inkl.com/anleitungen/datenbank/phpscripte/db_backup_anlegen_email.html?PHPSESSID=2ebd53888eb081b3121c35a5c6e3a103

    Gruß Tim

  17. danke für diese wirklich sehr gute anleitung. auch ich hatte das timeout problem bzgl. der perl-skripte bei all-inkl. hat man jedoch einen managed server, ist es kein problem den timeout von standardmäßigen 7 sekunden deutlich erhöhen zu lassen. bei mir sind es nun 40 sekunden und das ganze läuft mit einer >60mb großen datendank ohne probleme.

  18. Hallo,

    Danke für Deine tolle Hilfe, endlich läuft es.

    Kann das sein, dass die Sicherung per CronJob wesentlich kleiner ist als eine „manuell“ erstellte? Sonst haben wir rund 54 MB bei einer Datensicherung gehabt, nun sind es knapp 4 MB, aber die Tabellenanzahl stimmt überein und die Einträge weichen logischerweise ein wenig ab.

    Vielen herzlichen Dank!!!!!

    Jörn

  19. Hallo Jörn,

    also das klingt mir leider sehr danach, als wenn bei Dir die zeitliche Perl-Scriptbegrenzung von all-inkl zugeschlagen hat. Die Differenz von 50 MB ist einfach zu groß. Die Tabellen werden meine ich als erstes erzeugt, daher sind auch alle da. Es fehlen Dir sicher eine Menge Einträge. Genauere Aussagen erhälst Du eher im MySQLDumper Support Forum.

    Ich habe die Emailbenachrichtigung aktiviert und erhalte so immer eine Art Log-Datei zusätzlich per Email zugeschickt. Da kann ich einigermaßen nachverfolgen, ob mit dem Script alles geklappt hat.

    Ggf. bei all-inkl anfragen, ob sie das Timeout für Perlscripte hochsetzen können.

  20. Ich habe genau das Timeoutproblem bei allinkl. wie du es hattest. Ein Anruf beim Support war jedoch recht ernüchternd: Der Bitte des Anhebens des Timeouts wird nur bei eigenen bzw. angemieteten Servern nachgekommen. Nicht jedoch bei Shareed-Servern wie in meinem Fall. Ich habe den Privat-Tarif.
    Ganz schöner Mist. Somit kann ich mit dem MySQLDumper genau so wenig anfangen wie mit der phpBB3 eigenen Backup-funktion, nämlich nichts. Schade!

  21. Ich hätte mir das hier auch gern eingerichtet, allerdings kommt bei mir die Zeile: „Wenn Du diese Zeile hier siehst, dann wird Perl nicht ausgefuehrt.“ Obwohl mein Hoster Perl anbietet und dies auch in meinem Paket enthalten ist. :/
    Woran könnte das nur liegen?

  22. Ich habe hier mit Begeisterung die Anleitung gefunden und bin noch dabei es einzurichten.

    Ich weiß nicht, ob es bereits erwähnt wurde (habe mir nicht alle 60 Kommentare durchgelesen), aber es gibt bei all-inkl die Möglichkeit eine .htaccess-Datei in’s Root-Verzeichnis des FTP zu legen und folgende Zeile einzufügen:
    Options +ExecCGI

    Diese bewirkt, dass PERL-Skripte nicht mehr nur aus dem cgi-bin-Ordner aufgerufen werden müssen, sondern irgendwo auf dem FTP liegen können. Der Ordner, in dem die Skripte liegen, muss lediglich die CHMOD 755 eingestellt haben. Nicht mehr und nicht weniger.

  23. Marcus Raschke

    Vielen Dank für diese tolle und ausführliche Beschreibung.
    Ich habe bis jetzt meine MSD Dumps immer per Hand ausgeführt und zudem noch in sehr unregelmäßigen Abständen !
    Da ich auch bei All-Inkl bin , freut es mich natürlich sehr, dass sich jemand soviel Mühe gemacht hat um anderen Usern das Leben mit MSD und Cronjobs zu erleichtern !

    Respekt !!!

    Weiterhin viel Spass und Erfolg !!!

  24. Hab das gerade mal nach deiner Anleitung gemacht und funzt ganz wunderbar! Sogar die automatischen Emails haben auf Anhieb funktioniert.

    Herzlichen Dank für den tollen Beitrag

    Henning

  25. Hallo Nils,
    Vielen Dank für diese wirklich sehr hilfreiche Beschreibung.
    Hatte mich bisher nicht rangetraut an automatische backups.

    Eine Kleinigkeit zur Verbesserung: Du schreibst „Jetzt legst Du einen Ordner mit der Bezeichnung “cgi-bin” im MySQLDumperverzeichnis an.“ bei mir funktionierts nur, wenn ich die ins Hauptverzeichnis lege, bzw. die dort bereits befindliche benutze. Du korrigierst das zwar gleich in der nächsten Zeile aber das verwirrt. Ich habs zwei mal machen müssen….nur so als Anregung gemeint.
    Vielen Dank nochmal

  26. Hallo, danke für das tolle Tut, jedoch habe ich ein Problem, beim manuellen Test von dem Backup per Pearl-Conscript hängt er sich mittig auf, das erzeugte Backup hat auch nur knapp die Hälfte an Größe, statt ca. 13MB lande ich hier bei ca. 5MB. Woran kann das liegen? Bitte um Hilfe.

  27. Wie schon mehrfach beschrieben, erlaubt all-inkl wie fast alle Hostinganbieter nur eine begrenzte Laufzeit für Skripte. Bei zu großer Datenmenge (und ‚groß‘ ist hier sicher nicht viel) wird das Skript einfach unterbrochen und das Backup wird mittendrin unterbrochen.

    Ich habe gerade gestern bei Cashy den Hinweis auf zwei interessante WordPressplugins gelesen, die für ein automatisches Backup nicht nur der Datenbank zu verschiedensten Zielorten wie z.B. Dropbox oder Amazon S3 sorgen sollen:

    1. wp Time Machine
    2. Updraft

    (von mir noch nicht getestet)

  28. Pingback: HerrKronens Blog » Blog Archive » Automatisches Sichern der Datenbank

Kommentar verfassen

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