Object Storage bei WebDisk: Bucket, Objekt, Schlüssel – und was Sie in der Praxis davon haben
WebDisk Blog · Kategorie: Cloud-Computing · Lesezeit: ~9 Minuten
Kurz gefasst:- Object Storage speichert Daten als Objekte in Buckets – nicht als Festplattenblöcke und nicht als Verzeichnisbaum. Jedes Objekt hat seinen eigenen Schlüssel, und man kommuniziert mit ihm über HTTP, wie mit einer Website.- Es bewährt sich dort, wo eine Datei einmal geschrieben und viele Male gelesen wird: Backups, Archive, Medien, statische Dateien, gemeinsamer Speicher für Anwendungen. Eine Festplatte für eine Datenbank ersetzt es nicht.- S3 ist heute der De-facto-Standard für die Kommunikation mit einem solchen Speicher – dieselben Tools (aws,s3cmd,rclone) und dieselben Bibliotheken funktionieren bei uns wie bei anderen Anbietern. >Sie arbeiten nicht mit dem Terminal? Die Befehlsblöcke können Sie getrost überspringen – der Rest des Artikels lässt sich auch ohne sie lesen.
Das Netzlaufwerk der Firma füllt sich schneller, als irgendjemand geplant hatte. Überwachungskameras produzieren Aufnahmen, die niemand ansieht, die aber nicht gelöscht werden dürfen. Eine Anwendung läuft in drei Instanzen, und jede muss dieselben Dateien sehen.
Alle diese Probleme haben einen gemeinsamen Nenner: Daten, von denen es viele gibt, die unvorhersehbar wachsen und die von mehreren Orten gleichzeitig zugänglich sein müssen. Eine klassische Festplatte im Server kommt damit mit jedem zusätzlichen Terabyte schlechter zurecht. Object Storage wurde geschaffen, damit dieses Szenario kein Problem mehr ist.
In diesem Artikel erklären wir, worin sich Objektspeicher von einer Festplatte und einer Netzwerkfreigabe unterscheidet, wie die drei Begriffe zu verstehen sind, um die sich alles dreht (Bucket, Objekt, Schlüssel), wofür sich S3 wirklich eignet – und wofür nicht – und wie Sie in der Praxis damit anfangen. Am Ende beschreiben wir, was wir davon bei WebDisk anbieten.
Worin unterscheiden sich Block-, Datei- und Objektspeicher?
Blockspeicher ist die unterste Ebene: Eine Festplatte (physisch oder als Netzwerk-Volume) stellt dem Betriebssystem rohe Blöcke zur Verfügung, und erst das Dateisystem gibt ihnen einen Sinn. Vorteil: geringste Latenzen und volle Freiheit bei Änderungen – man kann beliebige 512 Bytes mitten in einer Datei überschreiben. Nachteil: Das Volume ist in der Regel einer einzigen Maschine zugeordnet.
Dateispeicher ist eine Netzwerkfreigabe (NFS, SMB): Verzeichnishierarchie, Berechtigungen, Dateisperren, viele Clients gleichzeitig. Probleme entstehen bei großer Skalierung – ein Baum mit Dutzenden Millionen Dateien wird teuer in der Verwaltung, und der Dateiserver wird schnell zum Flaschenhals.
Objektspeicher verzichtet auf Hierarchie und auf Änderungen an Ort und Stelle. Eine Datei gelangt in den Speicher als Objekt: Inhalt plus Metadaten plus ein eindeutiger Schlüssel. Sie möchten sie ändern? Dann schreiben Sie das Objekt neu, als Ganzes. Im Gegenzug bekommen Sie drei Dinge, die die beiden vorherigen Modelle nicht so leicht bieten: praktisch lineare Skalierbarkeit, Zugriff über gewöhnliches HTTP von jedem Ort aus und eingebaute Redundanz auf Seiten des Clusters.
- Einheit – Blockspeicher: Block · Dateispeicher: Datei im Verzeichnis · Objektspeicher: Objekt im Bucket
- Zugriff – Blockspeicher: Festplattentreiber · Dateispeicher: Netzwerkprotokoll (NFS/SMB) · Objektspeicher: HTTP (S3-API)
- Änderung eines Teilbereichs – Blockspeicher: ja · Dateispeicher: ja · Objektspeicher: nein – das gesamte Objekt wird neu geschrieben
- Typischer Client – Blockspeicher: eine Maschine · Dateispeicher: viele Maschinen im LAN · Objektspeicher: beliebige Anwendung im Internet
- Natürlicher Einsatzbereich – Blockspeicher: Datenbank, Betriebssystem · Dateispeicher: gemeinsame Dokumente, Home-Verzeichnisse · Objektspeicher: Backup, Medien, Archive, Anwendungsdaten
Das sind keine Konkurrenten, sondern drei Schichten desselben Werkzeugkastens.
Was sind Bucket, Objekt und Schlüssel in S3?
Bucket (wörtlich „Eimer“) ist ein Container für Objekte – das Gegenstück zu einer Festplatte oder einer Netzwerkfreigabe. Der Name eines Buckets muss innerhalb der Plattform eindeutig sein, denn er wird Teil der Adresse. Auf Bucket-Ebene wird das meiste eingestellt, was von Bedeutung ist: wer Zugriff hat, ob die Daten verschlüsselt werden, wie lange sie leben.
Objekt ist eine einzelne gespeicherte Einheit: der Inhalt der Datei, ihre Metadaten (MIME-Typ, Datum, eigene Header) und eine Versions-ID, falls für den Bucket die Versionierung aktiviert ist.
Schlüssel (Key) ist der vollständige Name eines Objekts im Bucket – und hier verbirgt sich das häufigste Missverständnis. Der Namensraum in S3 ist flach: Es gibt keine Verzeichnisse, sondern nur eine lange Zeichenkette. Der Schlüssel 2026/07/faktury/FV-118.pdf bezeichnet keine drei verschachtelten Ordner, sondern einen einzigen Namen, der Schrägstriche enthält. Die Tools zeichnen daraus zu Ihrer Bequemlichkeit einen Baum und fragen den Server dazu nach allen Objekten mit dem jeweiligen Präfix.
Die Konsequenz ist praktischer Natur: Das „Verschieben eines Verzeichnisses“ bedeutet in S3 in Wirklichkeit, jedes Objekt einzeln zu kopieren und zu löschen. Das sollte man bei der Planung der Schlüsselstruktur im Hinterkopf behalten – ein gut entworfenes Präfix (Datum, Kunde, Datentyp) erleichtert später sowohl die Suche als auch Zugriffsrichtlinien und Aufräumregeln.
Wofür eignet sich Object Storage – und wofür nicht?
Backup und Archiv. Das ist heute das Standardziel für Sicherungskopien – alle nennenswerten Backup-Systeme können direkt nach S3 schreiben. Die Kopie liegt außerhalb des Servers, den sie absichert, ist über das Netzwerk erreichbar und erfordert keine Bandbibliothek. Ausführlicher schreiben wir darüber im Artikel Backup in der Cloud – das Fundament der IT-Sicherheit.
Medien und statische Dateien. Fotos, Videos, PDFs, Anhänge. Die Anwendung muss sie nicht durch sich hindurchleiten – sie kann den Nutzer direkt zum Speicher schicken und nimmt damit den eigenen Servern den gesamten Download-Verkehr ab.
Statische Website oder Dokumentation. Ein Bucket mit öffentlichem Lesezugriff liefert HTML, CSS und Bilder ohne jeden Applikationsserver aus. Eine günstige, robuste und praktisch wartungsfreie Lösung. Eine Einschränkung: Vollwertiges Website-Hosting – mit Indexdokument, Fehlerseite und eigener Domain – erfordert den Website-Modus auf Anbieterseite; der öffentliche Lesezugriff allein genügt, um Dateien auszuliefern, zum Beispiel Bilder und Downloads.
Gemeinsamer Speicher für Anwendungen. Das ist das Szenario, in dem Object Storage wirklich glänzt. Mehrere Instanzen derselben Anwendung – auf virtuellen Maschinen oder in Kubernetes-Pods – sehen denselben Bucket und dieselben Dateien, ohne gemeinsames Volume und ohne die Frage, auf welchem Knoten der Upload gelandet ist. Ein Gerät oder Prozess lädt Daten hoch, ein anderer holt sie ab und verarbeitet sie.
Was Object Storage nicht ersetzt: die Festplatte für eine Datenbank, das Dateisystem für eine Anwendung, die Dateien an Ort und Stelle ändert, und keinen Speicher, der Latenzen im Mikrosekundenbereich verlangt. Jede Operation ist ein HTTP-Request – Parallelität und große Objekte verkraftet das System hervorragend, aber ein einzelner Schreibvorgang wird nie so schnell sein wie auf einer lokalen NVMe. Es ergibt auch keinen Sinn, Millionen winziger Dateien planlos nach S3 zu kippen: Der Overhead pro Request kann dann die Kosten der eigentlichen Daten übersteigen.
Der erste Bucket: drei Tools, dieselbe Geschichte
Für die Arbeit mit S3 brauchen Sie drei Dinge: die Endpoint-Adresse des Anbieters, einen Zugriffsschlüssel (Access Key) und ein Secret (Secret Key). Die folgenden Beispiele verwenden unseren öffentlichen Endpoint https://s3.dco.webdisk.io – bei einem anderen Anbieter tauschen Sie einfach die Adresse aus, und alles funktioniert genauso. Das ist übrigens einer der Hauptvorteile des S3-Standards: Ein Anbieterwechsel bedeutet nicht, die Integrationen neu zu schreiben – mehr dazu in unserem Artikel über die Anbieterabhängigkeit.
Eine Sache, die man gleich wissen sollte: Die Adresse eines Buckets lässt sich auf zwei Arten bilden – pfadbasiert (endpoint/bucket) oder über den Hostnamen (bucket.endpoint). Die Standardeinstellungen der Clients unterscheiden sich, deshalb geben wir in den Beispielen unten die pfadbasierte Adressierung explizit an.
s3cmd – der einfachste Einstieg, praktisch für manuelle Operationen:
s3cmd --configure # access key, secret key, host: s3.dco.webdisk.io # host_bucket: s3.dco.webdisk.io/%(bucket)ss3cmd mb s3://firma-archiwum # Bucket anlegens3cmd put raport.pdf s3://firma-archiwum/2026/ # Datei hochladens3cmd ls s3://firma-archiwum/2026/ # Präfix auflistens3cmd get s3://firma-archiwum/2026/raport.pdf # herunterladens3cmd du s3://firma-archiwum # belegter Speicherplatz
aws CLI – der offizielle AWS-Client, funktioniert mit jedem S3-kompatiblen Speicher:
aws configure # access key, secret key, region: z. B. us-east-1aws configure set default.s3.addressing_style path # pfadbasierte Adressierung# den Endpoint geben Sie beim Befehl an…aws --endpoint-url https://s3.dco.webdisk.io s3 ls# …oder einmalig per Umgebungsvariable (aws CLI v2 ab Version 2.13)export AWS_ENDPOINT_URL=https://s3.dco.webdisk.ioaws s3 mb s3://firma-archiwumaws s3 cp ./raporty s3://firma-archiwum/2026/ --recursiveaws s3api head-object --bucket firma-archiwum --key 2026/raport.pdf
rclone – am besten für die Synchronisierung von Verzeichnissen und das Verschieben von Daten zwischen Anbietern:
rclone config # Typ: s3, Provider: Ceph, Endpoint wie oben # das Ceph-Profil stellt pfadbasierte Adressierung selbst ein# inkrementell kopieren: übertragen wird nur, was sich geändert hatrclone copy /srv/dane webdisk:firma-archiwum/dane --progress# Achtung: sync LÖSCHT im Ziel Dateien, die es in der Quelle nicht gibtrclone sync /srv/dane webdisk:firma-archiwum/dane --dry-run
Eine Regel, die Nerven spart: rclone sync führen Sie zuerst mit --dry-run aus – und erst nach Durchsicht der Änderungsliste ohne diesen Schalter.
Wie Sie den Zugriff auf einen Bucket kontrollieren: Policies und Presigned URLs
Standardmäßig ist ein Bucket privat – nur der Inhaber der Schlüssel sieht ihn. Zugriff wird bewusst geöffnet, auf zwei Arten.
Eine Bucket-Policy ist ein JSON-Dokument, das beschreibt, wem wir was erlauben. Ein klassisches Beispiel – ein Bucket, der statische Dateien ausliefert, mit öffentlichem Lesezugriff auf Objekte und privatem Schreibzugriff:
{ "Version": "2012-10-17", "Statement": [{ "Sid": "PublicRead", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::moja-strona/*" }]}
aws s3api put-bucket-policy --bucket moja-strona --policy file://polityka.json
Achten Sie auf Resource mit dem Sternchen: Die Policy bezieht sich auf die Objekte im Bucket, nicht auf den Bucket selbst. Der Tausch von arn:aws:s3:::moja-strona/* gegen arn:aws:s3:::moja-strona ist der häufigste Anfängerfehler – plötzlich funktioniert nichts mehr oder, schlimmer, es funktioniert zu viel.
Eine Presigned URL löst ein anderes Problem: „Ich möchte einer Person eine Datei geben, für eine Stunde, ohne ihr ein Konto anzulegen.“ Das ist ein gewöhnlicher Link zum Objekt mit angehängter Signatur und Ablaufdatum. Wer den Link hat, kann die Datei herunterladen; nach Ablauf der Zeit wird der Link unbrauchbar, und der Bucket selbst bleibt privat:
# Link eine Stunde gültig (3600 Sekunden)aws s3 presign s3://firma-archiwum/2026/raport.pdf --expires-in 3600
Presigned URLs funktionieren auch in die andere Richtung – die Anwendung kann einen Link erzeugen, der zum Hochladen einer Datei berechtigt – so schickt der Browser des Nutzers die Datei direkt in den Speicher, am Applikationsserver vorbei. Man sollte nur daran denken, dass ein solcher Link ein Geheimnis ist: Wer ihn abfängt, hat für die gesamte Gültigkeitsdauer Zugriff auf das Objekt. Deshalb setzt man die Fristen kurz an und verschickt die Links nicht über Kanäle, die man nicht kontrolliert.
Der dritte Mechanismus – temporäre Anmeldedaten (STS) – ersetzt dauerhafte Schlüssel durch einen eine Stunde gültigen Passierschein, der auf Basis der Firmenanmeldung ausgestellt wird. Wir haben ihn ausführlich beschrieben im Artikel über den Zugriff auf S3 mit dem Firmenkonto (STS + SSO). Einen eigenen Text haben wir auch den Varianten der Verschlüsselung ruhender Daten (SSE-S3, SSE-KMS, SSE-C) gewidmet – über sie sollte man bei jeder Einführung sprechen.
Was bietet Object Storage – und was nicht?
Object Storage bietet: Skalierung ohne Kapazitätsplanung im Voraus, Zugriff über HTTP von jedem Ort aus, einen Standard, den Sie zwischen Anbietern mitnehmen, Abrechnung nach gebuchtem Speicherplatz, der sich ohne Datenmigration erweitern lässt, und einen natürlichen Ort für Daten, die Sie nicht auf dem Produktionsserver halten möchten.
Object Storage bietet nicht: die Semantik eines Dateisystems (keine Änderungen an Ort und Stelle, keine Sperren, keine echten Verzeichnisse), Latenzen auf dem Niveau einer lokalen Festplatte, automatischen Schutz vor dem Löschen – wenn Sie einen Nutzerfehler oder Ransomware überstehen wollen, brauchen Sie Versionierung und Objektunveränderlichkeit (Object Lock), und beides muss bewusst aktiviert werden. Auch die Verschlüsselung ruhender Daten allein schützt nicht vor dem Abfluss von Zugriffsschlüsseln: Wer gültige Anmeldedaten hat, bekommt die Daten entschlüsselt. Sicherheit ist immer die Summe mehrerer Schichten, nicht ein einzelner Schalter.
Wie das bei WebDisk aussieht
Unsere Objektspeicher-Plattform läuft auf Ceph und seinem S3-Gateway (RADOS Gateway) – offener Software, die von vielen Cloud-Anbietern eingesetzt wird. Das ist kein Marketing-Detail: Es bedeutet, dass Sie mit uns über dieselbe API sprechen wie mit AWS, und mit denselben Clients – s3cmd, awscli, boto3, rclone, Plugins in Backup-Systemen.
Der öffentliche Endpoint ist https://s3.dco.webdisk.io. Der Speicher ist auf die Kosten der Aufbewahrung großer Datenbestände abgestimmt – Archive, Sicherungskopien und Medien. Ein Bucket lässt sich serverseitig verschlüsseln (Option beim Anlegen, permanent). Versionierung und Objektunveränderlichkeit (Object Lock) sind verfügbar – die Unveränderlichkeit wird beim Anlegen des Speichers aktiviert und ist eine Einbahn-Entscheidung. Die Anmeldung bei S3 mit dem Firmenkonto (STS) bereiten wir als eigenen Dienst vor – den Mechanismus selbst haben wir im oben verlinkten Artikel beschrieben. Der Speicher wird im Panel bestellt, zusätzlicher Speicherplatz nach Bedarf hinzugebucht. Den aktuellen Funktionsumfang und die Preisliste finden Sie auf der Seite des Dienstes Object Storage – und falls Sie sich fragen, wo Ihre Daten physisch liegen: Darüber schreiben wir in unserem Text über die polnische Cloud.
Häufige Fragen
Muss ich Programmierer sein, um S3 zu nutzen?
Nein. Für die manuelle Arbeit genügen grafische Clients (z. B. Cyberduck, WinSCP, S3 Browser) oder rclone im Verzeichnis-Synchronisierungsmodus. Das Terminal ist bequem, aber nicht Pflicht.
Worin unterscheidet sich ein Bucket von einem Netzlaufwerk?
Vor allem durch das fehlende Dateisystem. Einem Bucket können Sie keinen Laufwerksbuchstaben zuweisen und keine Datei darin direkt zur Bearbeitung öffnen – Objekte werden als Ganzes heruntergeladen und wieder hochgeladen. Dafür ist der Bucket von jedem Ort im Internet aus erreichbar, und die Kapazität erhöhen Sie durch das Hinzubuchen weiterer Pakete – ohne Datenumzug und ohne Ausfallzeit.
Gibt es in S3 Verzeichnisse und Ordner?
Nein – der Namensraum in einem Bucket ist flach. Schrägstriche im Objektschlüssel (z. B. 2026/07/raport.pdf) sind Teil des Namens und keine verschachtelten Ordner; die Tools zeichnen zu Ihrer Bequemlichkeit einen Verzeichnisbaum aus den Präfixen. Deshalb bedeutet das „Verschieben eines Verzeichnisses“ in der Praxis, jedes Objekt einzeln zu kopieren und zu löschen.
Sind die Daten in einem Bucket sicher, wenn jemand eine Datei löscht?
Nur dann, wenn Sie Versionierung oder die Unveränderlichkeitssperre aktivieren. Standardmäßig ist ein gelöschtes Objekt weg. Es gilt dasselbe Prinzip wie bei jedem anderen Speicher: Backup und Aufbewahrung sind eine eigene Entscheidung, keine eingebaute Eigenschaft.
Wie ziehe ich einige Terabyte von einem anderen Anbieter um?
Am einfachsten mit rclone und der Konfiguration zweier Remote-Speicher – es kopiert direkt zwischen ihnen und setzt einen unterbrochenen Transfer fort. Bei großen Datenbeständen lohnt es sich, die Parallelität zu erhöhen (--transfers) und die Daten präfixweise zu übertragen.
Eignet sich S3 für Daten, auf die ich einmal im Jahr zugreife?
Ja – und das ist eines der besten Szenarien. Ein Archiv im Objektspeicher kostet wenig, und die Daten bleiben sofort verfügbar, ohne Wiederherstellung vom Band.
Fazit
Object Storage ist keine „bessere Festplatte“ – es ist ein anderes Werkzeug, entworfen für ein anderes Nutzungsmuster: einmal schreiben, viele Male lesen, von vielen Orten aus, in einem Maßstab, den Sie nicht im Voraus planen möchten. Passt dieses Muster zu Ihren Daten, vereinfacht S3 die Architektur mehr als jeder zusätzliche Dateiserver. Passt es nicht – dann ist es besser, das zu wissen, bevor die Anwendung anfängt, gegen den Speicher zu kämpfen.
Sie haben einen konkreten Fall und wissen nicht, ob S3 die richtige Wahl ist – oder möchten es einfach ausprobieren? Schreiben Sie uns: Wir gehen ihn gemeinsam durch, helfen bei der Wahl der Konfiguration und richten Ihnen den Zugang zu einem Bucket ein.