Blobversionshantering

Du kan aktivera blob-versionering för att automatiskt underhålla tidigare versioner av ett objekt. När du aktiverar blobversionering kan du komma åt tidigare versioner av en blob för att återställa din data om den ändras eller raderas.

Rekommenderad dataskyddskonfiguration

Blob-versionering är en av flera dataskyddsfunktioner. Att välja rätt funktion eller kombination av funktioner beror på din arbetsbelastning och vad du skyddar mot. För att lära dig mer om Microsoft rekommendationer för dataskydd, se Översikt över dataskydd.

Versioner jämfört med snapshots

En blob-version liknar en snapshot, men de två skiljer sig åt i hur de skapas och vad de passar bäst till. En version hanteras automatiskt av systemet: Azure Storage skapar en ny version vid varje skrivning eller borttagning när blob-versionering är aktiverad, utan att applikationslogik krävs. En snapshot är manuell och applikationsdriven: du skapar uttryckligen en tidpunktskopia när din applikation bestämmer att en behövs.

Använd versionshantering när du vill ha automatiskt, kontinuerligt skydd mot oavsiktliga eller skadliga överskrivningar och borttagningar. Använd ögonblicksbilder när du vill ha avsiktliga kopior av systemets tillstånd vid en viss tidpunkt, som en verifierat fungerande kontrollpunkt före en planerad uppdatering. Microsoft rekommenderar att du slutar ta snapshots av blockblobbar när versionshanteringen är aktiverad.

Så här fungerar blobversionshantering

En version samlar in tillståndet för en blob vid en viss tidpunkt. Varje version har ett versions-ID. När du aktiverar blob-versionering för ett lagringskonto skapar Azure Storage automatiskt en ny version med ett unikt ID när du först skapar en blob och varje gång du ändrar bloben.

Ett versions-ID kan identifiera den aktuella versionen eller en tidigare version. En blob kan bara ha en aktuell version åt gången, det vill säga dess aktuella tillstånd. En blob kan ha flera tidigare versioner.

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 skrivoperationer, och hur en tidigare version kan uppgraderas till den aktuella versionen:

Tidigare blobversioner är oföränderliga, vilket betyder att du inte kan ändra innehållet eller metadatan.

Versions-ID

Varje blob-version har ett unikt versions-ID. Värdet på versions-ID:t är tidsstämpeln när blobben uppdaterades. Du tilldelar versions-ID när du skapar versionen.

Du kan läsa eller ta bort en specifik version av en blob genom att använda dess versions-ID. Om du inte inkluderar versions-ID:t riktar sig operationen mot den aktuella versionen.

När du utför en skrivoperation för att skapa eller ändra en blob returnerar Azure Storage headern x-ms-version-id i svaret. Denna header innehåller versions-ID för den aktuella versionen av blobben som skrivoperationen skapade.

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

Versionshantering vid skrivåtgärder

När du slår på blobversionering skapar varje skrivoperation till en blob en ny version. Skrivåtgärder inkluderar Put Blob, Put Block List, Copy Blob och Set Blob Metadata.

Om skrivoperationen skapar en ny blob är den resulterande blobben den aktuella versionen av blobben. Om skrivoperationen modifierar en befintlig blob blir den aktuella versionen en tidigare version, och en ny aktuell version fångar den uppdaterade blobben.

Följande diagram visar hur skrivåtgärder påverkar blobversioner. För enkelhetens skull visar diagrammen i denna artikel versions-ID 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.

När du aktiverar blobversionering för ett lagringskonto utlöser alla skrivoperationer på blockblobs skapandet av en ny version, förutom Put Block-operationen .

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:

• Lägg till BLOB
• Sätt Blocklista
• Ange Blob-metadata
• Kopiera Blob

Följande operationer utlöser inte skapandet av en ny version:

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

För att fånga förändringar från dessa operationer, ta en manuell snapshot. För mer information, se Blob-snapshots.

Alla versioner av en blob måste vara av samma blob-typ. 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 utför Delete Blob-operationen utan att ange ett versions-ID blir den nuvarande versionen en tidigare version, och det finns inte längre någon aktuell version. Operationen bevarar alla befintliga tidigare versioner av blobben.

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 du också aktiverar blob soft delete för lagringskontot, behåller systemet versionen tills soft delete-bevaringsperioden har löpt ut.

När du skriver nya data till bloben skapas en ny aktuell version av bloben. Denna åtgärd påverkar inte några befintliga versioner, som visas i 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å . Genom att flytta äldre versioner av en blob till cool- eller arkivnivå kan du dra nytta av lägre priser för lagringskapacitet. Mer information finns i åtkomstnivåerna Frekvent, Lågfrekvent, Kall och Arkiv för blobdata.

För att automatisera processen att flytta blockblobbar till rätt nivå, skapa en Lifecycle Management-princip, skapa en Storage Actions-uppgift eller aktivera Smart Tier.

Aktivera eller inaktivera blobversionshantering

För instruktioner om hur man aktiverar eller inaktiverar blob-versionering, se Aktivera och hantera blob-versionering.

Om du inaktiverar blobversioner tas inte befintliga blobar, versioner eller ögonblicksbilder bort. När du stänger av blob-versionering kan du inte skapa nya versioner.

Efter att du inaktiverat versionshantering skapar en ändring av den aktuella versionen en blob som inte är en version. 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 genom att använda versions-ID:t efter att versionshanteringen är inaktiverad. 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.

Funktionsstöd

Stöd för den här funktionen kan påverkas genom att aktivera Data Lake Storage Gen2, NFS-protokollet (Network File System) 3.0 eller SSH File Transfer Protocol (SFTP). Om du har aktiverat någon av dessa funktioner kan du läsa Blob Storage funktionsstöd i Azure Storage konton för att utvärdera stödet för den här funktionen.

Blob-versionshantering är tillgängligt för standardkonton för generell användning v2, premium blockblob och äldre Blob-lagringskonton. 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.

Versionshantering stöds inte för blobs som du laddar upp med hjälp av Data Lake Storage API:er.

Auktorisera åtgärder i blobversioner

Du kan auktorisera åtkomst till blobversioner genom att använda en av följande metoder:

• Använd Azures rollbaserade åtkomstkontroll (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 Authorize access to data in Azure Storage.
• Använd en shared access-signatur (SAS) för att delegera åtkomst till blob-versioner. Ange versions-ID för den signerade resurstypen bv, som representerar en blobversion, för att skapa en SAS-token för operationer på en specifik version. Mer information om signaturer för delad åtkomst finns i Grant begränsad åtkomst till Azure Storage resurser med hjälp av signaturer för delad åtkomst (SAS).
• Använd kontons åtkomstnycklar för att auktorisera operationer mot blob-versioner genom att använda Shared Key. Mer information finns i Auktorisera med delad nyckel.

Blobversionshantering är utformat för att skydda din 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.

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.

Befintlig arbetsbelastning

• Att ta bort en blob frigör inte längre utrymme. När du aktiverar versionshantering innebär det inte att data tas bort när du tar bort en blob. Den nuvarande versionen blir en tidigare version som består och fortsätter att medföra kostnader. Arbetsbelastningar som är beroende av borttagningsoperationer för att återta lagring fortsätter att debiteras tills du uttryckligen raderar dessa versioner.

• Arbetsbelastningar med mycket överskrivning kan samla på sig versioner. Versioner kvarstår tills du uttryckligen tar bort dem. Denna persistens kan leda till en ackumulering av versioner om du inte hanterar dem ordentligt. För att minska kostnaderna, gör ändringar på blocknivå som debiteras på blocknivå över versionerna, vilket minimerar kostnaderna för varje version.

Interaktioner mellan funktioner

Mjuk borttagning

Versionshantering av blobar och mjuk borttagning av blobar ingår i den rekommenderade dataskyddskonfigurationen för lagringskonton. Mer information om Microsoft rekommendationer för dataskydd finns i Översikt över dataskydd.

Skriva över ett dataobjekt

Om du aktiverar både blob-versionering och blob-mjuk borttagning för ett lagringskonto, skapar överskrivning av en blob automatiskt en ny tidigare version som speglar blobens tillstånd före skrivoperationen. Den nya versionen är inte markerad som raderad och kvarstår tills den uttryckligen raderas. Inga ögonblicksbilder med mjuk borttagning skapas.

Ta bort en blob eller version

Om du aktiverar både versionshantering och mjuk borttagning för ett lagringskonto, blir den aktuella versionen av blobben en tidigare version när du tar bort en blob. Operationen skapar inte en ny version eller några mjukt raderade snapshots. Den mjuka raderingsperioden gäller inte för den raderade blobben.

Mjuk borttagning ger extra skydd när blob-versioner tas bort. När du raderar en tidigare version av blobben tas den versionen bort med mjuk borttagning. 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.

Återställa en tillfälligt borttagen version

Använd funktionen Undelete Blob för att återställa mjukt raderade versioner under mjukraderingsperioden. Åtgärden Ta bort blob återställer alltid alla mjuk borttagna versioner av bloben. Du kan inte återställa bara en enda mjukt raderad version.

Att återställa mjukt raderade versioner med hjälp av Undelete Blob-operationen främjar inte någon version till att bli 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.

Efter att kvarhållningsperioden för mjuk borttagning har löpt ut raderar systemet permanent alla mjukraderade blobversioner.

Blob-ögonblicksbilder

En ögonblicksbild av en blob är en skrivskyddad kopia av bloben som har tagits vid en viss tidpunkt. Blob-snapshots och blob-versioner är liknande, men du eller din applikation skapar manuellt en snapshot, medan en blob-version automatiskt skapas vid en skriv- eller borttagningsoperation när du aktiverar blob-versionering för ditt lagringskonto.

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

Även om det inte rekommenderas kan du ta en snapshot av en blob som också är versionad. 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 snapshot av en versionerad blob skapar du en ny version samtidigt som snapshoten. Du skapar också en ny aktuell version när du tar en snapshot.

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

Kända begränsningar

• Stöds inte på konton med hierarkiskt namnområde (Azure Data Lake Storage), eller för blobbar som laddas upp med hjälp av Data Lake Storage-API:er.

• Det skyddar inte mot att en container eller ett konto raderas. Versionshantering fungerar endast på blob-nivå. Att ta bort en container tar bort alla blobs och deras versioner. Att återställa efter den raderingen kräver mjuk borttagning för containrar. Att skydda mot radering av konto kräver ett resurslås.

• Versioner är oföränderliga. Du kan inte ändra innehållet eller metadata i en befintlig version.

• Alla versioner av en blob måste vara av samma blob-typ. Du kan inte skriva över en blob med en annan blob-typ när den har tidigare versioner om du inte först tar bort blobben och alla dess versioner.

• Alla skrivoperationer skapar inte en version. Hänvisa till informationen tidigare i denna artikel som beskriver undantagen. För att spara dessa tillstånd använd en manuell ögonblicksbild.

• Man kan inte inaktivera versionshantering medan objektreplikeringspolicyer finns på kontot. Du måste ta bort alla objektreplikeringspolicyer först.

• Undelete Blob återställer alla mjukraderade versioner av en blob, inte en enda. Du kan inte återställa en enskild version selektivt. Återställ gör aldrig en version till den aktuella versionen.

• Rekommenderat tak på 1 000 versioner per blob. Att överskrida den försämrar bloblistningsprestandan.

Prissättning och fakturering

När du aktiverar blob-versionering kan du få extra kostnader för datalagring. När du utformar din applikation, tänk på hur dessa avgifter kan summeras så att du kan hålla kostnaderna nere.

Du faktureras för blob-versioner, som blob-snapshots, till samma pris som aktiva data. Hur du faktureras för versioner beror på om du uttryckligen sätter nivån för nuvarande eller tidigare versioner av en blob (eller snapshots). Mer information om blobnivåer finns i Åtkomstnivåer för Frekvent, Lågfrekvent, Kall och Arkiv för blobdata.

Om du inte ändrar en blobs eller versions åtkomstnivå faktureras du för unika datablock över den blobben, dess versioner och eventuella snapshots den kan ha. För mer information, se Billing när blob-nivån inte är explicit inställd.

Om du ändrar en blobbs eller versions åtkomstnivå faktureras du för hela objektet, oavsett om blobben och versionen hamnar i samma åtkomstnivå igen. Mer information finns i Fakturering när blobnivån anges explicit.

För mer information om faktureringsdetaljer för blob-ögonblicksbilder, se Blob-ögonblicksbilder.

För lagringskonton som använder smart tier, betalar du för versioner och snapshots i full innehållslängd. Mer information finns i Optimera kostnader med smart nivå.

Fakturering när du inte uttryckligen anger blobnivån

Om du inte uttryckligen anger blob-nivå för någon version av en blob, faktureras du för unika block eller sidor i alla versioner, samt eventuella snapshots den kan ha. Du debiteras för data som delas mellan blobversioner bara en gång. När du uppdaterar en blob avviker datan i den nya aktuella versionen från den data som lagrats i tidigare versioner, så du faktureras för den unika datan per block eller sida.

När du ersätter ett block inom en blockblob faktureras du för det blocket som ett unikt block. Denna regel gäller även om blocket har samma block-ID och samma data som i föregående version. Efter att du committar blocket igen avviker det från sin motsvarighet i föregående version, och du debiteras för dess data. Samma regel gäller för en sida i en sidblob som du uppdaterar med identisk data.

Blob-lagring har inget sätt att avgöra om två block innehåller identisk data. Varje block du laddar upp och commit behandlas som unikt, även om det har samma data och samma block-ID. Eftersom du debiteras för unika block, tänk på att uppdatering av en blob när versionering aktiveras resulterar i extra unika block och extra kostnader.

När du aktiverar blobversionering bör du använda uppdateringsåtgärder på blockblobbar så att de uppdaterar så få block som möjligt. Skrivåtgärderna som tillåter detaljerad kontroll över block är Put Block och Put Block List. Put Block mellanlagrar ändringarna, men själva modifieringen och versionsskapandet sker vid Put Block List-operationen. Put Blob-operationen, å andra sidan, ersätter hela innehållet i en blob och kan därför leda till extra avgifter.

Följande scenarier visar hur avgifter uppstår för en blockblob och dess versioner när du inte uttryckligen anger blobens åtkomstnivå.

Scenario 1:

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

Scenarie 2

I scenario 2 uppdateras ett block (block 3 i diagrammet) i blobben. Ä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 uppdateras blobben, men versionen gör det inte. Block 3 ersätts med block 4 i den nuvarande blobben, men den tidigare versionen speglar fortfarande block 3. Därför debiteras kontot för fyra block.

Scenario 4

I scenario 4 är den nuvarande versionen helt uppdaterad och innehåller inga av sina ursprungliga block. Som ett resultat debiteras kontot för alla åtta unika block – fyra i den nuvarande versionen och fyra tillsammans i de två tidigare versionerna. Detta scenario kan uppstå om du skriver till en blob med hjälp av Put Blob-operationen , eftersom den ersätter hela innehållet i blobben.

Fakturering när du uttryckligen anger blobnivån

Om du uttryckligen sätter blob-nivån för en blob, version eller snapshot, betalar du för hela innehållslängden av objektet i den nya nivån, oavsett om det delar block med ett objekt i den ursprungliga nivån. Du betalar också för hela innehållslängden på den äldsta versionen i originalnivån. För eventuella andra tidigare versioner eller ögonblicksbilder som finns kvar på den ursprungliga nivån betalar du för de unika block som de delar, enligt beskrivningen i Fakturering när blobnivån inte anges uttryckligen.

Flytta en blob till en ny nivå

Följande tabell beskriver faktureringsbeteendet för en blob eller version när du flyttar den till en ny nivå.

¹Om det finns andra tidigare versioner eller ögonblicksbilder som du inte har flyttat från sin ursprungliga åtkomstnivå, debiteras dessa versioner eller ögonblicksbilder utifrån antalet unika block som de innehåller, enligt beskrivningen i Fakturering när blob-åtkomstnivån inte uttryckligen anges.

Följande diagram illustrerar hur objekt faktureras när du flyttar en versionerad blob till en annan tier.

Du kan inte ångra att du explicit ställt in nivån för en blob, version eller snapshot. Om du flyttar en blob till en ny nivå och sedan flyttar tillbaka den till dess ursprungliga nivå, betalar du för hela innehållsvärdet av objektet även om det delar block med andra objekt i 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 specificerad nivå

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

När du aktiverar blob soft delete betalar du för alla mjukt raderade enheter till samma pris som live-data. Om du raderar eller skriver över en aktuell version som du uttryckligen har satt nivån för, betalar du för alla tidigare versioner av blobben som har markerats för borttagning i full innehållslängd. För mer information om hur blob-versionering och soft delete fungerar tillsammans, se Funktionsinteraktioner.

Övervaka och felsöka

• Min LCM-policy raderar inte versioner när jag förväntar mig det: En versions ålder baseras på när du ursprungligen skrev dess data, inte när den blev en tidigare version. Klockan startar vid blob-skapandet, inte vid överskrivningen som gjorde att den hamnade i versionshistoriken. Som ett resultat kan en blob som varit aktuell länge innan den skrivs över producera en tidigare version som redan överskrider din daysAfterCreationGreaterThan tröskel i samma ögonblick som den skapas, vilket gör att den raderas nästan omedelbart. Omvänt kan versioner av nyligen skapade blobs finnas kvar längre än väntat. För att bekräfta, kontrollera den faktiska skapandetidsstämpeln på versionerna istället för att anta att den matchar överskrivningstiden. Om du behöver basera retention på när en version blev oaktuell eller vill ha mer detaljerad kontroll än vad livscykelhanteringens dagbaserade tröskelvärden tillåter, överväg att använda Azure Storage Actions istället. För mer information, se Lagringsåtgärder.

• Min räkning är fortfarande hög efter att ha inaktiverat versioner: Befintliga versioner finns kvar tills du manuellt raderar dem.

• Jag kan inte inaktivera versionshantering. Objektreplikering kan konfigureras på kontot. Ta bort alla objektreplikeringspolicyer först och inaktivera sedan versionshantering. Alternativt kan en Oföränderlighetspolicy (WORM) finnas på en container eller det konto där versionering inte kan inaktiveras.

Se även

• Aktivera och hantera blobversioner
• Skapa en ögonblicksbild av en blob
• Mjuk borttagning för blobar
• Mjuk radering för containrar