Blobversionshantering
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.
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:
- Blobversionshantering för att automatiskt underhålla tidigare versioner av en blob. När blobversionshantering är aktiverat kan du återställa en tidigare version av en blob för att återställa dina data om de ändras eller tas bort felaktigt. Information om hur du aktiverar blobversionering finns i Aktivera och hantera blobversionshantering.
- Mjuk borttagning av container 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.
Varning
När du har aktiverat blobversionshantering för ett lagringskonto resulterar varje skrivåtgärd till en blob i kontot i skapandet av en ny version. Därför kan aktivering av blobversioner leda till 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 samlar in 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 blobben ä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 samla in det uppdaterade tillståndet och den nya versionen är den aktuella versionen. När du tar bort en blob blir den aktuella versionen av blobben en tidigare version och det finns inte längre någon aktuell version. Alla tidigare versioner av bloben finns kvar.
Följande diagram visar hur versioner skapas vid skrivåtgärder och hur en tidigare version kan höjas upp till den aktuella versionen:
Blobversioner är oföränderliga. Du kan inte ändra innehållet eller metadata för en befintlig blobversion.
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 standardkonton för 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 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 som bloben uppdaterades med. Versions-ID:t tilldelas när versionen skapas.
Du kan utföra läs- eller borttagningsåtgärder på en viss 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 returnerar Azure Storage rubriken 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 samla in 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.
Kommentar
En blob som skapades innan versionshantering aktiverades för lagringskontot har inget versions-ID. När den 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, förutom put block-åtgärden .
För sidblobar och tilläggsblobar utlöser endast en delmängd 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:
- 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:
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 behålls versionen i systemet tills kvarhållningsperioden för mjuk borttagning förflutit.
När du skriver nya data till bloben skapas en ny aktuell version av bloben. Befintliga versioner påverkas inte, enligt följande diagram.
Å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 åtkomstnivåerna Frekvent, Lågfrekvent, Kall och Arkiv 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 blobversionshantering
Information om hur du aktiverar eller inaktiverar blobversioner finns i Aktivera och hantera blobversionshantering.
Om du inaktiverar blobversioner tas inte befintliga blobar, versioner eller ögonblicksbilder bort. När du inaktiverar blobversionshantering 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 när 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:t när versionshantering har inaktiverats. Du kan också lista en blobversion efter att versionshantering har inaktiverats.
Objektreplikering förlitar sig på blobversionshantering. Innan du kan inaktivera versionshantering av blobar måste du ta bort eventuella principer för objektreplikering på kontot. Mer information om objektreplikering finns i Objektreplikering för blockblobar.
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 blobben bevaras.
Versionshantering av blobar och mjuk borttagning
Mjuk borttagning 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 dataskyddskonfiguration i den här artikeln och Översikt över dataskydd.
Skriva över en blob
Om blobversionshantering och mjuk borttagning av blobar är aktiverade för ett lagringskonto skapar en blob automatiskt en ny version. 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 ögonblicksbilder med mjuk borttagning 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 ögonblicksbilder med mjuk borttagning 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 blobben 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.
Följande diagram visar vad som händer när du tar bort en blob eller en blobversion.
Återställa en mjuk borttagen version
Du kan använda åtgärden Ta bort blob för att återställa mjuk borttagna versioner under kvarhållningsperioden för mjuk borttagning. Åtgärden Ta bort blob återställer alltid alla mjuk borttagna versioner av bloben. Det går inte att återställa endast en enda mjuk borttagen version.
Återställning av mjuk borttagna versioner med åtgärden Ta bort blob höjer inte upp någon version till den aktuella versionen. Återställ den aktuella versionen genom att först återställa alla mjukt borttagna versioner och sedan använda åtgärden Kopiera blob för att kopiera en tidigare version till en ny aktuell version.
Följande diagram visar hur du återställer mjuk borttagna blobversioner med åtgärden Ta bort blob och hur du återställer den aktuella versionen av bloben med åtgärden Kopiera blob .
När kvarhållningsperioden för mjuk borttagning har förflutit tas alla mjuk borttagna blobversioner bort permanent.
Ögonblicksbilder av blobversioner och blobar
En blobögonblicksbild är en skrivskyddad kopia av en blob som tas vid en viss tidpunkt. Blobögonblicksbilder och blobversioner liknar dem, men en ögonblicksbild skapas manuellt av dig eller ditt program, medan en blobversion skapas automatiskt vid en skriv- eller borttagningsåtgärd när blobversionshantering är aktiverat för ditt lagringskonto.
Viktigt!
Microsoft rekommenderar att du när du har aktiverat blobversionshantering ä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 några ytterligare skydd för dina blockblobdata om blobversionshantering ä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 ditt program 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.
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 Microsoft Entra-säkerhetsobjekt. Microsoft rekommenderar att du använder Microsoft Entra-ID för överlägsen säkerhet och användarvänlighet. Mer information om hur du använder Microsoft Entra-ID 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 i en viss version. Mer information om signaturer för delad åtkomst finns i Bevilja begränsad åtkomst till Azure Storage-resurser med hjälp av 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ä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
I följande tabell visas vilka Azure RBAC-åtgärder som stöder borttagning av en blob eller en blobversion.
| beskrivning | Blobtjä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 blobb data-deltagare |
| Ta bort en tidigare version | Ta bort blob | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action | Ägare av lagringsblobdata |
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 |
|---|---|---|
| Delete | x | Ta bort en blobversion. |
Prissättning 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 uppstå 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 de aktuella eller tidigare versionerna av en blob (eller ögonblicksbilder). Mer information om blobnivåer finns i Åtkomstnivåer för Frekvent, Lågfrekvent, Kall och Arkiv för blobdata.
Om du inte har ändrat en blob eller versionsnivå debiteras du för unika datablock i blobben, dess versioner och eventuella ögonblicksbilder. Mer information finns i Fakturering när blobnivån inte har angetts uttryckligen.
Om du har ändrat en blob eller versions nivå 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.
Kommentar
Aktivering av versionshantering för data som skrivs över ofta kan leda till ökade avgifter för lagringskapacitet och ökad svarstid under listå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 Blob-ögonblicksbilder.
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 som den kan ha. Data som delas mellan blobversioner debiteras bara en gång. När en blob uppdateras avviker data i den nya aktuella versionen från 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 senare 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 inget 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 ackumuleras 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 blobversionshantering ä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 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 blobben en tidigare version. Blobben har inte uppdaterats sedan versionen skapades, så avgifter debiteras endast för unika block 1, 2 och 3.
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.
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.
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 kombineras i de två tidigare versionerna. Det här scenariot kan inträffa om du skriver till en blob med put blob-åtgärden eftersom den ersätter hela innehållet i blobben.
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 hela innehållslängden för objektet 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. 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... |
|---|---|
| Explicit 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 explicit angiven nivå faktureras endast för unika block.1 |
| Så här arkiverar du | Den fullständiga innehållslängden för alla versioner och ögonblicksbilder.1. |
1Om 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 visar hur objekt faktureras när en versionsblob flyttas till en annan nivå.
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:
- 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 aktiverad
När mjuk borttagning av blobar är aktiverat debiteras alla mjukt borttagna entiteter med fullständig innehållslängd. Om du tar bort eller skriver över en aktuell version som uttryckligen har angetts på dess nivå 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 Blob-versionshantering 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.
Versionshantering stöds inte för blobar som laddas upp med hjälp av Data Lake Storage-API :er.