Storage Server für die eigene Website nutzen: Bilder, Downloads, Archive
Der Platz auf einem Webserver ist teuer, der auf einem Storage Server nicht. Dieser Artikel zeigt, was sich auslagern lässt, welches Protokoll vom Webserver aus funktioniert und wie die Dateien sicher bei den Besuchern ankommen.
Auf einem Webserver ist Plattenplatz das teuerste Gut. Er sitzt auf schnellen NVMe-SSDs, die für Datenbanken und PHP gebaut sind, und wird mit jedem Gigabyte spürbar teurer. Gleichzeitig liegen dort Dinge, die diese Geschwindigkeit nie brauchen: Originalfotos, Videodateien, Downloadarchive, alte Sicherungen.
Ein Storage Server kostet einen Bruchteil davon und nimmt genau diese Last ab. Dieser Artikel zeigt, was sich sinnvoll auslagern lässt, welches Protokoll vom Webserver aus funktioniert, wie die Dateien sicher bei den Besuchern ankommen, und wo die Grenzen liegen.
Was sich auslagern lohnt, und was nicht
| Gehört auf den Storage | Bleibt auf dem Webserver |
|---|---|
| Originale von Bildern und Videos | Vorschaubilder und zugeschnittene Fassungen |
| Downloadarchive, ISO-Dateien, PDF-Sammlungen | CSS, JavaScript, Schriften |
| Rohdaten, Exporte, Protokollarchive | Die Datenbank |
| Sicherungen der Website | Alles, was bei jedem Seitenaufruf gebraucht wird |
Die Trennlinie ist einfach: Was selten gelesen und einmal groß übertragen wird, gehört auf den Speicher. Was bei jedem Seitenaufruf mitgeladen wird, bleibt dort, wo es schnell ist.
Was ein Storage Server ist, und was er nicht ist
Ein Storage Server ist Netzwerkspeicher mit Benutzerkonten. Du verbindest dich mit Zugangsdaten und liest oder schreibst Dateien. Er ist kein Objektspeicher mit öffentlichen Adressen und kein CDN.
Praktisch bedeutet das: Du kannst in deiner Seite kein Bild direkt auf den Speicher verlinken, denn jeder Zugriff ist angemeldet. Dein Webserver holt die Datei und reicht sie weiter, oder du erzeugst selbst zeitlich begrenzte Downloadlinks. Wie das sauber geht, steht weiter unten.
Das klingt nach einer Einschränkung, hat aber einen Vorteil: Niemand kann deine Dateien abgreifen, indem er Adressen errät oder einen Link weitergibt. Der Zugriff läuft immer über deine Anwendung, und damit über deine Regeln.
Das Muster, das in der Praxis funktioniert
Drei Schritte, mehr ist es nicht:
- Originale liegen auf dem Speicher. Sie werden einmal hochgeladen und danach selten angefasst.
- Abgeleitete Fassungen entstehen einmal und liegen auf dem Webserver. Also Vorschaubilder, zugeschnittene Varianten, komprimierte Versionen. Sie sind klein, und sie werden bei jedem Seitenaufruf gebraucht.
- Downloads laufen über deine Anwendung. Ein kleines Skript prüft die Berechtigung, holt die Datei vom Speicher und gibt sie aus.
Wer das umdreht und Vorschaubilder bei jedem Aufruf frisch vom Speicher holt, baut sich eine langsame Website. Die Netzlaufzeit je Datei summiert sich, und eine Galerie mit vierzig Bildern wartet vierzigmal.
Welches Protokoll für welchen Fall
| Protokoll | Port | Gut für | Braucht |
|---|---|---|---|
| SMB / CIFS | 445 | Einbinden als Verzeichnis | Root-Rechte auf dem Server |
| SSHFS | 23 | Einbinden als Verzeichnis, verschlüsselt | Root-Rechte auf dem Server |
| SFTP | 23 | Zugriff aus PHP, Skripte, Übertragungen | ausgehenden Port 23 |
| WebDAV über HTTPS | 443 | Shared Hosting, eingeschränkte Umgebungen | nur HTTPS |
| rsync | 23 | Abgleich großer Verzeichnisse | ausgehenden Port 23 |
| BorgBackup | 23 | Sicherungen mit Entdoppelung | ausgehenden Port 23 |
Die wichtigste Entscheidung hängt nicht am Geschmack, sondern an deinen Rechten: Auf einem eigenen Server bindest du den Speicher als Verzeichnis ein, und jede Anwendung kann ihn benutzen, ohne etwas davon zu wissen. Wie das geht, steht in Storage Server als Netzlaufwerk einbinden.
Auf Shared Hosting hast du keine Root-Rechte, Einbinden fällt damit aus. Dort führt der Weg über WebDAV oder SFTP aus der Anwendung heraus, und WebDAV ist meist der geringere Widerstand, weil Port 443 praktisch nie gesperrt ist.
Zugriff aus PHP einrichten
Für SFTP genügt eine reine PHP-Bibliothek, es braucht keine Erweiterung auf dem Server:
composer require phpseclib/phpseclib:~3.0
use phpseclib3\Net\SFTP;
$sftp = new SFTP('u123456.storage.kernelhost.net', 23);
if (!$sftp->login('u123456-sub1', $passwort)) {
throw new RuntimeException('Anmeldung fehlgeschlagen');
}
// Datei hochladen
$sftp->put('/bilder/2026/original.jpg', '/tmp/upload.jpg', SFTP::SOURCE_LOCAL_FILE);
// Datei lesen
$inhalt = $sftp->get('/bilder/2026/original.jpg');
Für WebDAV reicht sogar die eingebaute curl-Erweiterung:
$ch = curl_init('https://u123456.storage.kernelhost.net/bilder/2026/original.jpg');
curl_setopt_array($ch, [
CURLOPT_RETURNTRANSFER => true,
CURLOPT_USERPWD => 'u123456-sub1:' . $passwort,
CURLOPT_TIMEOUT => 30,
]);
$inhalt = curl_exec($ch);
curl_close($ch);
Beide Beispiele nutzen ein Unterkonto, nicht das Hauptkonto. Warum, steht im nächsten Abschnitt.
Für jeden Zweck ein eigenes Unterkonto
Jeder Storage Server erlaubt bis zu 100 Unterkonten, und zwar in jedem Tarif. Jedes bekommt:
- ein eigenes Startverzeichnis, aus dem es nicht herauskommt,
- ein eigenes Passwort,
- eigene Protokollfreigaben, also zum Beispiel nur SFTP und kein Samba.
Für eine Website heißt das: ein Unterkonto für den Webserver, das nur SFTP darf und nur /web sieht, ein zweites für die Sicherung, das nur /backup sieht. Wird der Webserver einmal übernommen, kommt der Angreifer nicht an die Sicherungen, denn das Konto kennt sie gar nicht.
Eine Grenze gibt es: Ein Unterkonto bekommt kein eigenes Platzkontingent. Es bleibt in seinem Verzeichnis, kann dort aber den gesamten Speicher des Tarifs füllen. Wer einzelne Nutzer wirklich begrenzen will, braucht eine Anwendung davor, die das übernimmt. Nextcloud mit dem Storage Server verbinden zeigt genau diesen Aufbau.
Downloads sicher ausliefern
Der häufigste Fehler ist, die Zugangsdaten in den Browser zu lassen, etwa über einen Link mit Benutzername und Passwort. Richtig ist, dass dein Server die Verbindung aufbaut und die Datei durchreicht:
<?php
// Berechtigung pruefen, bevor irgendetwas passiert
if (!nutzer_darf_datei($_GET['id'])) {
http_response_code(403);
exit;
}
$sftp = neue_verbindung();
$datei = $sftp->get(pfad_zu($_GET['id']));
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="dokument.pdf"');
header('Content-Length: ' . strlen($datei));
echo $datei;
Bei sehr großen Dateien liest du besser in Blöcken statt alles in den Speicher zu laden, sonst reißt das PHP-Speicherlimit. Setze dafür ob_end_flush() und gib die Datei stückweise aus.
Wer viele gleichzeitige Downloads erwartet, sollte zusätzlich bedenken, dass jeder laufende Download einen PHP-Prozess belegt. Ab einer gewissen Größenordnung gehört so etwas hinter einen eigenen Server statt hinter Shared Hosting.
Die Website auf den Storage sichern
Das ist der einfachste Einstieg, und er bringt sofort etwas. Mit rsync überträgst du nur die Änderungen:
rsync -az --delete -e "ssh -p 23" \
/var/www/example.com/ \
u123456-sub2@u123456.storage.kernelhost.net:/backup/web/
Für Sicherungen mit Entdoppelung und Verschlüsselung ist BorgBackup die bessere Wahl, es ist auf dem Speicher nativ verfügbar. Dazu kommen die Snapshots des Speichers selbst als zweite Ebene: je nach Tarif 10, 20, 30 oder 40 manuelle Snapshots, dazu ebenso viele automatische in täglichem, wöchentlichem und monatlichem Rhythmus.
Der Unterschied zur Sicherung auf demselben Server ist der entscheidende: Eine gelöschte oder verschlüsselte Festplatte nimmt eine lokale Sicherung mit, eine Sicherung auf getrenntem Speicher nicht.
Bevor du anfängst: zwei Schalter
Im Kundenbereich findest du beim Storage Server den Knopf „Zugriffseinstellungen". Zwei Dinge müssen stimmen:
- Externe Erreichbarkeit muss eingeschaltet sein, sonst kommt dein Webserver über das Internet nicht an den Speicher.
- Das gewünschte Protokoll muss freigegeben sein, also Samba für SMB, SSH für SFTP und rsync, WebDAV für den HTTPS-Weg.
Bei neu bestellten Servern ist alles davon aktiv. Wer aus Sicherheitsgründen abschaltet, was er nicht braucht, sollte daran denken, dass genau das später die häufigste Ursache für „es geht nicht mehr" ist.
Welcher Tarif passt
| Tarif | Platz | Unterkonten | Snapshots | Preis |
|---|---|---|---|---|
| Storage-1 | 1 TB | 100 | 10 plus 10 automatisch | 9,99 EUR |
| Storage-2 | 5 TB | 100 | 20 plus 20 automatisch | 29,99 EUR |
| Storage-3 | 10 TB | 100 | 30 plus 30 automatisch | 39,99 EUR |
| Storage-4 | 20 TB | 100 | 40 plus 40 automatisch | 69,99 EUR |
Alle Storage Server stehen in Deutschland, sprechen FTP, FTPS, SFTP, SCP, Samba, WebDAV und WebDAVs, bringen rsync und BorgBackup nativ mit und haben IPv4 und IPv6. Es gibt keine Einrichtungsgebühr, abgerechnet wird auf PrePaid-Basis ohne Mindestlaufzeit. Du kannst also mit 1 TB anfangen und später vergrößern, ohne umzuziehen.
Für ein Rechenbeispiel: 1 TB zusätzlicher Platz auf einem Webserver kostet je nach Anbieter ein Vielfaches von 9,99 Euro im Monat, und er liegt dann auf derselben Maschine wie die Website. Der Speicher daneben ist nicht nur billiger, er ist auch getrennt.
Häufige Fragen
Kann ich Bilder direkt vom Storage Server in meine Website einbinden?
Welches Protokoll soll ich vom Webserver aus nehmen?
Ersetzt ein Storage Server ein CDN?
Wie viele Unterkonten kann ich anlegen?
Kann ich einem Unterkonto einen eigenen Speicherplatz zuteilen?
Wie schnell ist der Zugriff?
Sind die Zugangsdaten im Browser sichtbar?
Kann ich damit auch meine Website sichern?
Brauche ich dafür einen eigenen Server?
Was kostet das?
2026 KernelHost GmbH. Alle Rechte vorbehalten. Diese Anleitung ist urheberrechtlich geschützt. Eine Veröffentlichung auf anderen Webseiten, auch auszugsweise oder in bearbeiteter Form, ist ohne unsere schriftliche Zustimmung nicht gestattet. Zitate mit Quellenangabe und Link sind ausdrücklich willkommen.

