Hallo liebe Leser! Also heute hatte ich mal eine schlaflose Nacht, denn mein TikiWiki ist gecrasht und zwar total. Als ich mich im Backend einloggte, war das Backend zerschossen, als ob CSS nicht dargestellt wurde und so probierte ich dies und jenes aus. Manche Optionen im Control Panels waren nicht erreichbar und ich sah nur eine weisse Seite im Backend.
Ich setze TikiWiki 15.0 ein, so wie es in Control Panels steht und so suchte ich lokal nach der letzten Tiki-Version, um es hochzuladen. Ich dachte, es würde das Problem lösen. Doch dann nach einer Weile Hochladen, was bei einem Paket von sagenhaften 200+ MB, mehr als eine ganze Stunde dauern würde, refreshte ich die Webseite im Frontend und sieh da, eine weisse Seite. Da habe ich es schon fast geahnt, dass nach dem kompletten Hochladen ebenfalls eine weisse Seite angezeigt wird.
Gehofft habe ich, dass der Hochladevorgang das Frontend irgendwie sperrt und nicht darstellt. Aber das ist Quatsch, denn die Datenbank war in Ordnung und alles andere stimmte soweit so gut auch. Also grübelte ich weiter und brach das Hochladen erstmals ab. Ich wäre eingeschlafen, so beim Anstarren des Displays und etwas anderes wollte ich nicht machen. Das Problem beschäftige mich mehrere Stunden, bis ich es löste, aber alles der Reihe nach 🙂
Also meldete ich mich schnell bei meinem Webhoster und bat ihn darum, mir im FTP-Account das letzte Datenbank-Backup abzulegen, was auch klappte. So lud ich die .gz-Datei herunter, sie war nur 8 MB gross, da ich noch nicht so viele Inhalte im TikiWiki aufzuweisen habe. Also alles herunterladen, lokal entpacken, mit dem HTML-Editor Phase 5 öffnen, wieder als .sql-Datei speichern und via SSH-Console einspielen. Da begann schon die Kunst des Suchens in Google und wie man das anstellen kann. Möglich ist mit SSH ja alles Mögliche und auch das Hochladen, Packen, Entpacken, Löschen der Verzeichnisse, Dateien, Pakete und so weiter und so fort.
Einspielen des Backups in die Datenbank mittels SSH
Man lädt die SQL-Datei in ein Verzeichnis hoch, ich habe den Tikiwiki in /tikiwiki von Internetblogger.de, also lud ich es hier hinein. Dann loggte ich mich in Putty mit meinen SSH-Daten ein und navigierte zum Verzeichnis /tikiwiki mit diesem Befehl.
cd /tikiwiki
Dann war ich drin und nun hatte ich ja schon das Backup auch drin und musste diesen Befehl eintippen, um das Backup in die aktuelle Datenbank einzuspielen.
mysql -h localhost -u Benutzername -pPasswort Datenbank < backup.sql
Das klappte super fix und ich war schon mal froh sowie einen wichtigen Schritt weiter. Da die Datenbank nun top aktuell und von gestern war, musste doch das Frontend wieder angezeigt werden, dachte ich. Nein, ganz und gar nicht und da war der Hund wahrscheinlich ganz woanders begraben. Die Ursache für das heutige Problem konnte ich letztendlich nicht finden. Ich war ja im Backend und habe nur ein neues Theme eingestellt und schon war alles zerschossen. Vermutlich oder möglich wäre es, dass es am internen Cache lag.
Also die Datenbank wiederhergestellt und nun musste ich erstmals alles vom FTP löschen, was ich mit diesem Befehl in der Konsole via SSH machte.
rm -rf tikiwiki/
Dann war alles binnen Sekunden weg. Ihr müsst es euch so vorstellen, dass mehr als 200 MB vom FTP-Account im Nu entfernt wurden. Das dauert manuell per FTP eine ganze Ewigkeit und so viel Geduld konnte ich leider nicht aufbringen. Erfolg musste her und zwar schnellstens 🙂
Also alles gelöscht und dann das neue TikiWiki-Installationspaket hochgeladen. Dazu fand ich lokal das entpackte Paket, machte mit dem Tool WinRAR daraus ein ZIP-Paket und lud es ins Verzeichnis /tikiwiki hoch. Das ging schnell, denn das ist immer so. Das gepackte Paket war nur 70 MB gross anstatt des mehr als 220 MB grossen Paketes und so ging es recht zügig beim Hochladen.
Also was macht man dann?? Danach muss man es via SSH entpacken und dazu dient dieser Befehl.
unzip trunk.zip
trunk.zip war mein ZIP-Paket und so sah ich in der Konsole die Zeilen nur noch so entstehen, was auch bedeutete, dass fleissig entpackt wurde. Euch wird/werden via SSH alles und auch Misserfolge angezeigt, wenn etwas falsch, ein falscher Befehl oder eine Datei fehlt oder oder oder. Inzwischen arbeite ich oft mit der Konsole und was besseres gibt es vielleicht nicht.
Also alles hochladen und nun installierte ich den TikiWiki in der Version 15.0 neu. Das klappte auch und danach habe ich die Datei /db/local.php mit dem HTML-Editor geöffnet und die Datenbank-Daten meiner alten Datenbank eingetragen. Dann passierte beim Refreshen der Seite im Frontend folgendes. Es wurden die Module und Plugins angezeigt, die nicht geladen werden konnten. Ich musste lediglich die Haken setzen und auf Ändern klicken. Dann war es auch schon geschehen, der TikiWiki war wieder der alte und vorhanden.
Ich habe nur noch ein anderes Theme aktiviert und war ja so froh, dass ich diese Leistung mitten in der Nacht vollbringen konnte. Dank Google, meiner Intuition, FTP, Webhoster, Konsole klappte es dann doch noch.
Ich habe immer noch keine Ahnung, warum der TikiWiki gecrasht war und werde es wohl nie erfahren, denn ich fand keinen error.log in der Installation und nur auf dem Server ist es irgendwo.
Beim Installieren des TikiWikis kann man in einem der Schritte den Debug aktivieren, was nur für die Admin zu sichten sein wird. Das machte ich auch heute, aber vermutlich machte ich es vorher nicht. Es war alles nur noch eine weisse Seite. Ihr könnt noch via PHPmyAdmin in der Tabelle tiki_preferences beim error_reporting_level den Code 2047 eintragen, damit Fehler im Frontend sichtbar sind. Das fand ich erst nach Stunden heraus und machte es auch, aber alles nutzlos gewesen, denn dargestellt wurde rein gar nichts 🙁
Also diese Lösung half mir dann, die ich oben erwähnte. Ich hoffe nur, dass der Tiki ab jetzt brav bleibt, denn eine weitere Nachtsession mit solchen Problemen will ich nicht haben. Ich konnte gute Erfahrungen sammeln und weiss nun mehr über das Ganze.
Vielleicht dient dieser Bericht allen anderen Nutzern, die ebenfalls solche Sachen erleben werden. Ich weiss es nun aus Erfahrung, solange man eine funktionierende Datenbank und ein Backup davon hat, ist fast alles gerettet. Anders wäre es, wenn per FTP alles kaputt ist und die Inhalte nicht in der Datenbank, sondern in den Text-Dateien im FTP-Account abgelegt werden. Aber da muss man mit dem eigenen Webhoster wegen einem solchen Backup reden. Ich habe mich inzwischen durch die zusätzliche Festplatte gut abgesichert, denn es ist bei meinen CMS unverzichtbar geworden.
Nun kann ich erstmals chillen und heute ist auch noch der Kommentiersonntag bei mir, aber vielleicht erstmals einschlafen.
by Alexander Liebrecht