Blob löschen

Der Delete Blob Vorgang löscht das angegebene Blob oder die Momentaufnahme.

Beachten Sie, dass Sie zum Löschen eines Blobs alle zugehörigen Momentaufnahmen löschen müssen. Sie können beide gleichzeitig mit dem Delete Blob Vorgang löschen.

Anfrage

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

Anforderungs-URI der DELETE-Methode	HTTP-Version
`https://myaccount.blob.core.windows.net/mycontainer/myblob` `https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>` `https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>`	HTTP/1.1

Emulierter Speicherdienst-URI

Wenn Sie eine Anforderung an den emulierten Speicherdienst senden, geben Sie den Hostnamen des Emulators und den Azure Blob Storage-Port als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos.

Anforderungs-URI der DELETE-Methode	HTTP-Version
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob`	HTTP/1.1

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

URI-Parameter

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

Parameter	Description
`snapshot`	Wahlfrei. Der snapshot-Parameter ist ein nicht transparenter `DateTime` Wert, der, wenn er vorhanden ist, die zu löschende Blobmomentaufnahme angibt. Weitere Informationen zum Arbeiten mit Blobmomentaufnahmen finden Sie unter Erstellen einer Momentaufnahme eines Blobs.
`versionid`	Optional, Version 2019-12-12 und höher. Bei dem `versionid` Parameter handelt es sich um einen nicht transparenten `DateTime` Wert, der, sofern vorhanden, die Version des zu löschenden Blobs angibt.
`timeout`	Wahlfrei. Der `timeout` Parameter wird in Sekunden ausgedrückt. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgänge.
`deletetype`	Optional, Version 2020-02-10 oder höher. Der Wert von `deletetype` kann nur sein `permanent`.

Anforderungsheader

In der folgenden Tabelle werden die erforderlichen und optionalen Anforderungsheader beschrieben.

Anforderungs-Kopfzeile	Description
`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 (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 Anfragen. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure Storage-Dienste.
`x-ms-lease-id:<ID>`	Erforderlich, wenn das Blob über eine aktive Pacht verfügt. Um diesen Vorgang für ein Blob mit einer aktiven Lease auszuführen, geben Sie die gültige Lease-ID für diesen Header an. Wenn dieser Header in der Anforderung nicht angegeben ist, gibt Blob Storage den Statuscode 412 (`LeaseIdMissing`Vorbedingung fehlgeschlagen) zurück. Wenn in der Anforderung eine falsch formatierte Lease-ID angegeben wird, schlägt der Vorgang mit dem Statuscode 400 (`InvalidHeaderValue`, Ungültige Anforderung) fehl. Wenn eine ordnungsgemäß formatierte Lease-ID angegeben wird, die angegebene Lease-ID jedoch nicht dem Blob zugeordnet ist, schlägt der Vorgang mit dem Statuscode 412 fehl (`LeaseIdMismatchWithBlobOperation` Vorbedingung fehlgeschlagen)
`x-ms-delete-snapshots: {include, only}`	Erforderlich, wenn das Blob Momentaufnahmen zugeordnet hat. Geben Sie eine der folgenden Optionen an: - `include`: Löschen Sie das Basisblob und alle zugehörigen Momentaufnahmen. - `only`: Löscht nur die Momentaufnahmen des Blobs und nicht das Blob selbst. Geben Sie diesen Header nur für eine Anforderung an die Basisblobressource an. Wenn dieser Header in einer Anforderung zum Löschen einer einzelnen Momentaufnahme angegeben wird, gibt Blob Storage den Statuscode 400 (Ungültige Anforderung) zurück. Wenn dieser Header in der Anforderung nicht angegeben ist und dem Blob Momentaufnahmen zugeordnet sind, gibt Blob Storage den Statuscode 409 (Konflikt) zurück.
`x-ms-client-request-id`	Wahlfrei. Stellt einen vom Client generierten, undurchsichtigen Wert mit einer Zeichenbeschränkung von 1 Kibibyte (KiB) bereit, der in den Protokollen aufgezeichnet wird, wenn die Protokollierung konfiguriert 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 von Azure Blob Storage.

Dieser Vorgang unterstützt auch die Verwendung von bedingten Headern, um das Blob nur dann zu löschen, wenn eine angegebene Bedingung erfüllt ist. Weitere Informationen finden Sie unter Angeben bedingter Header für Blob Storage-Vorgänge.

Anfragekörper

Keiner.

Antwort

Die Antwort enthält einen HTTP-Statuscode und eine Reihe von Antwortheadern.

Statuscode

Ein erfolgreicher Vorgang gibt den Statuscode 202 (Akzeptiert) zurück. Weitere Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.

Antwortkopfzeilen

Die Antwort für diesen Vorgang enthält die folgenden Header. Die Antwort kann auch zusätzliche, standardmäßige HTTP-Header enthalten. Alle Standard-Header entsprechen der HTTP/1.1-Protokollspezifikation.

Header der Antwort	Description
`x-ms-request-id`	Dieser Header identifiziert die gestellte Anforderung eindeutig und kann für die Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung bei API-Vorgängen.
`x-ms-version`	Gibt die Version von Blob Storage an, die zum Ausführen der Anforderung verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher gestellt werden.
`x-ms-delete-type-permanent`	Für Version 2017-07-29 und höher gibt Blob Storage zurück `true` , ob das Blob dauerhaft gelöscht wurde und `false` ob das Blob vorläufig gelöscht wurde.
`Date`	Ein UTC-Wert für Datum/Uhrzeit, der den Zeitpunkt angibt, zu dem die Antwort initiiert wurde. Der Dienst generiert diesen Wert.
`x-ms-client-request-id`	Sie können diesen Header verwenden, um Probleme mit Anforderungen und entsprechenden Antworten zu beheben. Der Wert dieses Headers entspricht dem Wert des Headers `x-ms-client-request-id` , wenn er in der Anforderung vorhanden ist. Der Wert beträgt maximal 1.024 sichtbare ASCII-Zeichen. Wenn der `x-ms-client-request-id` Header in der Anforderung nicht vorhanden ist, ist dieser Header in der Antwort nicht vorhanden.

Autorisierung

Eine Autorisierung ist erforderlich, wenn ein Datenzugriffsvorgang in Azure Storage aufgerufen wird. Sie können den Delete Blob Vorgang wie unten beschrieben autorisieren.

Von Bedeutung

Microsoft empfiehlt die Verwendung der Microsoft Entra ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Microsoft Entra ID bietet im Vergleich zur Autorisierung mit gemeinsam verwendeten Schlüsseln überlegene Sicherheit und Benutzerfreundlichkeit.

Azure Storage unterstützt die Verwendung der Microsoft Entra-ID zum Autorisieren von Anforderungen an BLOB-Daten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) verwenden, um einem Sicherheitsprinzipal Berechtigungen zu erteilen. Bei dem Sicherheitsprinzipal kann es sich um einen Benutzer, eine Gruppe, einen Anwendungsdienstprinzipal oder eine verwaltete Azure-Identität handeln. Der Sicherheitsprinzipal wird von Microsoft Entra ID authentifiziert, und gibt ein OAuth 2.0-Token zurück. Das Token kann dann verwendet werden, um eine Anforderung gegen den Blob-Dienst zu autorisieren.

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

Erlaubnisse

Im Folgenden sind die RBAC-Aktion aufgeführt, die erforderlich ist, damit ein Microsoft Entra-Benutzer, eine Gruppe, eine verwaltete Identität oder ein Dienstprinzipal den Delete Blob Vorgang aufrufen kann, sowie die integrierte Azure RBAC-Rolle mit den geringsten Berechtigungen, die diese Aktion umfasst:

Azure RBAC-Aktion:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
Integrierte Rolle mit den geringsten Berechtigungen:Mitwirkender an Storage-Blobdaten

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

Eine Shared Access Signature (SAS) bietet sicheren delegierten Zugriff auf Ressourcen in einem Speicherkonto. Mit einer SAS haben Sie eine detaillierte Kontrolle darüber, wie ein Client auf Daten zugreifen kann. Sie können angeben, auf welche Ressource der Client zugreifen darf, welche Berechtigungen er für diese Ressourcen hat und wie lange die SAS gültig ist.

Der Delete Blob Vorgang unterstützt drei Arten von Shared Access Signatures: SAS für die Benutzerdelegierung, Dienst-SAS und Konto-SAS.

Aus Sicherheitsgründen wird empfohlen, dass Sie Microsoft Entra Anmeldeinformationen anstelle des Speicherkontoschlüssels verwenden, der leichter kompromittiert werden kann. Wenn Ihr Anwendungsentwurf Shared Access Signatures erfordert, verwenden Sie nach Möglichkeit Microsoft Entra Anmeldeinformationen, um eine SAS für die Benutzerdelegierung zu erstellen.

Wenn der Zugriff auf gemeinsam verwendete Schlüssel für das Speicherkonto nicht zulässig ist, ist ein Dienst-SAS-Token oder ein Konto-SAS-Token für eine Anforderung an Blob Storage nicht zulässig. Weitere Informationen finden Sie unter Verstehen, wie sich das Deaktivieren von Shared Key auf SAS-Token auswirkt.

SAS für die Benutzerdelegierung

Eine SAS für die Benutzerdelegierung wird mit Microsoft Entra-Anmeldeinformationen und auch durch die für die SAS angegebenen Berechtigungen geschützt.

Für den Aufruf des Vorgangs mithilfe eines SAS-Tokens, das Delete Blob an eine Container- oder Blobressource delegiert wurde, ist die Berechtigung Löschen (d) als Teil des SAS-Tokens für die Benutzerdelegierung erforderlich.

Weitere Informationen zur SAS für die Benutzerdelegierung finden Sie unter Erstellen einer SAS für die Benutzerdelegierung.

Dienst-SAS

Eine Dienst-SAS wird mit dem Speicherkontoschlüssel gesichert. Eine Dienst-SAS delegiert den Zugriff auf eine Ressource in einem einzelnen Azure Storage-Dienst, z. B. Blob Storage.

Für das Aufrufen des Vorgangs mithilfe eines SAS-Tokens, das Delete Blob an eine Container- oder Blobressource delegiert wurde, ist die Berechtigung Löschen (d) als Teil des Dienst-SAS-Tokens erforderlich.

Weitere Informationen zur Dienst-SAS finden Sie unter Erstellen einer Dienst-SAS.

Konto SAS

Eine Konto-SAS wird mit dem Schlüssel des Speicherkontos gesichert. Ein Konto SAS delegiert den Zugriff auf Ressourcen in einem oder mehreren Speicherdiensten. Alle Vorgänge, die über eine Dienst- oder Benutzerdelegierungs-SAS verfügbar sind, sind auch über eine Konto-SAS verfügbar.

In der folgenden Tabelle sind der signierte Ressourcentyp und die signierten Berechtigungen aufgeführt, die beim Delegieren des Zugriffs angegeben werden sollen:

Operation	Signierter Service	Signierter Ressourcentyp	Signierte Berechtigung
Blob löschen	Klecks (b)	Objekt (o)	Buchstabe d streichen

Weitere Informationen zur Konto-SAS finden Sie unter Erstellen einer Konto-SAS.

Der Delete Blob Vorgang unterstützt die Autorisierung von gemeinsam verwendeten Schlüsseln. Die Autorisierung mit Kontoschlüsseln wird für die meisten Szenarien nicht empfohlen, da sie weniger sicher ist.

Microsoft empfiehlt, die Autorisierung von gemeinsam verwendeten Schlüsseln für das Speicherkonto nach Möglichkeit nicht zuzulassen. Weitere Informationen finden Sie unter Verhindern der Autorisierung mit gemeinsam verwendetem Schlüssel.

Bemerkungen

Wenn das Blob über eine aktive Lease verfügt, muss der Client eine gültige Lease-ID für die Anforderung angeben, um sie zu löschen.

Wenn ein Blob über eine große Anzahl von Momentaufnahmen verfügt, ist es möglich, dass für den Delete Blob Vorgang ein Timeout auftritt. In diesem Fall sollte der Client die Anforderung wiederholen.

Für Version 2013-08-15 und höher kann der Client aufrufen Delete Blob , um nicht committete Blobs zu löschen. Ein Blob ohne Commit ist ein Blob, das mit Aufrufen des Put Block-Vorgangs erstellt, aber nie mit dem Put Block List-Vorgang ausgeführt wurde. Bei früheren Versionen muss der Client zuerst einen Commit für das Blob ausführen, bevor er es löscht.

Funktion für vorläufiges Löschen deaktiviert

Wenn ein Blob erfolgreich gelöscht wurde, wird es sofort aus dem Index des Speicherkontos entfernt, und Clients können nicht mehr darauf zugreifen.

Funktion für vorläufiges Löschen aktiviert

Wenn ein Blob erfolgreich gelöscht wurde, wird es vorläufig gelöscht, und Clients können nicht mehr darauf zugreifen. Blob Storage behält das Blob oder die Momentaufnahme für die Anzahl von Tagen bei, die für die DeleteRetentionPolicy Eigenschaft von Blob Storage angegeben ist. Informationen zum Lesen von Blob Storage-Eigenschaften finden Sie unter Festlegen von Blob Storage-Eigenschaften.

Nach der angegebenen Anzahl von Tagen werden die Daten des Blobs aus dem Dienst entfernt. Sie können auf ein vorläufig gelöschtes Blob oder eine Momentaufnahme zugreifen, indem Sie den List Blobs-Vorgang aufrufen und die include=deleted Option angeben.

Sie können vorläufig gelöschte Blobs oder Momentaufnahmen wiederherstellen, indem Sie die Option Blob wiederherstellen verwenden. Für jeden anderen Vorgang für vorläufig gelöschte Blobs oder Momentaufnahmen gibt Blob Storage den Fehler 404 (Ressource nicht gefunden) zurück.

Dauerhaft löschen

Mit Version 2020-02-10 und höher können Sie einen vorläufig gelöschten Snapshot oder eine vorgefertigte Version dauerhaft löschen. Dazu aktivieren Sie die Funktion. Weitere Informationen finden Sie unter Festlegen von Blob Storage-Eigenschaften.

Hinweis

Für das Speicherkonto müssen die Versionsverwaltung oder Momentaufnahmen aktiviert sein. Das vorläufige Löschen muss auch für das Speicherkonto aktiviert sein, um Versionen oder Momentaufnahmen von Blobs im Konto vorläufig zu löschen. Beim dauerhaften Löschen werden nur vorläufig gelöschte Snapshots oder Versionen gelöscht.

Speicherkonten, für die das endgültige Löschen aktiviert ist, können den deletetype=permanent Abfrageparameter verwenden, um eine vorläufig gelöschte Momentaufnahme oder eine gelöschte Blobversion dauerhaft zu löschen.

Wenn der Abfrageparameter eine der folgenden Eigenschaften aufweist, gibt Blob Storage den Fehler 409 (Konflikt) zurück:

Das Feature zum dauerhaften Löschen ist für das Speicherkonto nicht aktiviert.
Weder noch versionidsnapshot werden sie zur Verfügung gestellt.
Der angegebene Snapshot oder die angegebene Version wird nicht vorläufig gelöscht.

Das endgültige Löschen umfasst auch eine SAS-Berechtigung zum dauerhaften Löschen einer Blobmomentaufnahme oder Blobversion. Weitere Informationen finden Sie unter Erstellen einer Dienst-SAS.