Einleitung
Drei Speicherparadigmen, ein Entscheid: Wer in der IT-Infrastruktur mit Storage zu tun hat, begegnet früher oder später den Begriffen File Storage, Block Storage und Object Storage. Die Unterschiede sind erheblich, und wer den falschen Typ wählt, zahlt entweder zu viel, kämpft mit Skalierungsproblemen oder bekommt schlicht die falsche Performance für seinen Workload.
Doch in der Schweiz und der EU ist die Storage-Entscheidung längst nicht mehr nur eine technische. Sie ist auch eine rechtliche und Compliance-Entscheidung. Wo Daten physisch liegen, welchem Rechtssystem der Anbieter untersteht und wer im Ernstfall Zugriff verlangen kann: Diese Fragen bestimmen zunehmend, welcher Storage-Typ und welcher Anbieter in Frage kommt.
Dieser Artikel erklärt, wie die drei Paradigmen technisch funktionieren, wo ihre Stärken und Schwächen liegen, und welcher Typ für welchen Use Case der richtige ist. Wer am Ende des Artikels weiss, dass Object Storage die richtige Wahl für sein Backup ist, findet ausserdem einen Hinweis auf einen Schweizer Anbieter mit Datenstandort in der Schweiz.
File Storage: Das bekannte Paradigma
Wie es funktioniert
File Storage ist das, womit fast jeder täglich arbeitet: Daten werden in einer
hierarchischen Verzeichnisstruktur organisiert, Ordner, Unterordner, Dateien. Der Zugriff erfolgt über den vollständigen Dateipfad. Das System ist unmittelbar verständlich, weil es dem mentalen Modell des Dateisystems auf dem Desktop entspricht.
Im Netzwerkkontext spricht man von
NAS (Network Attached Storage). Die typischen Protokolle sind:
-
NFS (Network File System) für Linux/Unix-Umgebungen
-
SMB/CIFS (Server Message Block) für Windows-Umgebungen
Stärken
- Einfache Navigation und Verwaltung über vertraute Verzeichnisstrukturen
- Mehrere Benutzer können gleichzeitig auf dasselbe Dateisystem zugreifen
- Breite Kompatibilität, fast jedes Betriebssystem unterstützt NFS oder SMB
Schwächen
- Skalierungsgrenzen: Bei steigendem Datenvolumen wird das Verwaltungssystem komplex. Scale-out erfordert zusätzliche Geräte und sorgfältige Planung.
- Performance unter Last: Bei sehr vielen Dateien können Metadaten-Operationen zum Engpass werden.
- Kosten: Kapazitätserweiterungen bedeuten neue Hardware, das macht File Storage bei grossen Datenmengen vergleichsweise teuer.
Typische Use Cases
- Team-Fileserver und Home-Verzeichnisse
- Dokumentenmanagement
- Kollaborative Umgebungen mit gleichzeitigem Mehrfachzugriff
- Kleinere bis mittlere Datenmengen im KMU-Umfeld
Block Storage: Das Hochleistungsparadigma
Wie es funktioniert
Block Storage zerlegt Daten in
gleichmässig grosse Blöcke (typisch einige Kilobyte bis mehrere Megabyte). Jeder Block erhält eine eindeutige logische Adresse (LBA, Logical Block Address). Das System kennt kein Dateisystem, dieses wird vom Betriebssystem auf den Blöcken aufgesetzt. Deshalb lässt sich Block Storage genauso wie eine lokale Festplatte nutzen, auch wenn die Daten physisch auf einem entfernten System liegen.
Im Netzwerkkontext spricht man von
SAN (Storage Area Network). Die wichtigsten Protokolle:
-
iSCSI: Block Storage über Standard-IP-Netzwerke
-
Fibre Channel (FC): dedizierte, hochperformante SAN-Netzwerke
-
NVMe over Fabrics (NVMe-oF): für ultra-low-latency Szenarien
Stärken
- Sehr geringe Latenz: Klassische All-Flash-Arrays erreichen 0,5 bis 1,5 ms, moderne Systeme teils unter 150 Mikrosekunden.
- Flexibilität: Das Betriebssystem verwaltet das Dateisystem nach eigenen Regeln, NTFS, ext4, XFS, etc.
- Ideal für transaktionale Workloads: Datenbanken und VM-Disks profitieren direkt.
Schwächen
- Kosten: Block Storage ist das teuerste Paradigma pro Gigabyte. SAN-Infrastruktur (Controller, Switches, HBAs) ist aufwendig und teuer.
- Minimale Metadaten: Block Storage speichert kaum Kontextinformationen zu den Daten.
- Skalierungsgrenzen: Kapazitätserweiterungen sind komplex und kostenintensiv.
Typische Use Cases
- Relationale Datenbanken (Oracle, SQL Server, PostgreSQL)
- VM-Disks (VMware vSphere, Hyper-V)
- Boot-Volumes für physische und virtuelle Server
- Echtzeitanalytics und Hochfrequenz-Transaktionssysteme
Object Storage: Das Cloud-Paradigma
Wie es funktioniert
Object Storage bricht mit der Verzeichnishierarchie. Daten werden als
diskrete Objekte in einem
flachen Namespace (keine Ordnerstruktur) abgelegt. Jedes Objekt besteht aus drei Teilen:
-
Nutzdaten: der eigentliche Inhalt (eine Datei, ein Backup-Chunk, ein Bild)
-
Metadaten: frei definierbar, beliebig viele Key-Value-Paare
-
Eindeutige ID / Key: zur Adressierung des Objekts
Der Zugriff erfolgt nicht über Dateipfade, sondern über
REST-APIs über HTTP. Die S3-API (ursprünglich von Amazon entwickelt) ist heute der De-facto-Standard und wird von praktisch jedem Object-Storage-Anbieter unterstützt.
Ein entscheidendes Merkmal:
Objekte können nicht partiell modifiziert werden. Eine Änderung bedeutet immer das Ersetzen des gesamten Objekts. Das klingt wie eine Einschränkung, ist für Backup und Archivierung aber ein Vorteil, denn es ermöglicht Immutability (Unveränderlichkeit) via
S3 Object Lock.
Stärken
- Nahezu unbegrenzte Skalierbarkeit: Object Storage skaliert horizontal über Commodity Hardware. Amazon S3 verarbeitet laut eigenen Angaben 100 Millionen Requests pro Sekunde.
- Kosteneffizient: Günstiges Pay-as-you-go-Modell, keine teure SAN-Infrastruktur.
- Umfangreiche Metadaten: Jedes Objekt kann beliebige Kontextinformationen tragen, ideal für Suche, Klassifizierung und Lifecycle-Policies.
- Immutability: S3 Object Lock schützt Backups vor Überschreiben und Löschen, auch gegen Ransomware.
Schwächen
- Höhere Latenz: HTTP-Overhead macht Object Storage ungeeignet für Workloads, die wenige Millisekunden oder weniger erfordern.
- Keine partielle Schreibbarkeit: Datenbankzugriffe, die einzelne Records aktualisieren, sind nicht möglich.
- API-Kenntnisse nötig: Zugriff erfordert S3-API-kompatible Clients oder SDKs, kein direktes Mounten als Dateisystem (ohne zusätzliche Layer).
Warum S3 zum Standard wurde
Die S3-API hat sich nicht nur bei Amazon durchgesetzt, sie ist heute der universelle Standard für Object Storage. VMware, Veeam, Acronis, Synology, QNAP und Hunderte weitere Systeme sprechen nativ S3. Das bedeutet: Wer einen S3-kompatiblen Storage-Endpunkt bereitstellt, kann sich in fast jede Backup- und Archivlösung integrieren.
Typische Use Cases
- Backup und Archivierung (insbesondere mit Object Lock / Immutable Backup)
- Media Assets: Bilder, Videos, Audio
- Log-Daten und IoT-Daten
- AI/ML-Trainingsdaten (Petabyte-Mengen)
- Statische Web-Assets und CDN-Ursprungsserver
- Data Lakes für Analytics
Direkter Vergleich: Alle drei auf einen Blick
| Merkmal |
File Storage |
Block Storage |
Object Storage |
| Datenorganisation |
Hierarchisch (Ordner/Dateien) |
Blöcke (flach, adressiert) |
Flacher Namespace (Objekte) |
| Protokoll |
NFS, SMB/CIFS |
iSCSI, Fibre Channel, NVMe-oF |
S3/REST (HTTP) |
| Latenz |
Mittel (einige ms) |
Sehr gering (0,5 bis 1,5 ms) |
Hoch (HTTP-Overhead) |
| Skalierbarkeit |
Begrenzt |
Begrenzt |
Nahezu unbegrenzt |
| Kosten/GB |
Mittel |
Hoch |
Gering |
| Metadaten |
Basis (POSIX) |
Minimal |
Umfangreich / frei definierbar |
| Mutabilität |
Hoch (CRUD) |
Hoch (CRUD) |
Niedrig (Replace only) |
| Immutability |
Begrenzt (ACLs) |
Nein |
Ja (Object Lock / WORM) |
| Typischer Einsatz |
NAS, Teamshares |
Datenbanken, VM-Disks |
Backup, Archiv, Cloud-native |
| Cloud-nativ |
Eingeschränkt |
Eingeschränkt |
Ja |
Typische Fehler und Missverständnisse
1. NAS für Backups verwenden, weil es "einfach" ist
NAS-Backups funktionieren, aber sie skalieren schlecht und bieten keine nativen Immutability-Mechanismen. Bei grossen Datenmengen wird File Storage teuer. Object Storage mit S3 Object Lock ist für Backup-Szenarien die überlegene Wahl.
2. Object Storage für Datenbanken einsetzen
Die höhere Latenz von Object Storage macht es ungeeignet für transaktionale Workloads. Wer PostgreSQL oder Oracle auf S3-basiertem Storage betreiben will, erhält ungenügende Performance. Datenbanken gehören auf Block Storage.
3. Block Storage für Archivdaten verwenden
Block Storage ist das teuerste Paradigma. Historische Daten, die selten abgerufen werden, gehören in Object Storage. Die Kostendifferenz kann je nach Datenvolumen erheblich sein.
4. Annehmen, Object Storage sei schwer integrierbar
Die S3-API ist heute der universelle Standard. Veeam, Synology, QNAP, Restic, Duplicati, Rclone: praktisch jede relevante Backup-Lösung spricht nativ S3. Integration ist in den meisten Fällen eine Frage von Minuten, nicht Tagen.
Empfehlung: Was für welchen Use Case?
Datenbanken, VM-Disks, Boot-Volumes: Block Storage
Wenn Latenz unter einer Millisekunde und direkte Block-Adressierung gefragt sind, ist Block Storage die einzige sinnvolle Wahl. Kein anderes Paradigma bietet vergleichbare I/O-Performance.
Teamshares, Home-Verzeichnisse, kollaborative Umgebungen: File Storage
Wenn mehrere Benutzer gleichzeitig Dateien lesen und schreiben, braucht man ein Dateisystem mit NFS oder SMB. File Storage (NAS) ist hierfür optimiert.
Backup, Archiv, Mediendaten, Logs, Data Lakes: Object Storage
Für alle Workloads, bei denen grosse Datenmengen kosteneffizient und skalierbar gespeichert werden müssen, ist Object Storage die richtige Wahl. Besonders für Backup gilt: S3 Object Lock schützt Daten vor unbeabsichtigtem oder böswilligem Löschen, ein zentrales Argument in einer Zeit, in der Ransomware-Angriffe auf Backup-Systeme zunehmen.
Für Schweizer Unternehmen und EU-regulierte Organisationen gilt ausserdem: Schweizer S3-Object-Storage ist nicht nur technisch, sondern auch rechtlich die sicherere Wahl gegenüber US-Hyperscalern. Warum das so ist, erklärt der folgende Abschnitt.
Schweizer Kontext: Datensouveränität und Compliance
Die Storage-Wahl hat in der Schweiz und der EU eine regulatorische Dimension, die viele Unternehmen unterschätzen. Drei Rechtsrahmen sind entscheidend.
revDSG (in Kraft seit 1. September 2023)
Das revidierte Schweizer Datenschutzgesetz enthält keine explizite Pflicht, Daten physisch in der Schweiz zu speichern. Die Rechenschaftspflicht (Art. 8 DSG) und die Meldepflicht bei Datenschutzverletzungen stellen aber hohe Anforderungen: Unternehmen müssen jederzeit nachweisen können, wo ihre Daten sind und wer darauf Zugriff hat. Wer das nicht belegen kann, riskiert Bussen bis CHF 250'000 bei vorsätzlichen Verletzungen. Die Wahl eines Anbieters, dessen Rechtssystem intransparent oder ausländischen Behörden zugänglich ist, erhöht dieses Risiko erheblich.
DSGVO Art. 44 ff.
Für alle Unternehmen, die Personendaten von EU-Bürgerinnen und -Bürgern bearbeiten, gilt: Datenübermittlungen in Drittländer sind nur zulässig, wenn das Zielland ein angemessenes Schutzniveau bietet (z.B. die Schweiz, UK) oder geeignete Garantien vorliegen (Standardvertragsklauseln, Binding Corporate Rules). Ohne eine solche Grundlage ist der Transfer in ein Drittland, also z.B. in die USA, unzulässig.
CLOUD Act (USA, 2018): Das unterschätzte Risiko
Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) erlaubt US-Behörden, von US-Cloud-Anbietern wie Microsoft Azure, Google Cloud oder AWS die Herausgabe von Daten zu verlangen, unabhängig davon, ob diese Daten physisch in der Schweiz oder der EU gespeichert sind. Entscheidend ist nicht der Serverstandort, sondern der rechtliche Kontrollbegriff: "possession, custody or control" des US-Unternehmens. Ein Azure-Server in Zürich bleibt dem CLOUD Act unterstellt, weil Microsoft ein US-Unternehmen ist.
Diese rechtliche Realität hat in der Schweiz konkrete Konsequenzen ausgelöst:
- November 2025: Die Konferenz der Schweizer Datenschutzbeauftragten (privatim) empfahl faktisch, US-Hyperscaler in der öffentlichen Verwaltung nicht einzusetzen, wegen des unauflösbaren Konflikts zwischen CLOUD Act und Schweizer Datenschutzrecht.
- Februar 2026: Das Bundesamt für Gesundheit (BAG) schrieb beim SwissHDS-Infrastrukturprojekt explizit aus: "keine technische oder rechtliche Abhängigkeit von ausländischen Rechtssystemen (z.B. US CLOUD Act)." Selbst der Bund bewegt sich aktiv weg von US-Hyperscalern für sensitive Daten.
Konsequenz für die Storage-Wahl
S3-kompatibler Object Storage von einem Schweizer Anbieter ist technisch gleichwertig zu AWS S3, bietet aber echte Datensouveränität. Veeam, Synology, QNAP und andere Backup-Lösungen integrieren sich genauso in einen Schweizer S3-Endpunkt wie in AWS. Der einzige Unterschied: Der Schweizer Anbieter untersteht Schweizer Recht und ist dem CLOUD Act nicht zugänglich.
Wer den Datenstandort Schweiz bei Backup ONE AG wählt, kombiniert S3-Kompatibilität mit echter Datensouveränität, ohne Kompromisse bei Funktionsumfang oder Integration.
Fazit
File Storage, Block Storage und Object Storage sind keine konkurrierenden Technologien, sondern ergänzende Paradigmen für unterschiedliche Anforderungen. Die Wahl des richtigen Typs hat direkte Auswirkungen auf Performance, Kosten und Skalierbarkeit.
Die Faustregel:
-
Transaktional und latenzempfindlich: Block Storage
-
Kollaborativ und dateizentriert: File Storage
-
Skalierbar, kosteneffizient, für Backup und Archiv: Object Storage
Für die grosse Mehrheit der Backup- und Archivierungs-Use Cases ist Object Storage mit S3-API die richtige Wahl, kosteneffizient, beliebig skalierbar und mit modernen Sicherheitsmechanismen wie Object Lock ausgestattet. Für Schweizer und EU-regulierte Unternehmen kommt ein weiteres, entscheidendes Argument hinzu: Nur ein Anbieter unter Schweizer Recht bietet echten Schutz vor dem Zugriff durch ausländische Behörden.
Weiterführende Informationen: Swiss S3 Object Storage von Backup ONE AG
Backup ONE AG betreibt einen S3-kompatiblen Object Storage mit Rechenzentren in der Schweiz (Zürich Tier-IV, georedundant mit Genf). Die Rechenzentren sind ISO- und SOC-zertifiziert. Die Lösung lässt sich direkt mit Veeam, Synology, QNAP und weiteren Backup-Lösungen integrieren.
Backup ONE AG untersteht ausschliesslich Schweizer Recht. Kein CLOUD Act. Kein Zugriff durch ausländische Behörden. Daten bleiben in der Schweiz, rechtlich und physisch.
→ Swiss S3 Object Storage von Backup ONE AG entdecken
Daten bleiben in der Schweiz. Immer.