Storage Server mit WordPress nutzen: was funktioniert und was nicht

Das Verzeichnis wp-content/uploads ist der Teil von WordPress, der ungebremst wächst. Bilder, PDF-Dateien, Videos, dazu von jedem Bild mehrere Größen, die WordPress automatisch erzeugt. Nach ein paar Jahren liegen dort Dutzende Gigabyte, und der Platz auf dem Webserver ist der teuerste, den man kaufen kann.

Ein Storage Server kostet einen Bruchteil davon. Die Frage ist nur, was sich wirklich auslagern lässt. Im Netz steht dazu viel, was in der Praxis nicht funktioniert. Dieser Artikel trennt die drei Fälle sauber.

Die drei Fälle im Überblick

Der letzte Punkt ist der, über den die meisten stolpern. Deshalb zuerst die unbequeme Wahrheit.

Warum es für die Mediathek kein Plugin gibt

Die bekannten Auslagerungs-Plugins für WordPress sprechen alle dieselbe Sprache: S3. Sie verbinden sich mit Amazon S3 oder einem kompatiblen Dienst, laden die Datei dorthin, löschen die lokale Kopie und ersetzen die Adresse im Beitrag durch eine öffentliche Adresse des Dienstes.

Genau das lässt sich auf einen Storage Server nicht übertragen, und zwar aus zwei Gründen:

• Der Speicher spricht SMB, SFTP und WebDAV, aber kein S3.
• Es gibt keine öffentliche Adresse je Datei. Jeder Zugriff ist angemeldet, es kann also keinen Link geben, den der Browser des Besuchers direkt aufruft.

Es gibt einzelne Plugins, die mit FTP arbeiten, aber keines mit nennenswerter Verbreitung und aktueller Pflege, das die Mediathek vollständig über SFTP oder WebDAV auslagert. Wer eines findet, sollte vor dem Einsatz auf das Datum der letzten Aktualisierung und die Zahl der aktiven Installationen sehen.

Der Weg, der funktioniert: einbinden statt auslagern

Auf einem eigenen Server mit Root-Rechten dreht man die Sache um. Statt WordPress beizubringen, mit fremdem Speicher zu reden, bringt man den Speicher an die Stelle, an der WordPress ohnehin hinschreibt:

apt install -y cifs-utils
mkdir -p /mnt/storage
printf 'username=u123456-sub1\npassword=DEIN_PASSWORT\n' > /etc/samba/storage.cred
chmod 600 /etc/samba/storage.cred

Eintrag in /etc/fstab:

//u123456.storage.kernelhost.net/backup /mnt/storage cifs credentials=/etc/samba/storage.cred,uid=www-data,gid=www-data,file_mode=0660,dir_mode=0770,seal,_netdev,nofail 0 0

Danach die vorhandenen Dateien umziehen und das Verzeichnis ersetzen:

mount -a
mkdir -p /mnt/storage/uploads
rsync -a /var/www/example.com/wp-content/uploads/ /mnt/storage/uploads/
mv /var/www/example.com/wp-content/uploads /var/www/example.com/wp-content/uploads.alt
ln -s /mnt/storage/uploads /var/www/example.com/wp-content/uploads

WordPress merkt davon nichts, für die Anwendung ist es ein ganz normaler Pfad. Das alte Verzeichnis bleibt als uploads.alt liegen, bis du geprüft hast, dass alles funktioniert. Erst dann löschen, nicht vorher.

Die Falle dabei: Vorschaubilder

WordPress erzeugt von jedem Bild mehrere Größen und lädt sie bei jedem Seitenaufruf. Liegen diese kleinen Dateien auf dem Netzspeicher, kommt je Datei die Netzlaufzeit dazu, und eine Galerie mit vierzig Bildern wartet vierzigmal.

Zwei Lösungen, beide gut:

• Einen Zwischenspeicher davor setzen, etwa einen Cache im Webserver, der die ausgelieferten Dateien lokal vorhält.
• Nur die Originale auf den Speicher legen und die erzeugten Größen lokal lassen. Das ist etwas mehr Arbeit, aber der sauberste Weg für Seiten mit vielen Bildern.

Sicherungen: der schnellste Nutzen

Wenn du nur eine Sache machst, dann diese. Eine Sicherung auf demselben Server ist keine Sicherung: Wird die Platte gelöscht oder die Website verschlüsselt, ist sie mit weg. Auf getrenntem Speicher überlebt sie.

Das kostenlose Plugin WPvivid kann in der Grundfassung per SFTP auf den Speicher sichern, mit Zeitplan und Aufbewahrungsregel. Die vollständige Anleitung dazu steht in WordPress-Backups auf den Storage Server.

Auf einem eigenen Server geht es noch besser, nämlich mit rsync oder BorgBackup direkt aus einem Zeitplan heraus. Dann überträgst du nur die Änderungen, und BorgBackup entdoppelt zusätzlich.

Große Downloads ausliefern

Für Dateien, die Besucher herunterladen sollen, ist der Storage ideal: Sie werden selten gelesen, sind groß, und sie müssen nicht schnell sein, sondern nur ankommen. Der Zugriff läuft über ein kleines Skript, das vorher die Berechtigung prüft:

<?php
// in der functions.php oder als eigenes Plugin
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('Bitte anmelden', '', ['response' => 403]);
    }

    $pfad = '/mnt/storage/downloads/' . basename($_GET['kh_download']);
    if (!is_readable($pfad)) {
        wp_die('Datei nicht gefunden', '', ['response' => 404]);
    }

    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="' . basename($pfad) . '"');
    header('Content-Length: ' . filesize($pfad));
    readfile($pfad);
    exit;
});

Das Beispiel geht von einem eingebundenen Speicher aus. Ohne Einbinden ersetzt du readfile() durch einen SFTP- oder WebDAV-Abruf, wie er in Storage Server für die eigene Website nutzen beschrieben ist.

Der Nebeneffekt ist angenehm: Weil die Datei nie eine öffentliche Adresse hat, kann niemand den Link weitergeben. Die Berechtigungsprüfung lässt sich nicht umgehen.

Was auf Shared Hosting übrig bleibt

Auf Shared Hosting ist WebDAV über HTTPS der verlässlichste Weg, weil Port 443 praktisch nie gesperrt ist. SFTP funktioniert ebenfalls, läuft bei uns aber auf Port 23, und nicht jeder Anbieter lässt ausgehende Verbindungen auf solchen Ports zu. Das sollte man vor der Bestellung kurz prüfen.

Ein Unterkonto je Zweck

Jeder Storage Server erlaubt bis zu 100 Unterkonten, jedes mit eigenem Startverzeichnis, eigenem Passwort und eigenen Protokollfreigaben. Für WordPress heißt das mindestens zwei:

• Ein Konto für die Website, das nur /uploads sieht.
• Ein Konto für die Sicherungen, das nur /backup sieht.

Wird die Website einmal übernommen, findet der Angreifer in der wp-config.php die Zugangsdaten des ersten Kontos. Die Sicherungen bleiben unberührt, weil dieses Konto sie gar nicht kennt. Mit einem einzigen Hauptkonto wäre an dieser Stelle alles weg.

Wenn mehrere Benutzer eigenen Platz brauchen

Ein Storage Server kennt keine Quote je Unterkonto. Ein Konto bleibt in seinem Verzeichnis, kann dort aber den gesamten Tarif füllen. Wer Kunden, Fotografen oder Redakteuren je ein begrenztes Kontingent geben will, setzt deshalb eine Anwendung davor, die das übernimmt. Nextcloud ist dafür die naheliegendste, es bringt Benutzer, Quoten und Freigabelinks mit: Nextcloud mit dem Storage Server verbinden.

Welcher Tarif passt

Für eine einzelne WordPress-Seite mit Sicherungen reicht Storage-1 in aller Regel lange. Wer Mediatheken mehrerer Seiten auslagert oder mit Video arbeitet, landet schnell bei Storage-2 oder Storage-3. Alle Tarife stehen in Deutschland, kommen ohne Einrichtungsgebühr, werden auf PrePaid-Basis abgerechnet und haben keine Mindestlaufzeit. Ein Wechsel in den nächstgrößeren Tarif ist jederzeit möglich, ohne die Daten anzufassen.