Snapshot Blob

  • Artikel

Der Snapshot Blob-Vorgang erstellt eine schreibgeschützte Momentaufnahme eines BLOB.

Anforderung

Sie können die Snapshot Blob Anforderung wie folgt erstellen. HTTPS wird empfohlen. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos:

PUT-Methodenanforderungs-URI HTTP-Version
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=snapshot HTTP/1.1

Emulierter Speicherdienst-URI

Wenn Sie eine Anforderung für den emulierten Speicherdienst stellen, geben Sie den Hostnamen des Emulators und Azure Blob Storage Port als 127.0.0.1:10000an, gefolgt vom emulierten Kontonamen:

PUT-Methodenanforderungs-URI HTTP-Version
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=snapshot HTTP/1.1

Weitere Informationen finden Sie unter Verwenden des Azurite-Emulators für lokale Azure Storage-Entwicklung.

URI-Parameter

Sie können den folgenden zusätzlichen Parameter für den Anforderungs-URI angeben.

Parameter BESCHREIBUNG
timeout Optional. Der timeout-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgänge.

Anforderungsheader

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

Anforderungsheader BESCHREIBUNG
Authorization Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Date oder x-ms-date Erforderlich. Gibt die koordinierte Weltzeit (Coordinated Universal Time, UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Erforderlich für alle autorisierten Anforderungen. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
x-ms-meta-name:value Optional. Gibt ein benutzerdefiniertes Name-Wert-Paar an, das dem Blob zugeordnet ist. Wenn Sie keine Namen-Wert-Paare angeben, kopiert der Vorgang die Basisblobmetadaten in die Momentaufnahme. Wenn Sie mindestens ein Name-Wert-Paar angeben, wird die Momentaufnahme mit den angegebenen Metadaten erstellt, und Metadaten werden nicht aus dem Basisblob kopiert.

Beachten Sie, dass Metadatennamen ab Version 2009-09-19 den Benennungsregeln für C#-Bezeichner entsprechen müssen. Weitere Informationen finden Sie unter Benennen und Verweisen auf Container, Blobs und Metadaten .
If-Modified-Since Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um eine Momentaufnahme des Blobs zu übernehmen, nur wenn er seit dem angegebenen Datum/der angegebenen Uhrzeit geändert wurde. Wenn das Basisblob nicht geändert wurde, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück.
If-Unmodified-Since Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um eine Momentaufnahme des Blobs zu übernehmen, nur wenn er seit dem angegebenen Datum/der angegebenen Uhrzeit nicht geändert wurde. Wenn das Basisblob geändert wurde, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück.
If-Match Optional. Ein ETag-Wert. Geben Sie einen ETag Wert für diesen bedingten Header an, um eine Momentaufnahme des Blobs zu übernehmen, nur wenn sein ETag Wert mit dem angegebenen Wert übereinstimmt. Wenn die Werte nicht übereinstimmen, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück.
If-None-Match Optional. Ein ETag-Wert.

Geben Sie einen ETag Wert für diesen bedingten Header an, um eine Momentaufnahme des Blobs zu übernehmen, nur wenn sein ETag Wert nicht mit dem angegebenen Wert übereinstimmt. Wenn die Werte identisch sind, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück.
x-ms-encryption-scope Optional. Gibt den Verschlüsselungsbereich an, der zum Verschlüsseln des Anforderungsinhalts verwendet werden soll. Dieser Header wird ab Version 2019-02-02 unterstützt.
x-ms-lease-id:<ID> Optional. Wenn Sie diesen Header angeben, wird der Vorgang nur ausgeführt, wenn die beiden folgenden Bedingungen erfüllt sind:

– Die Lease des Blobs ist derzeit aktiv.
– Die in der Anforderung angegebene Lease-ID entspricht der des Blobs.

Wenn dieser Header angegeben ist und eine dieser Bedingungen nicht erfüllt ist, schlägt die Anforderung fehl. Der Snapshot Blob Vorgang schlägt mit status Code 412 (Vorbedingung fehlgeschlagen) fehl.
x-ms-client-request-id Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (KiB) bereit, der beim Konfigurieren der Protokollierung in den Protokollen aufgezeichnet wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter Überwachen Azure Blob Storage.

Dieser Vorgang unterstützt auch die Verwendung bedingter Header zum Ausführen des Vorgangs, nur wenn eine angegebene Bedingung erfüllt ist. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob Storage-Vorgänge.

Anforderungsheader (vom Kunden bereitgestellte Verschlüsselungsschlüssel)

Ab Version 2019-02-02 können Sie die folgenden Header für die Anforderung angeben, ein Blob mit einem vom Kunden bereitgestellten Schlüssel zu verschlüsseln. Die Verschlüsselung mit einem vom Kunden bereitgestellten Schlüssel (und der entsprechenden Gruppe von Headern) ist optional. Wenn ein Blob zuvor mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt wurde, müssen diese Header in die Anforderung einbezogen werden, um den Lesevorgang erfolgreich abzuschließen.

Anforderungsheader BESCHREIBUNG
x-ms-encryption-key Erforderlich. Der Base64-codierte AES-256-Verschlüsselungsschlüssel.
x-ms-encryption-key-sha256 Erforderlich. Der Base64-codierte SHA256-Hash des Verschlüsselungsschlüssels.
x-ms-encryption-algorithm: AES256 Erforderlich. Gibt den Algorithmus an, der für die Verschlüsselung verwendet werden soll. Der Wert dieses Headers muss auf AES256 festgelegt sein.

Anforderungstext

Keine.

Antwort

Die Antwort enthält den HTTP-Statuscode und einen Satz von Antwortheadern.

Statuscode

Bei einem erfolgreichen Vorgang wird der Statuscode 201 (Erstellt) zurückgegeben. Informationen zu status Codes finden Sie unter Status- und Fehlercodes.

Antwortheader

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort kann auch zusätzliche HTTP-Standardheader enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Syntax BESCHREIBUNG
x-ms-snapshot: <DateTime> Gibt einen DateTime Wert zurück, der die Momentaufnahme eindeutig identifiziert. Der Wert dieses Headers gibt die Momentaufnahme Version an, und Sie können ihn in nachfolgenden Anforderungen verwenden, um auf die Momentaufnahme zuzugreifen. Beachten Sie, dass dieser Wert nicht transparent ist.
ETag Die ETag der Momentaufnahme. Wenn die Anforderungsversion 2011-08-18 oder höher lautet, wird der ETag Wert in Anführungszeichen angegeben. Beachten Sie, dass ein Momentaufnahme nicht in geschrieben werden kann, sodass sich der ETag eines bestimmten Momentaufnahme nie ändert. Die ETag des Momentaufnahme unterscheidet sich jedoch von dem des Basisblobs, wenn neue Metadaten mit der Snaphot Blob Anforderung bereitgestellt werden. Wenn keine Metadaten mit der Anforderung angegeben werden, ist der ETag des Momentaufnahme identisch mit dem des Basisblobs zum Zeitpunkt der Momentaufnahme.
Last-Modified Die Zeit der letzten Änderung der Momentaufnahme. Weitere Informationen finden Sie unter Darstellung von Datums-/Uhrzeitwerten in Headern.

Beachten Sie, dass ein Momentaufnahme nicht in geschrieben werden kann, sodass sich der Zeitpunkt der letzten Änderung eines bestimmten Momentaufnahme nie ändert. Der Zeitpunkt der letzten Änderung des Momentaufnahme unterscheidet sich jedoch von dem des Basisblobs, wenn neue Metadaten mit der Snaphot Blob Anforderung bereitgestellt werden. Wenn keine Metadaten mit der Anforderung angegeben werden, ist der Zeitpunkt der letzten Änderung des Momentaufnahme identisch mit dem des Basisblobs zum Zeitpunkt der Momentaufnahme.
x-ms-request-id Identifiziert die durchgeführte Anforderung eindeutig und kann für die Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
x-ms-version Gibt die Version von Blob Storage an, die zum Ausführen der Anforderung verwendet wurde. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher erfolgen.
Date Ein UTC-Datums-/Uhrzeitwert, der den Zeitpunkt angibt, zu dem die Antwort initiiert wurde. Der Dienst generiert diesen Wert.
x-ms-request-server-encrypted: true/false Version 2019-02-02 oder höher. Der Wert dieses Headers wird auf truefestgelegt, wenn der Inhalt der Anforderung mithilfe des angegebenen Algorithmus erfolgreich verschlüsselt wurde. Andernfalls wird der Wert auf false festgelegt.
x-ms-encryption-key-sha256 Version 2019-02-02 oder höher. Wird zurückgegeben, wenn die Anforderung einen vom Kunden bereitgestellten Schlüssel für die Verschlüsselung verwendet hat. Der Client kann sicherstellen, dass der Inhalt der Anforderung mithilfe des bereitgestellten Schlüssels erfolgreich verschlüsselt wurde.
x-ms-encryption-scope Version 2019-02-02 oder höher. Wird zurückgegeben, wenn die Anforderung einen Verschlüsselungsbereich verwendet hat. Der Client kann mithilfe des Verschlüsselungsbereichs sicherstellen, dass der Inhalt der Anforderung erfolgreich verschlüsselt wurde.
x-ms-version-id: <DateTime> Version 2019-12-12 und höher. Gibt einen undurchsichtigen DateTime Wert zurück, der das Blob eindeutig identifiziert. Der Wert dieses Headers gibt die Version des Blobs an, und Sie können ihn in nachfolgenden Anforderungen verwenden, um auf das Blob zuzugreifen.
x-ms-client-request-id Kann zur Problembehandlung von Anforderungen und entsprechenden Antworten verwendet werden. Der Wert dieses Headers ist gleich dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist. Der Wert beträgt höchstens 1.024 sichtbare ASCII-Zeichen. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist er in der Antwort nicht vorhanden.

Antworttext

Keine.

Authorization

Beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage ist eine Autorisierung erforderlich. Sie können den Snapshot Blob Vorgang wie unten beschrieben autorisieren.

Azure Storage unterstützt die Verwendung von Microsoft Entra ID zum Autorisieren von Anforderungen für Blobdaten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) verwenden, um einem Sicherheitsprinzipal Berechtigungen zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Azure-Identität sein. Der Sicherheitsprinzipal wird von Microsoft Entra ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann anschließend zum Autorisieren einer Anforderung an den Blob-Dienst verwendet werden.

Weitere Informationen zur Autorisierung mit Microsoft Entra ID finden Sie unter Autorisieren des Zugriffs auf Blobs mithilfe von Microsoft Entra ID.

Berechtigungen

Unten sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra Benutzer, eine Gruppe oder einen Dienstprinzipal erforderlich ist, um den Snapshot Blob Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle mit den geringsten Berechtigungen, die diese Aktion enthält:

Weitere Informationen zum Zuweisen von Rollen mithilfe von Azure RBAC finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf Blobdaten.

Hinweise

Momentaufnahmen stellen schreibgeschützte Versionen von BLOBs bereit. Nachdem Sie eine Momentaufnahme erstellt haben, können Sie ihn lesen, kopieren oder löschen, aber nicht ändern.

Eine Momentaufnahme bietet eine komfortable Möglichkeit zum Sichern von BLOB-Daten. Sie können einen Momentaufnahme verwenden, um ein Blob in einer früheren Version wiederherzustellen, indem Sie Copy Blob aufrufen, um ein Basisblob mit seinem Momentaufnahme zu überschreiben.

Wenn Sie eine Momentaufnahme erstellen, gibt Blob Storage einen DateTime Wert zurück, der die Momentaufnahme relativ zum Basisblob eindeutig identifiziert. Sie können diesen Wert verwenden, um weitere Vorgänge für die Momentaufnahme durchzuführen. Beachten Sie, dass Sie diesen DateTime Wert als undurchsichtig behandeln sollten.

Der DateTime Wert identifiziert die Momentaufnahme für den URI. Beispielsweise ähneln die URIs eines Basis-BLOB und der zugehörigen Momentaufnahmen den folgenden:

  • Basisblob: http://myaccount.blob.core.windows.net/mycontainer/myblob

  • Snapshot: http://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>

Beachten Sie, dass Sie bei jedem Aufruf des Snapshot Blob Vorgangs eine neue Momentaufnahme mit einem eindeutigen DateTime Wert erstellen. Ein BLOB kann eine beliebige Anzahl von Momentaufnahmen unterstützen. Vorhandene Momentaufnahmen werden nie überschrieben. Sie löschen sie explizit, indem Sie Delete Blob aufrufen und den x-ms-include-snapshots Header auf den entsprechenden Wert festlegen.

Ein erfolgreicher Aufruf gibt Snapshot Blob einen DateTime Wert im x-ms-snapshot Antwortheader zurück. Anschließend können Sie mit diesem DateTime Wert Lese-, Lösch- oder Kopiervorgänge für eine bestimmte Momentaufnahme Version ausführen. Sie können jeden Blob Storage-Vorgang aufrufen, der für eine Momentaufnahme gültig ist, indem Sie nach dem Blobnamen angeben?snapshot=<DateTime>.

Wenn Sie eine Momentaufnahme eines BLOB erstellen, werden die folgenden Systemeigenschaften mit denselben Werten in die Momentaufnahme kopiert:

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • x-ms-blob-sequence-number (nur für Seitenblobs)

  • x-ms-blob-committed-block-count (nur für Anfügeblobs)

  • x-ms-copy-id (Version 2012-02-12 und höher)

  • x-ms-copy-status (Version 2012-02-12 und höher)

  • x-ms-copy-source (Version 2012-02-12 und höher)

  • x-ms-copy-progress (Version 2012-02-12 und höher)

  • x-ms-copy-completion-time (Version 2012-02-12 und höher)

  • x-ms-copy-status-description (Version 2012-02-12 und höher)

Die Commitblockliste des Basisblobs wird auch in die Momentaufnahme kopiert, wenn es sich bei dem Blob um ein Blockblob handelt. Nicht signierte Blöcke werden nicht kopiert.

Das Momentaufnahme Blob hat immer die gleiche Größe wie das Basisblob zum Zeitpunkt der Momentaufnahme. Der Wert des Headers Content-Length für das Momentaufnahme-Blob ist identisch mit dem Wert für das Basisblob.

Sie können einen oder mehrere neue Metadatenwerte für die Momentaufnahme angeben, indem Sie den x-ms-meta-name:value-Header für die Anforderung angeben. Wenn dieser Header nicht angegeben wird, werden die Metadaten, die dem Basisblob zugeordnet sind, in das Momentaufnahme kopiert.

Alle Tags, die dem Basisblob zugeordnet sind, werden in die Momentaufnahme kopiert. Es ist nicht möglich, neue Tagwerte für die Momentaufnahme festzulegen.

Sie können bedingte Header für die Anforderung angeben, um eine Momentaufnahme des Blobs zu übernehmen, wenn eine Bedingung erfüllt ist. Wenn die angegebene Bedingung nicht erfüllt ist, wird der Momentaufnahme nicht erstellt. Der Dienst gibt status Code 412 (Vorbedingung fehlgeschlagen) sowie zusätzliche Fehlerinformationen zur nicht erfüllten Bedingung zurück.

Wenn das Basisblob über eine aktive Lease verfügt, können Sie eine Momentaufnahme des Blobs nehmen, solange eine der folgenden Bedingungen für die Anforderung zutrifft:

  • Der bedingte x-ms-lease-id-Header wird angegeben, und die aktive Lease-ID für das Basis-BLOB wird in die Anforderung eingeschlossen. Diese Bedingung gibt an, dass die Momentaufnahme nur erstellt werden, wenn die Lease aktiv ist und die angegebene Lease-ID dem Blob zugeordnet ist.

  • Der x-ms-lease-id Header wird überhaupt nicht angegeben, in diesem Fall wird die Lease für exklusive Schreibvorgänge ignoriert.

Beachten Sie, dass eine dem Basisblob zugeordnete Lease nicht in die Momentaufnahme kopiert wird. Momentaufnahmen können nicht geleast werden.

Wenn Sie ein Basisblob mithilfe des Kopierblobvorgangs kopieren, werden alle Momentaufnahmen des Basisblobs nicht in das Zielblob kopiert. Wenn ein Ziel-BLOB mit einer Kopie überschrieben wird, bleiben alle dem Ziel-BLOB zugeordneten Momentaufnahmen unter dem Namen des BLOB erhalten.

Sie können ein Momentaufnahme-BLOB über das Basis-BLOB kopieren, um eine frühere Version eines BLOB wiederherzustellen. Die Momentaufnahme bleibt erhalten, das Basis-BLOB wird jedoch mit einer Kopie überschrieben, die gelesen und geschrieben werden kann.

Hinweis

Für das Bewerben einer Momentaufnahme fallen keine zusätzlichen Gebühren für Speicherressourcen an. Dies liegt daran, dass Blöcke oder Seiten zwischen dem Momentaufnahme und dem Basisblob freigegeben werden.

Sie können eine Blobebene auf einer Momentaufnahme ab REST-Version 2019-12-12 festlegen. Wenn eine Ebene für ein Stammblob festgelegt ist, erben alle Momentaufnahmen die Ebene vom Basisblob. Ein Momentaufnahme für ein archiviertes Blob schlägt fehl. Das explizite Festlegen der Ebene für ein Objekt führt zur Abrechnung für die vollständige Größe des Objekts. Wenn Sie eine Momentaufnahme eines Blobs verwenden, für das die Ebene festgelegt ist, wird eine vollständige Kopierabrechnung des Stammblobs und des Momentaufnahme. Ausführliche Informationen zum Tiering auf Blockblobebene finden Sie unter Speicherebene heiß, kalt und archivieren.

Es gibt einige Unterschiede zwischen Azure Storage Premium-Konten und Standardspeicherkonten in Bezug auf Momentaufnahmen:

  • Die Anzahl der Momentaufnahmen pro Seitenblob in einem Premium-Speicherkonto ist auf 100 beschränkt. Wenn dieser Grenzwert überschritten wird, gibt der Vorgang den Snapshot Blob Fehlercode 409 (Momentaufnahmeanzahl überschritten) zurück.

  • Sie können alle zehn Minuten eine Momentaufnahme eines Seitenblobs in einem Storage Premium-Konto aufnehmen. Wenn diese Rate überschritten wird, gibt der Vorgang den Snapshot Blob Fehlercode 409 (Momentaufnahmevorgangsrate überschritten) zurück.

  • Sie können einen Momentaufnahme eines Seitenblobs in einem Storage Premium-Konto nicht mithilfe von Get Blob lesen. In dieser Situation gibt der Dienst den Fehlercode 400 (Ungültiger Vorgang) zurück. Sie können jedoch Get Blob Properties (Blobeigenschaften abrufen) und Get Blob Metadata (Blobmetadaten abrufen) für eine Momentaufnahme aufrufen.

    Zum Lesen eines Momentaufnahme können Sie den Kopierblobvorgang verwenden, um eine Momentaufnahme in ein anderes Seitenblob im Konto zu kopieren. Das Ziel-Blob für den Kopiervorgang darf keine vorhandenen Momentaufnahmen besitzen. Wenn das Ziel-BLOB Momentaufnahmen enthält, gibt Copy Blob den Fehlercode 409 (SnapshotsPresent) zurück.

Weitere Informationen finden Sie unter Verwenden von Blob Storage-Vorgängen mit Azure Storage Premium.

Wenn die Versionsverwaltung aktiviert ist, generiert das Erstellen eines Momentaufnahme eines Blobs auch eine neue Version und speichert die vorherige Version des Basisblobs. Der x-ms-version-id Parameter gibt einen undurchsichtigen DateTime Wert für die neue Version des Blobs zurück.

Abrechnung

Preisanforderungen können von Clients stammen, die Blob Storage-APIs verwenden, entweder direkt über die Blob Storage-REST-API oder aus einer Azure Storage-Clientbibliothek. Für diese Anforderungen fallen Gebühren pro Transaktion an. Die Art der Transaktion wirkt sich auf die Belastung des Kontos aus. Beispielsweise werden Lesetransaktionen in eine andere Abrechnungskategorie als das Schreiben von Transaktionen angewendet. Die folgende Tabelle zeigt die Abrechnungskategorie für Snapshot Blob Anforderungen basierend auf dem Speicherkontotyp:

Vorgang Speicherkontotyp Abrechnungskategorie
Snapshot Blob Premium, Blockblob
Standard „Allgemein v2“
Standard „Allgemein v1“		 Dient zum Lesen von Vorgängen.

Weitere Informationen zu Preisen für die angegebene Abrechnungskategorie finden Sie unter Azure Blob Storage Preise.

Weitere Informationen

Erstellen einer Momentaufnahme eines Blobs

Autorisieren von Anforderungen an Azure Storage

Status- und Fehlercodes

Blob Storage-Fehlercodes