Backups und Wiederherstellung

Eine Kundin hat uns angerufen, weil nach einem fehlgeschlagenen Plugin-Update ihr kompletter Blog nur noch eine weiße Seite zeigte. Kein Problem, dachten wir, und fragten nach dem letzten Backup. Es gab keins. Die letzten drei Monate Arbeit, inklusive 15 neuer Rezepte, waren nicht gesichert.

Ein Backup ist deine Versicherung. Ohne Backup bist du bei einem Hack, einem fehlerhaften Update oder einem Server-Ausfall komplett aufgeschmissen. Und genau das ist der Punkt, an dem die meisten Foodblogger uns zum ersten Mal anrufen.

Was gehört in ein vollständiges Backup

Ein vollständiges Backup besteht aus zwei Teilen: den Dateien und der Datenbank. Die Dateien umfassen dein Theme, deine Plugins, deine Uploads (also alle Bilder) und die WordPress-Konfiguration. Die Datenbank enthält deine Beiträge, Seiten, Kommentare, Einstellungen und alles, was du im WordPress-Backend eingibst.

Nur die Dateien oder nur die Datenbank zu sichern, reicht nicht. Du brauchst beides. Ein häufiger Fehler, den wir bei Recovery-Anfragen sehen: Es gibt zwar einen Datenbank-Dump auf dem Server, aber /wp-content/uploads/ ist nicht gesichert. Heißt im Klartext: Die Rezepttexte sind da, die Bilder zu jedem Rezept sind weg. Bei einem Foodblog mit drei Jahren Inhalt ist das ein Schaden, der sich nicht mehr reparieren lässt.

Wie oft du sichern solltest

Wie oft du sichern solltest, hängt davon ab, wie oft du Inhalte veröffentlichst. Bei einem Blog, auf dem wöchentlich neue Rezepte erscheinen, ist ein tägliches Backup sinnvoll. Bei Blogs, die seltener aktualisiert werden, reicht ein wöchentliches Backup, aber nur, wenn du zusätzlich vor jedem Update ein manuelles Backup machst.

Hoster-Backup allein reicht nicht, die Offsite-Pflicht

Fast jeder Managed-Hoster wirbt mit "täglichen Backups inklusive". Das ist nett, aber es ist kein vollständiger Schutz. Wenn dein Hoster-Account selbst gekapert wird, schwaches Hoster-Login-Passwort, eine Phishing-Mail, ein gehacktes E-Mail-Postfach mit dem du den Hoster-Login zurücksetzen kannst, dann sind die Hoster-Backups mit dem Account zusammen weg. Wir hatten genau diesen Fall: Foodblog-Recovery, alles weg, und im Hoster-Login keine Backups mehr, weil der Angreifer sie als Erstes gelöscht hat.

Was du brauchst, ist mindestens eine Offsite-Kopie. Damit ist gemeint: ein Backup-Stand, der nicht auf dem gleichen Server und nicht im gleichen Account liegt wie dein Blog. Cloud-Speicher, externe Festplatte, ein zweiter Hoster, ein SFTP-Server, eine Mailadresse mit großem Postfach, was es genau ist, ist Geschmackssache. Dass es offsite ist, nicht.

Praktisch: Backup-Plugins können automatisch zu Dropbox, Google Drive, S3 oder einem SFTP-Server pushen. Wir konfigurieren das in Kundenprojekten so, dass täglich ein verschlüsselter Backup-Stand in einen externen Cloud-Speicher landet. Wenn der Hoster-Account brennt, ist der Backup-Stand trotzdem da.

Was wir oft sehen: Foodblogger verlassen sich vollständig auf das Hoster-Backup, weil es im Tarif drinsteht. Bis zu dem Tag, an dem es nicht mehr da ist. Eine zweite, unabhängige Kopie kostet wenig Zeit in der Einrichtung und beantwortet im Ernstfall die einzige Frage, die zählt: Komme ich an meinen Stand vom Vortag ran, ohne den Hoster zu fragen?

Restore in der richtigen Reihenfolge

Die Wiederherstellung ist der Teil, den die meisten vergessen. Ein Backup, das du nie getestet hast, ist kein Backup, sondern eine Hoffnung. Wir haben schon Backup-Dateien gesehen, die korrupt waren, oder Backups, die zwar die Datenbank enthielten, aber nicht die Uploads.

Die Reihenfolge bei einer Wiederherstellung ist wichtig:

1. Zuerst die Dateien zurückspielen, Theme, Plugins, Uploads, wp-config.php-Template.
2. Dann die Datenbank importieren.
3. Dann wp-config.php prüfen. Die Datenbank-Zugangsdaten müssen zur neuen DB passen, WP_HOME und WP_SITEURL müssen zur Ziel-URL passen, sonst weiße Seite oder Login-Loop.
4. Zum Schluss die Permalinks neu speichern. In den WordPress-Einstellungen einmal auf "Speichern" klicken reicht, das flusht die Rewrite-Rules und löst das klassische "alle Unterseiten gehen auf 404"-Problem nach einem Restore.

Wenn du diese Reihenfolge umdrehst, erst Datenbank, dann Dateien, landest du regelmäßig in dem Zustand, dass die Datenbank schon Verweise auf Bilder und Plugins enthält, die im Dateisystem noch gar nicht da sind. Das gibt entweder fehlende Bilder im ganzen Blog oder schlimmstenfalls einen kompletten Crash beim ersten Backend-Login.

Der jährliche Probelauf

Setz dir einmal im Jahr einen Termin in den Kalender für einen echten Restore-Test. Nicht "im Hoster sehen, dass die Backups da sind", sondern wirklich einmal durchspielen.

So sieht der Probelauf aus:

• Backup herunterladen, als Datei auf deinen Rechner, nicht nur den Status im Hoster-Panel ansehen.
• Inhalt prüfen: Ist die Datenbank-Datei (meist .sql oder .sql.gz) drin? Ist /wp-content/uploads/ mit allen Bildern drin? Sind die Theme- und Plugin-Verzeichnisse drin?
• Lokal oder auf einer Staging-URL den Restore durchspielen, Datenbank in einer Test-Installation importieren, Dateien hochladen, in der Test-wp-config.php die Zugangsdaten anpassen, prüfen ob der Blog auf der Test-URL läuft.
• Stichprobe: drei Beiträge öffnen, Bilder erscheinen, Kommentare sind da, das Backend-Login funktioniert.

Erst dann weißt du: Das Backup tut, was es soll. Wir haben in Kundenprojekten schon erlebt, dass sechs Monate lang automatisch ein Backup erzeugt wurde, das beim Test-Restore aber leer war, weil ein Pfad in der Plugin-Konfiguration falsch stand. Niemandem ist es aufgefallen, weil niemand jemals versucht hat, es zurückzuspielen.

Staging als Sicherheitsnetz für Updates

Eine Staging-Umgebung ist ein Klon deines Blogs, auf dem du Updates testen kannst, bevor sie auf den Live-Blog gehen. Bei vielen Managed-Hostern gibt es das als Ein-Klick-Funktion direkt im Hoster-Panel, Live-Stand wird auf eine Staging-URL kopiert, und du arbeitest dort weiter, ohne dass der Live-Blog etwas davon merkt.

Der Workflow, den wir bei Kundenprojekten fahren, sieht so aus: Live nach Staging klonen, Updates auf Staging testen, alle Rezeptseiten und Kategorieseiten auf Staging einmal durchklicken. Wenn alles läuft, dieselben Updates auf Live wiederholen. Wenn etwas kaputtgeht, passiert es auf Staging, und der Live-Blog bleibt davon unberührt.

Das macht das Plugin-Update aus der Lektion vorher deutlich entspannter. Statt "ich klick auf Update und hoffe das beste" gilt: erst Staging, dann Live. Bei sicherheitsrelevanten Plugin-Updates ist das wichtig, denn die kommen oft kurzfristig und du willst nicht warten, bis du Zeit für eine Komplett-Reparatur hast.

Was als Nächstes kommt

Was du in Teil 1 dieses Kurses jetzt selbst gebaut hast, Pflicht-Schicht aus Updates, Login-Härtung, Plugin-Hygiene und ein Backup-Konzept mit Offsite-Kopie und getestetem Restore, ist die Grundlage, auf der alles andere aufsetzt. Ohne diese Basis bringt dir keine Zusatztechnik etwas.

Teil 2 dieser Reihe, Sicherheitsfeatures im Foodblogliebe-Theme, zeigt dir, was wir technisch obendrauf legen, wenn ein Foodblog im Foodblogliebe-Sicherheitspaket läuft: Verzeichnisschutz für /wp-admin/ per Webserver-Konfiguration, Cloudflare als vorgelagerte WAF mit Bot- und Geo-Filtern, Hardening der WordPress-REST-API gegen Username-Enumeration, und ein Audit-Log mit gehashten IPs, das DSGVO-konform protokolliert, wer wann was im Backend gemacht hat.

Diese Themen gehören bewusst nicht in Teil 1, weil sie ohne die Basis nichts bringen. Wer keine getesteten Backups hat, dem nützt auch kein Verzeichnisschutz, wenn im Ernstfall der Restore-Stand fehlt.

Unser Tipp: Bevor du zu Teil 2 weitergehst, mach den jährlichen Probelauf, den wir oben beschrieben haben, einmal jetzt. Lade dein aktuelles Backup herunter, prüfe ob Dateien und Datenbank enthalten sind, und spiele es testweise auf einer lokalen WordPress-Installation ein. Erst dann hast du die Pflicht-Schicht wirklich abgeschlossen, und erst dann lohnt sich die nächste Stufe.