Ta bort blob

Åtgärden Undelete Blob återställer innehållet och metadata för en mjukt borttagen blob och eventuella associerade mjukt borttagna ögonblicksbilder.

Undelete Blob stöds endast i version 2017-07-29 eller senare.

Förfrågan

Du kan skapa begäran på Undelete Blob följande sätt. HTTPS rekommenderas. Ersätt myaccount med namnet på ditt lagringskonto.

URI för PUT-metodbegäran	HTTP-version
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=undelete	HTTP/1.1

Emulerad lagringstjänst-URI

När du gör en begäran mot den emulerade lagringstjänsten anger du emulatorns värdnamn och Azure Blob Storage port som 127.0.0.1:10000, följt av namnet på det emulerade lagringskontot.

URI för PUT-metodbegäran	HTTP-version
http://127.0.0.1:10000/ devstoreaccount1/mycontainer/myblob?comp=undelete	HTTP/1.1

Mer information finns i Använda Azurite-emulatorn för lokal Azure Storage-utveckling.

URI-parametrar

Du kan ange följande ytterligare parameter i begärande-URI:n.

Parameter	Beskrivning
timeout	Valfritt. Parametern timeout uttrycks i sekunder. Mer information finns i Ställa in tidsgränser för Blob Storage-åtgärder.

Begärandehuvuden (alla blobtyper)

I följande tabell beskrivs obligatoriska och valfria begärandehuvuden för alla blobtyper.

Begärandehuvud	Beskrivning
Authorization	Krävs. Anger auktoriseringsschema, kontonamn och signatur. Mer information finns i Auktorisera begäranden till Azure Storage.
Date eller x-ms-date	Krävs. Anger Coordinated Universal Time (UTC) för begäran. Mer information finns i Auktorisera begäranden till Azure Storage.
x-ms-version	Krävs för alla auktoriserade begäranden. Anger vilken version av åtgärden som ska användas för den här begäran. Mer information finns i Versionshantering för Azure Storage-tjänsterna.
x-ms-undelete-source	Valfritt. Version 2020-08-04 och senare. Endast för konton som är aktiverade med hierarkisk namnrymd. Sökvägen till den mjukt borttagna bloben som ska tas bort. Formatet är blobPath?deletionid=<id>. Kontot och containernamnet ingår inte i sökvägen. DeletionId är den unika identifieraren för den mjukt borttagna bloben. Du kan hämta den genom att visa en lista över mjukt borttagna blobar med REST-API:et List Blobs för konton som aktiveras med hierarkiskt namnområde. Sökvägen ska vara procentkodad.
x-ms-client-request-id	Valfritt. Tillhandahåller ett klientgenererat, täckande värde med en teckengräns på 1 kibibyte (KiB) som registreras i loggarna när loggning har konfigurerats. Vi rekommenderar starkt att du använder det här huvudet för att korrelera aktiviteter på klientsidan med begäranden som servern tar emot. Mer information finns i Övervaka Azure Blob Storage.

Begärandetext

Inga.

Svarsåtgärder

Svaret innehåller en HTTP-statuskod och en uppsättning svarshuvuden.

Statuskod

En lyckad åtgärd returnerar statuskod 200 (OK). Information om statuskoder finns i Status och felkoder.

Svarshuvuden

Svaret för den här åtgärden innehåller följande rubriker. Svaret kan även innehålla ytterligare STANDARD HTTP-huvuden. Alla standardhuvuden överensstämmer med http/1.1-protokollspecifikationen.

Syntax	Description
x-ms-request-id	Det här huvudet identifierar unikt den begäran som har gjorts och kan användas för att felsöka begäran. Mer information finns i Felsöka API-åtgärder.
x-ms-version	Anger vilken version av Blob Storage som används för att köra begäran.
Date	Ett datum-/tidsvärde för UTC som anger den tid då svaret initierades. Tjänsten genererar det här värdet.
x-ms-client-request-id	Du kan använda det här huvudet för att felsöka begäranden och motsvarande svar. Värdet för det här huvudet är lika med värdet för x-ms-client-request-id huvudet, om det finns i begäran. Värdet är högst 1 024 synliga ASCII-tecken. Om rubriken x-ms-client-request-id inte finns i begäran kommer det här huvudet inte att finnas i svaret.

Själva svaret

Inga.

Auktorisering

Auktorisering krävs när du anropar en dataåtkomståtgärd i Azure Storage. Du kan auktorisera åtgärden enligt beskrivningen Undelete Blob nedan.

Microsoft Entra ID

Azure Storage stöder användning av Microsoft Entra ID för att auktorisera begäranden till blobdata. Med Microsoft Entra ID kan du använda rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att bevilja behörigheter till ett säkerhetsobjekt. Säkerhetsobjektet kan vara en användare, grupp, programtjänstens huvudnamn eller en hanterad Azure-identitet. Säkerhetsobjektet autentiseras av Microsoft Entra ID för att returnera en OAuth 2.0-token. Token kan sedan användas för att auktorisera en begäran mot Blob-tjänsten.

Mer information om auktorisering med Microsoft Entra ID finns i Auktorisera åtkomst till blobar med hjälp av Microsoft Entra ID.

Behörigheter

Nedan visas den RBAC-åtgärd som krävs för att en Microsoft Entra användare, grupp eller tjänstens huvudnamn ska kunna anropa Undelete Blob åtgärden och den minst privilegierade inbyggda Azure RBAC-rollen som innehåller den här åtgärden:

• Azure RBAC-åtgärd:Microsoft.Storage/storageAccounts/blobServices/containers/write
• Minsta privilegierade inbyggda roll:Storage Blob Data-deltagare

Mer information om hur du tilldelar roller med hjälp av Azure RBAC finns i Tilldela en Azure-roll för åtkomst till blobdata.

Signaturer för delad åtkomst (SAS)

En signatur för delad åtkomst (SAS) ger säker delegerad åtkomst till resurser i ett lagringskonto. Med en SAS har du detaljerad kontroll över hur en klient kan komma åt data. Du kan ange vilken resurs klienten får åtkomst till, vilka behörigheter de har till dessa resurser och hur länge SAS är giltig.

Åtgärden Undelete Blob stöder tre typer av signaturer för delad åtkomst: SAS för användardelegering, tjänst-SAS och konto-SAS.

Vi rekommenderar att du använder Microsoft Entra autentiseringsuppgifter i stället för lagringskontonyckeln, vilket är enklare att kompromettera. Om din programdesign kräver signaturer för delad åtkomst använder du Microsoft Entra autentiseringsuppgifter för att skapa en SAS för användardelegering när det är möjligt.

När åtkomst med delad nyckel inte tillåts för lagringskontot tillåts inte en SAS-token för tjänsten eller en SAS-token för kontot på en begäran till Blob Storage. Mer information finns i Förstå hur nekande av delad nyckel påverkar SAS-token.

SAS för användardelegering

En SAS för användardelegering skyddas med Microsoft Entra autentiseringsuppgifter och även av de behörigheter som anges för SAS.

Undelete Blob Att anropa åtgärden med en SAS-token som delegerats till en containerresurs kräver skrivbehörigheten (w) som en del av SAS-token för användardelegering.

Mer information om SAS för användardelegering finns i Skapa en SAS för användardelegering.

Tjänst-SAS

En tjänst-SAS skyddas med lagringskontonyckeln. En tjänst-SAS delegerar åtkomst till en resurs i en enda Azure Storage-tjänst, till exempel bloblagring.

Undelete Blob Att anropa åtgärden med en SAS-token som delegerats till en containerresurs kräver skrivbehörigheten (w) som en del av tjänstens SAS-token.

Mer information om tjänstens SAS finns i Skapa en tjänst-SAS.

Konto-SAS

Ett konto-SAS skyddas med lagringskontonyckeln. En konto-SAS delegerar åtkomst till resurser i en eller flera av lagringstjänsterna. Alla åtgärder som är tillgängliga via en sas för tjänst- eller användardelegering är också tillgängliga via ett konto-SAS.

Följande tabell anger den signerade resurstypen och de signerade behörigheter som ska anges när åtkomst delegeras:

Åtgärd	Signerad tjänst	Signerad resurstyp	Signerad behörighet
Ta bort blob	Blob (b)	Container (c)	Skriva (w)

Mer information om kontots SAS finns i Skapa ett konto-SAS.

Delad nyckel

Åtgärden Undelete Blob stöder auktorisering med delad nyckel. Auktorisering med kontonycklar rekommenderas inte för de flesta scenarier, eftersom det är mindre säkert.

Microsoft rekommenderar att du inte tillåter auktorisering av delad nyckel för lagringskontot när det är möjligt. Mer information finns i Förhindra auktorisering med delad nyckel.

Kommentarer

När du tar bort en mjuk borttagningsblob är bloben och eventuella associerade ögonblicksbilder tillgängliga för åtgärder med hjälp av andra API:er. När du tar bort en blob som inte tas bort mjukt eller inte har några mjukt borttagna ögonblicksbilder, lyckas åtgärden utan några ändringar.

Fakturering

Prisbegäranden kan komma från klienter som använder Blob Storage-API:er, antingen direkt via REST-API:et för Blob Storage eller från ett Azure Storage-klientbibliotek. Dessa begäranden ackumulerar avgifter per transaktion. Typen av transaktion påverkar hur kontot debiteras. Lästransaktioner ackumuleras till exempel till en annan faktureringskategori än skrivtransaktioner. I följande tabell visas faktureringskategorin för Undelete Blob begäranden baserat på lagringskontotypen:

Åtgärd	Typ av lagringskonto	Faktureringskategori
Ta bort blob	Premium-blockblob Standard generell användning v2 Standard generell användning v1	Skrivåtgärder

Mer information om priser för den angivna faktureringskategorin finns i Azure Blob Storage Prissättning.

Se även

Auktorisera begäranden till Azure Storage
Status och felkoderTa bort blob