Der wichtigste Unterschied zwischen den drei Arten liegt darin, wie du auf die Daten zugreifst: als rohe Festplatte, über Ordner und Pfade oder über eine Web-API.
Block Storage#
Block Storage stellt Speicher als rohe Festplatte bereit, aufgeteilt in gleich große Blöcke ohne jede Struktur. Erst das Betriebssystem formatiert ihn mit einem Dateisystem wie ext4 oder XFS und verwaltet Ordner und Dateien selbst.
Typische Beispiele:
- lokale SSD oder NVMe im Server
- virtuelle Festplatte einer Proxmox-VM, etwa auf
local-lvmoder einem ZFS-Pool - iSCSI, Ceph RBD, AWS EBS
Stärken: sehr schnell, geringe Latenz, ideal für Datenbanken und Betriebssysteme.
Schwäche: In der Regel kann nur ein Server gleichzeitig darauf schreiben. Hängen zwei Rechner dieselbe Blockfreigabe ohne Cluster-Dateisystem ein, ist das Dateisystem schnell beschädigt.
File Storage#
File Storage liefert den Speicher mit fertigem Dateisystem, also mit Ordnern und Dateien, wie du sie vom eigenen Rechner kennst. Mehrere Clients greifen über das Netzwerk gleichzeitig darauf zu.
Typische Beispiele:
- NFS- und SMB-Freigaben
- dein NAS im Heimnetz
- CephFS
Stärken: vertraute Ordnerstruktur, von vielen Servern gleichzeitig nutzbar, einfach einzurichten.
Schwäche: langsamer als Block Storage und bei sehr vielen Dateien oder großen Datenmengen schwer zu skalieren. Für Datenbanken ist ein Netzwerk-Dateisystem meist keine gute Wahl.
Object Storage#
Object Storage legt Daten als einzelne Objekte in einem flachen Behälter ab, dem Bucket. Jedes Objekt hat eine eindeutige ID und Metadaten. Echte Ordner gibt es nicht, Pfade wie backups/2026/server.tar sind nur Teil des Objektnamens. Der Zugriff läuft über eine HTTP-API, meist kompatibel zu Amazon S3.
Typische Beispiele:
- Amazon S3, Backblaze B2, Hetzner Object Storage
- MinIO oder Garage als selbst gehostete Lösung
- Ceph RGW
Stärken: praktisch unbegrenzt skalierbar, günstig, von überall per HTTPS erreichbar und damit ideal für Backups, Bilder, Videos und Logs.
Schwäche: Objekte werden nur komplett gelesen oder ersetzt, nicht teilweise geändert. Für Datenbanken oder als Systemfestplatte ist Object Storage deshalb ungeeignet.
Die drei Speicherarten im Vergleich#
| Block Storage | File Storage | Object Storage | |
|---|---|---|---|
| Zugriff | als Festplatte | über Ordner und Pfade | über HTTP-API |
| Gleichzeitig nutzbar | ein Server | viele Server | beliebig viele |
| Geschwindigkeit | am schnellsten | mittel | am langsamsten |
| Skalierbarkeit | begrenzt | mittel | nahezu unbegrenzt |
| Typisch für | Datenbanken, VMs | gemeinsame Dateien | Backups, Medien, Archiv |
Storage in Proxmox#
In Proxmox begegnest du allen drei Arten:
- Block:
local-lvm, ZFS-Pools und Ceph RBD speichern die virtuellen Festplatten deiner VMs als Blockgeräte. Das ist die schnellste Variante. - File: Der Speicher
localsowie eingebundene NFS- oder SMB-Freigaben nehmen ISO-Images, Container-Vorlagen und Backups auf. - Object: Proxmox Backup Server kann seine Backups seit Version 4 auch in einem S3-kompatiblen Object Storage ablegen, anfangs noch als Technologievorschau, zum Beispiel als zusätzliche Kopie außer Haus.
Storage in Kubernetes#
In Kubernetes zeigt sich der Unterschied an den Access Modes eines PersistentVolumeClaims:
- ReadWriteOnce (RWO): Nur ein Node darf das Volume schreibend einbinden. Das passt zu Block Storage und ist die richtige Wahl für Datenbanken wie MariaDB oder PostgreSQL.
- ReadWriteMany (RWX): Mehrere Pods auf verschiedenen Nodes schreiben gleichzeitig. Dafür brauchst du File Storage wie NFS oder CephFS, etwa wenn mehrere WordPress-Pods dieselben Uploads teilen sollen.
- Object Storage bindest du gar nicht als Volume ein. Die Anwendung spricht ihn direkt über die S3-API an, zum Beispiel ein Backup-Tool wie Velero oder ein Medien-Plugin in WordPress.
Ein Beispiel für RWO aus der Praxis:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mariadb-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2GihostPath-Volume oder der Speicher local-path von k3s ist technisch ein Ordner auf der lokalen Festplatte des Nodes. Er verhält sich wie RWO, weil er nur auf genau diesem einen Node existiert. Fällt der Node aus, sind die Daten für den Cluster nicht mehr erreichbar.Welchen Storage solltest du wählen?#
- Datenbank oder VM-Festplatte? Block Storage.
- Ordner, auf den mehrere Server oder Pods gleichzeitig zugreifen? File Storage.
- Backups, Archiv, große Mengen an Bildern oder Videos? Object Storage.
In der Praxis kombinierst du meist alle drei: Die Datenbank liegt auf schnellem Block Storage, gemeinsam genutzte Dateien auf einer NFS-Freigabe, und die nächtlichen Backups wandern verschlüsselt in einen S3-Bucket außer Haus.
