Lösungen für: WordPress-Website komplett kaputt – retten, wenn nichts mehr geht

Wenn Ihre WordPress-Website gar nicht mehr funktioniert, alle Beiträge verschwunden sind oder WordPress meldet, die Datenbank müsse repariert werden, ist das ein großer Schreck. Endgültig verloren ist dabei selten etwas, und mit etwas Ruhe lässt sich fast immer mehr retten, als es im ersten Moment aussieht.

Sichern Sie zuerst den kaputten Zustand, Dateien und Datenbank, und reparieren Sie erst danach. Eine beschädigte Tabelle vom Typ MyISAM repariert WordPress selbst, bei InnoDB, dem heutigen Standard, hilft nur eine vorhandene Sicherung, Ihre eigene oder die Ihres Hosters. Wenn es keine gibt, bauen Sie die Website aus dem, was übrig ist, und aus dem Internet Archive wieder auf.

Alles in diesem Beitrag habe ich auf einer Testinstallation (WordPress 7.1.4 auf Deutsch, PHP 8.4, MySQL 8.4) absichtlich kaputt gemacht und wieder hergestellt: beschädigte Tabellen, gelöschte Ordner, eine verlorene Datenbank. Wo das Ergebnis anders aussieht, als Foren und Anleitungen berichten, steht das dabei.

Woran erkenne ich, dass die Daten meiner WordPress-Website beschädigt sind?

„Komplett kaputt“ kann vieles heißen. Wenn Ihre Website eine eindeutige Meldung zeigt, sind Ihre Daten meist in Ordnung, und die Meldung führt direkt zur Lösung:

• „Auf dieser Website ist ein kritischer Fehler aufgetreten“ oder eine weiße Seite: Ein PHP-Absturz, und was Sie dabei tun sollten, steht in meinem Artikel Lösungen für: kritischer Fehler und weiße Seite.
• „Fehler beim Aufbau einer Datenbankverbindung“: Meist kommt WordPress nicht an die Datenbank heran. Für eine empfohlene Vorgehensweise, siehe Lösungen für den Datenbankfehler. Was /wp-admin/ dazu sagt, steht aber auch gleich hier, etwas weiter unten, in diesem Artikel.
• Eine Zahl wie 500, 503 oder 403: Die entsprechende Vorgehensweise beim Auftreten dieser Fehler-Codes beschreibe ich in meinem Artikel Lösungen für die HTTP-Fehler.

Um beschädigte Daten geht es, wenn Sie eines der folgenden Anzeichen sehen. Jedes davon hat in meinem Test eine beschädigte Tabelle in der Datenbank ausgelöst:

• Unter /wp-admin/ steht „Eine oder mehrere Datenbanktabellen sind nicht verfügbar. Möglicherweise muss die Datenbank repariert werden.“ Auf der Website selbst war dabei nur „Fehler beim Aufbau einer Datenbankverbindung“ zu sehen. So hat eine beschädigte Tabelle wp_options ausgesehen, in der WordPress seine Einstellungen speichert.
• Alle Beiträge sind weg, ohne jede Fehlermeldung. Die Startseite hat „Es wurde leider nichts gefunden.“ gezeigt, jeder Beitrag „Seite nicht gefunden“, und das Dashboard hat unter Beiträge „Alle (0)“ gezeigt. So hat eine beschädigte Tabelle wp_posts ausgesehen. Nach der Reparatur waren alle Beiträge wieder da. In einem Forum hat jemand genau das beschrieben: Die Seiten sind aus dem Dashboard verschwunden, und erst der Debug-Modus hat die beschädigte Tabelle verraten.
• Im Fehlerprotokoll Ihres Hosters steht Table './…/wp_posts' is marked as crashed and should be repaired oder Incorrect key file for table. Diese Zeile schreibt WordPress auch ohne Debug-Modus ins Protokoll, mit dem Vorsatz WordPress database error.
• Der Datenbankfehler kommt und geht, und andere Websites beim selben Hoster sind auch betroffen. Das kann eine beschädigte Datei des Datenbankservers selbst sein. In meinem Test hat eine einzige Abfrage auf eine beschädigte Tabelle den ganzen Datenbankserver abstürzen lassen. Das sieht nur Ihr Hoster in seinem Protokoll, dort steht dann „Database page corruption on disk“.
• Auf Englisch: „One or more database tables are unavailable. The database may need to be repaired.“

Wenn dagegen Dateien fehlen, etwa nach einem abgebrochenen Update, ist das ein anderer Fall. Er steht unten in Schritt 4.

Bevor Sie etwas ändern: Ein falscher Handgriff kann mehr Schaden anrichten als der Fehler selbst. Ein Tippfehler in der wp-config.php legt die ganze Website lahm, ein falscher Befehl in der Datenbank oder auf der Kommandozeile lässt sich oft nicht zurücknehmen. Mit diesen Regeln bleibt jeder Schritt umkehrbar:

• Zuerst eine vollständige Sicherung von Dateien und Datenbank, abgelegt außerhalb Ihres Webspace. Viele Hoster bieten dafür eine eigene Funktion an. Fragen Sie im Zweifel nach, wie Sie die Sicherung wieder einspielen.
• Vor jeder Bearbeitung eine Kopie der Datei auf Ihren eigenen Rechner laden. Eine Kopie auf dem Server darf nicht wp-config.php.bak heißen, denn so kann sie jeder samt Datenbank-Passwort im Browser abrufen. Nennen Sie sie wp-config-kopie.php, und löschen Sie sie am Ende.
• Immer nur eine Änderung, dann testen. Hat sie nicht geholfen, machen Sie sie rückgängig, bevor Sie die nächste versuchen.
• Eine Testkopie (Staging) nutzen, wenn Ihr Hoster eine anbietet: Dort darf alles schiefgehen.
• Aufhören ist eine gute Option: wenn Sie nicht mehr wissen, was Sie geändert haben, wenn ein Schritt anders aussieht als hier beschrieben oder wenn die Website täglich Geld verdient. Dann schreiben Sie mir, das Angebot steht am Ende dieses Beitrags.

Schritt 1: Den kaputten Zustand der WordPress-Website sichern, bevor Sie etwas reparieren

Das klingt widersinnig, ist aber der wichtigste Schritt. Jede Reparatur und jede Wiederherstellung überschreibt etwas, und laut MySQL-Handbuch kann sogar die Reparatur einer Tabelle Daten kosten. Mit einer Kopie des jetzigen Zustands kommen Sie jederzeit zurück, und eine Fachperson kann später noch retten, was heute übersehen wird.

• Die Dateien: Laden Sie per FTP oder Dateimanager mindestens den Ordner wp-content und die Datei wp-config.php auf Ihren Rechner. In wp-content/uploads liegen Ihre Bilder und Dokumente, die gibt es sonst oft nirgends.
• Die Datenbank: In phpMyAdmin unter „Exportieren“, per SSH mit wp db export. Wenn eine Tabelle beschädigt ist, bricht der Export ab. Im Test hat wp db export mit „Table … is marked as crashed and should be repaired“ aufgehört, und die Datei war bis auf ein paar Zeilen leer. Mit dem Zusatz --force ist der Export durchgelaufen, allerdings ohne die beschädigte Tabelle. Sichern Sie so, was sich sichern lässt, und reparieren Sie erst danach.
• Beim Hoster: Fragen Sie gleich zu Beginn, welche Sicherungen er von Ihrer Website hat und wie weit sie zurückreichen. Sicherungen werden nach einer festen Zahl von Tagen überschrieben, bei meinen eigenen Websites nach 15. Wer zu lange wartet, verliert womöglich die letzte Sicherung von vor dem Fehler.

wp db export kaputt-vorher.sql
wp db export kaputt-vorher-force.sql --force

Schritt 2: Eine beschädigte WordPress-Datenbank reparieren

Ob sich eine Tabelle reparieren lässt, hängt von ihrem Typ ab. Sehen Sie in phpMyAdmin nach: Klicken Sie links auf Ihre Datenbank, dann steht in der Liste der Tabellen in der Spalte „Typ“ entweder InnoDB oder MyISAM.

• MyISAM findet man vor allem bei älteren Websites. Eine solche Tabelle lässt sich reparieren, und alle drei Wege unten haben in meinem Test funktioniert.
• InnoDB verwenden aktuelle Installationen, auch meine Testinstallation. Laut MySQL-Handbuch funktioniert die Reparatur nur bei MyISAM und zwei selten genutzten Typen. Was Sie bei InnoDB tun, steht am Ende dieses Schritts.

Die Datenbank mit der Reparaturseite von WordPress reparieren

WordPress bringt eine eigene Reparaturseite mit. Sie funktioniert auch, wenn Sie sich nicht mehr anmelden können:

1. Fügen Sie in der wp-config.php diese Zeile (nach dieser Liste) ein, oberhalb von „Das war’s, Schluss mit dem Bearbeiten!“ (auf Englisch „That’s all, stop editing!“).
2. Rufen Sie https://ihre-domain.at/wp-admin/maint/repair.php auf und klicken Sie auf „Datenbank reparieren“.
3. Lesen Sie das Ergebnis. Für jede Tabelle steht dort „Die Tabelle … ist in Ordnung.“ oder „Die Tabelle … ist nicht in Ordnung. Es liegt folgender Fehlerbericht vor: …“ und darunter, ob die Reparatur gelungen ist.
4. Nehmen Sie die Zeile sofort wieder heraus. Solange sie drinsteht, kann jeder diese Seite ohne Anmeldung aufrufen.

define( 'WP_ALLOW_REPAIR', true );

Zwei Dinge sollten Sie über diese Seite wissen. Sie prüft nur die Tabellen von WordPress selbst, also wp_posts, wp_options und die anderen aus der Liste im Bild. Tabellen von Plugins, etwa die eines Shops, lässt sie aus, für diese brauchen Sie phpMyAdmin oder WP-CLI. Und sie räumt nichts auf. Sie prüft jede Tabelle und repariert sie nur, wenn die Prüfung einen Fehler meldet. Erst die zweite Schaltfläche, „Datenbank reparieren und optimieren“, optimiert die Tabellen zusätzlich. Übrig gebliebene Einträge gelöschter Plugins löscht keine der beiden.

Eine beschädigte Tabelle in phpMyAdmin reparieren

1. Öffnen Sie phpMyAdmin im Kundenbereich Ihres Hosters und klicken Sie links auf Ihre Datenbank.
2. Setzen Sie ein Häkchen bei den Tabellen vom Typ MyISAM, oder mit „Alle auswählen“ bei allen.
3. Wählen Sie unten im Menü „markierte:“ den Eintrag „Repariere Tabelle“. phpMyAdmin zeigt danach für jede Tabelle das Ergebnis, im Test „Status OK“.

Im selben Menü stehen „Leeren“ und „Löschen“, und beide entfernen Ihre Daten. Lesen Sie also genau, bevor Sie klicken. Bei einer InnoDB-Tabelle bietet phpMyAdmin die Reparatur unter „Operationen“ übrigens gar nicht erst an.

Die WordPress-Datenbank per SSH mit WP-CLI prüfen und reparieren

wp db check
wp db repair

Lesen Sie bei beiden Befehlen jede Zeile, nicht nur die letzte. wp db check hat im Test bei einer beschädigten Tabelle wp_posts „error : Corrupt“ gemeldet und trotzdem mit „Success: Database checked.“ geendet. Und wp db repair hat bei InnoDB-Tabellen für jede einzelne „The storage engine for the table doesn't support repair“ geschrieben und danach „Success: Database repaired.“, obwohl gar nichts repariert worden ist. Bei MyISAM hat der Befehl die Tabelle wirklich repariert.

Eine beschädigte InnoDB-Tabelle in WordPress: Was jetzt hilft

Eine InnoDB-Tabelle können Sie selbst nicht reparieren. In meinem Test hat eine beschädigte InnoDB-Datei schon bei der ersten Abfrage den ganzen Datenbankserver abstürzen lassen. Danach hat die Website nur noch „Fehler beim Aufbau einer Datenbankverbindung“ gezeigt, und jeder neue Start hat beim nächsten Aufruf wieder mit einem Absturz geendet.

Ihr Hoster kann den Datenbankserver in einem besonderen Modus starten, um herauszuholen, was noch lesbar ist. Das MySQL-Handbuch warnt dabei selbst, dass die höheren Stufen dieses Modus die Dateien dauerhaft beschädigen können. Das ist also Arbeit für den Hoster. Für Sie ist hier der beste Weg das im nächsten Schritt beschriebene Einspielen einer vorhandenen Sicherung: In meinem Test hat das Einspielen der Sicherung die beschädigte Tabelle ersetzt, und die Website ist sofort wieder gelaufen.

Schritt 3: Eine Sicherung der WordPress-Website einspielen

Was seit der Sicherung dazugekommen ist, geht dabei verloren. Im Test war ein Beitrag, den ich nach der Sicherung geschrieben hatte, danach weg. Wenn nur die Datenbank beschädigt ist, spielen Sie deshalb auch nur die Datenbank zurück, dann bleiben neuere Bilder in wp-content/uploads erhalten.

Die Sicherung des Hosters wiederherstellen

Das ist der einfachste Weg, denn Sie brauchen dafür weder WordPress noch ein Plugin. Sehen Sie im Kundenbereich nach einer Funktion zum Wiederherstellen, und wenn Sie keine finden, fragen Sie den Support. Sagen Sie dazu, seit wann der Fehler besteht, damit er eine Sicherung von davor nimmt.

Eine eigene Sicherungsdatei der Datenbank einspielen

Wenn Sie eine Datei mit der Endung .sql haben, spielen Sie sie in phpMyAdmin unter „Importieren“ ein oder per SSH:

wp db import sicherung.sql

Im Test hat das auch über einer beschädigten InnoDB-Tabelle funktioniert, denn die Sicherung löscht jede Tabelle und legt sie neu an. Wenn die Datei komprimiert ist (Endung .gz), entpacken Sie sie vorher.

Eine Plugin-Sicherung wiederherstellen, wenn das Dashboard nicht mehr geht

Die meisten Sicherungs-Plugins stellen über das Dashboard wieder her, und genau das fehlt ja jetzt. UpdraftPlus etwa kann laut eigener Anleitung nur wiederherstellen, wenn es vorher schon installiert war und gesichert hat. Ohne funktionierendes Dashboard bleiben zwei Wege:

• Die Datenbank von Hand einspielen. Die Sicherung der Datenbank von UpdraftPlus ist eine Datei, deren Name auf -db.gz endet. Entpackt ist das eine gewöhnliche SQL-Datei. Im Test habe ich sie mit wp db import eingespielt, nachdem ich die Tabelle wp_options gelöscht hatte, und die Website war wieder da.
• Eine frische WordPress-Installation mit demselben Plugin. Dort laden Sie die Sicherungsdateien hoch und stellen von dort wieder her. Duplicator wirbt auf wordpress.org sogar damit, dass sich seine Sicherung ohne installiertes WordPress auf leerem Webspace auspacken lässt.

Wichtig: Ohne weitere Einstellung hat UpdraftPlus die Sicherung im Test nur auf demselben Server abgelegt, im Ordner wp-content/updraft. Im Browser ließ sie sich dort nicht abrufen, aber ist der Webspace weg, ist es auch die Sicherung.

Schritt 4: Beschädigte oder fehlende Dateien von WordPress ersetzen

• WordPress selbst: Wenn Dateien des Kerns fehlen, etwa nach einem abgebrochenen Update, finden Sie den Lösungsweg unter Ein Update wurde abgebrochen: Wie kann ich WordPress reparieren?. Ihre Inhalte und Plugins bleiben dabei unberührt.
• Plugins von wordpress.org: Per SSH vergleicht wp plugin verify-checksums --all jede Datei mit dem Original. Im Test hat es eine veränderte Datei mit „Checksum does not match“ gemeldet und eine hinzugekommene mit „File was added“. wp plugin install <name> --force ersetzt das Plugin dann durch eine frische Kopie. Im Test war die fremde Datei danach weg, und das Plugin ist samt Einstellungen aktiv geblieben.
• Gekaufte Plugins und Themes laden Sie im Kundenkonto des Herstellers neu herunter und ersetzen den Ordner per FTP.
• Bilder und Dokumente in wp-content/uploads lassen sich nicht neu herunterladen. Sie kommen nur aus einer Sicherung zurück oder aus dem Internet Archive (Schritt 5).

wp plugin verify-checksums --all
wp plugin install name-des-plugins --force

Schritt 5: Die WordPress-Website ohne Sicherung wiederherstellen

Ohne Sicherung kommt es darauf an, was noch da ist. Fast immer ist es mehr als nichts.

Die Datenbank ist noch da, aber die Dateien sind weg

Das ist der günstigste Fall, denn in der Datenbank stehen alle Texte, Seiten, Benutzer und Einstellungen. Hier steht auch drin, welche Plugins und welches Theme Ihre Website verwendet hat. In meinem Test habe ich die Ordner plugins und themes gelöscht: Die Website hat eine leere weiße Seite gezeigt, die Datenbank hat aber weiter beide Listen enthalten. In phpMyAdmin finden Sie sie in der Tabelle wp_options, in den Zeilen active_plugins, template und stylesheet, per SSH so:

wp option get active_plugins --skip-plugins --skip-themes
wp option get template --skip-plugins --skip-themes

Installieren Sie WordPress neu, tragen Sie in die wp-config.php die Daten Ihrer bisherigen Datenbank ein und installieren Sie Theme und Plugins wieder. Im Test waren die Plugins danach gleich wieder aktiv, mit ihren alten Einstellungen, und alle Beiträge waren wieder zu sehen. Öffnen Sie dazwischen nicht die Seite Plugins im Dashboard, denn dort schaltet WordPress jedes fehlende Plugin dauerhaft ab.

Die Dateien sind noch da, aber die Datenbank ist weg

Dann sind Ihre Bilder noch im Ordner wp-content/uploads, aber WordPress kennt sie nicht mehr. Nach einer neuen Installation trägt dieser Befehl ein Bild wieder in die Mediathek ein, und zwar unter seiner alten Adresse:

wp media import wp-content/uploads/2024/05/bild.jpg --skip-copy

Der Zusatz --skip-copy ist entscheidend. Ohne ihn hat WordPress im Test eine Kopie namens bild-1.jpg angelegt, mit einer neuen Adresse, und die alten Verweise in Ihren Texten hätten nicht mehr gepasst. Nehmen Sie nur die Originale, nicht die verkleinerten Fassungen mit Maßen im Namen wie bild-300x225.jpg, denn die erzeugt WordPress beim Import selbst.

Die Texte selbst müssen Sie neu anlegen. Woher Sie sie bekommen, steht im nächsten Abschnitt.

Texte und Bilder einer kaputten WordPress-Website aus dem Internet Archive holen

Das Internet Archive speichert seit Jahren Kopien öffentlicher Websites, möglicherweise auch von Ihrer. Eine Liste aller gespeicherten Adressen Ihrer Domain liefert diese Abfrage, im Browser aufgerufen, mit Ihrer Domain statt ihre-domain.at:

https://web.archive.org/cdx/search/cdx?url=ihre-domain.at/*&fl=timestamp,original&filter=statuscode:200&collapse=urlkey

Für websiteberater.com hat sie 213 Seiten und 298 Dateien aus dem Medienordner ergeben. Setzen Sie dann eine dieser Adressen in diese Form ein: https://web.archive.org/web/2099id_/https://ihre-domain.at/ihre-seite/. Mit der Jahreszahl 2099 nimmt das Archiv die jüngste gespeicherte Kopie, und id_ liefert sie so, wie Ihr Server sie damals ausgeliefert hat, ohne die Leiste und die umgeschriebenen Links des Archivs. Bilder holen Sie auf dieselbe Weise.

Zwei Einschränkungen: Die Kopie ist so alt wie der letzte Besuch des Archivs. Bei einem meiner Beiträge war die jüngste Kopie ein halbes Jahr alt. Und Seiten hinter einer Anmeldung fehlen ganz. Den Zwischenspeicher von Google gibt es übrigens nicht mehr, Google hat die Funktion eingestellt. Fragen bzw. sehen Sie auch dort nach, wo Ihre Texte sonst noch liegen könnten: in eigenen Dokumenten, alten E-Mails, bei der Agentur, die die Website gebaut hat.

Alle Beiträge in WordPress sind plötzlich weg: die möglichen Ursachen

Wenn Beiträge und Seiten auf einmal verschwunden sind, kommen nach meinen Tests drei Ursachen in Frage:

• Die Tabelle wp_posts ist beschädigt: Es gibt keine Fehlermeldung, die Listen sind leer, und im Fehlerprotokoll steht „marked as crashed“. Die Reparatur steht oben in Schritt 2.
• WordPress liest eine andere oder eine leere Datenbank, etwa nach einem Umzug. Wenn WordPress dann die Installation anzeigt, füllen Sie das Formular nicht aus, sondern lesen Sie warum plötzlich die Installation erscheint.
• Die Inhalte wurden gelöscht. Sehen Sie im Papierkorb nach.

Wie kann ich eine einzelne Seite in WordPress wiederherstellen?

Eine gelöschte Seite liegt zuerst im Papierkorb und lässt sich dort zurückholen. Wenn sie nur verunstaltet ist, hilft im Editor der Bereich „Revisionen“, dort finden Sie die früheren Fassungen. Für eine einzelne Seite brauchen Sie also keine Sicherung der ganzen Website.

Ist die WordPress-Datenbank voll?

Wie groß eine Datenbank sein darf, legt Ihr Hoster fest, und laut WordPress-Dokumentation kann er eine Datenbank, die ihr Kontingent überschreitet, auch abschalten. Die aktuelle Größe zeigt phpMyAdmin in der Liste der Tabellen in der Spalte „Größe“, per SSH dieser Befehl, die größten Tabellen zuerst:

wp db size --tables --human-readable --orderby=size --order=desc

So sehen Sie, welche Tabelle den Platz belegt, oft die eines Plugins. Wenn WordPress nicht mehr in die Datenbank schreiben darf, kann sich das auch ganz anders zeigen: In meinem Test ist die Anmeldung dann einfach immer wieder neu erschienen, ohne Meldung, die Login-Schleife.

Die üblichen Ursachen für eine beschädigte WordPress-Datenbank

Das MySQL-Handbuch nennt für MyISAM-Tabellen vor allem einen Datenbankserver, der mitten im Schreiben abbricht, einen plötzlich ausgeschalteten Server und defekte Hardware. Bei InnoDB hat der Datenbankserver in meinem Test selbst defekte Hardware als mögliche Ursache genannt. Das alles liegt beim Hoster und nicht an Ihnen. Wenn eine beschädigte Tabelle immer wieder kommt, sprechen Sie ihn deshalb darauf an, statt jedes Mal zu reparieren.

Auf Ihrer Seite liegen dagegen ein abgebrochenes Update oder ein abgebrochener Umzug, bei dem Dateien fehlen, und ein Klick auf „Leeren“ oder „Löschen“ in phpMyAdmin, der eigentlich einer anderen Tabelle gegolten hat.

Wenn nichts davon hilft

• Fragen Sie Ihren Hoster, und zwar konkret: Welche Sicherungen haben Sie? Ist der Datenbankserver in Ordnung? Steht in Ihrem Protokoll eine beschädigte Tabelle? Nur er sieht das Protokoll des Datenbankservers.
• Hören Sie auf, bevor Sie etwas überschreiben, von dem Sie keine Kopie haben. Mit der Sicherung aus Schritt 1 lässt sich fast alles später noch versuchen.
• Fragen Sie mich. Schreiben Sie mir, was unter /wp-admin/ steht und welche Sicherungen es gibt. Das Angebot steht gleich unter diesem Beitrag.

Dieser Beitrag behandelt beschädigte Daten, keine Hacks. Sehen Sie im Protokoll Dateien oder Plugins, die Sie nie installiert haben, wenden Sie sich an Ihren Hoster (oder an mich), statt weiter zu probieren.

Damit Ihre WordPress-Website nicht wieder komplett kaputt geht

• Sichern Sie außerhalb des Servers und probieren Sie das Einspielen aus. Ich sichere meine eigenen Websites täglich die Datenbank und wöchentlich alles, auf einen Speicher bei einem anderen Anbieter. Das Einspielen habe ich an einer Testkopie ausprobiert. Was sonst noch zur Pflege gehört, steht in meinem Artikel Eine WordPress-Website richtig pflegen.
• Lassen Sie alte MyISAM-Tabellen auf InnoDB umstellen, von Ihrem Hoster oder einer Fachperson. Ganz einfach ist das nicht: Im Test hat MySQL die Umstellung einer WordPress-Tabelle mit „Invalid default value for 'post_date'“ verweigert, solange seine strenge Grundeinstellung aktiv war.
• Notieren Sie, wo Sicherungen und Zugänge liegen, Hoster, FTP, phpMyAdmin. Im Ernstfall sucht man sonst zuerst diese.

Und haben Sie gar keinen Zugang mehr zu Hosting oder Dashboard, weil ihn jemand anderer hält, ist das kein Datenproblem: Dann führt der Weg über Ihren Hoster.