6 Objektspeicher hat grundlegend verändert, wie Unternehmen ihre Backup-Infrastruktur verwalten. Statt klassischer SAN- oder NAS-Hierarchien verteilt verteilter Objektspeicher Daten auf mehrere Server und Standorte und bietet damit Resilienz, Skalierbarkeit und eine Wirtschaftlichkeit, mit denen ältere Architekturen nicht mithalten können. Für Backup-Administratoren und Verantwortliche für Datensicherung ist es keine Option mehr, sich nicht mit verteiltem Objektspeicher auszukennen. Er ist die Architektur hinter den meisten modernen Backup-Zielen – von Cloud-Diensten bis zu On-Premises-Appliances. Die Frage ist nicht, ob verteilter Objektspeicher genutzt wird, sondern wie er wirksam konzipiert und betrieben wird. Ein Blick auf Anwendungsfälle für Objektspeicher (auf Englisch) verdeutlicht die Vorteile dieses Ansatzes für Backup- und Archiv-Workloads. Dieser Beitrag erklärt, wie verteilter Objektspeicher funktioniert, warum er zum bevorzugten Backup-Ziel geworden ist und was Sie im Betrieb verstehen müssen, um erfolgreich zu sein. Wie sich verteilter Objektspeicher grundlegend von klassischem Speicher unterscheidet Klassische Speicherarchitekturen (SAN, NAS) sind zentralisiert. Sie kaufen ein Speicher-Array, verbinden es mit Ihrem Netzwerk und verwalten es als eine Einheit. Die Kapazität ist durch die Größe des Arrays begrenzt. Für mehr Kapazität fügen Sie Laufwerke hinzu (begrenzt) oder kaufen ein weiteres Array und verwalten beide getrennt. Verteilter Objektspeicher behandelt Speicher als Sammlung unabhängiger Server. Jeder Server verwaltet einen Teil Ihrer Daten. Beim Schreiben werden die Daten auf mehrere Server verteilt. Fällt ein Server aus, bleiben Ihre Daten auf den anderen zugänglich. Darum ist das wichtig: Horizontale Skalierbarkeit: Kapazität kommt durch zusätzliche Server hinzu, nicht durch den Austausch von Arrays. Beginnen Sie mit drei Servern zu je 10 TB und erweitern Sie auf fünfzig Server zu je 100 TB. Klassischer Speicher lässt sich nicht so einfach skalieren. Resilienz durch Verteilung: Klassischer Speicher erreicht Resilienz durch Redundanz (RAID, Spiegelung). Verteilter Speicher erreicht Resilienz, indem er Daten auf viele Knoten verteilt. Fällt ein Knoten aus, enthalten viele andere Kopien. Das ist grundlegend anders und im großen Maßstab deutlich resilienter. Kosteneffizienz: Verteilter Speicher nutzt Standardhardware (handelsübliche Server und Laufwerke). Sie zahlen keine Premiumpreise für spezialisierte Appliances. Das macht verteilten Speicher für riesige Datenmengen kosteneffizient. Geografische Verteilung: Verteilter Objektspeicher erstreckt sich über mehrere Rechenzentren, Regionen oder Kontinente. Daten werden automatisch geografisch repliziert. Das schützt vor regionalen Katastrophen, die klassischen Speicher lahmlegen würden. Namespace-Föderation: Mehrere Cluster werden zu einem einzigen logischen Namespace zusammengeführt. Aus Sicht der Nutzer wirkt das wie ein einziges riesiges Speichersystem. Intern sind die Daten auf getrennte Cluster verteilt. Diese Eigenschaften machen verteilten Objektspeicher ideal für Backups im Unternehmensmaßstab. Datenverteilung verstehen: Replikation vs. Erasure Coding Verteilter Objektspeicher schützt Daten über zwei Mechanismen: Replikation: Der einfachste Ansatz. Beim Speichern eines Objekts werden Kopien erstellt und auf mehrere Knoten verteilt. Bei dreifacher Replikation existieren von jedem Objekt drei Kopien. Fällt ein Knoten aus, bleiben die beiden anderen zugänglich. Replikation ist unkompliziert, erfordert aber einen erheblichen Speicher-Overhead (drei Kopien bedeuten die dreifache Rohkapazität für eine Kopie der Daten). Erasure Coding: Ein ausgefeilterer Ansatz. Die Daten werden in Fragmente aufgeteilt (zum Beispiel 10) und so codiert, dass beliebige 7 der 10 Fragmente die Daten rekonstruieren können. Gehen 3 Fragmente verloren, reichen die verbleibenden 7 aus. Das schützt vor Knotenausfällen mit weniger Overhead als Replikation. Sie benötigen 10/7 = 1,43-fachen Speicher statt des 3-fachen. Erasure Coding ist aufwendiger umzusetzen und verursacht etwas höhere CPU-Kosten, ist aber deutlich speichereffizienter. Die meisten modernen verteilten Objektspeichersysteme unterstützen beides: Replikation für heiße Daten (häufig genutzt, profitieren von mehreren Kopien) und Erasure Coding für Archivdaten (selten genutzt, profitieren von Speichereffizienz). Für Backup-Architekten ist das Verständnis dieses Zielkonflikts entscheidend. Dreifache Replikation für alle Backups bedeutet die 3-fachen effektiven Speicherkosten. Erasure Coding (z. B. 10+4, bei dem 10 von 14 Fragmenten benötigt werden) bedeutet die 1,4-fachen Kosten. Die Wahl wirkt sich direkt auf das Infrastrukturbudget aus. Namespace-Föderation: mehrere Cluster wie einen verwalten Eine Herausforderung bei verteiltem Objektspeicher ist die Verwaltung von Daten über mehrere Standorte. Haben Sie Backup-Cluster in drei geografisch getrennten Rechenzentren, können Sie jeden einzeln verwalten (dann müssen Nutzer wissen, welcher Cluster welche Daten enthält) oder sie föderieren. Namespace-Föderation macht das transparent. Nutzer sehen einen einzigen, einheitlichen Objektspeicher-Namespace. Intern werden Schreibvorgänge automatisch auf die Cluster verteilt. Lesevorgänge finden die Daten, wo immer sie gespeichert sind. Diese Abstraktion vereinfacht die Verwaltung und ermöglicht eine intelligente Datenplatzierung: Häufig genutzte Daten werden lokal zwischengespeichert, selten genutzte Daten entfernt gespeichert. Für Backup-Architekten ist Namespace-Föderation wertvoll, weil sie Folgendes ermöglicht: Datenlokalität optimieren: Backup-Jobs in der gesamten Organisation laden Daten in den lokalen Cluster hoch. Die Daten werden automatisch in andere Cluster verschoben oder repliziert, um geografische Vielfalt zu erreichen. Nutzer müssen diese Komplexität nicht verstehen. Globale Deduplizierung: Ein föderierter Namespace erkennt, ob Daten bereits irgendwo vorhanden sind, und vermeidet doppelte Speicherung. Das ist besonders wertvoll für die Deduplizierung von Backups, die oft ähnliche Daten enthalten. Transparentes geografisches Failover: Ist ein Cluster nicht verfügbar, leitet der föderierte Namespace den Datenverkehr automatisch auf einen anderen Cluster um. Das geschieht transparent für die Backup-Software. Inline-Deduplizierung und Komprimierung im Objektspeicher Verteilter Objektspeicher umfasst oft Deduplizierung (doppelte Daten erkennen und einmal speichern) und Komprimierung (Datengröße verringern). Deduplizierung berechnet für jedes Objekt einen Hash. Haben zwei Objekte denselben Hash, sind sie wahrscheinlich identisch. Das System speichert die Daten einmal und führt Metadaten, die beide Verweise darauf lenken. Bei Backups senkt das den Speicherverbrauch drastisch. Ist Ihr Datenbank-Backup jeden Tag sehr ähnlich (mit nur inkrementellen Änderungen), beseitigt die Deduplizierung die Redundanz. Deduplizierung hat betriebliche Folgen: Zeitpunkt der Deduplizierung: Manche Systeme deduplizieren sofort (inline), andere asynchron (nach dem Schreiben). Inline verbraucht mehr CPU, spart aber sofort Speicher und Bandbreite. Asynchron verbraucht beim Schreiben weniger CPU, kann aber Stunden für die Deduplizierung brauchen (in denen Sie mehr Speicher als nötig belegen). Umfang der Deduplizierung: Manche Systeme deduplizieren innerhalb eines einzelnen Clusters, andere über einen föderierten Namespace. Clusterübergreifende Deduplizierung spart mehr Speicher, erfordert aber mehr Koordination und ist im Betrieb komplexer. Garbage Collection: Werden Daten gelöscht, muss das System die zugrunde liegenden Speicherblöcke irgendwann löschen, wenn keine anderen Objekte mehr darauf verweisen. Diese Garbage Collection muss effizient sein (zu häufige Durchläufe verbrauchen Ressourcen), darf aber nicht träge sein (verzögerte Durchläufe verschwenden Speicher). Dieses unscheinbare betriebliche Detail beeinflusst, wie effizient Ihr Speicher genutzt wird. Für Backup-Architekten ist das Verständnis der Deduplizierung entscheidend, weil es direkt bestimmt, ob die Backup-Infrastruktur effizient oder verschwenderisch ist. Ein schlecht konfiguriertes System verspricht vielleicht eine Komprimierung von 10:1, liefert in der Praxis aber nur 2:1. Unveränderlichkeit und WORM: Schutz vor Ransomware „Write Once, Read Many“ (WORM) ist ein Schutzmodus, bei dem einmal geschriebene Daten weder verändert noch gelöscht werden können. Manche verteilten Objektspeichersysteme unterstützen WORM über Unveränderlichkeitsrichtlinien. Werden Daten mit einer solchen Richtlinie geschrieben, setzt das System durch, dass niemand – nicht einmal Administratoren – die Daten für einen festgelegten Zeitraum löschen oder verändern kann. Das bietet starken Schutz vor Ransomware: Selbst wenn Angreifer Administratorzugangsdaten kompromittieren, können sie Ihre Backups nicht löschen. Die Umsetzung der Unveränderlichkeit unterscheidet sich: Unveränderlichkeit auf Objektebene: Jedes Objekt kann eine eigene Unveränderlichkeitsrichtlinie haben. Ein Backup-Objekt lässt sich zum Beispiel für 30 Tage unveränderlich konfigurieren. In diesem Zeitraum ist kein Löschen möglich. Governance- vs. Compliance-Aufbewahrung: Manche Systeme unterscheiden zwischen Governance-Aufbewahrung (die Nutzer mit hohen Berechtigungen mit entsprechender Begründung aufheben können) und Compliance-Aufbewahrung (die sich nie aufheben lässt). Die Compliance-Aufbewahrung ist stärker, aber restriktiver. Sperren für die Unveränderlichkeit: Manche Systeme unterstützen Legal Holds – Administratoren können Daten sperren und so das Löschen verhindern, selbst wenn die normale Aufbewahrungsfrist abgelaufen ist. Legal Holds sind für Rechtsstreitigkeiten und behördliche Untersuchungen unverzichtbar. Für Backup-Administratoren wird Unveränderlichkeit immer wichtiger. Ransomware gehört zu den größten Bedrohungen für Backup-Infrastruktur. Unveränderliche Backups geben die Gewissheit, dass eine Wiederherstellung immer möglich ist – selbst wenn Ihre primäre Infrastruktur vollständig kompromittiert ist. Betriebliche Aspekte: Monitoring, Leistung und Fehlerbehebung Der Betrieb von verteiltem Objektspeicher im großen Maßstab bringt betriebliche Herausforderungen mit sich: Rebalancing: Wird ein Knoten hinzugefügt oder entfernt, müssen die Daten neu auf die Knoten verteilt werden. Dieses Rebalancing verbraucht Netzwerkbandbreite und Festplatten-I/O. In einem produktiven Backup-System kann ein Rebalancing während der Geschäftszeiten die Backup-Leistung beeinträchtigen. Die meisten Betreiber planen es außerhalb der Spitzenzeiten. Knotenausfälle und Wiederherstellung: Fällt ein Knoten aus, muss das System die verlorenen Daten aus den verbleibenden Knoten rekonstruieren (aus anderen Replikaten oder aus per Erasure Coding erzeugten Fragmenten). Diese Rekonstruktion verbraucht Netzwerkbandbreite und Festplatten-I/O. Fallen mehrere Knoten gleichzeitig aus, ist eine Rekonstruktion unter Umständen nicht möglich (dann ist eine Wiederherstellung aus einem sekundären Backup nötig). Monitoring: Verteilter Objektspeicher erzeugt umfangreiche Metriken: Zustand des Clusters, Status der Knoten, Fortschritt des Rebalancing, API-Latenz, Speicherauslastung pro Knoten. Wirksames Monitoring ist unverzichtbar. Wenn Sie erst bemerken, dass ein Knoten ausfällt, wenn er vollständig offline ist, verlieren Sie Resilienz. Schulung der Betreiber: Verteilter Objektspeicher ist komplexer als klassischer Speicher. Ihr Team muss Rebalancing, Erasure Codes und Deduplizierung verstehen. Das kann Schulungen oder die Einstellung von Personal mit Erfahrung in verteilten Systemen erfordern. Backup und Notfallwiederherstellung: Auch Cluster mit verteiltem Objektspeicher müssen selbst gesichert werden. Fällt Ihr gesamter Cluster aus und gehen alle Knoten verloren (unwahrscheinlich, aber möglich), müssen Sie wiederherstellen können. Dazu werden in der Regel Metadaten und Konfiguration des Clusters getrennt von den Daten gesichert. Kapazitätsplanung für verteilten Objektspeicher Die Kapazitätsplanung unterscheidet sich bei verteiltem Speicher: Roh- vs. nutzbare Kapazität: Stellen Sie 100 TB an Laufwerken mit dreifacher Replikation bereit, beträgt die nutzbare Kapazität 33 TB. Mit Erasure Coding (z. B. 10+4) beträgt sie 71 TB. Diesen Unterschied zu verstehen, ist für die richtige Dimensionierung entscheidend. Wachstum und Reserven: Die meisten Betreiber halten die Auslastung unter 80–85 %. Darüber sinkt die Leistung, das Rebalancing wird komplex und die Wiederherstellung nach Ausfällen riskant. Erwarten Sie 100 TB an Backups und nutzen dreifache Replikation, brauchen Sie 300 TB Rohkapazität plus Reserven. Planen Sie mit 400 TB Kapazität. Tiering: Nicht alle Daten müssen online sein. Archivdaten können auf langsamerem, günstigerem Objektspeicher liegen. Heiße Backups (aktuell, häufig genutzt) können auf schnellerem Objektspeicher liegen. Die Kapazitätsplanung sollte dieses Tiering berücksichtigen. Egress-Kosten: Nutzen Sie Cloud-basierten verteilten Objektspeicher, können die Egress-Kosten (Gebühren für Daten, die die Cloud verlassen) erheblich sein. Die Kapazitätsplanung sollte das erwartete Abrufvolumen und die Egress-Kosten berücksichtigen. Migration auf verteilten Objektspeicher Viele Organisationen migrieren von klassischem Backup-Speicher auf verteilten Objektspeicher. Das ist anspruchsvoll: Datenmigration: Sie müssen Terabytes oder Petabytes vorhandener Backup-Daten vom alten auf den neuen Speicher verschieben. Das braucht Zeit und Bandbreite. Die meisten Migrationen verlaufen langsam, über Wochen oder Monate. Paralleler Betrieb: Während der Migration laufen beide Systeme meist parallel. Backups werden gleichzeitig auf den alten und den neuen Speicher geschrieben, bis die Migration abgeschlossen ist. Das erhöht vorübergehend Speicherkosten und betriebliche Komplexität. Umstellung: Irgendwann stellen Sie auf das neue System um. Backup-Jobs schreiben dann in das neue System, Wiederherstellungen erfolgen aus dem neuen System. Diese Umstellung ist riskant und muss gut geplant sein. Altdaten: Alte Backup-Daten können zu Archivzwecken auf dem Altsystem bleiben, oder Sie migrieren sie in das neue System. Die Kosten der Migration (an Speicher, Netzwerk und Arbeitszeit) müssen gegen den betrieblichen Nutzen eines einheitlichen Systems abgewogen werden. Erste Schritte mit verteiltem Objektspeicher für Backups Wenn Sie verteilten Objektspeicher für Backups evaluieren: Beginnen Sie mit unkritischen Backups. Setzen Sie ein Pilotprojekt mit sekundären Daten oder einer neuen Anwendung um. Prüfen Sie, ob sich Ihre Backup-Software gut integriert, ob die Leistung Ihren Anforderungen entspricht und ob der Betrieb beherrschbar ist. Erwägen Sie, zunächst für unkritische Workloads eine skalierbare Architektur für Backup-Ziele umzusetzen. Machen Sie sich mit den Funktionen des Systems für Deduplizierung, Erasure Coding und Unveränderlichkeit vertraut. Prüfen Sie, ob sie wie dokumentiert funktionieren. Viele Herstellerangaben zu Deduplizierungsquoten spiegeln nicht die Leistung in der Praxis wider. Entwickeln Sie betriebliche Verfahren: wie Knoten hinzugefügt und entfernt, Ausfälle überwacht und behoben werden. Diese sollten dokumentiert und getestet sein. Machen Sie sich mit den verfügbaren Lösungen für Backup-Ziele vertraut und damit, wie sie in Ihre Infrastruktur passen. Planen Sie Ihre Migration schrittweise. Migrieren Sie zuerst unkritische Backups. Prüfen Sie den Erfolg. Weiten Sie dann auf kritische Systeme aus. Bei der Ausweitung auf mehrere geografische Standorte ist die Planung Ihrer standortübergreifenden Architektur (auf Englisch) für die Resilienz unverzichtbar. Die Entscheidung für verteilten Objektspeicher als Backup-Ziel wird immer eindeutiger – für die meisten Organisationen ist er die richtige Wahl. Die Herausforderung liegt in der guten Umsetzung: seine Eigenschaften verstehen, richtig dimensionieren und wirksam betreiben. Organisationen, denen das gelingt, erschließen sich eine deutlich effizientere Backup-Infrastruktur. Verteilter Objektspeicher ist keine Spitzentechnologie mehr. Er ist das Fundament moderner Backup-Architekturen. Ihre Backup-Infrastruktur sollte darauf aufbauen. Weiterführende Artikel Skalierbare Architektur für Backup-Ziele Backup-Strategie für Unternehmen Die 3-2-1-1-0-Backup-Strategie erklärt Unveränderlicher Speicher und Abwehr von Ransomware (auf Englisch) Datenhaltbarkeit in Speichersystemen mit hoher Dichte Objektspeicher für Data Lakes (auf Englisch) Was ist unveränderlicher Speicher?
