Kein Zugriff mehr auf die Website wegen Speicherplatzüberschreitung – Datenbank prüfen

Diese Woche hatte ich einen interessanten Fall. Eine Website zeigte sich anfangs noch, doch ohne CSS, um sich im nächsten Moment nicht mehr aufrufen zu lassen. Um sicherzustellen, dass es kein Serverproblem war, ging ich in die Webspace-Verwaltung und wurde unterrichtet, dass der Speicherplatz von 500 GB um ca. 50 GB überschritten war.

Glücklicherweise gab es SSH-Zugang ( # du -sh ), so konnte ich erstmal abfragen wie es um den Speicherplatz bestellt war. Verblüffenderweise kam ich in Summe grade mal auf 118 GB von erlaubten 500. Da die Dateien den Platz nicht beanspruchten, kam nur noch eine Datenbank als Ursache der hohen Speicherplatzbelegung in Frage.

Über phpMyAdmin sicherte ich eine Datenbank nach der anderen. Nur eine Datenbank ließ sich nicht herunterladen.

Das war diejenige die näher untersucht werden musste. Dummerweise war die Oberfläche bei dem Webhoster wenig aussagefreundlich. Die Größe einzelner Tabellen wurde nicht angezeigt. Dafür musste eine SQL-Abfrage losgeschickt werden.

SELECT
  TABLE_NAME AS `Table`,
  ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024) AS `Size (MB)`
FROM
  information_schema.TABLES
WHERE
  TABLE_SCHEMA = "namederdatenbank"
ORDER BY
  (DATA_LENGTH + INDEX_LENGTH)
DESC;

Als Ergebnis kam eine Liste mit der größten Datenbank an erster Stelle. Die Tabelle {prefix}sitemeta war tatsächlich über 500 GB groß. Diese Tabelle gibt es nur in Multisite-Umgebungen (was ein vergleichbares Vorkommnis in Standalone-Umgebungen nicht ganz ausschließt, da es auch andere Tabellen mit Metadaten betreffen könnte).

Was diesen Boost verursacht hatte, fand ich nicht heraus, dafür hätte ich wissen müssen, welche Tabellenzelle(n) betroffen war(en). Es zeigten sich im Log sowohl ernsthafte Probleme mit WP Optimize (Pro) als auch mit SEOPress (Pro), von dem nach einem größeren Update mehrere Bugfix-Versionen nachgereicht wurden.

Eher im Verdacht habe ich WPO, das nicht nur (weiterhin) einen fatalen Fehler innerhalb seiner Caching-Funktionalität verursachte, sondern bei dem sich der (nicht mehr funktionierende) Cache nach der Wiederherstellung nicht deaktivieren ließ (eine in anderer Serverumgebung neu angelegte Staging-Kopie zeigte dieses Verhalten nicht). WP Super Cache übernahm das Caching.WP Optimize wurde ausgemustert.

Nach dem Versuch die Tabelle zu optimieren und reparieren war sie zwar auf schlanke 30 MB zurückgeschrumpft. Die Website lief allerdings trotzdem nicht mehr, und an einen Download der Datenbank war ebenfalls nicht zu denken. Nicht mal an eine einzelne Tabelle war noch heranzukommen.Das Vortag-Datenbankbackup wurde auf MariaDB neu eingespielt.

Nach mittlerweile vier Tagen Beobachtung zeigen sich keine besonderen Vorkommnisse mehr. Die durch eine MariaDB ersetzte MySQL-Problemdatenbank wurde gelöscht.

Der Fall demonstrierte, wie wichtig tägliche Backups sind. Sie sollten eine Selbstverständlichkeit sein. Sofern Du WordPress betreibst und kein Backupsystem eingerichtet hast, mach das – am besten jetzt gleich. Selbst wenn eine WordPress-Site jahrelang ohne Probleme lief, kann ein Fehler in einem Plugin – z.B. nach einem Update – im blödsten Fall die ganze jahrelange Arbeit zerstören, oder eine aufwendige und teure Rekonstruktion der Site zur Folge haben.