Datenbank-Sicherung
Regelmäßige Datensicherungen sind das Bloggers erste Bürgerpflicht, besonders vor einem Update auf eine neue WordPress-Version. Bei Strato gibt es dafür eine über den Kundenbereich erreichbare Version von phpMyAdmin. Diese habe ich bisher auch ohne Probleme genutzt, auch wenn sie bisweilen etwas träge daherkam.
Vor dem Update auf WordPress 2.7 habe ich natürlich auch erstmal eine Datenbanksicherung gemacht, zum Herunterladen wähle ich gewohnheitsmäßig die Option „GZip-komprimiert“. Die Datei ’schnurpsel_251_create.sql.gz‘ wurde gespeichert, alles in Ordnung, dachte ich, dann kann es mit dem Update ja losgehen.
Das Update auf WP 2.7 lief zunächst erstmal ohne Probleme, ich konnte mich in Adminbereich anmelden, das Blog selbst sah auf gut aus. Doch dann plötzlich gibt es beim Speichern eines neuen Artikels einen bösen Fehler 500, mit das schlimmste, was so passieren kann. Der Server hat da ein schwerwiegendes Problem. Nachdem ich zunächst nur einen kurzen Schwächeanfall des Servers oder der Datenbank vermutete wurde es aber leider nicht besser. Auch das Blog selbst meldete nur noch den 500er.
Sollte WordPress 2.7 etwa die Fehlerursache sein? Na gut, ist auch kein Beinbruch, ich hatte ja meine Kopie vom alten WordPress, also einfach die Verzeichnisse wieder umbenennen, die Datenbanktabellen löschen und die Datenbanksicherung zurückspielen. Doch was ist das? Da fehlen Tabellen, die Liste hört irgendwo bei ‚wp_posts‘ auf, da kommen doch eigentlich noch die Tag/Kategorie-Sachen (wp_term*) und die User-Tabellen (wp_user*). Hat beim Datenimport was nicht geklappt?
Die Datenbank-Sicherung ist praktisch eine Textdatei mit SQL-Anweisungen, also ganz normal als Text lesbar. Sie wird nur mit GZip gepackt. Beim Doppelklick auf die Datei meldet mir 7Zip jedoch nur:
Das Problem
Ein Blick in die .sql.gz-Datei offenbarte dann das Dilemma, die Daten dort sind überhaupt nicht gepackt, sie stehen da als lesbare SQL-Anweisungen drin, und was noch viel schlimmer ist, die Daten sind direkt nach dem Artikel mit der ID 27 zu Ende, da kommt nichts mehr, EOF.
Dann fiel mir das „Strato Backup-Control“ ein, da werden regelmäßg meine Daten gesichert auf die ich dann über eine spezielles FTP-Login zugreifen kann. Vielleicht gibt es da auch eine Datenbank-Sicherung. Nein, ist leider nichts von Datenbanken zu finden, die Sicherung betrifft nur die Dateien im Webspace.
Das bestätigt mir telefonisch auch ein Support-Mitarbeiter von Strato, der mir dann aber gleich noch zu einem Upgrade auf das Paket „PowerPlus L“ (€ 14,90 im Monat) rät, da wäre dann auch ein Datenbank-Backup enthalten.
Dumm gelaufen, würde ich sagen. So habe ich halt meine letzte Sicherung vom April 2008 eingespielt und da ich in der Zwischenzeit hier nicht besonders aktiv war einfach die verlorengegangenen Artikel per Hand (aus dem Google-Cache) nachgetragen.
Aber was war passiert, hatte ich mich einfach nur zu blöd angestellt, mit phpMyAdmin eine Sicherung zu machen? Nun wollte ich der Sache auf den Grund gehen.
Also habe ich die unterschiedlichen Varianten bei der Sicherung durchgespielt, einmal unkomprimiert, dann Zip und auch GZip. Bei unkomprimiert und Zip ist alles in Ordnung, nur bei GZip tritt der Fehler reproduzierbar auf. Die Daten werden nicht komprimiert und fatalerweise irgendwann einfach abgeschnitten.
Also rufe ich nochmal beim Strato Support an und schildere meine Beobachtung. Der Supportmitarbeiter kann nach meiner Anweisung das Problem sogar reproduzieren, hat aber auch keine Erklärung dafür und gibt es per Service-Ticket an die Technik weiter. Die Antwort kommt ein paar Tage später per E-Mail:
Sie haben berichtet, dass Datenbanken über die MYSQL-Datenbankverwaltung nicht komprimiert werden können.
Wir haben diesen Sachverhalt geprüft und konnten keine Beeinträchtigung feststellen. Die Datenbank DBXXYYZZ wird gzip komprimiert als *gz Archiv mit 196KB (entpackt 894KB) angeboten…
Eventuell wird die Übertragung clientseitig angebrochen.
Langsam kamen mir Zweifel, habe ich doch etwa selbst irgendeinen Fehler gemacht? Oder ist mein Anliegen bei der Technikabteilung nicht richtig angekommen? Also rufe ich zum dritten mal an und werde schließlich zur Technik weiterverbunden.
Nach einigem hin und her fragt mich der Techniker, was ich denn eigentlich wolle. Wenn ich meine Daten sichern will, würde das schließlich funktionieren, halt nur unkomprimiert und mit Zip, und das GZip nicht funktioniert sei eher mein Problem. Der „WebDatabase Manager“ sei ohnehin nur eine Zugabe und nicht Vertragsbestandteil. Er rät mir sogar für die Datenbanksicherung selber entsprechende Tools zu installieren, etwa mySQLDumper. Egal, es hilft ja nicht weiter, sich zu streiten, nach 20 Minuten war das Gepräch beendet.
Im übrigen wird mit dem „WebDatabase Manager“ (phpMyAdmin) als „Strato Profi Feature“ geworben, dann sollte sowas auch richtig und vor allem zuverlässig funktionieren. Und auch die Tatsache, das der Datenexport mit Zip-Komprimierung funktioniert, hilft nicht wirklich weiter, denn beim Datenimport wird Zip nicht unterstützt.
Die Ursache
Irgendeinen Grund muß es ja haben, das bei mir, und auch beim zweiten Support-Mitarbeiter die GZip-komprimierung fehlschlägt. Mehr durch Zufall bin ich dann drauf gestoßen, denn überraschenderweise trat genau das Problem auch bei meiner lokalen phpMyAdmin-Installation auf, die noch eine relativ alte 2.6er Version war (2.6.3, bei Strato immer noch 2.6.4).
Sollte es doch irgendwie am Client, sprich Browser, liegen? Also probierte ich die GZip-Sicherung mal testweise mit dem Internet-Explorer und siehe da, alles ist bestens. Hmmm, eigentlich hatte das immer auch mit dem Firefox funktioniert, warum denn nun auf einmal nicht mehr? Könnte es am neuen Firefox 3 liegen, lange Zeit noch hatte ich den 2er in Benutzung. Die Vermutung bestätigt sich nach einem kurzen Test, auch mit dem Firefox 2.x gibt es keine Probleme, eine ordentliche GZip-Datei wird gespeichert.
Der Rest ist dann schnell ermittelt, es gibt tatsächlich eine Problem mit phpMyAdmin und dem Firefox der 3er Reihe im Zusammenhang mit GZip, welches vermutlich bei allen phpMyAdmin-Versionen bis Version 2.11.6 auftritt und mit Version 2.11.7 gefixt wurde.
Und was kann Strato nun dafür? Ganz einfach, die haben da einen mehr als drei Jahre alten phpMyAdmin zu laufen, auf den sich der Kunde möglicherweise verläßt. Dabei schreibt Strato in den FAQ zu phpMyAdmin sogar unter Anmerkung, daß man regelmäßig, etwas einmal jährlich, Updates bereitstellen will:
Evtl. auftretende Sicherheitsrisiken oder bekannte Bugs in phpMyAdmin werden von uns selbstverständlich sofort entfernt.
Updates oder Versionsänderungen werden voraussichtlich einmal im Jahr durchgeführt.
Im übrigen sieht es bei 1&1 bezüglich der Datenbanksicherung auch nicht besser aus, dort läuft ebenfalls noch die alte phpMyAdmin-Version 2.6.4-pl3 als „MySQL-Control-Center“ und auch dort funktioniert der Export mit GZip-Komprimierung nicht. Immerhin gibt es bei 1und1 noch eine funktionierende BZip-Kompression, die man dann sogar wieder importieren kann.
Keine Probleme gibt es hingegen bei All-Inkl, da läuft phpMyAdmin in der Version 2.11.7 und Host-Europe mit dem der fast ganz akuellen 2.11.9.1er Version.
Fazit
Zunächst muß ich mir an die eigene Nase fassen, denn man sollte grundsätzlich überprüfen, ob die Datenbanksicherung auch tatsächlich lesbar ist. Nur darauf zu vertrauen, das alles geklappt hat, wenn die Datei auf dem eigenen Rechner liegt, reicht nicht.
Andererseits muß ich die Nutzer von Shared-Webhosting-Paketen bei Strato und 1und1 davor warnen, auf die vorinstallierten Datenbanktools der Anbieter zu vertrauen. Die derzeit dort laufende phpMyAdmin-Version 2.6.4-pl3 ist mehr als drei Jahre alt und hat reproduzierbare Fehler, die zu Datenverlusten führen können.
Man sollte sich entweder selbst eine aktuelle phpMyAdmin-Version installieren oder auch andere Werkzeuge zur Datenbanksicherung, wie mySQLDumper, verwenden.
Ohejeee… da bin ich ja noch gut weggekommen *ihn tröstet* Sind das Lockangebote von Strato? Auf Strato waren wir mit unserer Musikseite, sind dann weg, wie diese unsägliche Geschichte mit den Servern und der Kundenbetreung war. Auch schon ewig her.
Naja, die Geschichte geht ja noch weiter, aber da hab ich jetzt keine Lust mehr, ist mir zu spät. Den Rest schreibe ich morgen.
Und glücklicherweise ist das hier nur mein Test- und Zweitblog, da stecke ich so Probleme auch mal generös weg. Ursprünglich habe ich das hier eigentlich damals nur gestartet, weil so viele im WP-Forum über Strato meckern. Insbesondere die mangels mod_rewrite nicht funktionierenden Permalinks hatten meinen Ehrgeiz angestachelt, ich hatte es ja dann schließlich auch geschafft, daß es funktioniert. Wenn ich da noch an die Sache mit dem Datenbankfehler oder dem „ohne www“ denke, auch die Probleme konnte ich lösen.
Ich bin hier sowas wie der WordPress-bei-Strato-ein-Mann-Freizeit-Support, gedankt haben die mir das aber noch nicht :-)
Tja Schnurpselchem das ist im Leben und fast überall so. Die Problemchen lösen andere, warum sich dann nen Kopf machen. Aber mach du mal, die User sind bestimmt über den ein-Mann-Stato-Support richtig froh :-)
Fällt mir gerade ein: Kannst du da mySQLDumper da einsetzen? Als Alternative für die 14, 90?
http://www.mysqldumper.de/
Ja genau, mySQLDumper ist gut. Habe ich jetzt mal installiert.
Da die Dump-Dateien auf dem Webspace abgelegt werden, werde sie sogar vom „Strato Backup-Control“ mit gesichert. Werde ich mir noch irgendwo einen Cron-Job installieren, der das dann einmal täglich automatisch macht.
Jaja das liebe Problem mit den Backups ;-)
mySQLDumper ist eine feine Sache und die Idee mit den Cronjobs würde ich auch jedem entfehlen. Bei mySQLDumper gibt es weiterhin die Option unter Konfiguration > automatisches löschen die Anzahl der Datenbankbackups zu begrenzen (wird die hier gewählte Anzahl überschritten wird das älteste Backup gelöscht).
@Schnurpelchen: Cron-Job schon irgendwo eingerichtet?
Strato, mySQLDumper & Cron nicht wirklich outofthebox … :-(
@mg
Nein, im Moment nutze ich aus Zuverlässigkeitsgründen eine externe Datenbank. Ich warte mal noch die angekündigte Aufrüstung der Datenbankserver ab und hoffe, daß dann alles besser wird :-)
Entschuldige bitte, das ich Deinen Kommentar abgewiesen hatte, mein Antispam-Plugin war mit dem Kommantarformular auf der Startseite etwas überfordert.
Viel besser ist es nach der angekündigten Aufrüstung nicht geworden, oder?
Apropos Backup: Ich verwende jetzt das Plugin WP-DB-Backup (http://wordpress.org/extend/plugins/wp-db-backup/) – kann Schedulen … :-)
Scheinbar nicht.
Ein deutlicher Hinweis, daß es eben nicht nur an WordPress liegt ist die Tatsache, daß auch die Strato-Datenbankverwaltug grottenlangsam reagiert. Komischerweise ist davon aber nur MySQL5 betroffen. Bei MySQL 4 gibt es die Probleme nicht.
Außerdem läuft nun immer noch das hundealte und fehlerhafte „phpMyAdmin 2.6.4-pl3“.
Ups, ist mir noch gar nicht aufgefallen. Mit welcher MySQL Version läuft bei dir WordPress?
Sollte ich viellеiсht meine DB für WordPress bei Strato downgraden?
Was für inkompetente Leute arbeiten da überhaupt bei STRATO AG…!? Hääääh, Server, DNS, phpMyAdmin…!?!?!? Ein Glück, ich habe den Backup schon vorher getestet, und auch gemerkt, dass die Datei viel kleiner ist.
WARNUNG (Datenverlust): Es ist nicht möglich über STRATO`s phpMyAdmin funktionierende Backups zu erstellen.
initiant
Ich hatte ein ähnliches Problem auch vor kurzem mit dem WordPress Database Backup Addon. Die GZ-Dateien konnten nicht richtig entpackt werden. Gelöst habe ich das Problem in dem ich auf den Packer 7Zip umgestiegen bin. Dort konnte ich auf einmal die vorher angeblich kaputten Datein doch entpacken. Lag also vermutlich am packer. Das WP DB Backup Addon funktioniert sonst aber eigentlich ohne Probleme und mach seine Arbeit bisher immer zuverlässig im Hintergrund.