Skriv på versionsnivå en gång, läs många (WORM)-principer för oföränderliga blobdata
En skrivprincip på versionsnivå en gång, read many (WORM) är en typ av oföränderlighetsprincip som kan anges på konto-, container- eller versionsnivå. Mer information om oföränderlig lagring för Azure Blob Storage finns i Lagra affärskritiska blobdata med oföränderlig lagring i ett skrivläge en gång, läs många (WORM) tillstånd.
Tillgänglighet
Principer för oföränderlighet på versionsnivå (VLW) stöds på kontonivå för nya konton och på container- och blobnivå för nya och befintliga konton/containrar. Dessa principer stöds för både allmänna v2- och Premium-blockblobkonton. Den här funktionen stöds inte på hierarkiska namnområdeskonton.
Versionsberoende
Principer på versionsnivå kräver att blobversionshantering är aktiverat för lagringskontot. Information om hur du aktiverar blobversionering finns i Aktivera och hantera blobversionshantering. Tänk på att aktivering av versionshantering kan ha en faktureringspåverkan. Mer information finns i avsnittet Priser och fakturering för Blob-versionshantering.
När versionshantering har aktiverats, när en blob först laddas upp, är den versionen av blobben den aktuella versionen. Varje gång bloben skrivs över skapas en ny version som lagrar blobens tidigare tillstånd. När du tar bort den aktuella versionen av en blob blir den aktuella versionen en tidigare version och behålls tills den uttryckligen tas bort. En tidigare blobversion har den tidsbaserade kvarhållningsprincipen som var i kraft när den aktuella versionen blev en tidigare version.
Om en standardprincip gäller för lagringskontot eller containern ärver den nya aktuella versionen standardprincipen för kontot eller containern när en överskrivningsåtgärd skapar en tidigare version.
Varje version kan bara ha en tidsbaserad kvarhållningsprincip konfigurerad. En version kan också ha ett juridiskt undantag konfigurerat.
Information om hur du konfigurerar tidsbaserade kvarhållningsprinciper på versionsnivå finns i Konfigurera oföränderlighetsprinciper för blobversioner.
Aktivering och principinställning
Att använda oföränderliga principer med WORM på versionsnivå är en tvåstegsprocess. Aktivera först oföränderlighet på versionsnivå. Sedan kan du ange oföränderlighetsprinciper på versionsnivå.
Om du vill ange en princip på lagringskontonivå måste du först aktivera WORM på versionsnivå för lagringskontot. Du kan bara göra detta när kontot skapas. Det finns inget alternativ för att aktivera WORM på versionsnivå för befintliga konton.
Om du vill ange en princip på containernivå måste du först aktivera WORM på versionsnivå antingen på kontot eller på containern.
Om du planerar att aktivera WORM på versionsnivå i en container rekommenderar Microsoft att du aktiverar den när containern skapas. Du kan dock migrera en WORM-aktiverad container på icke-versionsnivå till en WORM-aktiverad container på versionsnivå. Om du väljer att inte migrera en container kan du fortfarande ange en WORM-princip på containernivå för containern, men alternativet att ange blobnivåprinciper är inte tillgängligt för containern.
Om du vill ange en princip på blobnivå måste du aktivera WORM på versionsnivå på antingen kontot eller containern. Det finns inget alternativ för att aktivera WORM på versionsnivå på blobnivå. den måste ärvas.
Migrering
Befintliga containrar kan stödja oföränderlighet på versionsnivå men måste genomgå en migreringsprocess först. Den här processen kan ta lite tid. När det är aktiverat kan inte worm-stöd på versionsnivå för containern tas bort. Du kan migrera 10 containrar åt gången per lagringskonto. Mer information om hur du migrerar en container för att stödja oföränderlighet på versionsnivå finns i Migrera en befintlig container för att stödja oföränderlighet på versionsnivå.
Konfigurera en princip för den aktuella versionen
När du har aktiverat stöd för oföränderlighet på versionsnivå för ett lagringskonto eller en container har du möjlighet att konfigurera en standardtidsbaserad kvarhållningsprincip för kontot eller containern. När du konfigurerar en standardtidsbaserad kvarhållningsprincip för kontot eller containern och sedan laddar upp en blob ärver blobben den standardprincipen. Du kan också välja att åsidosätta standardprincipen för alla blobar vid uppladdning genom att konfigurera en anpassad princip för den bloben.
Om standardprincipen för tidsbaserad kvarhållning för kontot eller containern är upplåst har den aktuella versionen av en blob som ärver standardprincipen också en olåst princip. När en enskild blob har laddats upp kan du förkorta eller förlänga kvarhållningsperioden för principen för den aktuella versionen av blobben eller ta bort den aktuella versionen. Du kan också låsa principen för den aktuella versionen, även om standardprincipen för kontot eller containern förblir olåst.
Om standardprincipen för tidsbaserad kvarhållning för kontot eller containern är låst har den aktuella versionen av en blob som ärver standardprincipen också en låst princip. Men om du åsidosätter standardprincipen när du laddar upp en blob genom att endast ange en princip för den bloben, förblir blobens princip olåst tills du uttryckligen låser den. När principen för den aktuella versionen är låst kan du utöka kvarhållningsintervallet, men du kan inte ta bort principen eller förkorta kvarhållningsintervallet.
Om ingen standardprincip har konfigurerats för lagringskontot eller containern kan du ladda upp en blob antingen med en anpassad princip eller utan princip.
Om standardprincipen för ett lagringskonto eller en container ändras förblir principerna för objekt i containern oförändrade, även om dessa principer ärvdes från standardprincipen.
I följande tabell visas de olika alternativ som är tillgängliga för att ange en tidsbaserad kvarhållningsprincip för en blob vid uppladdning:
| Standardprincipstatus för konto eller container | Ladda upp en blob med standardprincipen | Ladda upp en blob med en anpassad princip | Ladda upp en blob utan princip |
|---|---|---|---|
| Standardprincip för konto eller container (olåst) | Blob laddas upp med en olåst standardprincip | Blob laddas upp med anpassad olåst princip | Blob laddas upp utan princip |
| Standardprincip för konto eller container (låst) | Blob laddas upp med en låst standardprincip | Blob laddas upp med anpassad olåst princip | Blob laddas upp utan princip |
| Ingen standardprincip för något konto eller en container | Ej tillämpligt | Blob laddas upp med anpassad olåst princip | Blob laddas upp utan princip |
Konfigurera en princip för en tidigare version
När versionshantering är aktiverat skapar en skrivnings- eller borttagningsåtgärd till en blob en ny tidigare version av bloben som sparar blobens tillstånd före åtgärden. Som standard har en tidigare version den tidsbaserade kvarhållningsprincip som tillämpades för den aktuella versionen, om någon, när den aktuella versionen blev en tidigare version. Den nya aktuella versionen ärver principen på containern, om det finns en.
Om principen som ärvs av en tidigare version är olåst kan kvarhållningsintervallet förkortas eller förlängas, eller så kan principen tas bort. Principen på en tidigare version kan också låsas för den versionen, även om principen för den aktuella versionen är olåst.
Om principen som ärvs av en tidigare version är låst kan kvarhållningsintervallet förlängas. Principen kan inte tas bort och kvarhållningsintervallet kan inte heller förkortas. Om ingen princip har konfigurerats för den aktuella versionen ärver inte den tidigare versionen någon princip.
Du kan konfigurera en anpassad princip för versionen. Om principen för en aktuell version ändras förblir principerna för befintliga tidigare versioner oförändrade, även om principen ärvdes från en aktuell version.
Borttagning
När ett konto eller en container har aktiverats för en oföränderlig princip kan den inte tas bort förrän den är tom. Det viktigaste att tänka på är att det inte spelar någon roll om en oföränderlig princip har ställts in på ett WORM-konto eller en container på versionsnivå, det spelar roll om den är aktiverad för en princip. När det är det måste kontot eller containern vara tomma för att tas bort.
Scenarier
| Scenario | Otillåtna åtgärder | Blobskydd | Containerskydd | Kontoskydd |
|---|---|---|---|---|
| En blobversion skyddas av en aktiv kvarhållningsprincip och/eller ett bevarande av juridiska skäl gäller | Ta bort blob, ange blobmetadata och lägg till sida | Det går inte att ta bort blobversionen. Användarmetadata kan inte skrivas. Om du skriver över en blob med Put Blob, Put Block List eller Copy Blob skapas en ny version1. |
Det går inte att ta bort containrar om det finns minst en blob i containern, oavsett om principen är låst eller olåst. | Det går inte att ta bort lagringskontot om det finns minst en container med oföränderlig lagring på versionsnivå aktiverad, eller om den är aktiverad för kontot. |
| En blobversion skyddas av en kvarhållningsprincip som har upphört att gälla och inget bevarande av juridiska skäl gäller | Ange blobmetadata och placera sida | En blobversion skyddas av en kvarhållningsprincip som har upphört att gälla och inget bevarande av juridiska skäl gäller | Blobversionen kan tas bort. Om du skriver över en blob med Put Blob, Put Block List eller Copy Blob skapas en ny version1. |
Det går inte att ta bort lagringskontot om det finns minst en container som innehåller en blobversion med en låst tidsbaserad kvarhållningsprincip. Olåsda principer ger inte borttagningsskydd. |
1 Blob-versioner är alltid oföränderliga för innehåll. Om versionshantering är aktiverat för lagringskontot skapar en skrivåtgärd till en blockblob en ny version, med undantag för put block-åtgärden.
Gränser
Det kan bara finnas 10 000 containrar som har unika tidsbaserade kvarhållningsprinciper i ett konto. Du kan dock ange en princip på kontonivå som ska ärvas av mer än 10 000 containrar.