Versionshantering av blobar

Artikel
11/18/2021
16 minuter för att läsa

Du kan aktivera versionshantering för Blob Storage för att automatiskt underhålla tidigare versioner av ett objekt. När versionshantering av blobar är aktiverat kan du återställa en tidigare version av en blob för att återställa dina data om de har ändrats eller tagits bort felaktigt.

Rekommenderad dataskyddskonfiguration

Versionshantering av blobar är en del av en omfattande dataskyddsstrategi för blobdata. För optimalt skydd för dina blobdata rekommenderar Microsoft att du aktiverar alla följande dataskyddsfunktioner:

Versionshantering av blobar för att automatiskt underhålla tidigare versioner av en blob. När versionshantering av blobar är aktiverat kan du återställa en tidigare version av en blob för att återställa dina data om de har ändrats eller tagits bort felaktigt. Information om hur du aktiverar versionshantering av blobar finns i Aktivera och hantera blobversionshantering.
Mjuk borttagning av containrar för att återställa en container som har tagits bort. Information om hur du aktiverar mjuk borttagning av containrar finns i Aktivera och hantera mjuk borttagning för containrar.
Mjuk borttagning av blob för att återställa en blob, ögonblicksbild eller version som har tagits bort. Information om hur du aktiverar mjuk borttagning av blobar finns i Aktivera och hantera mjuk borttagning för blobar.

Mer information om Microsofts rekommendationer för dataskydd finns i Översikt över dataskydd.

Så här fungerar versionshantering av blobar

En version avbildar tillståndet för en blob vid en viss tidpunkt. Varje version identifieras med ett versions-ID. När blobversionshantering har aktiverats för ett lagringskonto skapar Azure Storage automatiskt en ny version med ett unikt ID när en blob först skapas och varje gång bloben ändras.

Ett versions-ID kan identifiera den aktuella versionen eller en tidigare version. En blob kan bara ha en aktuell version i taget.

När du skapar en ny blob finns det en enda version och den versionen är den aktuella versionen. När du ändrar en befintlig blob blir den aktuella versionen en tidigare version. En ny version skapas för att avbilda det uppdaterade tillståndet, och den nya versionen är den aktuella versionen. När du tar bort en blob blir den aktuella versionen av bloben en tidigare version och det finns inte längre någon aktuell version. Alla tidigare versioner av blobben finns kvar.

Följande diagram visar hur versioner skapas i skrivåtgärder och hur en tidigare version kan upphöjas till den aktuella versionen:

Diagram som visar hur blobversionshantering fungerar

Blobversioner är oföränderliga. Du kan inte ändra innehållet eller metadata för en befintlig blobversion.

Om du har ett stort antal versioner per blob kan du öka svarstiden för bloblistningsåtgärder. Microsoft rekommenderar att du underhåller färre än 1 000 versioner per blob. Du kan använda livscykelhantering för att automatiskt ta bort gamla versioner. Mer information om livscykelhantering finns i Optimera kostnader genom att automatisera Azure Blob Storage åtkomstnivåer.

Versionshantering av blobar är tillgängligt för standardkonton för generell användning v2, premium-blockblob och äldre Blob Storage. Storage-konton med en hierarkisk namnrymd som är aktiverad för användning med Azure Data Lake Storage Gen2 stöds inte för närvarande.

Version 2019-10-10 och senare av Azure Storage REST API stöd för blobversionshantering.

Viktigt

Versionshantering av blobar kan inte hjälpa dig att återställa från en oavsiktlig borttagning av ett lagringskonto eller en container. Om du vill förhindra oavsiktlig borttagning av lagringskontot konfigurerar du ett lås på lagringskontoresursen. Mer information om hur du låser ett lagringskonto finns i Tillämpa ett Azure Resource Manager för ett lagringskonto.

Versions-ID

Varje blobversion identifieras med ett unikt versions-ID. Värdet för versions-ID:t är tidsstämpeln där bloben uppdaterades. Versions-ID:t tilldelas när versionen skapas.

Du kan utföra läs- eller borttagningsåtgärder på en specifik version av en blob genom att ange dess versions-ID. Om du utelämnar versions-ID:t fungerar åtgärden mot den aktuella versionen.

När du anropar en skrivåtgärd för att skapa eller ändra en blob Azure Storage returnerar huvudet x-ms-version-id i svaret. Det här huvudet innehåller versions-ID:t för den aktuella versionen av bloben som skapades av skrivåtgärden.

Versions-ID:t förblir detsamma under hela versionens livslängd.

Versionshantering vid skrivåtgärder

När versionshantering av blobar är aktiverat skapar varje skrivåtgärd till en blob en ny version. Skrivåtgärderna omfattar Placera blob, Placera blocklista, Kopiera bloboch Ange blobmetadata.

Om skrivåtgärden skapar en ny blob är den resulterande bloben den aktuella versionen av bloben. Om skrivåtgärden ändrar en befintlig blob blir den aktuella versionen en tidigare version och en ny aktuell version skapas för att avbilda den uppdaterade bloben.

Följande diagram visar hur skrivåtgärder påverkar blobversioner. För enkelhetens skull visar de diagram som visas i den här artikeln versions-ID:t som ett enkelt heltalsvärde. I verkligheten är versions-ID:t en tidsstämpel. Den aktuella versionen visas i blått och tidigare versioner visas i grått.

Diagram som visar hur skrivåtgärder påverkar versionsblobar.

Anteckning

En blob som skapades innan versionshantering aktiverades för lagringskontot har inget versions-ID. När bloben ändras blir den ändrade bloben den aktuella versionen och en version skapas för att spara blobens tillstånd före uppdateringen. Versionen tilldelas ett versions-ID som är dess skapandetid.

När versionshantering av blobar är aktiverat för ett lagringskonto utlöser alla skrivåtgärder på blockblobar skapandet av en ny version, med undantag för put block-åtgärden.

För sidblobar och tilläggsblobbar utlöser bara en delmängd av skrivåtgärder skapandet av en version. Dessa åtgärder omfattar:

Följande åtgärder utlöser inte skapandet av en ny version. Om du vill samla in ändringar från dessa åtgärder tar du en manuell ögonblicksbild:

Placera sida (sidblob)
Tilläggsblock (tilläggsblob)

Alla versioner av en blob måste vara av samma blobtyp. Om en blob har tidigare versioner kan du inte skriva över en blob av en typ med en annan typ om du inte först tar bort bloben och alla dess versioner.

Versionshantering vid borttagningsåtgärder

När du anropar åtgärden Ta bort blob utan att ange ett versions-ID blir den aktuella versionen en tidigare version och det finns inte längre någon aktuell version. Alla befintliga tidigare versioner av bloben bevaras.

Följande diagram visar effekten av en borttagningsåtgärd på en versionsblob:

Diagram som visar borttagning av versionsblob.

Om du vill ta bort en specifik version av en blob anger du ID:t för den versionen för borttagningsåtgärden. Om mjuk borttagning av blobar också är aktiverat för lagringskontot behålls versionen i systemet tills kvarhållningsperioden för mjuk borttagning har gått ut.

När nya data skrivs till bloben skapas en ny aktuell version av bloben. Alla befintliga versioner påverkas inte, som du ser i följande diagram.

Diagram som visar återskapning av versionsblob efter borttagning.

Åtkomstnivåer

Du kan flytta valfri version av en blockblob, inklusive den aktuella versionen, till en annan blobåtkomstnivå genom att anropa åtgärden Ange blobnivå. Du kan dra nytta av lägre kapacitetspriser genom att flytta äldre versioner av en blob till låg nivå eller arkivnivå. Mer information finns i Åtkomstnivåer för hot, cool och arkiv för blobdata.

Om du vill automatisera processen med att flytta blockblobar till lämplig nivå använder du livscykelhantering för blobar. Mer information om livscykelhantering finns i Hantera Azure Blob Storage-livscykeln.

Aktivera eller inaktivera versionshantering av blobar

Information om hur du aktiverar eller inaktiverar versionshantering av blobar finns i Aktivera och hantera versionshantering av blobar.

Om du inaktiverar blobversionshantering tas inte befintliga blobar, versioner eller ögonblicksbilder bort. När du inaktiverar blobversionshantering är alla befintliga versioner fortfarande tillgängliga i ditt lagringskonto. Inga nya versioner skapas senare.

Om en blob skapades eller ändrades efter att versionshanteringen inaktiverades på lagringskontot skapas en ny version när bloben skrivs över. Den uppdaterade bloben är inte längre den aktuella versionen och har inget versions-ID. Alla efterföljande uppdateringar av bloben skriver över data utan att spara det tidigare tillståndet.

Du kan läsa eller ta bort versioner med hjälp av versions-ID:t när versionshanteringen har inaktiverats. Du kan också visa en blobs versioner när versionshanteringen har inaktiverats.

Följande diagram visar hur ändring av en blob efter att versionshantering har inaktiverats skapar en blob som inte är versionshantering. Alla befintliga versioner som är associerade med bloben bevaras.

Diagram som visar basblob som ändrats efter att versionshantering har inaktiverats.

Versionshantering av blobar och mjuk borttagning

Microsoft rekommenderar att du aktiverar mjuk borttagning av både versionshantering och blob för dina lagringskonton för optimalt dataskydd. Mer information om mjuk borttagning av blobar finns i Mjuk borttagning för Azure Storage blobar.

Skriva över en blob

Om både versionshantering för blobar och mjuk borttagning av blobar är aktiverade för ett lagringskonto skapas en ny version automatiskt när du skriver över en blob. Den nya versionen är inte mjuk borttagning och tas inte bort när kvarhållningsperioden för mjuk borttagning upphör att gälla. Inga mjukt borttagna ögonblicksbilder skapas.

Ta bort en blob eller version

Om både versionshantering och mjuk borttagning är aktiverade för ett lagringskonto blir den aktuella versionen av bloben en tidigare version när du tar bort en blob. Ingen ny version skapas och inga mjukt borttagna ögonblicksbilder skapas. Kvarhållningsperioden för mjuk borttagning gäller inte för den borttagna bloben.

Mjuk borttagning ger ytterligare skydd för borttagning av blobversioner. När du tar bort en tidigare version av bloben tas den versionen bort mjuk. Den mjukt borttagna versionen bevaras tills kvarhållningsperioden för mjuk borttagning har gått ut, då den tas bort permanent.

Om du vill ta bort en tidigare version av en blob anropar du åtgärden Ta bort blob och anger versions-ID:t.

Följande diagram visar vad som händer när du tar bort en blob eller en blobversion.

Diagram som visar borttagning av en version med mjuk borttagning aktiverat.

Återställa en mjukt borttagna version

Du kan använda åtgärden Undelete Blob (Undelete Blob) för att återställa mjukt borttagna versioner under kvarhållningsperioden för mjuk borttagning. Åtgärden Undelete Blob återställer alltid alla mjukt borttagna versioner av bloben. Det går inte att återställa endast en enda version med mjuk borttagning.

Återställning av mjukt borttagna versioner med åtgärden Undelete Blob (Undelete Blob) befordrar inte någon version till den aktuella versionen. Om du vill återställa den aktuella versionen återställer du först alla mjukt borttagna versioner och använder sedan åtgärden Kopiera blob för att kopiera en tidigare version till en ny aktuell version.

Följande diagram visar hur du återställer mjukt borttagna blobversioner med åtgärden Undelete Blob (Undelete Blob) och hur du återställer den aktuella versionen av bloben med åtgärden Copy Blob (Kopiera blob).

Diagram som visar hur du återställer mjukt borttagna versioner.

När kvarhållningsperioden för mjuk borttagning har gått ut tas alla blobversioner med mjuk borttagning bort permanent.

Versionshantering av blobar och blobögonblicksbilder

En blobögonblicksbild är en skrivskyddade kopia av en blob som tas vid en viss tidpunkt. Blobögonblicksbilder och blobversioner liknar varandra, men en ögonblicksbild skapas manuellt av dig eller ditt program, medan en blobversion skapas automatiskt på en skriv- eller borttagningsåtgärd när blobversionshantering har aktiverats för ditt lagringskonto.

Viktigt

Microsoft rekommenderar att du även uppdaterar ditt program för att sluta ta ögonblicksbilder av blockblobar när du aktiverar versionshantering av blobar. Om versionshantering har aktiverats för ditt lagringskonto avbildas och bevaras alla uppdateringar och borttagningar av blockblobar av versioner. Att ta ögonblicksbilder ger inte något ytterligare skydd för dina blockblobdata om versionshantering av blobar är aktiverat och kan öka kostnaderna och programmets komplexitet.

Ögonblicksbild av en blob när versionshantering är aktiverat

Även om det inte rekommenderas kan du ta en ögonblicksbild av en blob som också är versionshantering. Om du inte kan uppdatera programmet för att sluta ta ögonblicksbilder av blobar när du aktiverar versionshantering kan programmet ha stöd för både ögonblicksbilder och versioner.

När du tar en ögonblicksbild av en versionsblob skapas en ny version samtidigt som ögonblicksbilden skapas. En ny aktuell version skapas också när en ögonblicksbild tas.

Följande diagram visar vad som händer när du tar en ögonblicksbild av en versionsblob. I diagrammet innehåller blobversioner och ögonblicksbilder med version ID 2 och 3 identiska data.

Diagram som visar ögonblicksbilder av en versionsblob.

Auktorisera åtgärder på blobversioner

Du kan auktorisera åtkomst till blobversioner med någon av följande metoder:

Genom att använda rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att bevilja behörigheter till Azure Active Directory (Azure AD) säkerhetsobjekt. Microsoft rekommenderar att du använder Azure AD för bättre säkerhet och användarvänlighet. Mer information om hur du använder Azure AD med blobåtgärder finns i Auktorisera åtkomst till data i Azure Storage.
Genom att använda en signatur för delad åtkomst (SAS) för att delegera åtkomst till blobversioner. Ange versions-ID:t för den signerade resurstypen , som representerar en blobversion, för att bv skapa en SAS-token för åtgärder på en specifik version. Mer information om signaturer för delad åtkomst finns i Bevilja begränsad åtkomst till Azure Storage resurser med signaturer för delad åtkomst (SAS).
Genom att använda kontots åtkomstnycklar för att auktorisera åtgärder mot blobversioner med delad nyckel. Mer information finns i Auktorisera med delad nyckel.

Versionshantering av blobar är utformat för att skydda dina data från oavsiktlig eller skadlig borttagning. För att förbättra skyddet kräver borttagning av en blobversion särskilda behörigheter. I följande avsnitt beskrivs de behörigheter som krävs för att ta bort en blobversion.

Azure RBAC-åtgärd för att ta bort en blobversion

Följande tabell visar vilka Azure RBAC-åtgärder som stöder borttagning av en blob eller en blobversion.

Description	Blob Service-åtgärd	Azure RBAC-dataåtgärd krävs	Inbyggt rollstöd i Azure
Ta bort den aktuella versionen	Ta bort blob	Microsoft. Storage/storageAccounts/blobServices/containers/blobs/delete	Storage Blob Data-deltagare
Ta bort en tidigare version	Ta bort blob	Microsoft. Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action	Storage Blob Data-ägare

Sas-parametrar (signatur för delad åtkomst)

Den signerade resursen för en blobversion är bv . Mer information finns i Skapa en tjänst-SAS eller Skapa en SAS för användardelegering.

I följande tabell visas den behörighet som krävs för en SAS för att ta bort en blobversion.

Behörighet	URI-symbol	Tillåtna åtgärder
Ta bort	x	Ta bort en blobversion.

Priser och fakturering

Om du aktiverar blobversionshantering kan det leda till ytterligare datalagringsavgifter för ditt konto. När du utformar ditt program är det viktigt att vara medveten om hur dessa avgifter kan tillkomma så att du kan minimera kostnaderna.

Blobversioner, till exempel blobögonblicksbilder, debiteras med samma hastighet som aktiva data. Hur versioner faktureras beror på om du uttryckligen har angett nivån för basbloben eller någon av dess versioner (eller ögonblicksbilder). Mer information om blobnivåer finns i Åtkomstnivåer för hot, cool och arkiv för blobdata.

Om du inte har ändrat en blob- eller versionsnivå debiteras du för unika datablock i bloben, dess versioner och eventuella ögonblicksbilder. Mer information finns i Fakturering när blobnivån inte uttryckligen har angetts.

Om du har ändrat en blob- eller versionsnivå debiteras du för hela objektet, oavsett om bloben och versionen så småningom är på samma nivå igen. Mer information finns i Fakturering när blobnivån uttryckligen har angetts.

Anteckning

Om du aktiverar versionshantering för data som skrivs över ofta kan det leda till ökade avgifter för lagringskapacitet och längre svarstider under listningsåtgärder. Du kan åtgärda dessa problem genom att lagra ofta överskrivna data i ett separat lagringskonto med versionshantering inaktiverat.

Mer information om faktureringsinformation för blobögonblicksbilder finns i Blob-ögonblicksbilder.

Fakturering när blobnivån inte uttryckligen har angetts

Om du inte uttryckligen har angett blobnivån för en basblob eller någon av dess versioner debiteras du för unika block eller sidor i bloben, dess versioner och eventuella ögonblicksbilder. Data som delas mellan en blob och dess versioner debiteras bara en gång. När en blob uppdateras skiljer sig data i en basblob från de data som lagras i dess versioner, och unika data debiteras per block eller sida.

När du ersätter ett block i en blockblob debiteras blocket därefter som ett unikt block. Detta gäller även om blocket har samma block-ID och samma data som det har i den tidigare versionen. När blocket har utförts igen skiljer det sig från dess motsvarighet i den tidigare versionen och du debiteras för dess data. Detsamma gäller för en sida i en sidblob som uppdateras med identiska data.

Blob Storage kan inte avgöra om två block innehåller identiska data. Varje block som laddas upp och överförs behandlas som unika, även om de har samma data och samma block-ID. Eftersom avgifter påförs för unika block är det viktigt att komma ihåg att uppdatering av en blob när versionshantering har aktiverats leder till ytterligare unika block och ytterligare avgifter.

När versionshantering för blobar är aktiverat anropar du uppdateringsåtgärder på blockblobar så att de uppdaterar minsta möjliga antal block. Skrivåtgärderna som tillåter mer information om block är Put Block och Put Block List. Put Blob-åtgärden ersätter å andra sidan hela innehållet i en blob och kan därför leda till ytterligare avgifter.

Följande scenarier visar hur avgifter ackumuleras för en blockblob och dess versioner när blobnivån inte uttryckligen har angetts.

Scenario 1

I scenario 1 har bloben en tidigare version. Bloben har inte uppdaterats sedan versionen skapades, så avgifter debiteras bara för unika block 1, 2 och 3.

Diagram 1 som visar fakturering för unika block i basblob och tidigare version.

Scenario 2

I scenario 2 har ett block (block 3 i diagrammet) i bloben uppdaterats. Även om det uppdaterade blocket innehåller samma data och samma ID, är det inte samma som block 3 i den tidigare versionen. Därför debiteras kontot för fyra block.

Diagram 2 som visar fakturering för unika block i basblob och tidigare version.

Scenario 3

I scenario 3 har bloben uppdaterats, men inte versionen. Block 3 ersattes med block 4 i basbloben, men den tidigare versionen återspeglar fortfarande block 3. Därför debiteras kontot för fyra block.

Diagram 3 som visar fakturering för unika block i basblob och tidigare version.

Scenario 4

I scenario 4 har basbloben uppdaterats helt och innehåller inga av dess ursprungliga block. Därför debiteras kontot för alla åtta unika block fyra i — basbloben och fyra i den tidigare versionen. Det här scenariot kan inträffa om du skriver till en blob med åtgärden Placera blob eftersom den ersätter hela innehållet i basbloben.

Diagram 4 som visar fakturering för unika block i basblob och tidigare version.

Fakturering när blobnivån uttryckligen har angetts

Om du uttryckligen har angett blobnivån för en blob eller version (eller ögonblicksbild) debiteras du för objektets fullständiga innehållslängd på den nya nivån, oavsett om det delar block med ett objekt på den ursprungliga nivån eller inte. Du debiteras också för den fullständiga innehållslängden för den äldsta versionen på den ursprungliga nivån. Alla andra tidigare versioner eller ögonblicksbilder som finns kvar på den ursprungliga nivån debiteras för unika block som de kan dela, enligt beskrivningen i Fakturering när blobnivån inte uttryckligen har angetts.

Flytta en blob till en ny nivå

I följande tabell beskrivs faktureringsbeteendet för en blob eller version när den flyttas till en ny nivå.

När blobnivån anges explicit på...	Sedan debiteras du för...
En basblob med en tidigare version	Basbloben på den nya nivån och den äldsta versionen på den ursprungliga nivån, plus eventuella unika block i andra versioner. ¹
En basblob med en tidigare version och en ögonblicksbild	Basbloben på den nya nivån, den äldsta versionen på den ursprungliga nivån och den äldsta ögonblicksbilden på den ursprungliga nivån, plus eventuella unika block i andra versioner eller ögonblicksbilder^1.
En tidigare version	Versionen på den nya nivån och basbloben på den ursprungliga nivån, plus eventuella unika block i andra versioner. ¹

¹ Om det finns andra tidigare versioner eller ögonblicksbilder som inte har flyttats från den ursprungliga nivån debiteras dessa versioner eller ögonblicksbilder baserat på antalet unika block som de innehåller, enligt beskrivningen i Fakturering när blobnivåninte uttryckligen har angetts.

Följande diagram illustrerar hur objekt faktureras när en versionsblob flyttas till en annan nivå.

Diagram som visar hur objekt faktureras när en versionsblob uttryckligen nivåindelade.

Det går inte att ångra att uttryckligen ange nivån för en blob, version eller ögonblicksbild. Om du flyttar en blob till en ny nivå och sedan flyttar tillbaka den till den ursprungliga nivån debiteras du för objektets fullständiga innehållslängd även om den delar block med andra objekt på den ursprungliga nivån.

Åtgärder som uttryckligen anger nivån för en blob, version eller ögonblicksbild är:

Ange blobnivå
Placera blob med angiven nivå
Placera blockeringslista med angiven nivå
Kopiera blob med angiven nivå

Ta bort en blob när mjuk borttagning är aktiverat

När mjuk borttagning av blobar är aktiverat och du tar bort eller skriver över en basblob som uttryckligen har angetts för nivån debiteras alla tidigare versioner av den mjukt borttagna bloben med fullständig innehållslängd. Mer information om hur versionshantering av blobar och mjuk borttagning fungerar tillsammans finns i Versionshantering för blobar och mjuk borttagning.

I följande tabell beskrivs faktureringsbeteendet för en blob som är mjuk borttagning, beroende på om versionshantering är aktiverat eller inaktiverat. När versionshantering är aktiverat skapas en version när en blob tas bort mjuk borttagning. När versionshantering är inaktiverat skapar mjuk borttagning av en blob en ögonblicksbild med mjuk borttagning.

När du skriver över en basblob med dess nivå uttryckligen inställd...	Sedan debiteras du för...
Om mjuk borttagning av blob och versionshantering är aktiverade	Alla befintliga versioner med fullständig innehållslängd oavsett nivå.
Om mjuk borttagning av blobar är aktiverat men versionshantering är inaktiverat	Alla befintliga mjuk borttagningsögonblicksbilder med full innehållslängd oavsett nivå.

Funktionsstöd

Den här tabellen visar hur den här funktionen stöds i ditt konto och hur det påverkar supporten när du aktiverar vissa funktioner.

Typ av lagringskonto	Blob Storage (standardstöd)	Data Lake Storage Gen2 ¹	NFS 3.0 ¹	SFTP ¹
Standard generell användning v2
Premium blockblobar

¹ Data Lake Storage Gen2, NFS 3.0-protokollet (Network File System) och SFTP -protokollet (Secure File Transfer Protocol) kräver alla ett lagringskonto med en hierarkisk namnrymd aktiverad.