Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Du kan aktivera Blob Storage-versionshantering 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.
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. Av denna anledning kan aktivering av blob-versionering leda till extra 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 Optimize costs by automating Azure Blob Storage access tiers.
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:
Viktigt!
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 Optimize costs by automating Azure Blob Storage access tiers.
Blobversioner är oföränderliga. Du kan inte ändra innehållet eller metadata för en befintlig blobversion.
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.
Viktigt!
Blob-versionering kan inte hjälpa dig att återställa från en oavsiktlig radering av ett lagringskonto eller 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 Apply an Azure Resource Manager lock to a storage account.
Versions-ID
Varje blob-version har ett unikt versions-ID. Versions-ID-värdet ä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 anropar en skrivåtgärd för att skapa eller ändra en blob returnerar Azure Storage huvudet x-ms-version-id i svaret. Denna header innehåller versions-ID för den aktuella versionen av blobben som skrivoperationen skapar.
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.
Anteckning
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:
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 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 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. 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 blockklumpar till rätt nivå, använd blob lifecycle management. För mer information om livscykelhantering, se Hantera Azure Blob-lagringslivscykeln.
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 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.
Versionshantering av blobar och mjuk radering
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 både blobversionshantering och mjuk borttagning av blobar är aktiverade för ett lagringskonto, skapas en ny version automatiskt när en blob skrivs över. 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 du aktiverar versionshantering och mjuk borttagning för ett lagringskonto, blir den aktuella versionen av blobben en tidigare version när du tar bort en blob. Åtgärden skapar inte en ny version eller mjukt borttagna ögonblicksbilder. Den mjuka raderingsperioden gäller inte för den raderade blobben.
Soft delete ger extra skydd vid radering av blob-versioner. När du raderar en tidigare version av blobben tas den versionen bort mjukt. Den mjukt raderade versionen bevaras tills bevarandeperioden för mjuk radering är slut, och då raderas den 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 tillfälligt 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. 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.
Följande diagram visar hur man återställer mjukraderade blobversioner med hjälp av Undelete Blob-operationen , och hur man återställer den aktuella versionen av blobben med hjälp av Copy Blob-operationen .
Efter att lagringsperioden för mjuk borttagning är slut raderas alla mjukt raderade blob-versioner permanent.
Versionering av blobar och snapshots av blobar
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 skapas automatiskt under en skriv- eller borttagningsoperation när du aktiverar blob-versionering 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 du aktiverar versionshantering för ditt lagringskonto fångar och bevarar det alla uppdateringar och raderingar av blockblobs genom att använda versioner. Att ta snapshots ger inget extra skydd för din blockblob-data om blobversionering är aktiverad, och det kan öka kostnader och applikationskomplexitet.
Ö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 du skapar 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.
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.
| beskrivning | Blobtjänståtgärd | Azure RBAC-dataåtgärd krävs | Azure inbyggt rollstöd |
|---|---|---|---|
| Ta bort den aktuella versionen | Ta bort blob | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete | Storage Blob Data-bidragsgivare |
| 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 |
|---|---|---|
| Ta bort | x | Ta bort en blobversion. |
Prissättning och fakturering
Att aktivera blob-versionering kan leda till extra lagringskostnader för ditt konto. När du utformar din applikation, var medveten om hur dessa avgifter kan tillkomma så att du kan minimera kostnaderna.
Blobversioner, till exempel ögonblicksbilder av blobar, debiteras med samma hastighet som aktiva data. Hur du betalar för versioner beror på om du uttryckligen anger åtkomstnivån för de aktuella eller tidigare versionerna av ett blobobjekt (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 ändrar nivån för en blob eller en version betalar du för unika datablock i blobben, dess versioner och eventuella ögonblicksbilder. För mer information, se Billing när blob-nivån inte är explicit inställd.
Om du ändrar en blob eller versions nivå betalar du för hela objektet, oavsett om bloben och versionen till slut hamnar i samma tier igen. Mer information finns i Fakturering när blobnivån anges explicit.
Anteckning
Att aktivera versionshantering för data som ofta skrivs över kan öka lagringskapacitetskostnaderna och öka latensen under listningsoperationer. Du kan undvika dessa problem genom att lagra ofta överskrivna data i ett separat lagringskonto med versionshantering inaktiverat.
Aktivering av versioner på lagringskonton som säkerhetskopieras ofta kan utlösa avgifter för datahämtning när versionerna lagras på kalla eller kalla åtkomstnivåer.
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 åtkomstnivån för någon version av blobben betalar du för unika block eller sidor i alla versioner och eventuella ögonblicksbilder som den kan ha. Du betalar bara för delad data mellan blob-versioner en gång. När du uppdaterar en blob skiljer sig datan i den nya aktuella versionen från den data som lagrats i tidigare versioner, och du betalar för den unika datan per block eller sida.
När du byter ut ett block inom en blockklump betalar 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 den tidigare versionen. Efter att du committat blocket igen avviker det från sin motsvarighet i den tidigare versionen, och du betalar 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 betalar för unika block, tänk på att uppdatering av en blob när versionering aktiveras resulterar i fler unika block och extra avgifter.
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 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.
Scenario 2
I scenario 2 uppdaterar du 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. Som ett resultat betalar du för fyra kvarter.
Scenario 3
I scenario 3 uppdaterar du blobben, men du uppdaterar inte versionen. Du ersätter block 3 med block 4 i den nuvarande blobben, men den tidigare versionen speglar fortfarande block 3. Som ett resultat betalar du för fyra kvarter.
Scenario 4
I scenario 4 uppdaterar du helt den nuvarande versionen och den innehåller inga av sina ursprungliga block. Som ett resultat betalar du 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 blobnivån uttryckligen anges
Om du uttryckligen sätter blob-nivån för en blob, version eller snapshot, betalar du för hela innehållsnivån för objektet i den nya nivån, även 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å.
| När du ställer in blobnivån... | Då debiteras du för... |
|---|---|
| Tydligt 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 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 visar hur objekt faktureras när en versionsblob flyttas till en annan nivå.
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 tar bort eller skriver över en aktuell version som har en uttryckligen satt nivå, betalar du för alla tidigare versioner av den mjukt raderade blobben i full 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-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.
Versionshantering stöds inte för blobs som du laddar upp med hjälp av Data Lake Storage API:er.