Blob-versionshantering

Du kan aktivera Blob Storage-versionshantering för att automatiskt underhålla tidigare versioner av ett objekt. När blobversionshantering är aktiverat kan du komma åt tidigare versioner av en blob för att återställa dina data om de ändras eller tas bort.

Blob-versionshantering ä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:

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

Varning

När du har aktiverat blobversionshantering för ett lagringskonto resulterar varje skrivåtgärd till en blob i det kontot i att en ny version skapas. Därför kan aktivering av blobversionshantering resultera i ytterligare kostnader. För att minimera kostnaderna använder du en livscykelhanteringsprincip för att automatiskt ta bort gamla versioner. Mer information om livscykelhantering finns i Optimera kostnader genom att automatisera Azure Blob Storage åtkomstnivåer.

Så här fungerar blobversionshantering

En version registrerar tillståndet för en blob vid en viss tidpunkt. Varje version identifieras med ett versions-ID. När blobversionshantering är aktiverat 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 senare ä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 bevaras.

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

Diagram som visar hur versionshantering av blobar fungerar

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

Att ha ett stort antal versioner per blob kan öka svarstiden för bloblistningsåtgärder. Microsoft rekommenderar att du behå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.

Blob-versionshantering är tillgängligt för standard-generell användning v2, premiumblockblob och äldre Blob Storage-konton. Lagringskonton med ett hierarkiskt namnområde aktiverat 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öder blobversionshantering.

Viktigt

Blob-versionshantering kan inte hjälpa dig att återställa från 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-lås på 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 agerar åtgärden mot den aktuella versionen.

När du anropar en skrivåtgärd för att skapa eller ändra en blob returnerar Azure Storage 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 versionens livslängd.

Versionshantering vid skrivåtgärder

När blobversionshantering är aktiverat skapar varje skrivåtgärd till en blob en ny version. Skrivåtgärder inkluderar Put Blob, Put Block List, Copy Blob och Set Blob Metadata.

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 diagrammen 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 blobversionshantering ä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äggsblobar utlöser endast en delmängd av skrivåtgärder skapandet av en version. Dessa åtgärder omfattar följande:

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:

Alla versioner av en blob måste ha 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 vid borttagningsåtgärden. Om mjuk borttagning av blobar också är aktiverat för lagringskontot bevaras versionen i systemet tills kvarhållningsperioden för mjuk borttagning förflutit.

Om du skriver nya data till bloben skapas en ny aktuell version av bloben. Alla befintliga versioner påverkas inte, vilket visas i följande diagram.

Diagram som visar återskapande av versionsbaserad blob 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ågfrekvent nivå eller arkivnivå. Mer information finns i Frekvent, Lågfrekvent och Arkiv-åtkomstnivåer för blobdata.

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

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 versionshantering av blobar tas inte befintliga blobar, versioner eller ögonblicksbilder bort. När du inaktiverar versionshantering av blobar förblir alla befintliga versioner tillgängliga i ditt lagringskonto. Inga nya versioner skapas senare.

När versionshantering har inaktiverats skapas en blob som inte är en version om du ändrar den aktuella versionen. Alla efterföljande uppdateringar av bloben skriver över dess data utan att spara föregående tillstånd. Alla befintliga versioner finns kvar som tidigare versioner.

Du kan läsa eller ta bort versioner med versions-ID när versionshantering har inaktiverats. Du kan också visa en lista över en blobs versioner när versionshantering har inaktiverats.

Följande diagram visar hur du ändrar en blob när versionshantering har inaktiverats skapar en blob som inte är versionshanterad. Alla befintliga versioner som är associerade med bloben bevaras.

Diagram som visar att ändringar av en aktuell version efter att versionshantering har inaktiverats skapar en blob som inte är en version.

Versionshantering av blobar och mjuk borttagning

Versionshantering av blobar och mjuk borttagning av blobar ingår i den rekommenderade dataskyddskonfigurationen för lagringskonton. Mer information om Microsofts rekommendationer för dataskydd finns i Rekommenderad konfiguration av dataskydd i den här artikeln samt Översikt över dataskydd.

Skriva över en blob

Om blobversionshantering och mjuk borttagning av blobar båda är aktiverade för ett lagringskonto skapar en ny version automatiskt om du skriver över en blob. Den nya versionen tas inte bort mjukt 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 att ta bort blobversioner. När du tar bort en tidigare version av bloben tas den versionen bort mjukt. Den mjukt borttagna versionen bevaras tills kvarhållningsperioden för mjuk borttagning förflutit, 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 mjuk borttagningsversion

Du kan använda åtgärden Ta bort blob för att återställa mjukt borttagna versioner under kvarhållningsperioden för mjuk borttagning. Åtgärden Ta bort blob återställer alltid alla mjukt borttagna versioner av bloben. Det går inte att återställa endast en enskild mjukt borttagen version.

Återställning av mjukt borttagna versioner med åtgärden Ta bort blob höjer inte upp 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 Ta bort blob och hur du återställer den aktuella versionen av bloben med åtgärden Kopiera blob .

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

När kvarhållningsperioden för mjuk borttagning har förflutit tas alla mjukt borttagna blobversioner bort permanent.

Versionshantering av blobar och ögonblicksbilder av blobar

En blobögonblicksbild är en skrivskyddad kopia av en blob som tas vid en viss tidpunkt. Blobögonblicksbilder och blobversioner är liknande, men en ögonblicksbild skapas manuellt av dig eller ditt program, medan en blobversion skapas automatiskt vid en skriv- eller borttagningsåtgärd när versionshantering av blob är aktiverat för ditt lagringskonto.

Viktigt

Microsoft rekommenderar att du när du har aktiverat versionshantering av blobar även uppdaterar ditt program för att sluta ta ögonblicksbilder av blockblobar. Om versionshantering är aktiverat för ditt lagringskonto samlas alla blockblobuppdateringar och borttagningar in och bevaras av versioner. Att ta ögonblicksbilder ger inte ytterligare skydd för dina blockblobdata om versionshantering av blobar är aktiverat och kan öka kostnaderna och programkomplexiteten.

Ö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 versionshanterad. Om du inte kan uppdatera programmet för att sluta ta ögonblicksbilder av blobar när du aktiverar versionshantering, kan ditt program ha stöd för både ögonblicksbilder och versioner.

När du tar en ögonblicksbild av en versionshanterad blob 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 versionshanterad blob. 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 i 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 ett säkerhetsobjekt för Azure Active Directory (Azure AD). Microsoft rekommenderar att du använder Azure AD för överlägsen 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 för den signerade resurstypen bv, som representerar en blobversion, för att skapa en SAS-token för åtgärder på en viss 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 kontoåtkomstnycklarna 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ävs särskilda behörigheter för att ta bort en blobversion. 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

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

Beskrivning Blob-tjänstå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

Parametrar för signatur för delad åtkomst (SAS)

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 versionshantering av blobar kan det resultera i ytterligare datalagringsavgifter för ditt konto. När du utformar ditt program är det viktigt att vara medveten om hur dessa avgifter kan påföras så att du kan minimera kostnaderna.

Blobversioner, till exempel ögonblicksbilder av blobar, debiteras med samma hastighet som aktiva data. Hur versioner faktureras beror på om du uttryckligen har angett nivån för aktuella eller tidigare versioner av en blob (eller ögonblicksbilder). Mer information om blobnivåer finns i Frekvent, Lågfrekvent och Arkivåtkomstnivåer för blobdata.

Om du inte har ändrat nivån för en blob eller version 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 nivån för en blob eller version debiteras du för hela objektet, oavsett om bloben och versionen slutligen finns på samma nivå igen. Mer information finns i Fakturering när blobnivån uttryckligen har angetts.

Anteckning

Aktivering av versionshantering för data som ofta skrivs över kan leda till ökade kostnader för lagringskapacitet och ökad svarstid under listningsåtgärder. Du kan undvika 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 Ögonblicksbilder av blobar.

Fakturering när blobnivån inte uttryckligen har angetts

Om du inte uttryckligen har angett blobnivån för någon version av en blob debiteras du för unika block eller sidor i alla versioner och eventuella ögonblicksbilder. Data som delas mellan blobversioner debiteras bara en gång. När en blob uppdateras avviker data i den nya aktuella versionen från de data som lagrats i tidigare versioner och unika data debiteras per block eller sida.

När du ersätter ett block i en blockblob debiteras det blocket därefter som ett unikt block. Detta gäller även om blocket har samma block-ID och samma data som i den tidigare versionen. När blocket har checkats in igen avviker det 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 har inte något sätt att avgöra om två block innehåller identiska data. Varje block som laddas upp och checkas in behandlas som unikt, även om det 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 är aktiverat resulterar i ytterligare unika block och ytterligare avgifter.

När versionshantering av blobar är aktiverat anropar du uppdateringsåtgärder på blockblobar så att de uppdaterar det minsta möjliga antalet block. Skrivåtgärderna som tillåter detaljerad kontroll över block är Put Block (Placera block) och Put Block List (Placera blocklista). Åtgärden Put Blob 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 påförs 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 tillkommer endast 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 den aktuella bloben, 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 den aktuella versionen uppdaterats helt och innehåller inget av dess ursprungliga block. Därför debiteras kontot för alla åtta unika block – fyra i den aktuella versionen och fyra tillsammans i de två tidigare versionerna. Det här scenariot kan inträffa om du skriver till en blob med put blob-åtgärden , eftersom det ersätter hela innehållet i bloben.

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. 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 har angetts... Då debiteras du för...
Uttryckligen i en version, oavsett om den är aktuell eller tidigare Den fullständiga innehållslängden för den versionen. Versioner som inte har en uttryckligen angiven nivå debiteras endast för unika block. 1
Så här arkiverar du Den fullständiga innehållslängden för alla versioner och ögonblicksbilder. 1.

1 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ån inte 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åindelades.

Det går inte att ångra att 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:

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

När mjuk borttagning av blob är aktiverat debiteras alla mjukt borttagna entiteter med fullständig innehållslängd. Om du tar bort eller skriver över en aktuell version som har fått sin nivå uttryckligen angiven 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 av blobar och mjuk borttagning.

Funktionsstöd

Stöd för den här funktionen kan påverkas genom att aktivera Data Lake Storage Gen2, NFS 3.0-protokoll (Network File System) eller SSH File Transfer Protocol (SFTP).

Om du har aktiverat någon av dessa funktioner kan du läsa stöd för Blob Storage-funktioner i Azure Storage-konton för att utvärdera stödet för den här funktionen.

Se även