Unbrauchbares Cpanel-Restore

Es hat Jahre gedauert bis ich heraus fand, dass es am Restore von cpanel liegt, wenn eine Homepage mehr oder weniger unerwartet kaputt wurde. Es ist „normal“, dass von Zeit zu Zeit Hardware defekt wird oder ein Server neu aufgesetzt wird. In diesem Fall macht der Hoster ein Restore und alles sollte wieder ok sein.

Früher hat das Restore von einfachen Webseiten auch gut geklappt, mit meinem Webalbum hatte ich aber schon Probleme und mit diesem Blog auch.

Vor kurzem war es wieder mal so weit und dieses Mal wollte ich der Sache auf den Grund gehen, was da beim cpanel-Restore daneben geht.

Die Menalto-Gallery brachte nur mehr Fehlermeldungen,
das Serendipity-Blog lud in chaotischer Darstellung zu einer Installation ein,
2 Joomla-CMS brachten viele Fehlermeldungen,
die Drupal-CMS sahen oberflächlich gesehen nach dem Restore nicht beschädigt aus

Ich vermute, dass es nicht an den Restore-Optionen des Hosters liegt, da ich ja bei den früheren Hostern ähnliche Probleme hatte.

Die Fehlermeldungen ließen vermuten, dass es mit den Berechtigungen ein Problem gibt und mein erster Verdacht fiel auf die nobody-Dateien und genau das war das Problem. Mehr als 10000 Dateien hatten im Vergleich keine nobody-Rechte mehr und dann braucht man sich nicht zu wundern, wenn cpanel nicht 1:1 zurücksichert, dass die Webseiten nicht mehr funktionieren. Teilweise gab es auch eine wundersame Dateienvermehrung.

Da ich am Webserver zwar mit ssh zugreifen kann, aber keine Administrator-Rechte habe, ist es schwierig nobody-Rechte zu setzen. Ich habe daher die Rechte auf 777 gesetzt, wo ich annahm, dass dies zu keinen Problemen führt, weil entweder eine .htaccess-Datei die Dateien schützt oder die Dateien außerhalb des Homepage-Pfades (public_html) sind.

Bei der Menalto-Gallery half es die Fotos (hinter der Image-Firewall) auf 777 zu setzen. IMO sollte das kein Problem sein, da ja darauf aus dem Web nicht direkt zugegriffen werden kann.

Beim Serendipity-Blog habe ich aufgegeben. Das Rätselraten um das richtige Setzen der Rechte war mir zu groß, besonders da ich mein Blog ganz schnell wieder funktionsfähig brauchte: daher entschloss ich mich auf Drupal umzusteigen, das mir aber gar nicht leicht viel.

Die Probleme mit dem Joomla-CMS waren Cache-Probleme, da das Verzeichnis nicht mehr beschreibbar war. Zum Teil musste ich die Rechte des Cache-Ordners manuell ändern, zum Teil reichte es „SEF Urls löschen“ auszuführen.

Die Probleme bei Drupal zeigten sich erst im Backend-Modus, da /sites/default/files nicht mehr beschreibbar war.

Ich hoffe, dass alle meine Webseiten wieder funktionieren und überlege wie ich mich in Zukunft vor solchen Problemen schützen kann. Ich fürchte, dass die einzige Lösung ein virtueller Server wäre, bei dem ich dann für die Sicherheitsupdates selber verantwortlich bin und Root-Rechte habe.