Nextcloud und Amazon S3: Der externe Speicher, der kein Dateisystem ist

Die Entscheidung für Nextcloud ist meist auch eine Entscheidung für Souveränität. Der eigene Server, die eigene Infrastruktur, die Hoheit über Benutzerkonten und Verschlüsselung – zumindest in der Theorie. Umso ernüchternder ist es, wenn die Daten dann doch bei Amazon landen. Oder genauer: in einem S3-Bucket, einem Objektspeicher, der von außen bequem wirkt, sich aber grundlegend von dem unterscheidet, was Administratoren als „Dateisystem“ kennen.

Trotzdem ist die Kombination aus Nextcloud und Amazon S3 erstaunlich beliebt. Und sie ist keineswegs ein Widerspruch, solange man versteht, was da eigentlich passiert. Nextcloud bietet schon seit Jahren die Möglichkeit, über die App „External Storage“ verschiedene Speicheranbieter in den eigenen Datenraum einzuhängen. Ein S3-Bucket lässt sich damit wie ein lokales Verzeichnis im Dateibaum von Nextcloud behandeln. Man kann darin navigieren, Dateien hoch- und herunterladen, teilen, kommentieren – ein Großteil der Funktionen funktioniert ohne, dass die Nutzer überhaupt bemerken, dass ihre Daten in einem ganz anderen Rechenzentrum liegen als der Nextcloud-Server.

Dabei zeigt sich allerdings eines: Die Verlockung ist groß, S3 einfach als „günstigen Cloud-Speicher“ zu verwenden. Die Ernüchterung folgt spätestens dann, wenn man mit den Eigenheiten des Objektspeichers kollidiert. Wer sich einmal mit den Feinheiten von Nextcloud External Storage auf S3-Basis beschäftigt, wird feststellen, dass dieser Speicherplatz einiges an Denkarbeit abverlangt.

Was ist Amazon S3 eigentlich?

Für alle, die S3 nur vom Hörensagen kennen: Amazon Simple Storage Service ist kein klassischer Dateiserver. Ein Bucket ist letztlich eine flache Sammlung von Objekten, die über einen Schlüssel oder englisch „Key“ identifiziert werden. Die berühmte Ordnerstruktur, die man in der AWS-Konsole oder in Nextcloud sieht, ist eine Illusion, die auf einer Konvention beruht. Ein Objekt mit dem Namen „/uploads/2025/bericht.pdf“ hat keinen echten Ordner über sich; der Pfad ist Teil des Dateinamens. Das ist eine wichtige Erkenntnis, denn die fehlende Hierarchie beeinflusst fast alles, was an S3 später als Einschränkung empfunden wird.

Dafür bietet S3 eine Reihe von Vorteilen, die lokale Platten nicht haben. Der Speicher ist nahezu unbegrenzt skalierbar, langlebig und überall auf der Welt verfügbar. Amazon verspricht eine hohe Verfügbarkeit, und die API hat sich als De-facto-Standard für Objektspeicher durchgesetzt. Längst vermarkten auch andere Anbieter S3-kompatible Schnittstellen, darunter MinIO, Scaleway, Exoscale, Wasabi oder inzwischen auch Hetzner. Und Nextcloud kann mit allen diesen Diensten umgehen, weil sie dieselbe Sprache sprechen.

Obwohl man in der Nextcloud-Oberfläche konkret „Amazon S3“ auswählt, kann man bei Bedarf jeden S3-kompatiblen Dienst dort eintragen. Das ist ein Umstand, der vielen erst später auffällt. Insofern ist das Thema heute viel breiter, als der Name der Aution im Konfigurationsdialog vermuten lässt. Dennoch lohnt es sich, die Besonderheiten von Amazon S3 konkret zu betrachten, weil AWS nach wie vor der Maßstab ist – auch in Sachen Nebenwirkungen auf die Brieftasche.

Warum S3 External Storage in Nextcloud?

Wer eine Nextcloud-Instanz betreibt, steht irgendwann vor der Platzfrage. Die Datenbank, in der Metadaten und Dateien liegen, wächst. Die Festplatten des Servers werden knapp. Neue User kommen dazu, Projekte sammeln immer mehr Dateien, und die Backups werden unhandlich. Man könnte den Server erweitern, neue Platten einbauen, ein RAID umziehen – oder man mietet einfach Speicher in der Cloud. Amazon S3 erscheint da vielen als die einfachste Lösung, weil es keine Wartung erfordert und sofort verfügbar ist.

Nextcloud External Storage ist genau für solche Szenarien gedacht. Man bindet den S3-Bucket als Laufwerk innerhalb der Nextcloud ein, ohne den eigentlichen Datenbestand von Nextcloud dorthin zu verschieben. Das ist ein wichtiger Unterschied zum „Primary Storage“, bei dem Nextcloud die gesamten Daten aller Nutzer direkt im Objektspeicher ablegt. Beim External Storage bleibt es bei einer Erweiterung, die der Administrator oder auch ein einzelner Benutzer einhängen kann. Man kann einem Team also einen gemeinsamen Bereich geben, der in Wirklichkeit ein S3-Bucket ist, während die persönlichen Dateien weiterhin lokal liegen.

Der Charme liegt auf der Hand: Der Nextcloud-Server bleibt schlank, die Administratoren müssen sich nicht um die Erweiterung der eigenen Festplatten kümmern, und die Anwender arbeiten einfach weiter in ihrer gewohnten Umgebung. Kein zusätzlicher Webclient, keine zweite Benutzeroberfläche, keine komplexe VPN-Sache. Nextcloud wird dabei zum Gateway zwischen den Nutzern und dem Objektspeicher. Das Interface bleibt gewohnt, egal ob die Dateien aus einer lokalen Platte, von einem SMB-Server oder aus einem S3-Bucket kommen.

Die Praxis sieht allerdings oft anders aus, als die Werbeversprechen vermuten lassen. Wer S3 mit Nextcloud verbindet, sollte sich klarmachen, dass Nextcloud in diesem Fall ein Mittelsmann ist. Jede Datei, jeder Ordnerinhalt, jedes Streaming wird über die Nextcloud-Instanz geleitet. Das bedeutet: Wenn ein User in einer entfernten Stadt eine Datei herunterladen möchte, holt der Nextcloud-Server zunächst das Objekt von S3, um es dann an den Browser weiterzureichen. Das kostet Zeit, Bandbreite und letztlich auch Geld – besonders, wenn AWS Egress-Gebühren anfallen.

Die Einrichtung kann jeder, die Konfiguration ist die Kunst

Technisch gesehen ist die Anbindung eines S3-Buckets an Nextcloud kein Hexenwerk. Man installiert die App „External Storage Support“, öffnet unter „Verwaltung“, dann „Externe Speicher“ und fügt einen neuen Speicher des Typs „Amazon S3“ hinzu. Die Eingabemaske fragt nach einem lokalen Ordnernamen, nach der Verfügbarkeit für Benutzer oder Gruppen und natürlich nach den Zugangsdaten. Access Key, Secret Key, Bucket-Name – das ist so weit unspektakulär.

Interessant wird es bei den versteckten Optionen. Die Region zum Beispiel. Wer in Europa arbeitet und den Bucket in Frankfurt oder Irland angelegt hat, sollte die Region nicht vergessen. Nextcloud nutzt die Angaben, um den korrekten regionalen Endpunkt zu erreichen. Wenn die Region nicht stimmt, funktioniert die Authentifizierung nicht – oder schlimmer, es werden Daten an den falschen geografischen Ort geschickt. Manche Administratoren wundern sich dann, warum die Verbindung langsam ist, und die Lösung liegt einfach darin, dass der Traffic einmal quer über den Atlantik läuft.

Dazu kommt die Frage, ob der Bucket über „Virtual-Hosted-Style“ oder „Path-Style“ angesprochen wird. Bei Amazon S3 wird standardmäßig die moderne Form verwendet: Der Bucket-Name wird Teil der URL, also etwa „https://bucketname.s3.eu-central-1.amazonaws.com“. Bei anderen S3-Implementierungen funktioniert das aber nicht immer, weil die DNS-Konfiguration anders ist. MinIO etwa bevorzugt den alten „Path-Style“, bei dem der Bucket als Pfad in der URL auftaucht. Nextcloud bietet in der Auswahlmöglichkeit an, zwischen diesen Varianten zu wechseln. Zu wissen, welche Variante der jeweilige Anbieter unterstützt, gehört zur Grundausstattung eines Administrators.

Die häufigsten Fehler bei der Einrichtung haben übrigens nichts mit Nextcloud oder dem S3-Protokoll zu tun, sondern mit den AWS-Berechtigungen. Es kursieren immer wieder Anleitungen, in denen der Administrator die Zugangsschlüssel des AWS-Root-Kontos in Nextcloud einträgt. Das funktioniert zwar, ist aber ein erhebliches Sicherheitsrisiko, denn der Root-Benutzer hat Zugriff auf sämtliche Dienste des AWS-Kontos. Stattdessen sollte man einen dedizierten IAM-Benutzer anlegen, dessen Rechte auf einen einzigen Bucket beschränkt sind. Die Policy dafür ist mit ein paar Zeilen erledigt, wird aber gerne unterschlagen. Immerhin gilt auch für die interne Nextcloud-Instanz: Wer den externen Speicher übernimmt, verwaltet faktisch eine Brücke zu AWS – und diese Brücke sollte so schmal wie möglich sein.

Ein weiterer Aspekt ist die Angabe des Endpunkts. Nextcloud fragt standardmäßig nach einer „Hostname“-, manchmal auch nach einer „URL“-Angabe. Wer Amazon S3 nutzt, sollte hier den regionalen Endpunkt angeben – nicht irgendeine generische Adresse aus einem alten Blogbeitrag. Beispiel: Stand die Instanz früher in Frankfurt, der Bucket wurde aber später nach Irland verschoben, dann sollte auch der Endpunkt in der Konfiguration angepasst werden. Das klingt trivial, wird aber in der Praxis oft übersehen, da Amazon weiterhin stillschweigend eine Weiterleitung vornimmt.

Metadaten, Ordner und andere Illusionen

Nach erfolgreicher Einrichtung erscheint der S3-Bucket als Ordner im Dateibaum von Nextcloud. Und jetzt kommt der Punkt, an dem viele Benutzer zum ersten Mal an den Eigenheiten des Objektspeichers scheitern. Sie versuchen, einen kompletten Ordner von einem Nextcloud-Bereich in den S3-Bereich zu verschieben. Nextcloud stößt dabei an eine Grenze, die beim normalen Dateisystem nicht existiert: S3 kennt keine „Rename“-Operation für Verzeichnisse. Um einen Ordner zu verschieben, muss das System jedes einzelne Objekt kopieren und anschließend löschen. Das ist nicht nur langsam, sondern erzeugt auch eine Unmenge an API-Requests, die am Ende auf der AWS-Rechnung landen.

Intern legt Nextcloud die Dateien im S3-Bucket in einer Struktur ab, die zwar wie ein Ordner aussieht, aber letztlich nur aus Schlüsseln mit einem Schrägstrich besteht. Beispiel: Die Datei „Projektbericht.pdf“ im Nextcloud-Ordner „S3-Archiv“ hat den S3-Key „S3-Archiv/Projektbericht.pdf“. Das ermöglicht es Nextcloud, die Hierarchie nachzustellen. Dennoch ist es ein Unterschied, ob man ein echtes Verzeichnis inklusive Attributen auf einem lokalen Dateisystem anlegt oder ob man eine flache Schlüsselstruktur simuliert. Man merkt das etwa daran, dass S3 keine leeren Ordner kennt. Ein Ordner existiert nur so lange, wie es ein Objekt mit dem passenden Präfix gibt. Räumt man alle Dateien aus einem Ordner, verschwindet auch der Ordner selbst – was Nextcloud in der Oberfläche manchmal mit einer leeren Hülse kaschiert.

Ein interessanter Aspekt ist die Dateiversionierung. Viele Nextcloud-Administratoren sind gewohnt, dass ältere Versionen einer Datei vorgehalten werden und man den Papierkorb lokaler Speicher leeren kann. Bei S3 ist das anders. Zwar kann AWS in einem Bucket die Versionierung aktivieren, was im Hintergrund jeden Objektstand speichert. Aber Nextcloud weiß davon nichts. Wenn eine Datei über Nextcloud gelöscht wird, führt das im S3-Bucket zu einem „Delete Marker“, sofern die Bucket-Versionierung aktiv ist. Die Datei ist also nicht sofort weg, aber sie ist für Nextcloud nicht als Papierkorb-Inhalt sichtbar. Der Nextcloud-Papierkorb ist eine Funktion der lokalen Datenhaltung. Externe Speicher haben davon oft eine eigene, reduzierte Vorstellung. Das führt im Ernstfall zu bösen Überraschungen: Man löscht in Nextcloud eine Datei auf dem S3-Laufwerk und wundert sich, warum sie nicht im Papierkorb auftaucht.

Ich rate daher dazu, die S3-eigene Versionierung unabhängig von Nextcloud zu aktivieren, wenn der Bucket wichtige Daten enthält. Sie ist billig, verhindert aber nicht, dass man in der Oberfläche verzweifelt, weil der scheinbar leere Ordner in AWS Hunderte von Objekten enthält. Wer allerdings einmal in der AWS-Konsole nachschaut, wundert sich, warum der Speicherplatzverbrauch plötzlich steigt. Die Antwort sind eben diese alten Objektversionen, die nach einer Löschung in Nextcloud noch als historische Versionen liegen bleiben.

Performance: Wenn der Server zum Flaschenhals wird

Die Performance von S3 External Storage hängt von drei Faktoren ab: der Anbindung des Nextcloud-Servers an AWS, der Größe der Dateien und der Geduld des Anwenders. Was viele nicht beachten: Die Verbindung zwischen Nextcloud und S3 ist nur ein Teil der Strecke. Der Nutzer sitzt vielleicht im selben Netz wie der Nextcloud-Server, muss aber trotzdem auf die Daten aus einem AWS-Rechenzentrum warten, das möglicherweise hunderte Kilometer entfernt ist. Jede Datei wird von S3 zum Nextcloud-Server übertragen und von dort an den Client ausgeliefert. Bei kleinen Dateien ist das kein Thema. Bei großen Videos, virtuellen Maschinen oder Datenbank-Dumps wird die Sache zur Geduldsprobe.

Nextcloud versucht, den Zugriff durch ein internes Caching abzufedern. Aber das Caching bezieht sich meist auf die Metadaten der Dateien, also auf Dateinamen, Größen und Änderungsdaten. Der Inhalt wird in den seltensten Fällen vollständig auf dem Nextcloud-Server zwischengespeichert. Und selbst wenn dieses Caching aktiviert ist, belegt es schnell wertvollen Platz auf dem lokalen Datenträger. Wer also glaubt, mit einem kleinen Nextcloud-Server und einem riesigen S3-Bucket ein Performance-Wunder zu erleben, der wird enttäuscht. Der Server muss jede Datei durchreichen, und das kostet CPU, RAM und vor allem Netzwerkbandbreite.

Ein weiteres Manko ist die fehlende POSIX-Kompatibilität. S3 unterstützt keine Sperren auf Dateiebene. Wenn zwei Benutzer gleichzeitig dieselbe Datei in Nextcloud bearbeiten, kann es zu Konflikten kommen, die Nextcloud normalerweise über Dateisperren abfängt. Bei S3 ist das nicht so einfach. Nextcloud nutzt seine Datenbank, um die Sperre zu verwalten. Aber was nützt eine Sperre, wenn ein anderer Client direkt auf den Bucket zugreift? Dann gibt es keine Möglichkeit, die Datei gegen konkurrierende Schreibzugriffe abzusichern. Solche parallelen Zugriffe sind einer der Hauptgründe, warum man S3 nicht wie ein normales Netzlaufwerk behandeln sollte.

Sicherheit beginnt vor dem Bucket

Wer Amazon S3 als externen Speicher an Nextcloud anbindet, verschiebt die Sicherheitsarchitektur auf mehrere Ebenen. Der Nextcloud-Server ist eine Angriffsfläche, der AWS-Account eine andere, und die Übertragungsstrecke dazwischen ist die dritte. Nextcloud bietet seit Langem eine serverseitige Verschlüsselung an, die Daten bereits im lokalen Dateisystem verschlüsselt. Diese Verschlüsselung lässt sich prinzipiell auch für Externen Speicher verwenden. Man sollte sich jedoch darüber im Klaren sein, dass die Verschlüsselung dann auf der Nextcloud-Ebene stattfindet und die verschlüsselten Objekte so im S3-Bucket landen. Das ist grundsätzlich sinnvoll, weil auch Amazon selbst dann keinen Klartext lesen kann. Aber es hat einen Haken: Die Schlüsselverwaltung liegt dann vollständig bei Nextcloud, und wenn die Datenbank oder der Schlüsselbestand verloren geht, sind die Daten im S3-Bucket unlesbar. Ein Backup der Datenbank und der Schlüssel ist damit nicht optional.

AWS seinerseits bietet mit der Server-Side Encryption verschiedene Möglichkeiten, Daten auf dem Bucket zu verschlüsseln. Man kann die Standardschlüssel von Amazon verwenden oder KMS-Schlüssel aus dem eigenen AWS-Konto. Diese Verschlüsselung schützt die Daten auf dem Weg in den Speicher und auf der Festplatte. Sie schützt aber nicht davor, dass ein Angreifer mit gültigen Zugangsdaten die Daten über die normale API liest. Das ist ein Unterschied, der in Kundengesprächen oft übersehen wird. Verschlüsselung ist kein Ersatz für eine saubere Zugriffskontrolle.

Die Zugriffskontrolle beginnt in Nextcloud mit der Vergabe des S3-Speichers. Man kann den externen Speicher nur für bestimmte Gruppen freigeben. Das ist sinnvoll, aber es ist nicht die letzte Verteidigungslinie. Der eigentliche AWS-Zugangschlüssel wird von allen Nextcloud-Anwendern gemeinsam genutzt, sobald sie Dateien über den externen Speicher ablegen. Das bedeutet: Ein kompromittierter Nextcloud-Account kann nicht nur auf Dateien in Nextcloud zugreifen, sondern auch auf den S3-Bucket – zumindest solange er ein Räumungsrecht über Nextcloud hat. Will man das unterbinden, braucht man eine feinere Lösung. Dazu gehört etwa, die AWS-Zugangsdaten nicht an normale Benutzer zu geben, sondern den gesamten AWS-Zugriff über Nextcloud zu kanalisieren und in Nextcloud wiederum mit App-Passwörtern oder Zwei-Faktor-Authentifizierung zu sichern.

Ein Punkt, der gerne unterschätzt wird: Wenn der Nextcloud-Server einmal kompromittiert ist, sind auch die S3-Schlüssel in Gefahr. Es ist deshalb ratsam, in AWS sogenannte „Access Keys“ zu verwenden, die nur das Recht haben, genau diesen einen Bucket zu nutzen, und die keine anderen Dienste administrieren. Die Vergabe dieser Keys ist der heikelste Teil der gesamten Installation. Wer hierzu das Root-Konto verwendet, macht im Grunde alles falsch, was man falsch machen kann.

Der Blick in die Kostenfalle

Amazon S3 wird oft mit einem niedrigen Gigabyte-Preis beworben. Das klingt verlockend, ist aber nur die halbe Wahrheit. S3 besteht aus mehreren Kostenblöcken: Speicher, Requests, Datenübertragung und möglicherweise zusätzlichen Funktionen wie Versionierung oder Lifecycle-Regeln. Nextcloud verursacht durch seine Arbeitsweise eine erhebliche Menge an Requests. Jede Anzeige eines Ordners kann Dutzende von „LIST“-Operationen auslösen, jede Datei, die geändert wird, benötigt mehrere „PUT“- und „GET“-Operationen. In der Praxis kommen da schnell einige tausend Requests pro Tag zusammen, und bei AWS kostet jeder Request einen winzigen Bruchteil eines Cents. Wenn das System allerdings unsauber konfiguriert ist und Nextcloud regelmäßig den gesamten Ordnerinhalt neu abruft, exponentieren sich die Kosten. Die monatliche Rechnung kann dann überraschend hoch ausfallen, obwohl die reine Speichermenge kaum gewachsen ist.

Ein weiterer Posten ist der Datentransfer. AWS berechnet Gebühren für Daten, die aus dem Bucket herausgehen – also genau das, was Nextcloud bei jedem Herunterladen tut. Der Traffic zwischen Nextcloud-Server und S3-Bucket ist nicht kostenlos. Wenn der Server aber selbst in einem AWS-Rechenzentrum in derselben Region steht, spart man sich diese Gebühr. Das ist ein starkes Argument dafür, eine Nextcloud-Instanz ebenfalls bei AWS zu betreiben, wenn man S3 als externen Speicher nutzt. Wer seine Nextcloud dagegen im eigenen Rechenzentrum oder bei einem deutschen Provider betreibt, zahlt für jede Datei, die vom Bucket abgerufen wird, die Egress-Gebühr. Bei großen Datenmengen kann diese Gebühr die Speicherkosten schnell übersteigen.

Der deutsche Markt hat hier zum Glück eine Alternative: Immer mehr heimische Anbieter haben S3-kompatible Speicher im Programm, die keine oder deutlich geringere Traffickosten verlangen. Ein öffentlicher Nextcloud-Dienst mit S3-Anbindung sollte daher nicht automatisch auf Amazon zeigen, nur weil „Amazon S3“ im Dialogfeld steht. Der Dienst bleibt derselbe, aber die Rechnung fällt anders aus.

Praktische Tipps aus dem Alltag

Nach einigen Jahren mit Nextcloud External Storage und diversen S3-kompatiblen Anbietern lässt sich ein paar Erfahrungen festhalten, die in keinem Handbuch stehen:

Erstens: S3 ist kein Ort für Daten, auf die Menschen täglich mit hoher Latenz zugreifen. Wenn ein Team ständig an denselben Dokumenten arbeitet, sind die Dateien in einem S3-Bucket spürbar langsamer als auf lokalen Platten. Das liegt nicht an Nextcloud, sondern an der Natur des Objektspeichers und der zusätzlichen Netzwerkstrecke. Für gemeinsames Arbeiten direkt in Nextcloud eignen sich S3-Buckets nur bedingt.

Zweitens: Man sollte S3 als Archiv oder als kalte Ablage nutzen. Viele Teams setzen genau das erfolgreich um: Der Nextcloud-Server steht im Firmennetz, und ein S3-Bucket wird als „Archiv“ eingebunden. Wer in der Ablage im Zweifel keine Datei verändert, sondern nur alte Unterlagen ablegt, der hat kaum Performance-Probleme. Und die Latenz fällt nicht ins Gewicht, wenn es ein reines Speichermedium ist.

Drittens: Einmal pro Woche sollte ein Blick auf die AWS-Rechnung geworfen werden, nicht erst am Monatsende. So erkennt man frühzeitig, ob eine Synchronisationsschleife oder eine fehlerhafte Nextcloud-Aufgabe zu einer ungewöhnlichen Anzahl von API-Requests führt. Das passiert häufiger, als man denkt. Eine kaputte Verbindung oder ein fehlkonfigurierter Hintergrundjob kann mit einem Mal zehntausende Abfragen pro Tag auslösen, ohne dass ein Benutzer aktiv etwas tut.

Viertens: Das Anlegen des Buckets ist nicht die letzte Konfigurationssache. Lifecycle-Regeln in AWS können helfen, alte Objektversionen nach einigen Tagen automatisch zu löschen oder in den günstigeren Glacier-Speicher zu verschieben. Nextcloud selbst hat dafür kein Äquivalent. Es ist durchaus lohnend, diese Regeln direkt in AWS zu setzen. Sie sind flexibel und verhindern, dass der Bucket unkontrolliert wächst.

Eine Empfehlung, die man nicht oft genug wiederholen kann: Vor der Anbindung eines S3-Buckets sollte man testen, ob der Bucket wirklich leer ist. Klingt banal, ist aber ein häufiger Anfängerfehler. Wenn man einen S3-Bucket in Nextcloud einbindet, der bereits Daten aus einem anderen Projekt enthält, sieht Nextcloud diese Daten natürlich im Dateisystem – aber die Metadaten sind nicht mit Nextcloud synchronisiert. Das funktioniert zwar, aber es kann zu Konflikten kommen, wenn Nextcloud die Dateien in seiner Datenbank falsch einordnet. Ein leerer Bucket bleibt die sauberste Ausgangslage.

External Storage ist nicht gleich Primary Storage

In der Diskussion um Nextcloud und S3 wird oft zweierlei verwechselt: das externe Einbinden eines Buckets als Laufwerk und die Nutzung von S3 als eigentliches Datenverzeichnis von Nextcloud. Letzteres ist eine durchaus ernsthafte Option für den Betrieb einer Nextcloud im großen Stil. Nextcloud speichert dann die zugrunde liegenden Dateien nicht mehr auf einer lokalen Partition, sondern direkt in einem Objektspeicher. Das ist eine ganz andere Architektur, die vor allem im Enterprise-Umfeld attraktiv ist, weil sie das System unabhängig vom einzelnen Server macht.

Beim External Storage geht es jedoch um eine nachträgliche Ergänzung. Der Unterschied ist wichtig, weil sich die Verwaltung völlig anders gestaltet. External Storage bedeutet, dass Nextcloud die Daten nicht selbst verwaltet; es greift lediglich auf einen fremden Speicher zu. Die Konsequenzen zeigen sich bei Funktionen wie Papierkorb, Versionen, Einstellungen und vor allem bei den Datenbankeinträgen. Bestimmte Operationen an einer externen Datei können nicht sauber abgebildet werden, eben weil Nextcloud nicht die Kontrolle über den kompletten Lebenszyklus der Datei hat.

Auch im Bereich der Zugriffsrechte gibt es Unterschiede. Nextcloud verwendet für externe Speicher eine eigene Speicherkennung, die Dateien im externen Speicher aber wie normale Dateien behandelt. Der Administrator kann für diesen Mountpunkt festlegen, ob er für alle Benutzer oder nur für bestimmte Gruppen gilt. Er kann aber nicht einzelnen Unterordnern im S3-Laufwerk unterschiedliche Besitzer zuweisen. Das ist ein Beispiel, wo Nextcloud an die Grenzen der eigenen Abstraktion stößt.

Für den produktiven Einsatz ist es deshalb wichtig, sich vorab zu überlegen, ob man S3 als externe, geteilte Ablage einsetzt oder ob man die gesamte Nextcloud auf einem S3-Fundament aufbaut. Beides sind legitime Wege, aber beides sind unterschiedliche Projekte mit unterschiedlichen Risiken.

Der S3-Bucket und die Dateisperre

Wer schon einmal erlebt hat, dass sich zwei Personen gleichzeitig in dieselbe Datei in einer Nextcloud verirren, weiß, wie wichtig Dateisperren sind. Die Funktion ist in Nextcloud seit Langem eingebaut und funktioniert bei lokalen Dateien zuverlässig. Bei S3 sieht das anders aus. S3 kennt keine Dateisperren im herkömmlichen Sinne. Es gibt zwar die Möglichkeit, einzelne Objekte mit einer Sperre zu versehen, das nennt sich Object Lock, aber das ist eine Schutzfunktion für Compliance-Zwecke und keine dynamische Sperre für gerade laufende Bearbeitungsvorgänge.

Nextcloud umgeht dieses Manko, indem es die Sperren in seiner Datenbank festhält. Das funktioniert so lange, wie alle Zugriffe tatsächlich über Nextcloud laufen. Sobald es aber einen zweiten Weg in den S3-Bucket gibt – etwa über die AWS-Konsole, ein Skript oder eine Anwendung, die direkt auf den Bucket zugreift –, ist die Sperre wirkungslos. Wenn ein Nextcloud-Benutzer eine Datei sperrt und ein anderes Mitglied der Firma die Datei gleichzeitig über die AWS-API verändert, kann es zu Datenverlust oder Inkonsistenzen kommen.

Für Unternehmen, die S3 als externe Ablage in Nextcloud nutzen wollen, heißt das: Zusätzliche Zugriffspfade auf den Bucket sollte man konsequent vermeiden. Der Bucket gehört nicht in den Händen der Fachabteilung, sondern ist technisches Rüstzeug, das idealerweise nur die Nextcloud-Instanz und der Administrator sehen. Wenn andere Abteilungen eigene Tools verwenden, die Daten in denselben Bucket schreiben oder lesen, dann vermischt sich das schnell zu einem Datenchaos.

Die Alternative: S3-kompatible Dienste einbinden

Amazon ist nicht gleich Amazon. Die Nextcloud-Konfigurationsmaske bietet unter dem Namen „Amazon S3“ eigentlich ein Sammelbecken für alle Dienste, die die S3-API beherrschen. Es lohnt sich, diesen Umstand auszuschlachten. Gerade in Deutschland und Europa sind mittlerweile Anbieter wie Hetzner oder Scaleway mit S3-Schnittstellen präsent, die bessere Datenschutzbedingungen erfüllen als der US-Cloud-Riese. Das ist für viele Unternehmen ein entscheidendes Argument, insbesondere wenn personenbezogene Daten verarbeitet werden.

MinIO ist zudem eine Open-Source-Software, die man im eigenen Rechenzentrum als S3-kompatiblen Speicher aufsetzen kann. Die Kombination aus einer Nextcloud im eigenen Rechenzentrum und einem MinIO-Cluster auf derselben Infrastruktur ist eine sehr elegante und vor allem geopolitisch robuste Lösung. Der Aufwand dafür ist nicht viel höher als für die Anbindung an Amazon. Man muss nur wissen, dass MinIO Path-Style-Endpunkte nutzt, und Nextcloud dafür entsprechend konfigurieren. Wer einmal die S3-kompatible Welt durchgespielt hat, wird feststellen: Der Name „Amazon S3“ in der Nextcloud-Oberfläche ist fast irreführend, denn die Möglichkeiten sind breiter, als der AWS-Riese es suggeriert.

Ein Vorteil der europäischen Anbieter ist die kalkulierbare Datenübertragung. Viele haben keine oder nur begrenzte Egress-Gebühren. Für Nextcloud-Betreiber, die nicht möchten, dass die monatliche Rechnung explodiert, ist das ein Segen. Der Nachteil dieser Dienste liegt manchmal im Detail, etwa bei der maximalen Anzahl von Requests oder der Verfügbarkeit einer Versionierungsfunktion. Bevor man sich festlegt, sollte man also nicht nur den Preis pro Gigabyte vergleichen, sondern auch die API-Limits und die Zusatzkosten für Traffic und Requests unter die Lupe nehmen.

Die Bedeutung der Datenbanksynchronität

Eine Sache, die viele Admins in den Wahnsinn treibt, ist die Frage: Warum sieht Nextcloud eine Datei nicht, die direkt im S3-Bucket angelegt wurde? Die Antwort ist simpel: Nextcloud synchronisiert den externen Speicher nicht automatisch in Echtzeit. Die Ordnerstruktur und die Dateien werden auf Basis der Datenbank abgebildet. Wenn jemand außerhalb von Nextcloud ein Objekt in den Bucket legt, erfährt Nextcloud davon erst beim nächsten Abgleich der Metadaten. Nextcloud hat dafür einen Hintergrundjob, der den Inhalt des externen Speichers abgleicht. Diesen Job muss man aktivieren und gegebenenfalls in kurzen Intervallen laufen lassen.

Solche Abgleiche sind aber nicht gratis. Bei S3 bedeutet jeder Abgleich eine Menge an API-Requests, die auf der AWS-Rechnung auftauchen. Ein zu häufiger Abgleich kann teuer werden. Ein zu seltener Abgleich führt zu einem veralteten Dateibestand in der Nextcloud-Oberfläche. Die Kunst ist, das richtige Intervall zu finden. In einem typischen Unternehmen reicht ein Abgleich alle fünfzehn Minuten meist völlig aus. Wer allerdings einen Bucket als Ablage für eine Anwendung nutzt, die automatisiert Daten hineinschreibt, sollte überlegen, ob Nextcloud wirklich das richtige Frontend ist oder ob nicht eine strukturierte Upload-Pipeline mit fester Dateinamensliste sinnvoller wäre.

Noch kniffliger wird die Sache bei Dateiänderungen. Wenn ein Objekt direkt in S3 verändert wird, überschreibt es das vorhandene Objekt. Nextcloud erkennt die Änderung anhand der Modifikationszeit und gleicht sie beim nächsten Abgleich ab. Allerdings kann Nextcloud nicht erkennen, ob dieselbe Datei auf der Nextcloud-Seite gerade lokal verändert wurde. In diesem Fall kommt es zu einem Konflikt, den Nextcloud nicht echt lösen kann. Es entsteht dann im Grunde die Frage: Wem gehört die Datei? Der Letzte, der schreibt, gewinnt. Das ist kein spezifisches S3-Problem, aber bei einem externen Speicher entsteht diese Kollision viel leichter, weil externe Anwendungen nicht in die Nextcloud-Interne Dateikontrolle eingebunden sind.

Wartung und Monitoring

Die Anbindung an S3 ist keine Feuer-und-vergessen-Geschichte. Wenn Nextcloud nicht mehr auf den Bucket zugreifen kann, macht sich das nicht sofort bemerkbar. Nextcloud puffert einen Teil der Fehler und zeigt den externen Speicher in der Admin-Oberfläche einfach als „nicht verfügbar“ an. Im Useralltag bedeutet das: Dateien sind plötzlich unsichtbar. Sie werden nicht angezeigt, bis die Verbindung wieder steht. In solchen Fällen hilft ein Monitoring, das die S3-Konfiguration überwacht und Alarm schlägt, bevor die Benutzer sich beschweren.

Ein guter Indikator ist die Zugriffszeit auf den Bucket. Nextcloud bietet dafür kein direktes Dashboard, aber man kann mit einfachen Skripten oder der AWS-CLI den Bucket von außen pingen. Ein weiterer Punkt ist die Auslastung der lokalen Nextcloud-Festplatte, denn der externe Speicher nutzt lokalen Platz für den Metadaten-Cache. Wenn der Datenbestand im S3-Bucket rasant wächst, kann auch der lokale Speicher des Nextcloud-Servers unerwartet knapp werden.

Nicht zuletzt gehört auch das Backup des AWS-Buckets selbst in das Gesamtkonzept. Viele verlassen sich darauf, dass AWS die Daten schon nicht verlieren wird – die berühmte 99,999999999-Prozent-Haltbarkeit. Aber diese Haltbarkeit ist ein statistisches Phänomen und schützt nicht vor einer fehlerhaften Löschaktion, einem kompromittierten Schlüssel oder einem böswilligen Administrator. Ein separates Backup des Buckets an einem anderen Standort ist daher genauso notwendig wie ein Backup der Nextcloud-Datenbank. Die Daten aus S3 wiederherzustellen ist ein Akt, den man nicht zum ersten Mal im Notfall probieren sollte.

Blick in die Zukunft

Nextcloud und Objektspeicher – das ist keine flüchtige Modeerscheinung. Die Integration von S3 in die nächsten Generationen von Nextcloud wird eher noch enger werden. Nextcloud hat in den letzten Jahren seine Objektspeicher-Anbindung stark ausgebaut, vor allem mit Blick auf die Primary Storage-Architektur. Damit reagiert das Projekt auf die Erkenntnis, dass klassische Dateiserver bei großen Installationen nicht mehr mithalten oder zu teuer sind. Objektspeicher sind günstiger, skalierbarer und über Rechenzentren hinweg verfügbar.

Bedeutet das, dass das Konzept „External Storage“ eines Tages verschwindet? Wohl kaum. Der Bedarf, unterschiedliche Speicherorte in einer einzigen Oberfläche zu vereinen, ist zu groß. Viele Unternehmen haben bereits Daten auf NAS-Systemen, in SharePoint-WebDav-Verzeichnissen und an verschiedenen Orten. External Storage ist die Brücke, um diese Fragmentierung zu überwinden, ohne alle Daten physisch zu migrieren. Gerade S3 bietet sich dabei an, weil es als Ziel und als Quelle funktioniert. Man kann ein altes NAS einbinden und die Daten später nach S3 migrieren. Das geschieht in derselben Umgebung, ohne die Anwender zu schulen. So ist der External Storage auch ein Werkzeug des Übergangs.

Dennoch sollte man sich nicht der Illusion hingeben, dass eine solche Anbindung die Komplexität der IT vermindert. Sie verlagert sie nur. Anstelle von lokalen Festplatten verwaltet man Buckets, IAM-Policies, Lifecycle-Regeln und die S3-API. Die Frage ist nicht mehr nur, wie viel Speicherplatz vorhanden ist, sondern wie die Übergänge zwischen den Speicherwelten organisiert werden. Administratoren müssen sich heute mit zwei Datenbanken herumschlagen: mit der von Nextcloud und der von AWS. Das ist nicht unbedingt schlechter, aber es ist anspruchsvoller.

Fazit: S3 in Nextcloud – ja, aber richtig

Nextcloud External Storage in Verbindung mit Amazon S3 ist eine mächtige Sache, wenn man die Eigenheiten beider Systeme versteht. Es ist keine Lösung für ein paar Klicks, sondern ein kleines Projekt, das sorgfältig geplant und überwacht werden will. Wer bereit ist, sich mit Buckets, Keys, Regionen und Endpunkten zu beschäftigen, bekommt eine erstaunlich flexible Ablage: unbegrenzt wachsbar, unabhängig vom Serverstandort und anschlussfähig an die große Welt der Cloud-Dienste.

Auch wer Amazon aus Datenschutzgründen ablehnt, findet mit den S3-kompatiblen Anbietern eine Möglichkeit, die Architektur zu nutzen, ohne die Daten dem US-Konzern anzuvertrauen. Der deutsche Markt hat inzwischen einiges zu bieten, und Nextcloud steht dieser Entwicklung aufgeschlossen gegenüber. Die zentrale Erkenntnis aber lautet: S3 bleibt S3. Man kann es in einem Nextcloud-Netzdialog spazieren führen, aber man sollte nie vergessen, dass es im Hintergrund ein flaches, fernes Objektsystem ist, das sich grundlegend von einer vertrauten Festplatte unterscheidet. Wer das verinnerlicht, wird auf lange Sicht Freude an der Kombination haben – und weniger Überraschungen auf der Rechnung.

Ein letzter Rat aus der Praxis: Führt das Vorhaben nicht in einem Winkel der Nextcloud-Installation ein, sondern behandelt es wie ein eigenes Subsystem. Schafft klare Verantwortlichkeiten, dokumentiert die Bucket-Struktur und legt schon am Anfang fest, wer Zugriff haben darf und wer nicht. Ein einziger S3-Bucket mit einer gut durchdachten Ordnerstruktur kann ein Unternehmen jahrelang begleiten. Ein ungeordneter Bucket wird zur digitalen Müllhalde, auf der kaum jemand noch etwas findet. Die Entscheidung über die Einführung von S3 in Nextcloud ist also weniger eine technische als eine organisatorische.

Dass Nextcloud diese Option überhaupt schon so lange anbietet, ist bemerkenswert. In einer IT-Welt, die gern schnelle, oberflächliche Lösungen feiert, ist die External-Storage-Funktion ein Stück pragmatische Solidität. Sie wird uns erhalten bleiben – und sie verdient mehr Aufmerksamkeit, als sie in der täglichen Admin-Arbeit üblicherweise bekommt.