Ist meine Website eigentlich gesichert, wenn der Hoster ausfällt?

Von /

„Backup macht doch der Hoster.“ Den Satz höre ich von Geschäftsführern regelmäßig. Er stimmt. Bis zu dem Tag, an dem der Hoster selbst das Problem ist.

Anfang November 2026 hat es den russischen Hoster Beget getroffen. Über 450.000 Websites liefen dort. Angreifer kamen an die Verwaltungsebene und haben mit einer Schadsoftware gelöscht: Server, Cloud-Speicher und die Backups gleich mit. Laut Beget bekommt nur etwa die Hälfte der betroffenen VPS-Kunden überhaupt noch eine Datei-Sicherung zurück.

Das ist kein russisches Problem. Anfang 2024 traf es Tietoevry in Schweden, einen der größten IT-Dienstleister Europas. Auch dort waren Kundendaten und Backups verschlüsselt, auch dort haben Kunden ihre Daten dauerhaft verloren.

Warum das Backup beim Hoster nicht reicht

Ein Backup beim Hoster ist eine Kopie im selben Haus. Wer an die Verwaltung des Anbieters kommt, kommt auch an dessen Sicherungen. Gegen einen kaputten Server hilft das. Gegen einen Angriff auf den Anbieter selbst nicht.

Dazu kommen die unspektakulären Fälle: Der Hoster geht pleite, kündigt den Vertrag, sperrt das Konto wegen einer offenen Rechnung. Oder die Agentur, die die Seite gebaut hat, ist nicht mehr erreichbar und niemand hat die Zugangsdaten.

Eine Website ohne eigene Kopie gehört dir nur so lange, wie dein Hoster funktioniert.

In meinem Artikel zu den WordPress-Pflicht-Plugins steht Backup als eigener Punkt. Hier geht es einen Schritt weiter: Wie kommt die Sicherung tatsächlich auf deinen eigenen Rechner oder dein NAS?

Was zu einer WordPress-Sicherung gehört: Dateien und Datenbank

Eine WordPress-Website besteht aus zwei Teilen, die getrennt gespeichert sind. Wer nur einen davon sichert, hat im Ernstfall nichts.

  • Die Dateien: WordPress selbst, Theme, Plugins und vor allem der Ordner wp-content/uploads mit allen Bildern und PDFs.
  • Die Datenbank: alle Texte, Seiten, Beiträge, Einstellungen, Benutzer und Formulareingaben. Meist MySQL oder MariaDB beim Hoster.

Typischer Fehler in KMU: Jemand hat per FTP den Webspace kopiert und hält das für ein Backup. Die Bilder sind da. Die Texte nicht. Denn die liegen in der Datenbank, und die kommt per FTP nicht mit.

Eine Website-Sicherung ohne Datenbank ist ein Fotoalbum ohne Bildunterschriften.

Weg 1: WordPress-Backup mit WPvivid, kostenlos und in zehn Minuten

WPvivid Backup & Migration ist ein kostenloses WordPress-Plugin, das Dateien und Datenbank gemeinsam in ein Archiv packt. Die Gratisversion kann manuelle und zeitgesteuerte Sicherungen, Wiederherstellung per Klick und Umzug auf eine andere Domain. Als externe Ziele unterstützt sie unter anderem Dropbox, Google Drive, OneDrive, Amazon S3, FTP und SFTP.

So kommst du zu deiner ersten eigenen Kopie:

  1. Im WordPress-Backend unter Plugins → Installieren nach „WPvivid“ suchen, installieren, aktivieren.
  2. Im neuen Menüpunkt WPvivid Backup die Sicherung starten. Als Umfang „Datenbank + Dateien“ wählen, nicht nur eines von beiden.
  3. Speicherort zunächst lokal lassen, also auf dem Webspace. Mit „Backup Now“ starten. Je nach Größe dauert das ein bis zehn Minuten.
  4. Das fertige Backup erscheint in der Liste darunter. Dort auf Download klicken und die ZIP-Datei auf deinen Rechner laden.
  5. Die Datei dorthin legen, wo deine übrigen Firmendaten gesichert werden: Fileserver, NAS, Backup-Laufwerk. Nicht nur in den Download-Ordner.

Ab diesem Moment existiert deine Website zweimal: beim Hoster und bei dir.

Praxistipp aus dem Pflicht-Plugins-Artikel: Zeitgesteuerte Sicherungen nicht zur vollen Stunde laufen lassen, sondern zum Beispiel um 3:17 Uhr. Um volle Stunden ist auf Shared-Hosting-Servern am meisten los.

Weg 2: FileZilla für die Dateien, phpMyAdmin für die Datenbank

Der zweite Weg funktioniert auch, wenn WordPress selbst nicht mehr startet. Und für jede andere Website, ob Typo3, Joomla oder statisch.

Dateien mit FileZilla holen:

  1. FileZilla Client installieren (kostenlos, Windows, macOS, Linux).
  2. Zugangsdaten aus dem Kundenbereich deines Hosters nehmen: Server, Benutzer, Passwort.
  3. Wenn der Hoster es anbietet, SFTP oder FTPS wählen, nicht unverschlüsseltes FTP. Sonst gehen Passwort und Daten im Klartext übers Netz.
  4. Verbinden, rechts den Webspace öffnen, den kompletten WordPress-Ordner auf die linke Seite in einen lokalen Ordner ziehen. Bei vielen Bildern dauert das.

Wenn du vorher mit WPvivid gesichert hast, reicht auch der Ordner wp-content/wpvividbackups. Dort legt das Plugin seine Archive standardmäßig ab, Datenbank inklusive.

Datenbank separat exportieren:

  1. Im Kundenbereich des Hosters phpMyAdmin oder die Datenbankverwaltung öffnen.
  2. Die WordPress-Datenbank auswählen. Welche das ist, steht in der Datei wp-config.php unter DB_NAME.
  3. Exportieren, Format SQL, Standard-Einstellungen reichen.
  4. Die .sql-Datei neben den FileZilla-Ordner legen.

Erst Dateien und Datenbank zusammen ergeben eine Sicherung, mit der du die Seite bei einem anderen Hoster wieder aufbauen kannst.

Exkurs: Website-Backup vollständig automatisieren

Von Hand klappt das dreimal. Dann vergisst es jemand. Wer es dauerhaft will, automatisiert es in zwei Stufen.

  1. Beim Hoster: WPvivid legt nach Zeitplan jede Nacht ein Archiv aus Dateien und Datenbank auf den Webspace, zum Beispiel um 3:17 Uhr.
  2. Bei dir: Ein Rechner in deinem Netz holt dieses Archiv eine Stunde später per SFTP ab. Unter Windows geht das mit WinSCP und der Aufgabenplanung, viele NAS-Systeme können das von Haus aus.

Der entscheidende Punkt ist die Richtung. Dein Rechner holt ab, der Webserver schickt nicht. Würde WPvivid direkt auf dein NAS schreiben, lägen die NAS-Zugangsdaten auf dem Webserver. Wer den Webserver übernimmt, könnte dann auch deine Kopie löschen. Beim Abholen kennt der Webserver dein Netz gar nicht.

Dazu gehören noch drei Kleinigkeiten:

  • Mehrere Generationen aufheben, zum Beispiel 14 Tage, damit ein unbemerkter Schaden nicht die einzige Kopie überschreibt.
  • Eine Benachrichtigung, wenn der Abholauftrag fehlschlägt.
  • Die abgeholten Archive landen im normalen Firmen-Backup und damit auch auf dessen Offline-Kopie.

Das Pull-Prinzip ist die kürzeste Antwort auf die Lehre aus dem Beget-Vorfall: Die letzte Kopie darf niemand löschen können, der nur an den Hoster herankommt.

Wo das an Grenzen stößt

Für die klassische Firmenwebsite reicht eine nächtliche Sicherung. Für einen Onlineshop mit Bestellungen im Minutentakt nicht: Dort fehlen nach einer Wiederherstellung alle Bestellungen seit der letzten Sicherung. Shops brauchen häufigere Datenbank-Sicherungen oder eine Lösung direkt auf Datenbank-Ebene.

Und: Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung. Einmal im Jahr die Sicherung auf einem Testsystem oder einer Subdomain wiederherstellen. Erst dann weißt du, dass sie funktioniert.

Was das für dich als Geschäftsführer bedeutet

Du musst das nicht selbst machen. Aber du solltest eine Frage stellen können und eine klare Antwort bekommen: „Wo liegt die letzte Kopie unserer Website, die nicht beim Hoster liegt, und von wann ist sie?“

Wenn darauf niemand im Haus und keine Agentur sofort antworten kann, hast du dein Website-Backup gefunden: Es gibt keins.

Wer das für die eigene Website einmal sauber einrichten lassen möchte, erreicht mich über sesoft.de/kontakt.

Quellen und Links

Über den Autor

Sönke Schäfer berät seit über 25 Jahren Unternehmen in Norddeutschland rund um Datenbanken und Websites. Er betreut WordPress-Installationen für KMU aus Ostholstein und entwickelt Lösungen mit Microsoft Access und SQL Server. Als früherer IT-Leiter eines Unternehmens mit rund 300 Mitarbeitenden weiß er, dass Datensicherung erst dann zählt, wenn die Wiederherstellung klappt.

Ähnliche Beiträge

Nach oben scrollen