Nextcloud und S3 Skalierbare Speicherlösung

„`html

Vor einigen Wochen saß ich mit einem IT-Leiter zusammen, der seine Nextcloud-Instanz migrieren musste. Das lokale RAID war voll, die Erweiterung teuer – und die Geschäftsführung drängte auf eine Cloud-Lösung. Die Frage war: Wie bekommt man die nächsten Terabyte kosteneffizient unter, ohne die Kontrolle über die Daten zu verlieren? Die Antwort lag in einem Objektspeicher, genauer gesagt in S3-kompatiblen Buckets. Was damals wie eine technische Randnotiz klang, entpuppte sich als strategischer Schachzug. Denn Nextcloud und S3 – das ist mehr als nur eine Speichererweiterung. Es ist eine architektonische Entscheidung, die über Flexibilität, Skalierbarkeit und nicht zuletzt über die monatliche Rechnung entscheidet.

Das Ende der lokalen Plattenlogik

Wer Nextcloud betreibt, kennt das Problem. Die Daten wachsen, die Benutzer laden Fotos, Dokumente und Videos hoch – und die Festplatten im Server füllen sich. Früher oder später steht man vor der Entscheidung: nachrüsten, umziehen oder auslagern. Klassische SAN- oder NAS-Lösungen sind zwar erprobt, aber sie skalieren nur bedingt linear. Jedes zusätzliche Terabyte kostet nicht nur Speicherplatz, sondern auch Verwaltungsaufwand. Und dann ist da noch das Thema Ausfallsicherheit. Ein gespiegeltes RAID schützt vor Plattenausfall, aber nicht vor einem Controller-Defekt oder einem Brand im Rechenzentrum.

Genau hier setzt das Konzept des Objektspeichers an. Anders als bei blockbasiertem Storage speichert ein S3-kompatibles System Daten als Objekte – mit einer eindeutigen ID, Metadaten und ohne hierarchische Ordnerstruktur. Das klingt erstmal abstrakt, aber in der Praxis bedeutet es: unbegrenzte Skalierbarkeit, geografische Redundanz und oft ein deutlich günstigerer Preis pro Gigabyte. Nextcloud unterstützt S3 als primären Speicher schon seit einigen Versionen, und die Integration ist inzwischen so ausgereift, dass man sie in Produktivumgebungen einsetzen kann, ohne ständig Kompromisse eingehen zu müssen.

S3 in Nextcloud: Wie die Anbindung funktioniert

Die Architektur ist prinzipiell simpel. Nextcloud nutzt ein sogenanntes „External Storage“-Backend, das auf verschiedene Protokolle setzen kann – darunter S3, aber auch SFTP, WebDAV oder lokale Verzeichnisse. Entscheidend ist, dass S3 nicht nur als Anhängsel dient, sondern als vollwertiger Primärspeicher. Das bedeutet: Alle hochgeladenen Dateien landen direkt im Bucket, die Metadaten (Benutzer, Berechtigungen, Freigaben) verbleiben in der Nextcloud-Datenbank. Der Webserver selbst greift über die S3-API auf die Objekte zu. Das entkoppelt den Speicher von der Rechenleistung – ein klassischer Cloud-native-Ansatz.

Interessant wird es, wenn man tiefer in die Konfiguration eintaucht. Nextcloud unterscheidet zwischen „Primary Object Store“ und „Secondary Object Store“. Der primäre Objektspeicher wird für alle standardmäßigen Dateioperationen verwendet, während sekundäre Buckets etwa für Versionen oder Papierkorb zuständig sein können. Das ist ein Feature, das man nicht unterschätzen sollte: Versionierung und gelöschte Dateien fressen bekanntlich Platz, und wenn man sie auf einem separaten, günstigeren Speicher ablegen kann, spart das bares Geld.

Die Einrichtung erfolgt entweder über die Konfigurationsdatei config.php oder über die Kommandozeile mit occ. Ein typischer Eintrag sieht so aus:

  'objectstore' => [
    'class' => '\\OC\\Files\\ObjectStore\\S3',
    'arguments' => [
      'bucket' => 'nextcloud-data',
      'key'    => 'AKIA...',
      'secret' => '...',
      'region' => 'eu-central-1',
      'hostname' => 's3.amazonaws.com',
      'use_ssl' => true,
    ],
  ],

Das ist der Minimalfall. In der Praxis kommt es auf Details an: Welchen Hostname verwende ich bei einem S3-kompatiblen Dienst wie MinIO? Wie verhält es sich mit Pfaden innerhalb des Buckets? Und vor allem: Wie vermeide ich Latenzprobleme, wenn die Nextcloud-Instanz in Frankfurt steht, der Bucket aber in Oregon? Das sind keine akademischen Fragen, sondern echte Herausforderungen, die im Alltag entscheiden, ob die Lösung akzeptiert wird oder nicht.

Warum S3 die bessere Wahl sein kann – aber nicht immer

Der offensichtlichste Vorteil ist die Kostenstruktur. Während ein lokales SAN mit 20 TB schnell im fünfstelligen Bereich liegt, bieten S3-Dienste oft Pay-per-Use-Modelle an, die je nach Anbieter bei zwei bis fünf Cent pro Gigabyte und Monat beginnen. Dazu kommt, dass man keine Reserve für Spitzenlasten vorhalten muss – der Objektspeicher skaliert von allein. Wer also eine Nextcloud-Instanz mit vielen Benutzern betreibt, die unregelmäßig große Datenmengen hochladen, profitiert von dieser Elastizität.

Ein weiterer Punkt ist die geografische Verteilung. S3-Buckets lassen sich in verschiedenen Regionen replizieren. Das ist nicht nur für die Ausfallsicherheit relevant, sondern auch für die Performance. Ein internationales Team, dessen Mitglieder auf der ganzen Welt verteilt sind, kann auf den jeweils nächstgelegenen Bucket zugreifen – wenn die Infrastruktur entsprechend aufgebaut ist. Nextcloud selbst speichert die Metadaten zwar zentral, aber die Dateien liegen dezentral. Das reduziert Latenzzeiten massiv.

Aber: S3 ist kein Allheilmittel. Ein Aspekt, der oft übersehen wird, ist die Latenz beim Schreiben von kleinen Dateien. Objektspeicher arbeiten mit HTTP-Requests, und jeder Upload erzeugt einen Overhead. Bei tausenden von kleinen Textdateien oder Konfigurationsschnipseln kann das spürbar sein. Nextcloud puffert zwar, aber in Extremszenarien (etwa beim massenhaften Upload von Thumbnails) kann die Performance einbrechen. Hier hilft es, einen lokalen Cache oder eine CDN-Integration vorzuschalten. Auch der Einsatz von Redis als Transaktionspuffer ist zu empfehlen.

Die Qual der Wahl: Welcher S3-Anbieter passt?

Die Liste der S3-kompatiblen Dienste ist lang. Amazon Web Services (AWS) S3 ist der Urvater und bietet die umfangreichste Feature-Palette, aber auch die höchsten Kosten – vor allem bei Datenabrufen (Egress). Wer viele Dateien herunterlädt oder eine Nextcloud-Instanz im öffentlichen Netz betreibt, sollte die Kosten genau kalkulieren. Ein Tipp aus der Praxis: AWS S3 ist ideal für Archive und wenig frequentierte Daten, aber weniger geeignet für aktive Kollaborationsumgebungen.

MinIO ist eine interessante Alternative für alle, die die Kontrolle behalten wollen. Der Dienst lässt sich on-premises oder in einer eigenen Cloud-Umgebung betreiben und ist zu 100% kompatibel zur AWS S3 API. Das Schöne daran: Man kann MinIO auf handelsüblicher Hardware aufsetzen und spart sich die monatlichen Gebühren. Der Haken: Man ist selbst für Wartung, Backup und Hochverfügbarkeit verantwortlich. In größeren Unternehmen, die bereits über eine eigene Storage-Infrastruktur verfügen, ist MinIO daher eine beliebte Wahl.

Dazwischen tummeln sich Anbieter wie Wasabi, Backblaze B2 oder Scaleway. Wasabi wirbt mit null Egress-Kosten, was auf den ersten Blick verlockend klingt. Allerdings gibt es Fallstricke bei der Nutzung als Primärspeicher: Wasabi erhebt Gebühren für das Löschen von Daten innerhalb eines Mindestzeitraums. Wer also regelmäßig Dateien aktualisiert oder Versionen löscht, kann unerwartete Kosten produzieren. Backblaze B2 ist günstig, aber die API ist nicht vollständig deckungsgleich mit AWS S3 – manche Nextcloud-Komponenten brauchen Workarounds. Scaleway (Frankreich) punktet mit DSGVO-Konformität und günstigen Preisen in der Region, aber die Performance bei Schreibzugriffen ist nicht immer konstant.

Ein interessanter Aspekt ist die wachsende Zahl von lokalen Anbietern, die S3-kompatible Speicher in deutschen Rechenzentren anbieten. Hetzner zum Beispiel hat mit dem „Object Storage“ einen Dienst gestartet, der auf der S3-API basiert und preislich sehr attraktiv ist. Für Unternehmen, die Wert auf Datenhoheit legen, ist das eine echte Option. Allerdings ist das Angebot noch relativ jung, und nicht alle Nextcloud-Features (etwa Versioning in der Cloud) sind bereits vollständig getestet.

So vermeidet man typische Fallstricke

Die Integration von S3 in Nextcloud ist gut dokumentiert, aber die Praxis zeigt immer wieder die gleichen Probleme. Das erste ist die Vermischung von Primär- und Sekundärspeicher. Wer etwa den Primary Object Store auf S3 setzt, aber den Papierkorb auf einem lokalen Verzeichnis behält, erzeugt eine inkonsistente Latenz. Besser: alles auslagern oder alles lokal lassen. Die Migration bestehender Daten von lokalem Speicher auf S3 erfordert zudem eine sorgfältige Planung. Nextcloud bietet zwar das Tool occ files:scan und spezielle Migrationsskripte, aber bei einem produktiven System mit vielen Benutzern ist ein nächtliches Downtime-Fenster unvermeidlich.

Ein weiteres Problem sind fehlerhafte Berechtigungen. Da S3-Buckets über Access Keys verwaltet werden, muss der Schlüssel für Nextcloud sowohl Lese- als auch Schreibrechte haben. Wer aus Sicherheitsgründen restriktive IAM-Richtlinien einsetzt, kann schnell in eine Sackgasse geraten, wenn etwa das Anlegen von Unterordnern im Bucket verhindert wird. Nextcloud erzeugt nämlich für jeden Benutzer einen eigenen Pfad innerhalb des Buckets, und ohne entsprechende Rechte schlägt der Upload fehl. Die Lösung: eine gründliche Testphase mit einem separaten Bucket, bevor man den Produktivbetrieb umstellt.

Nicht zuletzt ist die Verschlüsselung ein Thema, das oft unterschätzt wird. S3 bietet serverseitige Verschlüsselung (SSE-S3 oder SSE-KMS), die den Datenverkehr zwischen Nextcloud und dem Provider schützt. Was aber, wenn der Provider selbst Zugriff auf die Schlüssel hat? In sensiblen Umgebungen sollte man clientseitige Verschlüsselung einsetzen, also die Daten bereits vor dem Upload verschlüsseln. Nextcloud unterstützt das mit der integrierten End-to-End-Verschlüsselung (E2EE), die allerdings nur für bestimmte Dateitypen und mit Leistungseinbußen funktioniert. Ein Kompromiss ist die Kombination aus serverseitiger Verschlüsselung und der Nutzung eines eigenen KMS (Key Management Service), etwa mit HashiCorp Vault oder AWS KMS. Aber das erfordert zusätzliche Infrastruktur und Know-how.

Performance-Tuning für S3 in der Praxis

Wer Nextcloud mit S3 zügig betreiben will, kommt um Caching nicht herum. Die Datenbankabfragen sind meist das kleinere Problem – der Flaschenhals ist der Netzwerkzugriff auf den Objektspeicher. Ein Redis-Server, der Metadaten und häufig abgerufene Dateiinformationen zwischenspeichert, reduziert die Latenz spürbar. Auch die Verwendung von APCu für den lokalen Cache ist empfehlenswert, insbesondere bei PHP-Opcache. Die Konfiguration dafür ist einfach und in vielen Nextcloud-Setups ohnehin Standard.

Ein weiterer Stellhebel ist die Optimierung der S3-Client-Einstellungen. Nextcloud verwendet unter der Haube die AWS SDK für PHP, die verschiedene Parameter wie Multipart-Upload-Schwellenwerte oder Timeouts zulässt. In der config.php kann man etwa 'objectstore_multipart_upload_size' => anpassen, um die Anzahl der parallelen Teile zu steuern. Bei großen Dateien über 100 MB ist Multipart-Upload ohnehin aktiv, aber die Standardwerte sind nicht für jede Netzwerksituation optimal. Ein zu kleiner Teil erhöht die Anzahl der Requests, ein zu großer Teil führt zu höheren Latenzen bei Fehlern. Empirische Tests sind hier der beste Ratgeber.

Wenn die Nextcloud-Instanz und der S3-Bucket in derselben Cloud-Region laufen (z. B. beide bei AWS in Frankfurt), ist die Latenz minimal. Kritisch wird es, wenn man einen externen Anbieter wie MinIO in einem eigenen Rechenzentrum betreibt. Dann sollte man die Netzwerkanbindung genau messen. Manchmal hilft es, einen lokalen Proxy oder eine CDN-Zone vor den Bucket zu schalten, um die Anbindung zu verbessern. Nextcloud selbst kann keine CDN-Anbindung von Haus aus, aber durch geschickte DNS-Konfiguration oder den Einsatz eines Reverse Proxy (nginx, HAProxy) lässt sich die Latenz für Lesezugriffe reduzieren.

Sicherheit und Compliance – was ist zu beachten?

Nextcloud wird oft in Umgebungen eingesetzt, in denen Datenschutz und Compliance oberste Priorität haben. Die Kombination mit S3 wirft sofort Fragen auf: Wo liegen die Daten? Wer hat Zugriff? Welche Verschlüsselungsstandards werden verwendet? Die Antwort hängt vom Anbieter ab. AWS S3 bietet beispielsweise Compliance-Zertifikate wie SOC 2, ISO 27001 oder PCI DSS. MinIO in einer eigenen Umgebung kann man nach eigenen Standards härten. Wichtig ist, dass Nextcloud selbst keine Metadaten über den Speicherort der Dateien speichert – die zentrale Datenbank enthält nur die Pfade, die Objekt-IDs und die Bucket-Konfiguration. Das bedeutet: Wenn der Bucket kompromittiert wird, sind die Dateien lesbar, aber ohne die Nextcloud-Datenbank (die idealerweise separat geschützt ist) weiß ein Angreifer nicht, welche Datei zu welchem Benutzer gehört. Das ist ein gewisser Schutz.

Ein kritischer Punkt ist das Löschen von Daten. S3-Buckets bieten in der Regel eine Versionierungsfunktion, die verhindert, dass Dateien endgültig gelöscht werden – es sei denn, man konfiguriert Lifecycle-Regeln. Wer also eine Nextcloud-Instanz betreiben möchte, die das vollständige Löschen von Dateien ermöglicht (etwa aus datenschutzrechtlichen Gründen), muss die Versionierung deaktivieren oder regelmäßig alte Versionen manuell entfernen. Das ist ein Balanceakt zwischen Datensicherheit und Compliance. Mein Rat: Vorab klären, welche gesetzlichen Anforderungen gelten, und dann die S3-Lifecycle-Policies entsprechend anpassen.

Nicht zu vergessen: Zugriffsprotokolle. AWS CloudTrail oder die Audit-Logs von MinIO zeichnen jeden API-Zugriff auf. Diese Logs sollte man mit einem SIEM-System korrelieren, um verdächtige Aktivitäten zu erkennen. Nextcloud selbst bietet ein internes Audit-Log, das Benutzeraktionen auf der Anwendungsebene protokolliert. Die Kombination beider Log-Quellen liefert ein umfassendes Bild und hilft, Sicherheitsvorfälle rechtzeitig zu erkennen.

Wann lohnt sich S3 für Nextcloud? Erfahrungen aus der Praxis

Ich habe in den letzten Jahren mehrere Migrationen begleitet – von kleinen Fünf-Personen-Teams bis hin zu Organisationen mit mehreren hundert Nutzern. Die Erfolgsgeschichten haben eines gemeinsam: Sie haben die Speicherstrategie von Anfang an durchdacht. Ein Beispiel: Ein mittelständisches Ingenieurbüro mit Standorten in Deutschland und Österreich nutzte Nextcloud als zentralen Datenaustausch für CAD-Dateien. Die lokalen Server in München waren überlastet, die Replikation nach Wien war teuer. Sie entschieden sich für einen AWS S3-Bucket in Frankfurt und einen zweiten als Replikat in Irland. Die Nextcloud-Instanz lief auf einer günstigen VPS in Frankfurt. Die Latenz beim Öffnen von Dateien war minimal, und die monatlichen Kosten sanken um 40% – bei gleichzeitig höherer Ausfallsicherheit. Der Clou: Sie nutzten S3 Intelligent-Tiering, um selten genutzte CAD-Versionen automatisch in günstigere Speicherklassen zu verschieben.

Ein anderes Beispiel zeigt die Schattenseiten. Ein Verein mit vielen freiwilligen Administratoren betrieb Nextcloud auf einem günstigen Server bei Hetzner und wollte auf S3 umstellen, um Speicherplatz zu sparen. Sie wählten einen günstigen Anbieter ohne nennenswerten Support. Bei der Migration traten Fehler bei der Berechtigungsvergabe auf – einige Benutzer konnten plötzlich keine Dateien mehr hochladen. Die Fehlersuche zog sich über Wochen, weil die Logs des S3-Anbieters unvollständig waren. Am Ende blieb man bei lokalen Festplatten, ergänzt durch ein NAS. Die Lehre: S3 ist eine solide Lösung, aber sie erfordert ein Mindestmaß an Know-how und eine verlässliche Support-Struktur. Für Bastler und kleine Teams ohne dedizierten IT-Admin kann der Umstieg schnell zum Flaschenhals werden.

Die Zukunft: Wohin entwickelt sich die Kombination?

Nextcloud arbeitet kontinuierlich an der Verbesserung der S3-Integration. Mit Version 28 und 29 kamen Features wie der „S3 Object Store“ als Standard-Backend für Neuinstallationen und eine optimierte Handhabung von großen Dateien. Auch das Monitoring der S3-verbindung wurde verbessert – Admins können jetzt in der Weboberfläche sehen, ob der Bucket erreichbar ist und wie viel Speicherplatz noch zur Verfügung steht. Das sind kleine, aber wichtige Schritte, die die Akzeptanz erhöhen.

Ein Trend, der sich abzeichnet, ist die Nutzung von S3 nicht nur für Dateiinhalte, sondern auch für Metadaten. Einige Nextcloud-Erweiterungen testen bereits, Teile der Datenbank (etwa die Dateikatalog-Informationen) in Objektspeicher auszulagern. Das würde die Skalierbarkeit weiter erhöhen, aber auch die Komplexität. Ich persönlich glaube, dass Nextcloud auf absehbare Zeit eine hybride Architektur beibehalten wird: eine relationale Datenbank für Metadaten und einen Objektspeicher für die rohen Dateien. Das ist bewährt und verhindert, dass man in die Fallstricke einer reinen NoSQL-Lösung gerät.

Auch das Thema Edge Computing wird relevanter. Statt alle Dateien zentral in einem Bucket zu speichern, könnten Nextcloud-Instanzen mit lokalen MinIO-Buckets arbeiten, die regelmäßig mit einem zentralen Speicher synchronisiert werden. Das wäre besonders für verteilte Teams interessant, die auch offline arbeiten müssen. Nextcloud unterstützt bereits lokale Speicher-Caches, aber die Konfiguration ist noch nicht ausgereift. Hier sehe ich in den nächsten Versionen noch Potenzial.

Praktische Tipps für die Entscheidungsfindung

Wer heute vor der Frage steht, ob Nextcloud mit S3 das Richtige ist, sollte sich drei Dinge fragen: Erstens: Wie groß ist das Datenwachstum? Wenn Sie monatlich mit mehr als 500 GB Zuwachs rechnen, lohnt sich die Auslagerung fast immer. Zweitens: Wie kritisch ist die Latenz? Wenn Ihre Benutzer große Dateien häufig öffnen und speichern, brauchen Sie eine schnelle Anbindung – dann ist ein lokaler MinIO-Server oder ein Bucket in derselben Region Pflicht. Drittens: Wie hoch ist das Budget für Speicherverwaltung? Wenn Sie keine Zeit oder kein Personal haben, um einen selbstbetriebenen Objektspeicher zu warten, sind Sie mit einem Managed-Service wie AWS S3 oder Wasabi besser beraten – auch wenn die Kosten höher sind.

Ein letzter Hinweis: Testen Sie vor der Migration unbedingt mit einem Dummy-Bucket. Legen Sie einen separaten Bucket an, konfigurieren Sie Nextcloud darauf und lassen Sie ein paar Power-User eine Woche lang damit arbeiten. Messen Sie die Ladezeiten, prüfen Sie die Upload-Geschwindigkeit und beobachten Sie die Logs. Erst wenn das Ergebnis zufriedenstellend ist, sollten Sie den alten Speicher abschalten. Das klingt banal, aber ich habe schon erlebt, dass Unternehmen direkt in den Produktivbetrieb gegangen sind und dann feststellen mussten, dass ihr gewählter S3-Anbieter beim Bulk-Delete von Versionen regelmäßig Timeouts produziert. Das sind Erfahrungen, die man nicht unbedingt selbst machen muss.

Nextcloud und S3: Das ist keine Modeerscheinung, sondern eine logische Weiterentwicklung des Dateimanagements in einer Welt, die zunehmend verteilt arbeitet. Die Technik ist reif, die Anwendungsfälle vielfältig – aber der Erfolg hängt von der sorgfältigen Planung ab. Wer die Fallstricke kennt und die richtigen Kompromisse eingeht, wird mit einem flexiblen, skalierbaren und kosteneffizienten System belohnt. Wer hingegen einfach nur den Speicher austauscht, ohne die Architektur zu überdenken, wird schnell auf die Nase fallen. So ist das in der IT – und so bleibt es auch.

– Ende des Artikels –

„`