Cloud-Speicher im Vergleich: Welcher passt?

Cloud-Speicher ist nicht gleich Cloud-Speicher: Objektspeicher passt zu großen Mengen unstrukturierter Daten, Blockspeicher zu virtuellen Maschinen und Datenbanken, Dateispeicher zu gemeinsam genutzten Verzeichnissen. Sync-Dienste richten sich dagegen an Menschen und Endgeräte. Die richtige Wahl beginnt beim Zugriffsmuster und beim getesteten Wiederanlauf.

Die vier Modelle in einer Minute

Die erste Frage lautet deshalb nicht, welcher Dienst am meisten Speicher bietet. Entscheidend ist, wer auf welche Daten wie zugreift und wie diese Daten nach einem Fehler wieder nutzbar werden.

Objektspeicher für API-basierte Daten

Objektspeicher legt Daten zusammen mit Metadaten unter einer eindeutigen Kennung ab. Anwendungen greifen typischerweise über HTTP-APIs darauf zu. Eine klassische Ordnerstruktur kann in der Oberfläche nachgebildet werden, ist aber nicht dasselbe wie ein gemeinsam eingehängtes Dateisystem.

Das Modell passt gut zu:

• Bildern, Videos und Downloads;
• Backups und Archiven;
• Protokollen und Analysedaten;
• statischen Website-Dateien;
• großen Datenmengen mit klarer Objektkennung.

Es passt weniger gut, wenn eine Anwendung Dateien ständig an beliebigen Stellen verändert oder ein echtes Dateisystem mit Sperren erwartet. Prüfen Sie außerdem, ob die verwendete API nur grundlegende S3-Funktionen oder auch Versionierung, Lifecycle, Sperren und spezielle Metadaten unterstützt.

Blockspeicher für Betriebssysteme und Datenbanken

Blockspeicher stellt einer virtuellen Maschine ein Volume bereit. Das Betriebssystem formatiert es mit einem Dateisystem und entscheidet anschließend, wie Dateien und Verzeichnisse organisiert werden. Für die Anwendung wirkt das Volume ähnlich wie eine lokale Platte.

Typische Einsatzfälle sind Systemplatten, Datenbanken und Anwendungen mit vielen kleinen, zufälligen Lese- und Schreibvorgängen. Hier zählen nicht nur Kapazität und Preis pro Gigabyte, sondern auch Latenz, IOPS, Durchsatz und das Verhalten bei Lastspitzen.

Ein Snapshot ist noch kein bewiesener Wiederanlauf. Klären Sie, ob er an eine Region oder Zone gebunden ist, wie konsistent die Anwendung zum Aufnahmezeitpunkt war und wie lange die Wiederherstellung eines vollständigen Systems dauert.

Dateispeicher für gemeinsame Pfade

Dateispeicher stellt Ordner, Dateien und Berechtigungen über Protokolle wie NFS oder SMB bereit. Mehrere Server oder Mitarbeitende können denselben Bestand verwenden, ohne die Anwendung auf eine Objekt-API umzubauen.

Das ist praktisch für Agentur-Assets, gemeinsame CMS-Verzeichnisse, Render-Pipelines und Fachanwendungen, die feste Pfade erwarten. Prüfen Sie gleichzeitig, wie der Dienst mit Dateisperren, Identitäten, vielen kleinen Dateien und sehr tiefen Verzeichnisstrukturen umgeht.

Zuständigkeit gehört zum Leistungsumfang. Bei einem verwalteten Dateidienst muss klar sein, wer Berechtigungen, Protokollzugang, Snapshots, Backup und Wiederherstellung betreibt. Ein gemeinsamer Ordner ist bequem; unklare Verantwortung bleibt trotzdem unklar.

Wann ein Sync-Dienst genügt

Ein Consumer-Sync-Dienst verteilt Dateien zwischen Endgeräten und bietet häufig Freigaben, Kommentare und eine Versionshistorie. Das ist sinnvoll, wenn Menschen Dokumente gemeinsam bearbeiten und der Desktop-Client Teil des Arbeitsablaufs ist.

Für eine Datenbank, eine VM-Systemplatte oder eine Anwendung mit vielen API-Operationen ist dieses Modell kein Ersatz für Block-, Datei- oder Objektspeicher. Synchronisation ist nicht automatisch Backup: Eine Löschung oder Verschlüsselung kann auf andere Geräte übertragen werden. Prüfen Sie Aufbewahrungsfristen und den tatsächlichen Restore-Weg.

Zugriffsmuster entscheidet vor Kapazität

Beschreiben Sie den Workload vor dem Produktvergleich:

• Werden ganze Objekte gelesen oder kleine Bereiche häufig geändert?
• Greift ein Server, greifen mehrere Server oder greifen vor allem Menschen zu?
• Muss ein Dateipfad unverändert bleiben?
• Wie viele Anfragen entstehen pro Objekt und Monat?
• Welche Latenz und welcher Durchsatz sind wirklich erforderlich?
• Darf die Anwendung bei einem Zonen- oder Regionsausfall pausieren?

Ein günstiger Gigabyte-Preis hilft wenig, wenn jede Listen-, Schreib- oder Abrufoperation berechnet wird oder die Anwendung wegen des falschen Protokolls umgebaut werden muss.

Dauerhaftigkeit ist keine Garantie für Wiederherstellung

Anbieter nennen für einzelne Speicherklassen mitunter elf oder mehr Neunen an konzipierter jährlicher Dauerhaftigkeit. Solche Werte beschreiben ein statistisches Designziel für den Verlust von Objekten innerhalb eines definierten Dienstes. Sie sind keine Garantie für ein bestimmtes Objekt und beantworten andere Risiken nicht.

Ein hoher Wert schützt nicht automatisch vor:

• versehentlichem Löschen mit gültigen Rechten;
• überschriebenen oder beschädigten Anwendungsdaten;
• kompromittierten Zugangsschlüsseln;
• falsch konfigurierten Lifecycle-Regeln;
• einem Konto- oder Vertragsproblem;
• einer Wiederherstellung, die zu lange dauert.

AWS beschreibt S3-Speicherklassen ausdrücklich als auf bestimmte Dauerhaftigkeitswerte ausgelegt. Lesen Sie diese Formulierung als Merkmal der Speicherarchitektur, nicht als Ersatz für Versionierung, getrennte Sicherungen und Tests.

Region und Datenstandort

Die Region beeinflusst Latenz, Datenstandort, verfügbare Funktionen und mögliche Kosten für Übertragungen. Dokumentieren Sie nicht nur den Ort der Primärdaten, sondern auch Backups, Replikate, Protokolle, Metadaten, Schlüssel und Supportzugriffe.

Bei Azure und Google Cloud hängen Speicheroptionen und Schutzfunktionen vom konkreten Dienst, Kontotyp und Standort ab. Prüfen Sie deshalb die Region auf Produktebene und nicht nur über eine allgemeine Standortkarte.

Für personenbezogene oder regulierte Daten gehören Auftragsverarbeitung, Unterauftragnehmer, Löschfristen und Zugriffskontrollen in die Prüfung. Der Regionsname allein belegt keine vollständige Konformität.

Egress, API-Operationen und Nebenkosten

Vergleichen Sie nicht nur den Kapazitätspreis. Ein belastbares Kostenmodell enthält:

• eingehenden und ausgehenden Datenverkehr;
• Abrufe aus kühleren oder archivierten Klassen;
• Schreib-, Lese-, Listen- und Lifecycle-Operationen;
• Mindestaufbewahrung und Mindestobjektgröße;
• Replikation zwischen Zonen oder Regionen;
• Snapshots, alte Versionen und gelöschte Marker;
• Support sowie Migrations- und Parallelbetrieb.

Messen Sie einen typischen Monat aus der Anwendung heraus. Viele kleine Dateien können bei gleichem Datenvolumen ein anderes Kostenprofil erzeugen als wenige große Objekte. Komfort braucht eine Ausstiegstür: Schätzen Sie auch Zeit, Bandbreite und API-Arbeit für den Export.

Lifecycle und Versionierung sauber trennen

Lifecycle-Regeln verschieben oder löschen Daten nach Alter, Status oder Speicherklasse. Versionierung bewahrt frühere Zustände eines Objekts. Beides kann zusammenarbeiten, aber eine Löschregel kann auch alte Versionen endgültig entfernen.

Definieren Sie deshalb vor der Aktivierung:

1. welche Daten wie lange aktuell bleiben;
2. wie lange frühere Versionen benötigt werden;
3. wann ein Archivabruf noch rechtzeitig ist;
4. wer Regeln ändern oder umgehen darf;
5. welches Budget alte Versionen erhalten.

Versionierung ist eine Schutzfunktion, kein vollständiges Sicherungskonzept. Eine getrennte Sicherung mit eigenem Zugriffspfad kann zusätzlich gegen Konto-, Berechtigungs- oder Konfigurationsfehler helfen.

Wiederherstellung testen

Replikation hält Kopien technisch synchron. Sie kann deshalb auch eine fehlerhafte Änderung oder Löschung weiterreichen. Ein Backup hält einen definierten früheren Zustand. Ob dieser Zustand nutzbar ist, zeigt erst ein Restore-Test.

Ein kleiner, wiederholbarer Test sollte prüfen:

• ob ein gelöschtes Objekt oder eine alte Version auffindbar ist;
• ob Berechtigungen und Schlüssel am Ziel funktionieren;
• ob eine Anwendung die wiederhergestellten Daten akzeptiert;
• wie lange Download, Import und Validierung dauern;
• ob der Ablauf auch ohne das ursprüngliche Administratorkonto gelingt.

Notieren Sie RPO und RTO in verständlicher Form: Wie viel Datenverlust ist akzeptabel, und wann muss der Dienst wieder arbeiten? Ein erfolgreich hochgeladenes Backup beantwortet keine dieser Fragen allein.

Support und Betriebsgrenzen

Support ist besonders wichtig, wenn das eigene Team den Speicher nicht täglich betreibt. Vergleichen Sie erreichbare Zeiten, Sprache, Eskalationswege und den Umfang der Hilfe. Ein Anbieter kann die Plattform reparieren, aber nicht automatisch Ihre Lifecycle-Regel oder Anwendungslogik verstehen.

Legen Sie eine kurze Verantwortungsmatrix an:

Entscheidung in fünf Schritten

Kurzes Fazit

Objekt-, Block- und Dateispeicher lösen unterschiedliche Aufgaben; Sync-Dienste bedienen einen weiteren Arbeitsablauf. Wählen Sie nach Zugriffsmuster, Betriebsgrenze und Wiederherstellungsziel. Ein guter Dienst speichert Daten zuverlässig. Eine gute Architektur sorgt zusätzlich dafür, dass Ihr Team sie rechtzeitig und vollständig zurückbekommt.