Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Unveränderlicher Speicher für Azure Blob Storage ermöglicht es, geschäftskritische Daten in einem WORM-Zustand (Write Once, Read Many) zu speichern. Im WORM-Zustand können Daten für ein vom Benutzer angegebenes Intervall weder geändert noch gelöscht werden. Durch Konfigurieren von Unveränderlichkeitsrichtlinien für Blobdaten können Sie Ihre Daten vor Überschreibungen und Löschungen schützen.
Unveränderlicher Speicher für Azure Blob Storage unterstützt zwei Arten von Unveränderlichkeitsrichtlinien:
Zeitbasierte Aufbewahrungsrichtlinien: Mit einer zeitbasierten Aufbewahrungsrichtlinie können Benutzer Richtlinien zum Speichern von Daten für ein angegebenes Intervall festlegen. Wenn eine zeitbasierte Aufbewahrungsrichtlinie festgelegt wird, können Objekte erstellt und gelesen, aber nicht geändert oder gelöscht werden. Nach Ablauf des Aufbewahrungszeitraums können Objekte gelöscht, aber nicht überschrieben werden.
Rechtliche Aufbewahrungsrichtlinien: Ein rechtlicher Vorbehalt speichert unveränderliche Daten, bis der rechtliche Vorbehalt ausdrücklich aufgehoben wird. Wenn eine Richtlinie zur Aufbewahrung für juristische Zwecke definiert ist, können Objekte erstellt und gelesen, aber nicht geändert oder gelöscht werden.
Sie können diese Policen zusammenstellen. Zum Beispiel können Sie sowohl eine zeitbasierte Aufbewahrungspolitik als auch eine rechtliche Sperre auf derselben Ebene und zur gleichen Zeit festlegen. Damit ein Schreiben erfolgreich ist, müssen Sie entweder die Versionsführung aktiviert haben oder weder eine gesetzliche Sicherung noch eine zeitbasierte Aufbewahrungsrichtlinie für die Daten haben. Damit eine Löschung erfolgreich ist, darf es keine rechtliche Sperre oder zeitbasierte Aufbewahrungspolitik für die Daten geben.
Das folgende Diagramm zeigt, wie zeitbasierte Aufbewahrungsrichtlinien und rechtliche Sperren Schreib- und Löschoperationen während ihrer Gültigkeit verhindern.
Es gibt zwei Funktionen unter dem Oberbegriff der unveränderlichen Speicherung: WORM auf Containerebene und WORM auf Versionsebene. Container-Level WORM erlaubt es, Richtlinien nur auf Containerebene festzulegen, während Versionslevel WORM erlaubt, Richtlinien auf Konto-, Container- oder Versionsebene festzulegen.
Informationen zu unveränderlichem Speicher für Blobs
Unveränderliche Speicherung hilft Gesundheitseinrichtungen, Finanzinstituten und verwandten Branchen (insbesondere Broker-Dealer-Organisationen), Daten sicher zu speichern. Darüber hinaus kann unveränderlicher Speicher in allen Szenarien verwendet werden, in denen kritische Daten vor Änderung oder Löschung geschützt werden sollen.
Beispiele für typische Anwendungen:
Einhaltung gesetzlicher Bestimmungen: Unveränderlicher Speicher für Azure-Blobspeicher unterstützt Organisationen dabei, SEC 17a-4(f), CFTC 1.31(d), FINRA und andere Bestimmungen einzuhalten.
Sichere Dokumentaufbewahrung: Mit unveränderlichem Speicher für Blobs wird sichergestellt, dass Daten selbst dann nicht von Benutzern geändert oder gelöscht werden können, wenn diese über Administratorrechte für ein Konto verfügen.
Rechtliche Sperre: Unveränderliche Speicherung für Blobs ermöglicht es, sensible Informationen, die für Rechtsstreitigkeiten oder geschäftliche Nutzung entscheidend sind, in einem manipulationssicheren Zustand für die gewünschte Dauer zu speichern, bis die Sperre aufgehoben wird. Dieses Feature ist nicht allein auf rechtliche Anwendungsfälle beschränkt, sondern kann auch als ereignisbasierter Aufbewahrungsvorgang oder Unternehmenssperre angesehen werden, wenn Daten basierend auf Ereignisauslösern oder Unternehmensrichtlinien geschützt werden müssen.
Regulierungskonformität
Microsoft hat Cohasset Associates, ein führendes, auf Datensatzverwaltung und Information Governance spezialisiertes Unternehmen für unabhängige Bewertungen, damit beauftragt, unveränderlichen Speicher für Blobs und dessen Konformität mit den spezifischen Anforderungen der Finanzdienstleistungsbranche zu bewerten. Cohasset hat bestätigt, dass die Verwendung von unveränderlichem Speicher für Blobs im WORM-Zustand die relevanten Speicheranforderungen der CFTC-Regel 1.31(c)-(d), der FINRA-Regel 4511 und der SEC-Regel 17a-4(f) erfüllt. Microsoft hat die Einhaltung dieser Regeln angestrebt, da sie die weltweit striktesten Richtlinien zur Aufbewahrung von Datensätzen für Finanzinstitute darstellen.
Der Cohasset-Bericht ist im Microsoft-Dienst Trust Center verfügbar. Ausführliche Informationen zu den Compliancezertifizierungen von Microsoft finden Sie im Azure Trust Center. Wenden Sie sich an den Azure-Support, um einen Nachweis von Microsoft bezüglich der Unveränderlichkeitskonformität von WORM anzufordern.
Zeitbasierte Aufbewahrungsrichtlinien
Über eine zeitbasierte Aufbewahrungsrichtlinie werden Blobdaten im WORM-Format für einen festgelegten Zeitraum gespeichert. Wenn Sie eine zeitbasierte Aufbewahrungsrichtlinie festlegen, können Kunden Blobs erstellen und lesen, aber sie nicht ändern oder löschen. Nach Ablauf des Aufbewahrungsintervalls können Blobs gelöscht, aber nicht überschrieben werden.
Bereich
Sie können eine zeitbasierte Aufbewahrungsrichtlinie in folgenden Bereichen konfigurieren:
- WORM-Richtlinie auf Versionsebene: Konfigurieren Sie eine zeitbasierte Aufbewahrungsrichtlinie auf Konto-, Container- oder Versionsebene (Versionsmanagement muss auf dem Konto aktiviert sein). Wenn du es auf Konto- oder Containerebene konfigurierst, übernehmen alle Blobs im jeweiligen Konto oder Container die Policy. Wenn es eine rechtliche Sperre auf einem Container gibt, kannst du kein versionsbasiertes WORM für denselben Container erstellen. Diese Einschränkung besteht, weil der Legal Hold verhindert, dass die Versionen generiert werden.
- WORM-Richtlinie auf Containerebene: eine zeitbasierte Aufbewahrungsrichtlinie, die auf Containerebene konfiguriert wird und für alle Objekte im entsprechenden Container gilt. Man kann einzelne Blobs nicht mit eigenen Unveränderlichkeitsrichtlinien konfigurieren.
Aufbewahrungszeitraum für eine zeitbasierte Richtlinie
Der kürzeste Aufbewahrungszeitraum für eine zeitbasierte Aufbewahrungsrichtlinie liegt bei einem Tag und der längste bei 146.000 Tagen (400 Jahre). Wenn Sie eine zeitbasierte Aufbewahrungsrichtlinie konfigurieren, bleiben die betroffenen Objekte während des effektiven Aufbewahrungszeitraums im unveränderlichen Zustand. Die Gültigkeit des Aufbewahrungszeitraums für Objekte entspricht der Differenz zwischen der Erstellungszeit des Blobs und dem vom Benutzer angegebenen Aufbewahrungszeitraum. Da der Aufbewahrungszeitraum einer Richtlinie verlängert werden kann, wird für den unveränderlichen Speicher der letzte Wert des vom Benutzer angegebenen Aufbewahrungszeitraums verwendet, um den effektiven Aufbewahrungszeitraum zu berechnen.
Ein Beispiel: Angenommen, der Benutzer erstellt eine zeitbasierte Aufbewahrungsrichtlinie mit einem Aufbewahrungszeitraum von fünf Jahren. Ein in diesem Container vorhandenes Blob (testblob1) wurde vor einem Jahr erstellt. Der effektive Aufbewahrungszeitraum für testblob1 beträgt also vier Jahre. Wenn ein neues Blob (testblob2) in den Container hochgeladen wird, beträgt der effektive Aufbewahrungszeitraum für testblob2 fünf Jahre ab dem Zeitpunkt seiner Erstellung.
Gesperrte und entsperrte Richtlinien
Wenn Sie erstmals eine zeitbasierte Aufbewahrungsrichtlinie konfigurieren, wird die Richtlinie zu Testzwecken entsperrt. Nach Abschluss der Tests können Sie die Richtlinie sperren, damit sie mit SEC 17a-4(f) und anderen gesetzlichen Bestimmungen vollständig konform ist.
Gesperrte und entsperrte Richtlinien schützen vor Lösch- und Überschreibvorgängen. Sie können eine entsperrte Richtlinie jedoch ändern, indem Sie den Aufbewahrungszeitraum verkürzen oder verlängern. Außerdem können Sie eine nicht gesperrte Richtlinie löschen. Sie können eine gesperrte zeitbasierte Aufbewahrungsrichtlinie nicht löschen. Sie können den Aufbewahrungszeitraum verlängern, ihn aber nicht verkürzen. Maximal fünf Verlängerungen des effektiven Aufbewahrungszeitraums sind während der Lebensdauer einer gesperrten Richtlinie zulässig, die auf Containerebene definiert ist. Bei einer Richtlinie, die für eine Blobversion konfiguriert wurde, ist die Anzahl der Verlängerungen des effektiven Zeitraums nicht begrenzt.
Wichtig
Eine zeitbasierte Aufbewahrungsrichtlinie muss gesperrt sein, damit das Blob zur Erzielung von Konformität mit SEC 17a-4(f) und anderen gesetzlichen Bestimmungen in einem konformen unveränderlichen Zustand ist (Schreib- und Löschschutz). Microsoft empfiehlt, die Richtlinie in einem angemessenen Zeitraum zu sperren (in der Regel weniger als 24 Stunden). Obwohl der unveränderliche Zustand Schutz für Unveränderlichkeit bietet, empfehlen wir nicht, den entsperrten Zustand für etwas anderes als kurzfristige Tests zu verwenden.
Überwachungsprotokollierung für Aufbewahrungsrichtlinien
Jeder Container mit aktivierter zeitbasierter Aufbewahrungsrichtlinie umfasst ein Richtlinienüberwachungsprotokoll. Das Überwachungsprotokoll enthält bis zu sieben zeitbasierte Aufbewahrungsbefehle für gesperrte zeitbasierte Aufbewahrungsrichtlinien. Die Protokollierung beginnt in der Regel, nachdem Sie die Richtlinie gesperrt haben. Protokolleinträge enthalten Benutzer-ID, Befehlstyp, Zeitstempel und Aufbewahrungszeitraum. Das Überwachungsprotokoll wird für die Lebensdauer der Richtlinie gemäß den Richtlinien der Verordnung SEC 17a-4(f) aufbewahrt.
Das Azure-Aktivitätsprotokoll bietet ein umfassendes Protokoll aller Verwaltungsdienstaktivitäten. Azure-Ressourcenprotokolle enthalten Informationen zu Datenvorgängen. Sie sind dafür verantwortlich, diese Logs dauerhaft zu speichern, wie es aus regulatorischen oder anderen Gründen erforderlich sein könnte.
Änderungen an zeitbasierten Aufbewahrungsrichtlinien auf Versionsebene werden nicht überwacht.
Gesetzliche Aufbewahrungspflichten
Eine Aufbewahrung für juristische Zwecke ist eine vorübergehende Unveränderlichkeitsrichtlinie, die für juristische Untersuchungszwecke oder allgemeine Schutzrichtlinien angewendet werden kann. Eine rechtliche Sperre speichert Blob-Daten im Write Once, Read Many (WORM)-Format, bis die Sperre ausdrücklich aufgehoben ist. Wenn ein Zeitraum für die Aufbewahrung für juristische Zwecke festgelegt wird, können Blobs erstellt und gelesen, aber nicht geändert oder gelöscht werden. Verwenden Sie eine rechtliche Aufbewahrungssperre, wenn die Dauer, in der die Daten in einem WORM-Zustand aufbewahrt werden müssen, unbekannt ist.
Bereich
Eine Aufbewahrung für juristische Zwecke kann in einem der folgenden Bereiche konfiguriert werden:
WORM-Richtlinie auf Versionsebene: Eine rechtliche Sperre kann auf individueller Blob-Versionsebene für die detaillierte Verwaltung sensibler Daten konfiguriert werden (Versionsmanagement muss im Konto aktiviert sein).
WORM-Richtlinie auf Containerebene: Eine gesetzliche Aufbewahrungspflicht, die auf Containerebene konfiguriert ist, gilt für alle Blobs in diesem Container. Einzelne Blobs können nicht mit ihren eigenen Unveränderlichkeitsrichtlinien konfiguriert werden.
Schlagwörter
Sie müssen eine gesetzliche Aufbewahrungssperre auf Containerebene mit einer oder mehreren benutzerdefinierten alphanumerischen Kennzeichnungen verknüpfen, die als Kennzeichnerzeichenfolgen dienen. Zum Beispiel könnte ein Tag eine Fall-ID oder einen Ereignisnamen enthalten.
Überwachungsprotokollierung
Jeder Container mit einer Aufbewahrungsrichtlinie für juristische Zwecke stellt ein Richtlinienüberwachungsprotokoll bereit. Das Protokoll enthält die Benutzer-ID, den Befehlstypen, die Zeitstempel und die rechtlichen Aufbewahrungstags. Das Überwachungsprotokoll wird für die Lebensdauer der Richtlinie gemäß den Richtlinien der Verordnung SEC 17a-4(f) aufbewahrt.
Das Azure-Aktivitätsprotokoll bietet ein umfassendes Protokoll aller Verwaltungsdienstaktivitäten. Azure-Ressourcenprotokolle enthalten Informationen zu Datenvorgängen. Sie sind dafür verantwortlich, diese Logs dauerhaft zu speichern, wie es aus regulatorischen oder anderen Gründen erforderlich sein könnte.
Änderungen an gesetzliche Aufbewahrungspflichten auf Versionsebene werden nicht geprüft.
Funktionsoptionen des unveränderlichen Speichers
Die folgende Tabelle zeigt eine Aufschlüsselung der Unterschiede zwischen WORM auf Containerebene und WORM auf Versionsebene:
| Kategorie | WORM auf Containerebene | WORM auf Versionsebene |
|---|---|---|
| Granularitätsebene der Richtlinie | Konfigurieren Sie Richtlinien nur auf Containerebene. Jedes Objekt, das du in den Container hochlädst, erbt das unveränderliche Policy-Set. | Konfigurieren Sie Richtlinien auf Konto-, Container- oder Blob-Ebene. Wenn du eine Richtlinie auf Kontoebene einlegst, übernehmen alle Blobs, die du in dieses Konto hochlädst, die Policy. Die gleiche Logik gilt für Container. Wenn du eine Richtlinie auf mehreren Ebenen einlegst, ist die Prärangfolge immer Blob –> Container –> Account. |
| Verfügbare Richtlinientypen | Auf Containerebene werden zwei verschiedene Arten von Richtlinien festgelegt: Zeitbasierte Aufbewahrungsrichtlinien und rechtliche Sperren. | Auf Konto- und Containerebene sollten nur zeitbasierte Aufbewahrungsrichtlinien festgelegt werden. Auf Blob-Ebene sollten sowohl zeitbasierte Aufbewahrungsrichtlinien als auch rechtliche Sicherungen festgelegt werden. |
| Featureabhängigkeiten | Für dieses Feature sind keine anderen Features vorgesehen oder erforderlich. | Die Versionsverwaltung ist eine Voraussetzung für die Verwendung dieses Features. |
| Aktivierung für bestehende Konten und Container | Aktivieren Sie diese Funktion jederzeit für bestehende Container. | Je nach Granularitätsgrad ist diese Funktion möglicherweise nicht für alle bestehenden Konten und Container aktiviert. |
| Löschen von Konten/Containern | Nachdem du eine zeitbasierte Aufbewahrungsrichtlinie für einen Container gesperrt hast, kannst du Container nur löschen, wenn sie leer sind. | Nachdem du Versions-WORM auf Konto- oder Containerebene aktiviert hast, kannst du sie nur löschen, wenn sie leer sind. |
| Unterstützung für Azure Data Lake Storage (Speicherkonten, für die ein hierarchischer Namespace aktiviert wurde) | Unterstützen Sie WORM-Richtlinien auf Containerebene in Konten, die einen hierarchischen Namensraum haben. | WORM-Richtlinien auf Versionsebene werden in Konten mit hierarchischem Namensraum noch nicht unterstützt. |
Um mehr über Container-Level WORM zu erfahren, siehe Container-level WORM Policies. Um mehr über versionsebene WORM zu erfahren, siehe versionsbezogene WORM-Richtlinien.
WORM auf Containerebene vs. auf Versionsebene
Die folgende Tabelle hilft Ihnen bei der Entscheidung, welche Art von WORM-Richtlinie Sie verwenden sollten.
| Kriterien | WORM-Verwendung auf Containerebene | WORM-Verwendung auf Versionsebene |
|---|---|---|
| Organisation von Daten | Du solltest Richtlinien für bestimmte Datensätze festlegen, die du nach Container kategorisieren kannst. Alle Daten in diesem Container müssen für die gleiche Zeitspanne in einem WORM-Zustand gehalten werden. | Sie können Objekte nicht nach Aufbewahrungszeiträumen gruppieren. Alle Blobs müssen mit einer individuellen Aufbewahrungszeit basierend auf den Szenarien dieses Blobs gespeichert werden, sonst gibt es eine gemischte Arbeitslast, sodass einige Datengruppen in Containern gruppiert werden können, während andere Blobs das nicht können. Sie können auch Richtlinien auf Containerniveau und Richtlinien auf Blobniveau innerhalb desselben Kontos festlegen. |
| Menge der Daten, die eine Unveränderlichkeitsrichtlinie erfordern | Sie müssen keine Richtlinien für mehr als 10.000 Container pro Konto festlegen. | Du solltest Richtlinien für alle Daten oder große Datenmengen festlegen, die du nach Konto abgrenzen kannst. Sie wissen bereits, dass Sie, wenn Sie WORM auf Containerebene verwenden, den Grenzwert von 10.000 Containern überschreiten müssen. |
| Interesse an der Aktivierung der Versionsverwaltung | Sie möchten die Versionsverwaltung entweder aus Kostengründen nicht aktivieren oder weil die Workload zahlreiche zusätzliche Versionen erzeugen würde, mit denen Sie umgehen müssten. | Sie möchten entweder die Versionsverwaltung nutzen oder es macht Ihnen nichts aus, sie zu nutzen. Du weißt, dass du, wenn du Versionierung nicht aktivierst, keine Bearbeitungen oder Überschreibungen zu unveränderlichen Blobs als separate Versionen behalten kannst. |
| Speicherort (Blob Storage im Vergleich zu Data Lake Storage) | Ihre Workload ist vollständig auf Azure Data Lake Storage ausgerichtet. Sie haben kein unmittelbares Interesse oder planen nicht, zu einem Konto zu wechseln, bei dem die Funktion für hierarchische Namespaces nicht aktiviert ist. | Ihre Workload befindet sich entweder in einem Blob Storage-Konto, in dem das Feature für hierarchische Namespaces nicht aktiviert ist und WORM auf Versionsebene jetzt genutzt werden kann, oder Sie sind bereit, darauf zu warten, dass die Versionierung für Konten mit aktiviertem hierarchischen Namespace verfügbar wird (Azure Data Lake Storage). |
Zugriffsebenen
Alle Blobzugriffsebenen unterstützen unveränderlichen Speicher. Du kannst die Zugriffsstufe eines Blobs mit der Set Blob Tier-Operation ändern. Weitere Informationen finden Sie unter Zugriffsebenen für Blobdaten.
Redundanzkonfigurationen
Alle Redundanzkonfigurationen unterstützen unveränderlichen Speicher. Weitere Informationen zu Redundanzkonfigurationen finden Sie unter Azure Storage-Redundanz.
Empfohlene Blobtypen
Microsoft empfiehlt, Unveränderlichkeitsrichtlinien hauptsächlich für Blockblobs und Anfügeblobs zu konfigurieren. Die Konfiguration einer Unveränderlichkeitsrichtlinie für einen Page Blob, der eine VHD-Festplatte für eine aktive virtuelle Maschine speichert, wird nicht empfohlen, da Schreibvorgänge auf die Festplatte blockiert werden oder, falls Versionsmanagement aktiviert ist, jeder Schreib als neue Version gespeichert wird. Microsoft empfiehlt, die Dokumentation gründlich durchzugehen und Ihre Szenarios zu testen, bevor Sie zeitbasierte Richtlinien sperren.
Unveränderlicher Speicher bei vorläufigen Löschvorgängen für Blobs
Wenn Sie Blob Soft Delete für ein Speicherkonto konfigurieren, gilt dies für alle Blobs innerhalb des Kontos, unabhängig davon, ob eine gesetzliche Sperre oder eine zeitbasierte Aufbewahrungspolitik gilt. Microsoft empfiehlt, das vorläufige Löschen als zusätzliche Schutzmaßnahme zu aktivieren, bevor Unveränderlichkeitsrichtlinien angewendet werden.
Wenn du Blob Soft Delete aktivierst und dann eine Unveränderlichkeitsrichtlinie konfigurierst, werden alle Blobs, die du bereits soft gelöscht hast, dauerhaft gelöscht, sobald die Soft-Delete-Retention Policy abläuft. Du kannst vorläufig gelöschte Blobs innerhalb des Soft Delete-Aufbewahrungszeitraums wiederherstellen. Ein Blob oder eine Version, die Sie noch nicht vorläufig gelöscht haben, ist durch die Unveränderlichkeitsrichtlinie geschützt und kann erst dann vorläufig gelöscht werden, wenn die zeitbasierte Aufbewahrungsrichtlinie abgelaufen ist oder die rechtliche Aufbewahrungssperre aufgehoben wurde.
Verwenden Sie das Blob-Inventar, um Unveränderlichkeitsrichtlinien nachzuverfolgen.
Der Azure Storage-Blobbestand bietet eine Übersicht über die Container in Ihren Speicherkonten sowie die Blobs, Momentaufnahmen und Blobversionen innerhalb dieser Container. Sie können den Bericht zum Blobbestand nutzen, um sich über die Attribute von Blobs und Containern zu informieren. Diese Informationen umfassen u. a. die Angabe dazu, ob für eine Ressource eine Unveränderlichkeitsrichtlinie konfiguriert ist.
Wenn Sie den Blobbestand aktivieren, generiert Azure Storage täglich einen Bestandsbericht. Der Bericht enthält eine Übersicht über Ihre Daten, die Sie auch für Geschäfts- und Complianceanforderungen nutzen können.
Weitere Informationen zum Blobbestand finden Sie unter Azure Storage-Blobbestand.
Hinweis
Man kann keine Inventarrichtlinie in einem Konto konfigurieren, wenn die Unterstützung für Versionsebene Unveränderlichkeit auf diesem Konto aktiviert ist oder wenn die Unterstützung für Versionsunveränderlichkeit im Zielcontainer aktiviert ist, den Sie in der Inventarrichtlinie definieren.
Konfigurieren von Richtlinien im großen Stil
Sie können eine Speicheraufgabe verwenden, um Unveränderlichkeitsrichtlinien in großem Maßstab über mehrere Speicherkonten hinweg zu konfigurieren, basierend auf einer von Ihnen definierten Bedingungsmenge. Eine Speicheraufgabe ist eine Ressource, die in Azure Speichervorgänge verfügbar ist. Dies ist ein serverloses Framework, mit dem Sie allgemeine Datenvorgänge für Millionen von Objekten über mehrere Speicherkonten hinweg ausführen können. Weitere Informationen finden Sie unter Was ist Azure Storage Actions?
Preiskalkulation
Für die Verwendung von unveränderlichem Speicher fällt keine zusätzliche Kapazitätsgebühr an. Unveränderliche Daten werden auf die gleiche Weise abgerechnet wie änderbare Daten. Wenn du versionsbasiertes WORM verwendest, könnte die Rechnung höher sein, weil du die Versionsführung aktiviert hast, und es entstehen Kosten für zusätzliche Versionen, die gespeichert werden. Weitere Informationen finden Sie in den Preisrichtlinien für die Versionsverwaltung. Ausführliche Informationen zu Preisen von Azure Blob Storage finden Sie auf der Seite mit den Preisen für Azure Storage.
Beim Erstellen oder Löschen einer zeitbasierten Aufbewahrungsrichtlinie oder einer Richtlinie zur Aufbewahrung für juristische Zwecke für eine Blobversion fällt eine Gebühr für Schreibtransaktionen an. Die Änderung einer zeitbasierten Aufbewahrungsrichtlinie (entweder durch Sperren oder Verlängern) führt zu einer Gebühr für andere Operationen. Weitere Informationen zu Transaktionsgebühren finden Sie unter Betrieb und Datenübertragung.
Wenn Sie Ihre Rechnung nicht begleichen und Ihr Konto über eine aktive zeitbasierte Aufbewahrungsrichtlinie verfügt, werden die normalen Datenaufbewahrungsrichtlinien gemäß den Bestimmungen Ihres Vertrags mit Microsoft angewendet. Weitere Informationen finden Sie unter Datenverwaltung bei Microsoft.
Featureunterstützung
Wichtig
Dieses Feature ist nicht mit der Zeitwiederherstellung und der Nachverfolgung des letzten Zugriffs kompatibel.
Diese Funktion ist kompatibel mit kundengesteuerten ungeplanten Failovers. Allerdings werden alle Änderungen, die du nach der letzten Synchronisationszeit an der unveränderlichen Richtlinie vornimmst (wie das Sperren einer zeitbasierten Aufbewahrungsrichtlinie oder deren Verlängerung), nicht auf die sekundäre Region synchronisiert. Nach Abschluss des Failovers können Sie die Änderungen in der sekundären Region erneut vornehmen, um sicherzustellen, dass sie gemäß Ihren Anforderungen an die Unveränderlichkeit auf dem neuesten Stand ist. Unveränderlichkeitsrichtlinien werden in Konten, für die das NFS 3.0-Protokoll (Network File System, Netzwerkdateisystem) oder SFTP (SSH File Transfer Protocol, SSH-Dateiübertragungsprotokoll) aktiviert ist, nicht unterstützt.
Einige Workloads, z. B. SQL Server-Sicherung über URLs, erstellen ein Blob und fügen es dann hinzu. Wenn ein Container eine aktive zeitbasierte Aufbewahrungspolitik oder eine rechtliche Sperre hat, funktioniert dieses Muster nicht. Weitere Informationen finden Sie unter Zulassen von Schreibvorgängen in geschützten Anfügeblobs.
Weitere Informationen finden Sie unter Unterstützung der Blob Storage-Features in Azure Storage-Konten.