Azure Storage Redundanz

Azure Storage speichert immer mehrere Kopien Ihrer Daten, um sie vor geplanten und ungeplanten Ereignissen zu schützen. Zu diesen Ereignissen gehören vorübergehende Hardwarefehler, Netzwerk- oder Stromausfälle sowie Naturkatastrophen. Redundanz stellt sicher, dass Ihr Speicherkonto auch bei Ausfällen seine Verfügbarkeits- und Haltbarkeitsziele erreicht.

Berücksichtigen Sie bei der Entscheidung, welche Redundanzoption für Ihr Szenario am besten geeignet ist, die Kompromisse zwischen geringeren Kosten und höherer Verfügbarkeit. Anhand der folgenden Faktoren können Sie bestimmen, welche Redundanzoption Sie auswählen sollten:

  • Wie Ihre Daten in der primären Region repliziert werden.
  • Ob Ihre Daten von einer primären Region in eine sekundäre, geografisch entfernte Region repliziert werden, um Schutz vor regionalen Ausfällen zu bieten (Georeplikation).
  • Ob Ihre Anwendung Lesezugriff auf die replizierten Daten in der sekundären Region benötigt, wenn die primäre Region ausfällt (Georeplikation mit Lesezugriff).

Hinweis

Die in diesem Artikel beschriebenen Funktionen und regionale Verfügbarkeit stehen auch Konten mit hierarchischem Namensraum (Azure Blob Storage) zur Verfügung.

Die Dienste, die Azure Storage umfassen, werden über eine gemeinsame Azure Ressource verwaltet, die als Storagekonto bezeichnet wird. Das Speicherkonto stellt einen gemeinsamen Speicherpool dar, den Sie zum Bereitstellen von Speicherressourcen wie Blob-Containern (Blob Storage), Dateifreigaben (Azure Files), Tabellen (Table Storage) oder Warteschlangen (Queue Storage) verwenden können. Weitere Informationen zu Azure Storage Konten finden Sie unter Storage-Kontoübersicht.

Die Redundanzeinstellung für ein Speicherkonto wird für alle Speicherdienste freigegeben, die durch dieses Konto verfügbar gemacht werden. Bei allen in demselben Speicherkonto bereitgestellten Speicherressourcen gibt es dieselbe Redundanzeinstellung. Sie sollten verschiedene Arten von Ressourcen in separaten Speicherkonten isolieren, wenn sie unterschiedliche Redundanzanforderungen haben.

Redundanz in der primären Region

Azure Storage bietet zwei Optionen für die Replikation Ihrer Daten in der primären Region:

  • Lokal redundanter Speicher (LRS) repliziert die Daten in Ihren Speicherkonten in ein einzelnes physisches Rechenzentrum, das sich in der primären Region Ihrer Wahl befindet.

  • Zone-redundanter Speicher (ZRS) kopiert Ihre Daten synchron über drei oder mehr Azure Verfügbarkeitszonen in der primären Region. Für Anwendungen, die hohe Verfügbarkeit erfordern, empfiehlt Microsoft die Verwendung von ZRS in der primären Region und das Replizieren in eine sekundäre Region.

Hinweis

Microsoft empfiehlt die Verwendung von ZRS in der primären Region für Azure Data Lake Storage Workloads.

Lokal redundanter Speicher

Lokal redundanter Speicher (LRS) repliziert die Daten in Ihren Speicherkonten in ein einzelnes physisches Rechenzentrum in der primären Region Ihrer Wahl. Obwohl die Auswahl einer Verfügbarkeitszone nicht unterstützt wird, können Azure LRS-Konten über Zonen hinweg verschieben oder erweitern, um den Lastenausgleich zu verbessern. LRS stellt eine Dauerhaftigkeit von mindestens 99,999999999 % (11 Neunen) für Objekte in einem bestimmten Jahr bereit. Besuchen Sie den Was sind Azure Verfügbarkeitszonen Artikel, um mehr über die Zuverlässigkeit der Verfügbarkeitszonen zu erfahren.

LRS ist die kostengünstigste Redundanzoption und bietet im Vergleich zu anderen Optionen die geringste Dauerhaftigkeit. LRS schützt Ihre Daten vor Laufwerks-, Server- und Rackfehlern. Wenn jedoch eine Katastrophe wie Feuer oder Überschwemmung im Rechenzentrum eintritt, können alle Repliken eines Speicherkontos, die LRS verwenden, verloren gehen oder nicht wiederherstellbar sein. Wenn ein temporäres Ereignis, wie ein thermisches Ereignis, im Rechenzentrum auftritt, könnten alle Repliken vorübergehend nicht verfügbar sein, bis das Ereignis aufgelöst ist. Um diese Risiken zu verringern, empfiehlt Microsoft die Verwendung zone-redundanten Speichers (ZRS), geo-redundanten Speicher (GRS) oder geo-zone-redundanten Speicher (GZRS).

Alle Repliken spiegeln denselben aktuellen Zustand wider: Löschungen und Überschreibungen werden gleichzeitig auf alle Kopien angewendet. Redundanz schützt vor Hardwarefehlern und nicht vor Datenmodifizierungsvorgängen.

Das folgende Diagramm zeigt, wie Ihre Daten innerhalb eines einzelnen Rechenzentrums mit LRS repliziert werden:

Diagramm, das zeigt, wie Daten in einem einzelnen Rechenzentrum mit lokal redundantem Speicher-LRS repliziert werden.

LRS ist eine gute Wahl für die folgenden Szenarien:

  • Wenn Ihre Anwendung Daten speichert, die bei Datenverlust problemlos wiederhergestellt werden können, können Sie LRS verwenden.
  • Wenn Ihre Anwendungen aufgrund von Data Governance-Anforderungen auf die Replikation von Daten innerhalb einer Region beschränkt ist, können Sie einen LRS in Betracht ziehen. In einigen Fällen können sich die gepaarten Regionen, über die die Daten georepliziert werden, in einer anderen Region befinden. Weitere Informationen zu gekoppelten Regionen finden Sie unter Azure Regions.
  • Wenn Ihr Szenario nicht verwaltete Azure-Datenträger verwendet, sollten Sie LRS in Betracht ziehen. Obwohl es möglich ist, ein Speicherkonto für Azure nicht verwalteten Datenträger zu erstellen, die GRS verwenden, wird es aufgrund potenzieller Probleme mit Konsistenz gegenüber asynchroner Georeplikation nicht empfohlen.

Zonenredundanter Speicher

Zonenredundanter Speicher (ZRS) repliziert die Daten in Ihren Speicherkonten in drei oder mehr Azure Verfügbarkeitszonen, die sich in der primären Region Ihrer Wahl befinden. Jede Verfügbarkeitszone ist ein getrennter physischer Standort mit unabhängigen Stromversorgungs-, Kühlungs- und Netzwerkgeräten. Der ZRS bietet Dauerhaftigkeit für Speicherressourcen von mindestens 99,9999999999 % (12 Neuner) für ein bestimmtes Jahr. Besuchen Sie den Was sind Azure Verfügbarkeitszonen Artikel, um mehr über die Zuverlässigkeit der Verfügbarkeitszonen zu erfahren.

Wenn Sie ZRS verwenden, bleiben Ihre Daten sowohl für Lese- als auch für Schreibvorgänge zugänglich, selbst wenn eine Zone nicht verfügbar ist. Wenn eine Zone nicht mehr verfügbar ist, führt Azure Netzwerkupdates durch, z. B. durch die Festlegung neuer DNS-Ziele (Domain Name System). Diese Updates können sich möglicherweise auf Ihre Anwendung auswirken, wenn Sie auf Daten zugreifen, bevor die Updates abgeschlossen sind. Beim Entwerfen von Anwendungen für ZRS sollten Sie Praktiken zur Bewältigung vorübergehender Fehler befolgen, einschließlich der Implementierung von Wiederholungsrichtlinien mit exponentiellem Zurückfahren.

Eine Schreibanforderung an ein Speicherkonto, das ZRS verwendet, erfolgt synchron. Die Schreibanforderung wird erst dann erfolgreich zurückgegeben, nachdem die Daten in alle Replikate in den drei Verfügbarkeitszonen geschrieben wurden. Wenn eine Verfügbarkeitszone vorübergehend nicht verfügbar ist, gibt der Vorgang den Status „erfolgreich“ zurück, nachdem die Daten in alle verfügbaren Zonen geschrieben wurden.

Microsoft empfiehlt die Verwendung von ZRS in der primären Region für Szenarien, die eine hohe Verfügbarkeit erfordern. Der ZRS wird auch zum Einschränken der Datenreplikation auf eine bestimmte Region empfohlen, um die Anforderungen der Data Governance zu erfüllen.

Microsoft empfiehlt die Verwendung von ZRS für Azure Files Workloads. Wenn eine Zone nicht mehr zur Verfügung steht, ist keine Neueinbindung von Azure-Dateifreigaben auf den verbundenen Clients erforderlich.

Das folgende Diagramm zeigt, wie Ihre Daten mit ZRS über Verfügbarkeitszonen in der primären Region hinweg repliziert werden:

Diagramm, das zeigt, wie Daten über Verfügbarkeitszonen hinweg mit zonenredundantem Speicher-ZRS repliziert werden.

ZRS bietet hervorragende Leistung, geringe Latenz und Resilienz für Ihre Daten, wenn diese vorübergehend nicht verfügbar sind. ZRS selbst kann Ihre Daten jedoch möglicherweise nicht vollständig vor einer regionalen Katastrophe schützen, durch die mehrere Zonen dauerhaft betroffen sind. Geozonenredundanter Speicher (GZRS) verwendet ZRS in der primären Region und repliziert ihre Daten auch in eine sekundäre Region. GZRS ist in vielen Regionen erhältlich und wird zum Schutz vor regionalen Katastrophen empfohlen.

Die Archivebene für Blob Storage wird derzeit nicht für ZRS-, GZRS- oder RA-GZRS-Konten unterstützt. Nicht verwaltete Datenträger unterstützen kein ZRS oder GZRS.

Weitere Informationen dazu, welche Regionen ZRS unterstützen, finden Sie unter Azure Regionen mit Verfügbarkeitszonen.

Redundanz in einer sekundären Region

Redundanzoptionen sorgen für eine hohe Haltbarkeit Ihrer Anwendungen. In vielen Regionen können Sie die Daten innerhalb Ihres Speicherkontos in eine sekundäre Region kopieren, die Hunderte von Kilometern von der primären Region entfernt ist. Das Kopieren Ihres Speicherkontos in eine sekundäre Region stellt sicher, dass Ihre Daten auch bei einem kompletten Ausfall der Region oder einer Katastrophe, bei der die primäre Region nicht wiederhergestellt werden kann, erhalten bleiben.

Wenn Sie ein Speicherkonto erstellen, wählen Sie die primäre Region für das Konto aus. Die gekoppelte sekundäre Region wird basierend auf der primären Region bestimmt und kann nicht geändert werden. Weitere Informationen zu regionen, die von Azure unterstützt werden, finden Sie in der Liste Azure Regionen.

Azure Storage bietet zwei Optionen zum Kopieren Ihrer Daten in eine sekundäre Region:

  • Geo-redundanter Speicher (GRS) kopiert Ihre Daten synchron innerhalb einer oder mehrerer Azure-Verfügbarkeitszonen in der Hauptregion mittels LRS. Anschließend werden die Daten asynchron in die sekundäre Region kopiert. Innerhalb der sekundären Region werden Ihre Daten synchron mit LRS kopiert.

  • Geo-zonenredundanter Speicher (GZRS) kopiert Ihre Daten synchron über drei oder mehr Azure-Verfügbarkeitszonen in der Hauptregion mithilfe von ZRS. Anschließend werden die Daten asynchron in die sekundäre Region kopiert. Innerhalb der sekundären Region werden Ihre Daten synchron mit LRS kopiert.

Hinweis

Der Hauptunterschied zwischen GRS und GZRS besteht in der Art, wie Daten in der primären Region repliziert werden. Innerhalb des sekundären Bereichs werden die Daten stets synchron mittels LRS repliziert. LRS in der sekundären Region schützt Ihre Daten vor Hardwareausfällen.

Wenn du GRS oder GZRS verwendest, sind die Daten in der sekundären Region nicht für Lese- oder Schreibzugriffe verfügbar, es sei denn, es gibt einen Failover in die sekundäre Region. Für den Lesezugriff auf die sekundäre Region konfigurieren Sie Ihr Speicherkonto so, dass es lesezugriffsfähigen georedundanten Speicher (RA-GRS) oder lesezugriffsfähigen geozonenredundanten Speicher (RA-GZRS) verwendet. Weitere Informationen finden Sie unter Lesezugriff auf Daten in der sekundären Region.

Wenn die primäre Region nicht verfügbar ist, können Sie ein Failover in die sekundäre Region ausführen. Nachdem das Failover abgeschlossen ist, wird die sekundäre Region zur primären Region, und Sie können Daten lesen und schreiben. Weitere Informationen zur Notfallwiederherstellung und dazu, wie Sie ein Failover in die sekundäre Region durchführen, finden Sie unter Notfallwiederherstellung und Speicherkontofailover.

Wichtig

Da Daten asynchron in den sekundären Bereich repliziert werden, kann ein Fehler, der sich auf die primäre Region auswirkt, zu Datenverlust führen, wenn die primäre Region nicht wiederhergestellt werden kann. Das Intervall zwischen den letzten Schreibvorgängen in der primären Region und dem letzten Schreibvorgang in der sekundären Region wird als RPO (Recovery Point Objective) bezeichnet. Die RPO gibt den Zeitpunkt an, auf den Daten wiederhergestellt werden können. Azure Storage bietet Geo-Prioritätsreplikation, die sicherstellt, dass die RPO für Block Blobs weniger als oder gleich 15 Minuten liegt. Weitere Informationen finden Sie im Artikel Azure Storage Geo Priority Replication.

Georedundanter Speicher

Geo-redundanter Speicher (GRS) kopiert Ihre Daten synchron in eine oder mehrere Verfügbarkeitszonen in der Hauptregion mithilfe von LRS. Anschließend werden Ihre Daten asynchron in eine sekundäre Region kopiert, die Hunderte von Meilen von der primären Region entfernt ist. GRS bietet eine Zuverlässigkeit von mindestens 99,99999999999999 % (16 Neuner) für Speicherkapazitäten über ein Jahr.

Eine Schreiboperation wird zunächst am primären Standort festgelegt und mittels LRS repliziert. Anschließend wird das Update asynchron in die sekundäre Region repliziert. Wenn Daten an den sekundären Standort geschrieben werden, replizieren sie sich ebenfalls innerhalb dieses Ortes mithilfe von LRS.

Das folgende Diagramm zeigt, wie Ihre Daten mit GRS oder RA-GRS repliziert werden:

Diagramm, das zeigt, wie Daten mit georedundantem Speicher-GRS oder RA-GRS in eine sekundäre Region repliziert werden.

Geozonenredundanter Speicher

Mit geozonenredundantem Speicher (GZRS) wird die Hochverfügbarkeit durch Redundanz über Verfügbarkeitszonen hinweg mit dem Schutz vor regionalen Ausfällen kombiniert, der durch Georeplikation geboten wird. Daten in einem GZRS-Konto werden in drei oder mehr Azure Verfügbarkeitszonen in der primären Region kopiert. Zum Schutz vor regionalen Notfällen werden sie auch in eine sekundäre geografische Region repliziert. Microsoft empfiehlt den Einsatz von GZRS für Anwendungen, die hohe Konsistenz, Haltbarkeit, Verfügbarkeit und Resilienz für die Notfallwiederherstellung benötigen.

Mit einem GZRS-Konto können Sie weiterhin Daten lesen und schreiben, wenn eine Verfügbarkeitszone nicht verfügbar oder nicht wiederherstellbar ist. Außerdem bleiben Ihre Daten auch bei einem regionalen Komplettausfall oder einer Katastrophe, nach der die primäre Region nicht mehr wiederhergestellt werden kann, beständig gespeichert. Der GZRS bietet eine Dauerhaftigkeit von mindestens 99,99999999999999 % (16 Neuner) für Objekte in einem bestimmten Jahr.

Das folgende Diagramm zeigt, wie Ihre Daten mit GZRS oder RA-GZRS repliziert werden:

Diagramm, das zeigt, wie Daten mit geo-zonenredundanten Speicher-GZRS oder RA-GZRS repliziert werden.

Informationen dazu, ob eine Region GZRS unterstützt, finden Sie in der Liste Azure Regionen. Um GZRS zu unterstützen, muss eine Region Verfügbarkeitszonen unterstützen und über eine gekoppelte Region verfügen.

Lesezugriff auf Daten in der sekundären Region

Georedundanter Speicher (mit GRS oder GZRS) repliziert Ihre Daten an einen anderen physischen Standort in der sekundären Region, um sie vor regionalen Ausfällen zu schützen. Wenn ein Konto für GRS oder GZRS konfiguriert ist, können Benutzer*innen oder Anwendungen bei einem Ausfall der primären Region nicht direkt auf die Daten in der sekundären Region zugreifen, es sei denn, es findet ein Failover statt. Der Failoverprozess aktualisiert den von Azure Storage bereitgestellten DNS-Eintrag, sodass die Speicherdienstendpunkte in der sekundären Region zu den neuen primären Endpunkten für Ihr Speicherkonto werden. Während des Failovervorgangs können Sie nicht auf Ihre Daten zugreifen. Nach Abschluss des Failovers können Sie Daten in der neuen primären Region lesen und schreiben. Weitere Informationen finden Sie in wie das Failover eines vom Kunden verwalteten Speicherkontos bei einem Ausfall funktioniert.

Wenn Ihre Anwendungen hohe Verfügbarkeit benötigen, können Sie Ihr Speicherkonto für den Lesezugriff auf die sekundäre Region konfigurieren. Wenn Sie den Lesezugriff auf die sekundäre Region aktivieren, stehen Ihre Daten immer zur Verfügung, um von der sekundären Region gelesen zu werden, auch wenn die primäre Region nicht mehr verfügbar ist. Konfigurationen für georedundanten Speicher mit Lesezugriff (RA-GRS) oder geozonenredundanten Speicher mit Lesezugriff (RA-GZRS) ermöglichen den Lesezugriff auf die sekundäre Region.

Hinweis

Azure Files unterstützt nicht georedundanten Speicher mit Lesezugriff (RA-GRS) oder geozonenredundanten Speicher mit Lesezugriff (RA-GZRS).

Entwerfen von Anwendungen für den Lesezugriff am sekundären Standort

Wenn Ihr Speicherkonto für den Lesezugriff in der sekundären Region konfiguriert ist, können Sie Ihre Anwendungen so entwerfen, dass sie nahtlos zum Lesen von Daten in der sekundären Region wechseln, wenn die primäre Region aus irgendeinem Grund nicht verfügbar ist.

Die sekundäre Region ist für den Lesezugriff verfügbar, nachdem Sie RA-GRS oder RA-GZRS aktiviert haben. Diese Verfügbarkeit ermöglicht es Ihnen, Ihre Anwendung im Voraus zu testen, um sicherzustellen, dass sie während eines Ausfalls ordnungsgemäß von der sekundären Region gelesen wird. Weitere Informationen zum Entwerfen Ihrer Anwendungen zur Nutzung von Georedundanz finden Sie unter Verwenden von Georedundanz, um hoch verfügbare Anwendungen zu entwerfen.

Wenn der Lesezugriff auf den sekundären Endpunkt aktiviert ist, kann Ihre Anwendung sowohl von den sekundären als auch von den primären Endpunkten gelesen werden. Der sekundäre Endpunkt fügt das Suffix -secondary an den Kontonamen an. Zum Beispiel, wenn Ihr primärer Endpunkt für Blob Storage istmyaccount.blob.core.windows.net, dann ist myaccount-secondary.blob.core.windows.netder sekundäre Endpunkt . Die Zugriffsschlüssel für das Speicherkonto sind für die primären und sekundären Endpunkte identisch.

Planen für den Fall von Datenverlusten

Da Daten asynchron vom primären in den sekundären Bereich repliziert werden, liegt der sekundäre Bereich typischerweise hinter dem primären Bereich für Schreiboperationen. Wenn sich in der primären Region eine Katastrophe ereignet, ist es wahrscheinlich, dass einige Daten verloren gehen und dass die Dateien innerhalb eines Verzeichnisses oder Containers nicht mehr konsistent sind. Weitere Informationen zum Planen potenzieller Datenverluste finden Sie unter "Datenverlust" und "Inkonsistenzen".

Zusammenfassung der Redundanzoptionen

Die Tabellen in den folgenden Abschnitten fassen die redundanzoptionen zusammen, die für Azure Storage verfügbar sind.

Parameter für Dauerhaftigkeit und Verfügbarkeit

In der folgenden Tabelle werden die Schlüsselparameter für die einzelnen Redundanzoptionen beschrieben:

Parameter LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Prozentuale Dauerhaftigkeit von Objekten über ein bestimmtes Jahr mindestens 99,999999999 % (11 Neuner) mindestens 99,9999999999 % (12 Neuner) mindestens 99,99999999999999 % (16 Neuner) mindestens 99,99999999999999 % (16 Neuner)
Verfügbarkeit für Leseanforderungen Mindestens 99,9%; 99% für kühle/kalte/Archivzugriffsebenen Mindestens 99,9%; 99% für kühle/kalte Zugangsebene Mindestens 99,9% für GRS; 99% für kühle/kalte/Archivzugriffsebenen

Mindestens 99,99% für RA-GRS; 99.9% für Kühl-/Kalt-/Archivzugriffsstufen
Mindestens 99,9% für GZRS; 99% für kühle/kalte Zugangsebene

Mindestens 99,99% für RA-GZRS; 99,9% für kühle/kalte Zugangsebene
Verfügbarkeit für Schreibanforderungen Mindestens 99,9%; 99% für kühle/kalte/Archivzugriffsebenen Mindestens 99,9%; 99% für kühle/kalte Zugangsebene Mindestens 99,9%; 99% für kühle/kalte/Archivzugriffsebenen Mindestens 99,9%; 99% für kühle/kalte Zugangsebene

Hinweis: GRS stellt eine geografische Replikation bereit, lässt jedoch keinen Lesezugriff aus der sekundären Region zu. Um die Leseverfügbarkeit während eines Ausfalls der primären Region aufrechtzuerhalten, müssen RA-GRS oder RA-GZRS verwendet werden.

Weitere Informationen finden Sie im Service Level Agreement für Speicherkonten.

Dauerhaftigkeit und Verfügbarkeit nach Ausfallszenario

In der folgenden Tabelle wird gezeigt, ob Ihre Daten in einem bestimmten Szenario dauerhaft und verfügbar sind, aufgeschlüsselt nach dem Redundanztyp Ihres Speicherkontos:

Ausfallszenario LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Ein Knoten innerhalb eines Rechenzentrums steht nicht mehr zur Verfügung. Ja Ja Ja Ja
Ein gesamtes Rechenzentrum (zonal oder nicht zonal) fällt aus Nein Ja Ja1 Ja
Ein regionsweiter Ausfall in der primären Region Nein Nein Ja1 Ja1
Wenn die primäre Region nicht verfügbar ist, ist der Lesezugriff in der sekundären Region verfügbar. Nein Nein Ja (mit RA-GRS) Ja (mit RA-GZRS)

1 Ein Kontofailover ist erforderlich, um die Schreibverfügbarkeit wiederherzustellen, wenn die primäre Region nicht mehr verfügbar ist. Weitere Informationen finden Sie unter Notfallwiederherstellung und Speicherkontofailover.

Unterstützte Azure Storage Dienste

In der folgenden Tabelle sind die Redundanzoptionen aufgeführt, die von jedem Azure Storage Dienst unterstützt werden.

Dienstleistung LRS ZRS GRS RA-GRS GZRS RA-GZRS
Blob Storage
(einschließlich Data Lake Storage)
Queuespeicher
Tabellenspeicher
Azure Files 1 1
Azure verwaltete Datenträger 2
Azure Elastic SAN

1 SSD-Dateifreigaben werden in LRS und ZRS unterstützt.
2 ZRS-verwaltete Datenträger haben bestimmte Einschränkungen. Ausführliche Informationen finden Sie im Abschnitt "Einschränkungen " der Redundanzoptionen für verwaltete Datenträger.

Hinweis

Für Speicherkonten, die Smart Tier verwenden, bestehen bei Redundanzkonvertierungen und Kontofailoverszenarien Abhängigkeiten. Weitere Informationen finden Sie unter Optimieren von Kosten mit smarter Ebene

Unterstützte Speicherkontotypen

In der folgenden Tabelle wird gezeigt, welche Redundanzoptionen bei den einzelnen Speicherkontotypen unterstützt werden. Weitere Informationen zu Speicherkontotypen finden Sie unter Speicherkonto-Übersicht.

Speicherkontotypen LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Empfohlen Standard, Universell V2 (StorageV2)1

Premium-Blockblobs (BlockBlobStorage)1

SSD-Dateifreigaben (FileStorage)

Premium-Seitenblobs (StorageV2)
Standard, Universell V2 (StorageV2)1

Premium-Blockblobs (BlockBlobStorage)1

SSD-Dateifreigaben (FileStorage)
Standard, Universell V2 (StorageV2)1 Standard, Universell V2 (StorageV2)1
Hinterlassenschaft Standard, Universell V1 (Storage)

Legacy-Blob (BlobStorage)
n/v Standard, Universell V1 (Storage)

Legacy-Blob (BlobStorage)
n/v

1 Konten dieses Typs mit aktiviertem hierarchischen Namespace unterstützen auch die angegebene Redundanzoption.

Alle Daten für alle Speicherkonten werden gemäß der Redundanzoption für die Speicherkonten vom Primär- zum Sekundärspeicher kopiert. Objekte wie Blockblobs, Anhängeblobs, Seitenblobs, Warteschlangen, Tabellen und Dateien werden kopiert.

Daten in allen Ebenen, einschließlich der Archivebene, werden während der Georeplikation immer von der primären Region in die sekundäre kopiert. Die Archivstufe für Blob Storage wird für LRS-, GRS- und RA-GRS-Konten unterstützt, jedoch nicht für ZRS-, GZRS- oder RA-GZRS-Konten. Weitere Informationen zu Zugriffsebenen für Blob-Daten finden Sie unter Access tiers for blob data.

Nicht verwaltete Datenträger unterstützen kein ZRS oder GZRS.

Preisinformationen für jede Redundanzoption finden Sie unter Azure Storage pricing.

Hinweis

Blockblob-Speicherkonten unterstützen lokal redundanten Speicher (LRS) und zonenredundanten Speicher (ZRS) in bestimmten Regionen.

Datenintegrität

Azure Storage überprüft regelmäßig die Integrität gespeicherter Daten durch zyklische Redundanzprüfungen (CRCs) und repariert erkannte Datenkorruption durch Verwendung redundanter Daten. Azure Storage berechnet auch Prüfsummen für den gesamten Netzwerkdatenverkehr, um Beschädigungen von Datenpaketen beim Speichern oder Abrufen von Daten zu erkennen.

Siehe auch