CMS-Backup

Abstract: Das Backup von sämtlichen Daten einer Website, die mit einem Content Management System betrieben wird, ist wesentlich aufwendiger als bei einer Website, die aus statischen HTML-Dateien besteht. Jedes CMS arbeitet mit einem Datenbanksystem, meist ist das MySQL. Dessen Daten lassen sich mit dem herkömmlichen System, das meist auf einfachem Kopieren beruht, nicht zuverlässig sichern.
Der Artikel beschreibt drei häufig vorkommende Problemfälle.

Backup ist doch einfach: ich kopiere alle Dateien auf eine USB-Festplatte. Fertig!
Fertig? Was soll ein Backup, in diesem Fall Ihrer Website, eigentlich leisten? Wann brauchen Sie es? Die drei hier beschriebenen Szenarien sind alle schon oft vorgekommen und in jedem Fall waren die Konsequenzen mehr als unangenehm

• Szenario 1
  Sie verwalten und pflegen Ihre Website mit einem beliebigen CMS. Sie ergänzen die Site mit neuen Seiten, ändern Texte, fügen Links, pdf-Datein zum Download und Links hinzu. Das geht lange gut so.
  An einem Montagvormittag stellen Sie fest, dass statt Ihrer schönen Website eine Fehlermeldung am Bildschirm erscheint: „Could not connect to the database, user or password wrong“. Die Ursache ist mit ziemlicher Sicherheit in einer fehlerhaften (korrupten) oder nicht (mehr) vorhandenen Datenbank zu suchen.
  Sie rufen (wenn möglich) den Betreiber des Servers an und bitten ihn um Hilfe. Er weiss auch schon Bescheid und kann Ihnen sagen, dass am Samstag früh ein Stromausfall seinen Server lahmgelegt hat. Seit Samstag nachmittag läuft der aber wieder. Ihre Website nicht.
  Ihr Dienstleister (nennen wir ihn „Hoster“) war in der Zwischenzeit schon fleissig und hat ab Samstag nachmittag schon die Datensicherungen von der Nacht Freitag auf Samstag zurückgespielt. Für diesen Notfall hatte er ja täglich ein nächtliches Backup angelegt. Zwar nur eine Generation, aber immerhin.
  Nun wird es spannend: wurde das Backup per Kopierbefehl ausgeführt (das ist Standard), dann wurden sicher alle Dateien auch Ihrer Website gesichert und stehen Ihnen wieder zur Verfügung. Die Website geht dennoch nicht! Warum?
  Weil man eine Datenbank eben nicht wirklich kopieren kann, jedenfalls nicht im laufenden Betrieb. Dazu muss entweder die Datenbank gestoppt werden oder ein spezielles Verfahren (Datenbank-Dump) angewendet werden. Ansonsten kann (muss nicht, aber kann!) die Sicherung der Datenbank fehlschlagen und das Ergebnis ist, wie oben beschrieben: sie ist defekt! Dies ist übrigens um so wahrscheinlicher, je grösser die Datenbank ist.
  Die Datenbank muss nun von Hand repariert werden, das ist risikoreich,  teuer und dauert lange.

 

• Szenario 2
  Auch diesmal verwalten und pflegen Sie Ihre Website wieder mit einem beliebigen CMS. Jeden Tag aktualisieren Sie sie. Wieder am Montag stellen Sie fest, dass das automatische Verschieben von „News“ in das Archiv nicht mehr funktioniert und die alten News verschwunden sind. Sie rufen Ihren Dienstleister an. Der stellt fest, dass der Fehler offenbar schon seit Mittwoch letzter Woche besteht und seitdem ein Fehler in der Datenbank besteht. Ihr „Hoster“ ist gut (jedenfalls besser als die meisten) und hat drei Generationen Datenbankdumps (!) angelegt. In Worten: drei. Der Fehler besteht seit? Mittwoch letzter Woche. Das sind mehr als drei Tage Differenz.
  Sieben Generationen Datensicherung wären besser gewesen. Viel Freude bei der Reparatur!

 

• Szenario 3
  Diesmal haben Sie alles richtig gemacht: Sie haben nicht beim billigen Jakob ohne eigene Technik, sondern direkt bei einem echten Hoster mit eigenem DataCenter einen V-Server gemietet, Ihre Agentur kümmert sich um alles und Sie müssen nur die Inhalte regelmässig aktualisieren.
  Eines Tages stellen Sie fest, dass Ihre Website an vielen Stellen fehlerhafte Sonderzeichen (statt ä steht da :&.. etc.) anzeigt. Seit wann ist das denn schon so? Seit heute! Gestern war noch alles ok!
  Also wird der Hoster beauftragt, die Datensicherung (also Ihre Webdaten und die Datenbank) einzuspielen. Ergebnis: nicht besser als zuvor.
  Während Sie sich weiter ärgern, lesen Sie die eMail Ihres Hosters, der Sie darüber informiert, dass er wie vertraglich vereinbart, das Betriebssystem Ihres Servers aktualisiert hat. Immerhin hatten Sie ja einen „Managed Server“ gemietet, müssen sich also darum keine Gedanken machen. Wann hat er das gemacht? Gestern nach 22 Uhr. Ob der Fehler seit dem Zeitpunkt existiert?
  Jedenfalls stellt Ihre Agentur (die ausnahmsweise auch technisch ziemlich fit ist) fest, dass das Content Management System xy3 mit der neuen PHP-Version Zeichensatzprobleme hat, wenn die Extension tt_news verwendet wird. Sonst nicht.
  Die Lösung besteht nun also entweder darin, ein Downgrade der PHP-Version zu versuchen (was nicht einfach und schon gar nicht risikolos ist) oder ein Komplett-Backup des Servers einzuspielen und dann die Datenbank- und Datenbackups einzuspielen.
  Das funktioniert gut, wenn so ein Komplett-Backup vorhanden ist.