OpenCloud und S3
Datenbaukasten
Veröffentlicht in Ausgabe 05/2026 - SCHWERPUNKT
Wachsende Datenmengen gehören in vielen IT-Umgebungen längst zum Alltag. Klassische Fileserver-Architekturen lassen sich zwar durch zusätzliche Volumes oder Server erweitern, ihre grundlegende Architektur bleibt jedoch unverändert. Mit zunehmendem Datenbestand wachsen auch Strukturen, Abhängigkeiten und Speicherebenen – unabhängig davon, wie leistungsfähig die Hardware ist. Storage wird so weniger zur Frage der Kapazität als zur Frage des Aufbaus.
S3-kompatibler Objektspeicher verfolgt einen anderen Ansatz. Er ist bewusst einfach strukturiert, hoch skalierbar und vergleichsweise kostengünstig. Als Dateispeicher eignet er sich jedoch nicht. Dennoch hat sich S3 als Standardbackend für große Datenmengen etabliert. OpenCloud [1] kombiniert beide Ansätze. Mit dem "DecomposedS3 Storage Driver" lagert die Plattform Dateiinhalte in einen S3-Bucket aus, während die Metadaten weiterhin lokal auf einem POSIX-Dateisystem verbleiben. So nutzen Sie die Skalierbarkeit von Objektspeicher, ohne auf die Eigenschaften typischer Fileservices zu verzichten.
Wachstum in dateibasierten Speicherarchitekturen
Fileserver-Architekturen arbeiten zuverlässig, solange Datenmengen überschaubar bleiben. Mit wachsendem Volumen verschiebt sich der Aufwand jedoch in Richtung Backup, Wiederherstellung und Kapazitätsplanung. Der Speicher selbst lässt sich meist problemlos erweitern – die betrieblichen Prozesse darum herum werden komplexer.
Wachsende Datenmengen gehören in vielen IT-Umgebungen längst zum Alltag. Klassische Fileserver-Architekturen lassen sich zwar durch zusätzliche Volumes oder Server erweitern, ihre grundlegende Architektur bleibt jedoch unverändert. Mit zunehmendem Datenbestand wachsen auch Strukturen, Abhängigkeiten und Speicherebenen – unabhängig davon, wie leistungsfähig die Hardware ist. Storage wird so weniger zur Frage der Kapazität als zur Frage des Aufbaus.
S3-kompatibler Objektspeicher verfolgt einen anderen Ansatz. Er ist bewusst einfach strukturiert, hoch skalierbar und vergleichsweise kostengünstig. Als Dateispeicher eignet er sich jedoch nicht. Dennoch hat sich S3 als Standardbackend für große Datenmengen etabliert. OpenCloud [1] kombiniert beide Ansätze. Mit dem "DecomposedS3 Storage Driver" lagert die Plattform Dateiinhalte in einen S3-Bucket aus, während die Metadaten weiterhin lokal auf einem POSIX-Dateisystem verbleiben. So nutzen Sie die Skalierbarkeit von Objektspeicher, ohne auf die Eigenschaften typischer Fileservices zu verzichten.
Wachstum in dateibasierten Speicherarchitekturen
Fileserver-Architekturen arbeiten zuverlässig, solange Datenmengen überschaubar bleiben. Mit wachsendem Volumen verschiebt sich der Aufwand jedoch in Richtung Backup, Wiederherstellung und Kapazitätsplanung. Der Speicher selbst lässt sich meist problemlos erweitern – die betrieblichen Prozesse darum herum werden komplexer.
Längere Backupfenster, größere Snapshots und aufwendigere Restore-Szenarien prägen dann den Alltag. Zusätzliche Volumes oder größere Solid-State-Disks schaffen zwar Kapazität, verändern jedoch nicht die zugrunde liegende Architektur. Sie erweitern den Speicher, nicht aber die Struktur – und genau diese bleibt der begrenzende Faktor.
Hinzu kommt, dass Daten in vielen Umgebungen ungleichmäßig genutzt werden. Metadaten und Verzeichnisstrukturen stehen permanent im Zugriff, große Dateiinhalte dagegen deutlich seltener. Dennoch liegen beide dauerhaft auf performanten Speichersystemen, werden repliziert und gesichert. Der eigentliche Engpass entsteht dadurch weniger bei der Ein- und Ausgabeleistung als in der betrieblichen Handhabung.
Viele IT-Abteilungen reagieren darauf mit einer bewussten Trennung: Arbeitsnahe Daten verbleiben auf klassischen Dateisystemen, umfangreiche Dateiinhalte wandern in skalierbaren Objektspeicher. Diese Aufteilung entkoppelt Speicherwachstum vom operativen Betrieb und schafft die Grundlage für flexiblere Architekturen.
Technische Grundlagen von S3
S3-kompatibler Objektspeicher folgt einem anderen Paradigma als die üblichen Dateisysteme. Statt Dateien in hierarchischen Verzeichnisbäumen abzulegen, speichert er Objekte in einer flachen Struktur und adressiert sie über eindeutige Schlüssel. Eine echte Verzeichnishierarchie existiert nicht. Ordner, wie sie viele Weboberflächen anzeigen, bilden lediglich Namenskonventionen innerhalb dieser Schlüssel ab.
Gerade diese Vereinfachung ermöglicht die hohe Skalierbarkeit. Objektspeicher ist darauf ausgelegt, sehr große Datenmengen verteilt und kostengünstig zu speichern, ohne dass Metadaten-Operationen oder Verzeichnisstrukturen zum Engpass werden. Deshalb lässt sich S3 nahezu unbegrenzt erweitern. Als direktes Dateisystem eignet sich S3 jedoch nicht. POSIX-Semantik, Dateisperren oder schnelle Metadatenzugriffe sind nicht vorgesehen. Der Zugriff erfolgt über eine HTTPS-basierte Programmierschnittstelle statt über ein gemountetes Dateisystem. Das erhöht die Latenz und schließt bestimmte Arbeitslasten aus. Für interaktive Dateisysteme oder Anwendungen mit vielen kleinen Dateioperationen bleibt Objektspeicher daher nur eingeschränkt geeignet.
Trotzdem hat sich S3 als De-facto-Standard für Massenspeicher etabliert. Ursprünglich von Amazon eingeführt, unterstützen heute zahlreiche Anbieter das Protokoll, darunter auch europäische Provider wie Hetzner, IONOS, Exoscale oder Scaleway. Für Administratoren bedeutet das: Die Entscheidung für ein S3-Backend ist weniger eine Produktwahl als eine Architekturentscheidung.
Trennung von Metadaten und Dateiinhalten
OpenCloud nutzt Objektspeicher nicht als Ersatz für ein Dateisystem, sondern als gezielte Ergänzung. Der DecomposedS3 Storage Driver trennt Dateiinhalte bewusst von ihren Metadaten. Große, selten veränderte Nutzdaten speichert die Plattform als Blobs in einem S3-kompatiblen Objektspeicher, während Metadaten weiterhin lokal auf einem POSIX-Dateisystem liegen.
Diese Aufteilung folgt einer einfachen Beobachtung: In dateibasierten Umgebungen dominieren Metadatenoperationen. Verzeichnisstrukturen, Dateinamen, Freigaben und Zeitstempel stehen permanent im Zugriff, die eigentlichen Inhalte deutlich seltener. Indem OpenCloud Metadaten lokal vorhält, bleiben Navigation und Verwaltung schnell und unabhängig vom Speicherort der Blobs.
Durch die Trennung liegen Metadaten und Dateiinhalte in unterschiedlichen Speichersystemen. Architektonisch entsteht damit eine geteilte Speicherung – häufig als "Split-Brain"-Szenario bezeichnet –, die Sie bei Backup- und Restore-Konzepten berücksichtigen müssen. Nur wenn beide Ebenen konsistent gesichert und gemeinsam wiederhergestellt werden, lässt sich ein definierter Systemzustand reproduzieren. Die Architektur bleibt dabei klar strukturiert, erfordert jedoch abgestimmte Datensicherungsprozesse.
Objektadressierung im S3-Backend
Der Begriff "DecomposedS3" verweist auf eine technische Notwendigkeit. S3-kompatibler Objektspeicher kennt keine Dateipfade oder Verzeichnisstrukturen. Objekte werden ausschließlich über eindeutige Schlüssel adressiert. Namen, Ordnerhierarchien oder Pfadlängen existieren im Backend nicht als eigenständige Struktur, sondern nur als Bestandteil dieser Schlüssel.
OpenCloud reagiert darauf, indem es Dateien logisch aufteilt. Die eigentlichen Inhalte speichert das System als Objekte im S3-Bucket, während strukturierende Informationen wie Dateinamen, Verzeichnisse und Zuordnungen im lokalen POSIX-Dateisystem verbleiben. Diese Trennung ist Voraussetzung dafür, Objekt-Storage sinnvoll in eine dateibasierte Plattform einzubinden.
Für IT-Verantwortliche bleibt die Struktur dennoch nachvollziehbar. Metadaten und Verzeichnisbäume liegen weiterhin im Dateisystem und lassen sich mit bekannten Werkzeugen prüfen oder sichern. Der Objektspeicher übernimmt ausschließlich die Rolle des skalierbaren Datencontainers.
Vorbereitung des S3-Buckets
Für den Betrieb von OpenCloud mit einem S3-kompatiblen Objektspeicher sind nur wenige Vorbereitungen erforderlich. Unabhängig vom Anbieter benötigen Sie einen privaten Bucket, den zugehörigen Endpunkt, die Region sowie ein Zugangsdatenpaar aus Access Key und Secret Key. Diese Angaben reichen aus, um den Zugriff auf den Objektspeicher einzurichten.
Ein Programmier-Token für die Verwaltung der Cloudplattform ist nicht erforderlich. OpenCloud greift ausschließlich über die S3-Programmierschnittstelle auf den Bucket zu und verwendet dafür nur die entsprechenden Zugangsdaten.
Der Bucket sollte nicht öffentlich erreichbar sein. OpenCloud erwartet einen privaten Objektspeicher, auf den ausschließlich über die konfigurierten Anmeldedaten zugegriffen wird. Öffentliche Leserechte oder Freigaben sind weder notwendig noch sinnvoll.
S3-Backend einbinden und testen
Wir gehen im Folgenden davon aus, dass OpenCloud bereits läuft und per Docker Compose startet. Für die Nutzung von DecomposedS3 ist keine zusätzliche Software erforderlich. Sämtliche Komponenten für den Zugriff auf den S3-kompatiblen Objektspeicher sind in den Containern enthalten.
Der zentrale Einstiegspunkt ist die ENV-Datei Ihrer OpenCloud-Installation. Dort legen Sie fest, wie OpenCloud den Objektspeicher erreicht. Öffnen Sie die Datei in einem Texteditor und wechseln Sie zum Abschnitt "S3 Storage configuration". Tragen Sie hier die Daten Ihres S3-Buckets ein: Endpunkt des Anbieters, Region, Access Key, Secret Key sowie den Bucket-Namen.
Welche Storage-Variante OpenCloud verwendet, steuern Sie nicht über eine Variable in der ENV-Datei, sondern über die Compose-Konfiguration. Für DecomposedS3 stellt OpenCloud eine zusätzliche Compose-Datei bereit ("storage/decomposeds3.yml"), die Sie zur bestehenden "docker-compose.yml" hinzufügen. Erweitern Sie dazu die Variable "COMPOSE _FILE" am Anfang der ENV-Datei, etwa wie folgt:
COMPOSE_FILE=docker-compose.yml:storage/decomposeds3.yml
Alternativ binden Sie die zusätzliche Datei direkt beim Start ein:
docker compose -f docker-compose.yml -f storage/decomposeds3.yml up
Starten Sie die Container anschließend mit
docker compose up -d im Hintergrund. Ob alle Container korrekt laufen, prüfen Sie wie gewohnt mit docker ps. Die Ausgabe des Befehls beschränkt sich auf den Container-Status. Ob OpenCloud tatsächlich mit dem konfigurierten S3-Bucket arbeitet, erkennen Sie daran noch nicht. Prüfen Sie die Funktion daher im laufenden Betrieb: Melden Sie sich an Ihrer Instanz an und laden Sie eine neue Datei hoch. Wichtig ist, dass es sich um eine neu erstellte Datei handelt, da bestehende Dateien im bisherigen Storage verbleiben.Wechseln Sie anschließend in die Oberfläche Ihres S3-Anbieters und öffnen Sie den konfigurierten Bucket. Wenn DecomposedS3 korrekt arbeitet, erscheinen dort neue Objekte. Diese tragen keine Dateinamen oder Verzeichnisstrukturen, sondern interne Identifikatoren oder Hash-Werte. Genau dieses Verhalten ist erwartungsgemäß.
Im laufenden Betrieb bleibt die geteilte Speicherung für Anwender weitgehend transparent. Navigation, Dateilisten und Freigaben funktionieren wie gewohnt, auch Office-Dokumente oder größere Dateien lassen sich ohne sichtbare Unterschiede bearbeiten und abrufen.
Für Administratoren verschiebt sich jedoch der Schwerpunkt: Das Speicherwachstum findet im Objektspeicher statt, während Metadaten lokal verbleiben. Diese Trennung wirkt sich vor allem auf Datensicherung, Versionierung und Wiederherstellung aus und erfordert ein abgestimmtes Vorgehen über beide Speicherebenen hinweg.
Konsistente Datensicherung über zwei Speicherebenen
Mit DecomposedS3 sichern Sie Metadaten und Dateiinhalte getrennt, stimmen die Verfahren jedoch aufeinander ab. Da OpenCloud beide Ebenen in unterschiedlichen Speichersystemen ablegt, muss auch das Backupkonzept diese Trennung berücksichtigen.
Die Metadaten liegen im POSIX-Dateisystem und lassen sich mit etablierten Verfahren wie Snapshots oder dateibasierten Backups sichern. Sie bilden die Struktur der Plattform und entscheiden darüber, ob sich ein konsistenter Zustand wiederherstellen lässt.
Die eigentlichen Dateiinhalte befinden sich im S3-kompatiblen Objektspeicher. Hier kommen die Funktionen des jeweiligen Anbieters zum Einsatz, etwa Objekt-Versionierung oder Retention-Mechanismen. So können Sie frühere Versionen einzelner Dateien oder definierte Zeitpunkte wiederherstellen, ohne zusätzliche Logik in OpenCloud einzuführen.
Im Wiederherstellungsfall spielen Sie beide Ebenen abgestimmt zurück: zunächst die Metadaten, anschließend die zugehörigen Objekte im S3-Backend. In größeren Umgebungen empfiehlt es sich, diese Abläufe zu dokumentieren und regelmäßig zu testen.
Werkzeuge wie das Community-Tool "s3ctl" [2] unterstützen dabei, den Objektspeicher auf den Zeitpunkt eines Metadaten-Snapshots zurückzusetzen. So lassen sich Metadaten und Dateiinhalte konsistent auf einen definierten Stand bringen (Point-in-Time-Restore). Der Planungsaufwand steigt mit der Größe der Umgebung, das Verfahren bleibt jedoch klar strukturiert.
Server- und clientseitige Verschlüsselung
Beim Einsatz von S3-kompatiblem Objektspeicher spielt Verschlüsselung eine wichtige, aber klar einzugrenzende Rolle. Entscheidend ist die Unterscheidung zwischen dem Schutz gespeicherter Objekte und dem Schutz der Metadaten.
Viele S3-Backends verschlüsseln Daten standardmäßig serverseitig. Diese Serverside Encryption schützt Objekte vor unbefugtem physischem Zugriff auf die Storage-Infrastruktur. Die Verschlüsselung erfolgt transparent im Hintergrund und erfordert keine Anpassungen in OpenCloud.
Je nach Anbieter kommen unterschiedliche Varianten zum Einsatz. Teilweise verwaltet der Provider die Schlüssel selbst, teilweise können kundenseitig bereitgestellte Schlüssel genutzt werden. In beiden Fällen liegt die Schlüsselverwaltung jedoch außerhalb von OpenCloud und damit außerhalb des Einflussbereichs der Plattform.
Wichtig ist jedoch: Die serverseitige Verschlüsselung betrifft ausschließlich die im Objektspeicher abgelegten Dateiinhalte. Metadaten wie Dateinamen, Verzeichnisstrukturen oder Freigaben speichert OpenCloud weiterhin im lokalen POSIX-Dateisystem. Diese Informationen unterliegen damit den dort implementierten Schutzmechanismen.
Wenn Sie einen weitergehenden Schutz benötigen, verschlüsseln Sie Daten bereits vor dem Upload. Werkzeuge wie GnuPG oder verschlüsselte Sicherungstools wie BorgBackup ermöglichen eine clientseitige Verschlüsselung, bevor Daten in OpenCloud oder den Objektspeicher gelangen. In diesem Fall speichert das Backend ausschließlich verschlüsselte Datenblöcke – unabhängig von serverseitigen Mechanismen.
Serverseitige Verschlüsselung schützt also in erster Linie die Infrastruktur. Sie ersetzt keine Ende-zu-Ende-Verschlüsselung. Welche Variante sinnvoll ist, hängt vom jeweiligen Schutzbedarf und den organisatorischen Vorgaben ab.
Geeignete Einsatzbereiche und Grenzen
S3-kompatibler Objektspeicher spielt seine Stärken dort aus, wo Datenmengen wachsen und dateibasierte Speicherarchitekturen im Betrieb zunehmend aufwendig werden. In Kombination mit OpenCloud lässt sich das Datenvolumen skalieren, ohne gewohnte Datei-Workflows für Anwender zu verändern.
Der Ansatz ersetzt jedoch kein klassisches Dateisystem. Direkt gemountete Laufwerke, Network-File-System-ähnliche Nutzung oder stark latenzkritische Anwendungen bleiben Domänen von POSIX- oder Cluster-Dateisystemen. Auch Objektspeicher erfordert bewusste Entscheidungen – insbesondere bei Datensicherung, Wiederherstellung und Verschlüsselung.
Für IT-Verantwortliche ist S3 damit kein universeller Storage-Typ, sondern ein gezielt eingesetztes Werkzeug innerhalb einer Architektur. Richtig angewandt entkoppelt es Speicherwachstum vom operativen Betrieb. Unreflektiert eingeführt entstehen dagegen neue Abhängigkeiten zwischen Metadaten und Objektspeicher.
Fazit
Die Trennung von Metadaten und Dateiinhalten verschiebt große Datenmengen in eine eigenständige Speicherebene, ohne gewohnte Dateistrukturen aufzugeben. OpenCloud nutzt S3-kompatiblen Objektspeicher damit nicht als Ersatz, sondern als Ergänzung klassischer dateibasierter Architekturen. Der Ansatz reduziert strukturelle Abhängigkeiten beim Wachstum, verlangt jedoch eine abgestimmte Datensicherung und klare Konzepte für Wiederherstellung und Verschlüsselung. Entscheidend ist weniger die Wahl eines bestimmten Anbieters als die bewusste Architekturentscheidung: Wer Speicherwachstum vom operativen Betrieb entkoppeln möchte, erhält mit der geteilten Speicherung ein technisch konsistentes, aber nicht universell einsetzbares Modell.
(ln)