Blob-versiebeheer

Je kunt blob-versiebeheer inschakelen om eerdere versies van een object automatisch te behouden. Wanneer je blobversiebeheer inschakelt, kun je eerdere versies van een blob openen om je data te herstellen als deze wordt aangepast of verwijderd.

Let op

Nadat u blobversiebeheer voor een opslagaccount hebt ingeschakeld, resulteert elke schrijfbewerking in een blob in dat account in het maken van een nieuwe versie. Om deze reden kan het inschakelen van blobversiebeheer leiden tot extra kosten. Om kosten te minimaliseren, gebruik je een Lifecycle Management-beleid of een Storage Actions-taak om eerdere versies automatisch te verwijderen.

Blob-versiebeheer is een van de verschillende gegevensbeschermingsfuncties. Het kiezen van de juiste functie of combinatie van functies hangt af van je werklast en waartegen je je beschermt. Voor meer informatie over Microsoft's aanbevelingen voor gegevensbescherming, zie Overzicht gegevensbescherming.

Versies versus snapshots

Een blobversie lijkt op een snapshot, maar de twee verschillen in hoe ze worden gemaakt en waar ze het beste voor geschikt zijn. Een versie is automatisch en systeembeheerd: Azure Storage maakt bij elk schrijven of verwijderen een nieuwe versie aan wanneer blob-versiebeheer is ingeschakeld, zonder dat applicatielogica is vereist. Een snapshot is handmatig en applicatiegestuurd: je maakt expliciet een moment-in-time kopie wanneer je applicatie besluit dat er een nodig is.

Gebruik versiebeheer wanneer je automatische, continue bescherming wilt tegen per ongeluk of kwaadaardige overschrijvingen en verwijderingen. Gebruik snapshots wanneer je bewust gemaakte kopieën van een specifiek tijdstip wilt, zoals een bekende checkpoint vóór een geplande update. Microsoft raadt aan om te stoppen met het maken van snapshots van block blobs zodra versiebeheer is ingeschakeld.

Hoe blobversiebeheer functioneert

Een versie legt de status van een blob vast op een bepaald tijdstip. Elke versie heeft een versie-ID. Wanneer je blob-versiebeheer inschakelt voor een opslagaccount, maakt Azure Storage automatisch een nieuwe versie aan met een unieke ID wanneer je een blob aanmaakt en elke keer dat je de blob aanpast.

Een versie-id kan de huidige versie of een eerdere versie identificeren. Een blob kan slechts één huidige versie tegelijk hebben, namelijk zijn huidige toestand. Een blob kan meerdere eerdere versies hebben.

Wanneer u een nieuwe blob maakt, bestaat er één versie en die versie is de huidige versie. Wanneer u een bestaande blob wijzigt, wordt de huidige versie een eerdere versie. Er wordt een nieuwe versie gemaakt om de bijgewerkte status vast te leggen en die nieuwe versie is de huidige versie. Wanneer u een blob verwijdert, wordt de huidige versie van de blob een eerdere versie en is er geen huidige versie meer. Eventuele eerdere versies van de blob blijven behouden.

Het volgende diagram toont hoe versies worden aangemaakt bij schrijfoperaties, en hoe een eerdere versie kan worden gepromoveerd naar de huidige versie:

Diagram dat laat zien hoe blob-versiebeheer werkt. Eerdere blobversies zijn onveranderlijk, wat betekent dat je de inhoud of metadata niet kunt wijzigen.

Belangrijk

  • Als u een groot aantal versies per blob hebt, kan de latentie voor bewerkingen in blobvermeldingen toenemen. Microsoft raadt aan om minder dan 1.000 versies per blob te onderhouden. Je kunt een Lifecycle Management-beleid of een Storage Actions-taak gebruiken om oude versies automatisch te verwijderen.

  • Blob-versiebeheer kan je niet helpen herstellen van het per ongeluk verwijderen van een opslagaccount of container. Als u wilt voorkomen dat het opslagaccount per ongeluk wordt verwijderd, configureert u een vergrendeling voor de opslagaccountresource. Zie Apply an Azure Resource Manager lock to a storage account voor meer informatie over het vergrendelen van een opslagaccount.

Versie-id

Elke blobversie heeft een unieke versie-ID. De waarde van de versie-ID is de tijdstempel waarop de blob werd bijgewerkt. Je wijst de versie-ID toe wanneer je de versie aanmaakt.

Je kunt een specifieke versie van een blob lezen of verwijderen door het versie-ID te gebruiken. Als je de versie-ID niet toevoegt, richt de operatie zich op de huidige versie.

Wanneer je een schrijfoperatie uitvoert om een blob te creëren of te wijzigen, geeft Azure Storage de x-ms-version-id header terug in het antwoord. Deze header bevat de versie-ID van de huidige versie van de blob die door de schrijfoperatie is aangemaakt.

De versie-ID blijft hetzelfde gedurende de levensduur van de versie.

Versiebeheer voor schrijfbewerkingen

Wanneer je blob-versiebeheer inschakelt, maakt elke schrijfbewerking naar een blob een nieuwe versie aan. Schrijfbewerkingen zijn bijvoorbeeld Put Blob, Put Block List, Copy Blob en Set Blob Metadata.

Als de schrijfoperatie een nieuwe blob aanmaakt, is de resulterende blob de huidige versie van de blob. Als de schrijfoperatie een bestaande blob wijzigt, wordt de huidige versie een eerdere versie, en een nieuwe huidige versie vangt de bijgewerkte blob.

In het volgende diagram ziet u hoe schrijfbewerkingen van invloed zijn op blobversies. Voor de eenvoud tonen de diagrammen in dit artikel de versie-ID als een eenvoudige gehele getallenwaarde. In werkelijkheid is de versie-id een tijdstempel. De huidige versie wordt blauw weergegeven en eerdere versies worden grijs weergegeven.

Diagram waarin wordt getoond hoe schrijfbewerkingen van invloed zijn op versie-blobs.

Notitie

Een blob die je hebt aangemaakt voordat versiebeheer voor het opslagaccount werd ingeschakeld, heeft geen versie-ID. Wanneer je die blob aanpast, wordt de aangepaste blob de nieuwe huidige versie, en wordt de blob zoals die vóór de update was een eerdere versie. De huidige versie krijgt een versie-ID toegewezen die de aanmaaktijd aangeeft.

Wanneer je blob-versiebeheer inschakelt voor een opslagaccount, triggeren alle schrijfbewerkingen op blokblobs het aanmaken van een nieuwe versie, behalve de Put Block-operatie .

Voor pagina-blobs en append-blobs activeert slechts een subset van de schrijfbewerkingen het aanmaken van een versie. Deze bewerkingen omvatten:

De volgende bewerkingen activeren niet het aanmaken van een nieuwe versie:

Om wijzigingen van die operaties vast te leggen, maak je een handmatige snapshot. Voor meer informatie, zie Blob snapshots.

Alle versies van een blob moeten hetzelfde blobtype hebben. Als een blob eerdere versies heeft, kunt u een blob van het ene type niet overschrijven met een ander type, tenzij u eerst de blob en alle bijbehorende versies verwijdert.

Versiebeheer bij verwijderingsbewerkingen

Wanneer je de Delete Blob-operatie uitvoert zonder een versie-ID op te geven, wordt de huidige versie een eerdere versie en is er geen huidige versie meer. De operatie behoudt alle bestaande eerdere versies van de blob.

In het volgende diagram ziet u het effect van een verwijderbewerking op een geversiede blob:

Diagram met het verwijderen van versie-blob.

Als u een specifieke versie van een blob wilt verwijderen, geeft u de id voor die versie op voor de verwijderbewerking. Als je ook blob soft delete inschakelt voor het opslagaccount, behoudt het systeem de versie totdat de soft delete-retentieperiode is verstreken.

Als u nieuwe gegevens naar de blob schrijft, wordt een nieuwe huidige versie van de blob gemaakt. Deze actie heeft geen invloed op bestaande versies, zoals te zien is in het volgende diagram.

Diagram met het opnieuw maken van een geversiede blob na verwijdering.

Toegangsniveaus

U kunt elke versie van een blok-blob, inclusief de huidige versie, naar een andere blobtoegangslaag verplaatsen door de bewerking Blob-laag instellen aan te roepen. Door oudere versies van een blob naar de cool- of archieflaag te verplaatsen, kun je profiteren van lagere capaciteitsprijzen. Zie voor meer informatie de toegangslagen Hot, Cool, Cold en Archief voor blobgegevens.

Om het proces van het verplaatsen van blokblobs naar de juiste laag te automatiseren, maak je een Lifecycle Management-beleid , maak je een Storage Actions-taak aan, of schakel je Smart Tier in.

Blobversiebeheer in- of uitschakelen

Voor instructies over hoe u blob-versiebeheer in- of uitschakelt, zie Inschakelen en beheren van blob-versiebeheer.

Als u blobversiebeheer uitschakelt, worden bestaande blobs, versies of momentopnamen niet verwijderd. Als je blob-versiebeheer uitschakelt, kun je geen nieuwe versies maken.

Nadat je versiebeheer hebt uitgeschakeld, creëert het wijzigen van de huidige versie een blob die geen versie is. Alle volgende updates voor de blob overschrijven de gegevens zonder de vorige status op te slaan. Alle bestaande versies blijven behouden als eerdere versies.

Je kunt versies lezen of verwijderen door de versie-ID te gebruiken nadat versiebeheer is uitgeschakeld. U kunt ook de versies van een blob weergeven nadat versiebeheer is uitgeschakeld.

Objectreplicatie is afhankelijk van blobversiebeheer. Voordat u blobversiebeheer kunt uitschakelen, moet u alle beleidsregels voor objectreplicatie voor het account verwijderen. Zie Objectreplicatie voor blok-blobs voor meer informatie over objectreplicatie.

In het volgende diagram ziet u hoe het wijzigen van een blob nadat versiebeheer is uitgeschakeld, een blob maakt die niet is geversieerd. Eventuele bestaande versies die aan de blob zijn gekoppeld, blijven behouden.

Diagram waarin wordt weergegeven dat bij het wijzigen van een huidige versie nadat versiebeheer is uitgeschakeld, een blob wordt gemaakt die geen versie is.

Functieondersteuning

Ondersteuning voor deze functie kan worden beïnvloed door het inschakelen van Data Lake Storage Gen2, het NFS 3.0-protocol (Network File System) 3.0 of het SSH File Transfer Protocol (SFTP). Als u een van deze mogelijkheden hebt ingeschakeld, raadpleegt u Blob Storage functieondersteuning in Azure Storage accounts om ondersteuning voor deze functie te beoordelen.

Blob-versiebeheer is beschikbaar voor standaard algemeen gebruik v2-, Premium-blok-blob- en verouderde Blob Storage-accounts. Opslagaccounts waarvoor een hiërarchische naamruimte is ingeschakeld voor gebruik met Azure Data Lake Storage worden momenteel niet ondersteund.

Versie 2019-10-10 en hoger van de Azure Storage REST API ondersteunt blobversiebeheer.

Versiebeheer wordt niet ondersteund voor blobs die je uploadt met Data Lake Storage API's.

Bewerkingen voor blobversies autoriseren

Je kunt toegang tot blobversies autoriseren door een van de volgende benaderingen te gebruiken:

  • Gebruik Azure role-based access control (Azure RBAC) om rechten te verlenen aan een Microsoft Entra security principal. Microsoft raadt het gebruik van Microsoft Entra ID aan voor superieure beveiliging en gebruiksgemak. Zie Toegang tot gegevens in Azure Storage voor meer informatie over het gebruik van Microsoft Entra ID met blobbewerkingen.
  • Gebruik een shared access-handtekening (SAS) om toegang te delegeren aan blobversies. Specificeer de versie-ID voor het ondertekende resourcetype bv, dat een blobversie vertegenwoordigt, om een SAS-token te creëren voor operaties op een specifieke versie. Voor meer informatie over handtekeningen voor gedeelde toegang, zie Geef beperkte toegang tot Azure Storage resources met shared access signatures (SAS).
  • Gebruik de accounttoegangssleutels om operaties tegen blobversies te autoriseren door gebruik te maken van Shared Key. Zie Autoriseren met gedeelde sleutel voor meer informatie.

Blob-versiebeheer is ontworpen om uw gegevens te beschermen tegen onbedoelde of schadelijke verwijdering. Als u de beveiliging wilt verbeteren, hebt u speciale machtigingen nodig om een blobversie te verwijderen. In de volgende secties worden de machtigingen beschreven die nodig zijn om een blobversie te verwijderen.

Azure RBAC-actie om een blobversie te verwijderen

In de volgende tabel wordt weergegeven welke Azure RBAC-acties het verwijderen van een blob of blobversie ondersteunen.

Beschrijving Blob-servicebewerking Azure RBAC-gegevensactie vereist Azure ingebouwde ondersteuning voor rollen
De huidige versie verwijderen Blob verwijderen Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete Inzender voor opslagblobgegevens
Een vorige versie verwijderen Blob verwijderen Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action Opslag-blobgegevens eigenaar

Parameters voor gedeelde toegangs-handtekening (SAS)

De ondertekende resource voor een blobversie is bv. Zie Een service-SAS maken of Een SAS voor gebruikersdelegatie maken voor meer informatie.

In de volgende tabel ziet u de machtiging die is vereist voor een SAS om een blobversie te verwijderen.

Machtiging URI-symbool Toegestane bewerkingen
Verwijderen x Een blobversie verwijderen.

Bestaande overwegingen rond werklast

  • Het verwijderen van een blob maakt geen ruimte meer vrij. Wanneer je versiebeheer inschakelt, verwijdert het verwijderen van een blob niet de gegevens. De huidige versie wordt een eerdere versie die blijft bestaan en steeds kosten met zich meebrengt. Workloads die afhankelijk zijn van verwijderoperaties om opslag terug te winnen, blijven kosten maken totdat je die versies expliciet verwijdert.

  • Overschrijf-zware workloads kunnen versies ophopen. Versies blijven bestaan totdat je ze expliciet verwijdert. Deze persistentie kan leiden tot een opeenstapeling van versies als je ze niet goed beheert. Om kosten te verlagen, breng je wijzigingen aan op blokniveau, zodat deze op blokniveau over verschillende versies in rekening worden gebracht en de kosten per versie worden geminimaliseerd.

Interactie tussen functies

Zacht verwijderen

Blob-versiebeheer en voorlopig verwijderen van blobs maken deel uit van de aanbevolen configuratie voor gegevensbeveiliging voor opslagaccounts. Zie het overzicht van gegevensbescherming voor meer informatie over de aanbevelingen van Microsoft voor gegevensbescherming.

Een blob overschrijven

Als je zowel blobversiebeheer als blob soft delete inschakelt voor een opslagaccount, dan creëert het overschrijven van een blob automatisch een nieuwe vorige versie die de status van de blob vóór de schrijfoperatie weerspiegelt. De nieuwe versie wordt niet logisch verwijderd en blijft bestaan totdat deze expliciet wordt verwijderd. Er worden geen zacht verwijderde momentopnamen gemaakt.

Een blob of versie verwijderen

Als je zowel versiebeheer als soft delete inschakelt voor een opslagaccount, wordt de huidige versie van de blob een eerdere versie wanneer je een blob verwijdert. De bewerking maakt geen nieuwe versie of soft-verwijderde snapshots aan. De retentieperiode voor zachte verwijdering geldt niet voor de verwijderde blob.

Soft delete biedt extra bescherming bij het verwijderen van blob-versies. Wanneer je een eerdere versie van de blob verwijdert, wordt die versie voorlopig verwijderd. De voorlopig verwijderde versie blijft behouden totdat de bewaarperiode voor voorlopig verwijderen is verstreken, waarna deze definitief wordt verwijderd.

Als u een eerdere versie van een blob wilt verwijderen, roept u de bewerking Blob verwijderen aan en geeft u de versie-id op.

Een zacht verwijderde versie herstellen

Gebruik de Undelete Blob-operatie om zacht verwijderde versies te herstellen tijdens de retentieperiode van zacht verwijderen. De bewerking Blob ongedaan maken herstelt altijd alle versies van de blob die zacht zijn verwijderd. Je kunt niet slechts één zacht verwijderde versie herstellen.

Het herstellen van zacht verwijderde versies met de Undelete Blob-operatie bevordert geen enkele versie tot de huidige versie. Als u de huidige versie wilt herstellen, herstelt u eerst alle voorlopig verwijderde versies en gebruikt u vervolgens de bewerking Blob kopiëren om een vorige versie naar een nieuwe huidige versie te kopiëren.

Nadat de behoudsperiode voor zacht verwijderen is verstreken, verwijdert het systeem permanent alle zacht verwijderde blob-versies.

Blob-momentopnamen

Een blob-snapshot is een alleen-lezen kopie van een blob die op een bepaald tijdstip is gemaakt. Blob-snapshots en blobversies zijn vergelijkbaar, maar jij of je applicatie maakt handmatig een snapshot aan, terwijl een blob-versie automatisch wordt aangemaakt bij een schrijf- of verwijderoperatie wanneer je blob-versiebeheer voor je opslagaccount inschakelt.

Belangrijk

Nadat je blob-versiebeheer hebt ingeschakeld, update je je applicatie zodat er geen snapshots meer worden gemaakt van blokblobs. Als je versiebeheer voor je opslagaccount inschakelt, vangen en behouden versies alle updates en verwijderingen van blokblobs. Het maken van snapshots biedt geen extra bescherming aan je block blob-data als blobversiemanagement is ingeschakeld, en het kan de kosten en de applicatiecomplexiteit verhogen.

Momentopname van een blob wanneer versiebeheer is ingeschakeld

Hoewel dit niet wordt aangeraden, kun je een snapshot maken van een blob waarvoor ook versiebeheer is ingeschakeld. Als u uw toepassing niet kunt bijwerken om te stoppen met het maken van momentopnamen van blobs wanneer u versiebeheer inschakelt, kan uw toepassing zowel momentopnamen als versies ondersteunen.

Wanneer je een snapshot maakt van een blob met versiebeheer, maak je tegelijkertijd een nieuwe versie aan met de snapshot. Je maakt ook een nieuwe huidige versie aan wanneer je een snapshot maakt.

In het volgende diagram ziet u wat er gebeurt wanneer u een momentopname maakt van een geversiede blob. In het diagram bevatten blobversies en momentopnamen met versie-id 2 en 3 identieke gegevens.

Diagram dat snapshots toont van een blob met versiebeheer.

Bekende beperkingen

  • Niet ondersteund voor accounts met een hiërarchische naamruimte (Azure Data Lake Storage), of voor blobs die zijn geüpload met behulp van Data Lake Storage-API's.

  • Beschermt niet tegen het verwijderen van containers of accounts. Versiebeheer werkt alleen op blob-niveau. Het verwijderen van een container verwijdert alle blobs en hun versies. Herstellen van die verwijdering vereist soft delete voor containers. Bescherming tegen accountverwijdering vereist een resource lock.

  • Versies zijn onveranderlijk. Je kunt de inhoud of metadata van een bestaande versie niet veranderen.

  • Alle versies van een blob moeten hetzelfde blobtype hebben. Je kunt een blob niet overschrijven met een ander blob-type terwijl deze eerdere versies heeft, tenzij je eerst de blob en alle versies verwijdert.

  • Niet alle schrijfbewerkingen maken een versie. Verwijs naar de informatie eerder in dit artikel waarin de uitzonderingen worden beschreven. Om die toestanden vast te leggen, gebruik je een handmatige snapshot.

  • Versiebeheer kan niet worden uitgeschakeld zolang er beleid voor objectreplicatie op het account is ingesteld. Je moet eerst alle beleidsregels voor objectreplicatie verwijderen.

  • Undelete Blob herstelt alle soft-deleted versies van een blob, niet slechts één versie. Je kunt de verwijdering van één versie niet selectief ongedaan maken. Undelete promoot nooit een versie tot de huidige versie.

  • Aanbevolen maximum van 1.000 versies per blob. Het overschrijden hiervan verslechtert de prestaties van het weergeven van blobs.

Prijzen en facturering

Wanneer je blobversiebeheer inschakelt, kun je extra kosten voor gegevensopslag krijgen. Wanneer je je applicatie ontwerpt, denk dan na over hoe deze kosten kunnen oplopen zodat je de kosten laag kunt houden.

Je wordt gefactureerd voor blobversies, zoals blob-snapshots, tegen hetzelfde tarief als actieve data. Hoe je wordt gefactureerd voor versies hangt af van of je expliciet de tier hebt ingesteld voor de huidige of eerdere versies van een blob (of snapshots). Meer informatie over toegangsniveaus vind je in Warme, Koele, Koude en Archief toegangen voor blobgegevens.

Als je de tier van een blob of versie niet verandert, word je gefactureerd voor unieke datablokken over die blob, zijn versies en eventuele snapshots die het heeft. Voor meer informatie, zie Billing wanneer de blob-tier niet expliciet is ingesteld.

Als je de tier van een blob of versie verandert, word je voor het hele object gefactureerd, ongeacht of de blob en versie weer in dezelfde tier terechtkomen. Voor meer informatie, zie Facturering als het blobniveau expliciet is ingesteld.

Notitie

Als je versiebeheer inschakelt voor data die je vaak overschrijft, kun je hogere opslagcapaciteitskosten en meer latentie zien tijdens lijstbewerkingen. Om deze zorgen aan te pakken, sla vaak overschreven gegevens op in een apart opslagaccount met versionering uitgeschakeld.

Als je versies inschakelt op opslagaccounts die vaak worden geback-upt, kun je data-opvragingskosten veroorzaken wanneer de versies op cool- of cold access-niveaus worden opgeslagen.

Zie voor meer informatie over factureringsgegevens van blobmomentopnamen Blob-momentopnamen.

Voor opslagaccounts die Smart Tier gebruiken, betaal je voor versies en snapshots op volledige contentlengte. Zie Kosten optimaliseren met slimme laag voor meer informatie.

Factureren wanneer je de blob-tier niet expliciet instelt

Als je de blob-tier niet expliciet instelt voor geen enkele versie van een blob, betaal je voor unieke blokken of pagina's over alle versies, en eventuele snapshots die het heeft. Je wordt slechts één keer gefactureerd voor data die gedeeld wordt tussen blobversies. Wanneer je een blob bijwerkt, wijkt de data in de nieuwe huidige versie af van de data die in eerdere versies is opgeslagen, waardoor je wordt gefactureerd voor de unieke data per blok of pagina.

Wanneer je een blok binnen een blok-blob vervangt, wordt je voor dat blok als een uniek blok gefactureerd. Deze regel geldt zelfs als het blok dezelfde blok-ID en dezelfde gegevens heeft als in de vorige versie. Nadat je het blok opnieuw hebt gecommit, wijkt het af van het tegenhanger in de vorige versie, en word je voor de data gefactureerd. Dezelfde regel geldt voor een pagina in een page blob die je bijwerkt met identieke data.

Blob storage heeft geen manier om te bepalen of twee blokken identieke data bevatten. Elk blok dat je uploadt en committeert, wordt als uniek behandeld, zelfs als het dezelfde data en dezelfde blok-ID heeft. Omdat je wordt gefactureerd voor unieke blokken, houd er rekening mee dat het bijwerken van een blob wanneer versiebeheer is ingeschakeld extra unieke blokken en extra kosten oplevert.

Wanneer je blobversiebeheer inschakelt, roep dan update-operaties op block blobs aan zodat ze het zo min mogelijk aantal blokken updaten. De schrijfbewerkingen die fijnmazige controle over blokken toestaan, zijn Put Block en Put Block List. Put Block plaatst de wijzigingen in staging, maar de daadwerkelijke wijziging en versiecreatie gebeurt via de Put Block List-operatie. De Put Blob-operatie daarentegen vervangt de volledige inhoud van een blob en kan daardoor tot extra kosten leiden.

De volgende scenario's laten zien hoe er charges worden opgebouwd voor een block blob en zijn versies wanneer je de blob-laag niet expliciet instelt.

Scenario 1

In scenario 1 heeft de blob een eerdere versie. De blob is niet bijgewerkt sinds de versie is aangemaakt, dus betaal je alleen voor de unieke blokken 1, 2 en 3.

Diagram 1 toont de facturering voor unieke blokken in de basisblob en de vorige versie.

Scenario 2

In scenario 2 wordt één blok (blok 3 in het diagram) in de blob bijgewerkt. Hoewel het bijgewerkte blok dezelfde gegevens en dezelfde id bevat, is het niet hetzelfde als blok 3 in de vorige versie. Als gevolg hiervan wordt het account belast voor vier blokken.

Diagram 2 toont facturering voor unieke blokken in de basisblob en de vorige versie.

Scenario 3

In scenario 3 wordt de blob bijgewerkt, maar de versie niet. Blok 3 wordt vervangen door blok 4 in de huidige blob, maar de vorige versie weerspiegelt nog steeds blok 3. Als gevolg hiervan wordt het account belast voor vier blokken.

Diagram 3 toont de facturering voor unieke blokken in de basisblob en de vorige versie.

Scenario 4

In scenario 4 is de huidige versie volledig bijgewerkt en bevat geen van de oorspronkelijke blokken ervan. Daardoor wordt het account belast voor alle acht unieke blokken - vier in de huidige versie, en vier gecombineerd in de twee vorige versies. Dit scenario kan voorkomen als je naar een blob schrijft met de Put Blob-operatie , omdat deze de volledige inhoud van de blob vervangt.

Diagram 4 toont de facturering voor unieke blokken in de basisblob en de vorige versie.

Factureren wanneer je expliciet de blob-tier instelt

Als je expliciet de blob-tier instelt voor een blob, versie of snapshot, betaal je voor de volledige contentlengte van het object in de nieuwe tier, ongeacht of het blokken deelt met een object in de oorspronkelijke tier. Je betaalt ook voor de volledige inhoudslengte van de oudste versie in de originele tier. Voor andere eerdere versies of snapshots die in de originele laag blijven, betaal je voor unieke blokken die ze delen, zoals beschreven in Billing wanneer de blob-tier niet expliciet is ingesteld.

Een blob verplaatsen naar een nieuwe laag

De volgende tabel beschrijft het factureringsgedrag voor een blob of versie wanneer je deze naar een nieuwe laag verplaatst.

Wanneer je het blob-niveau instelt… Vervolgens wordt u gefactureerd voor...
Expliciet ingesteld op een versie, huidige of vorige De volledige inhoudslengte van die versie. Versies die geen expliciet ingestelde laag hebben, worden alleen gefactureerd voor unieke blokken.1
Gearchiveerd De volledige inhoud van alle versies en snapshots. 1

1Als er andere eerdere versies of snapshots zijn die je niet van hun oorspronkelijke laag hebt verplaatst, worden die versies of snapshots belast op basis van het aantal unieke blokken dat ze bevatten, zoals beschreven in Billing wanneer de blob-tier niet expliciet is ingesteld.

Het volgende diagram laat zien hoe objecten worden gefactureerd wanneer je een blob met versiebeheer naar een andere laag verplaatst.

Diagram waarin wordt getoond hoe objecten worden gefactureerd wanneer een gevensioneerde blob expliciet in lagen wordt onderverdeeld.

Je kunt het expliciet instellen van de tier voor een blob, versie of snapshot niet ongedaan maken. Als je een blob naar een nieuwe tier verplaatst en daarna terug naar de oorspronkelijke tier, betaal je voor de volledige contentlengte van het object, zelfs als het blokken deelt met andere objecten in de oorspronkelijke tier.

Bewerkingen die expliciet de laag van een blob, versie of momentopname instellen, zijn onder andere:

Een blob verwijderen wanneer soft delete is ingeschakeld

Wanneer je blob soft delete inschakelt, betaal je voor alle soft verwijderde entiteiten tegen hetzelfde tarief als live data. Als je een huidige versie verwijdert of overschrijft waarvoor je expliciet de tier hebt ingesteld, betaal je voor eerdere versies van de zacht verwijderde blob op volledige contentlengte. Voor meer informatie over hoe blob-versiebeheer en soft delete samenwerken, zie Feature-interacties.

Bewaking en problemen oplossen

  • Mijn LCM-beleid verwijdert geen versies wanneer ik verwacht: De leeftijd van een versie is gebaseerd op wanneer je oorspronkelijk de data hebt geschreven, niet wanneer het een eerdere versie werd. De klok begint bij het aanmaken van de blob, niet bij de overschrijving waardoor deze in de versiegeschiedenis terechtkwam. Daardoor kan een blob die lange tijd actueel bleef voordat hij werd overschreven, een eerdere versie produceren die je daysAfterCreationGreaterThan drempel al overschrijdt op het moment dat hij wordt aangemaakt, waardoor deze vrijwel direct wordt verwijderd. Omgekeerd kunnen versies van recent aangemaakte blobs langer blijven bestaan dan verwacht. Controleer ter bevestiging de daadwerkelijke aanmaaktijdstempel op de versies in plaats van aan te nemen dat deze overeenkomt met de overschrijftijd. Als je retentie moet baseren op wanneer een versie niet meer actueel werd of meer gedetailleerde controle wilt dan de daggebaseerde drempels van lifecycle management toestaan, overweeg dan in plaats daarvan Azure Storage Actions te gebruiken. Voor meer informatie, zie Opslagacties.

  • Mijn factuurbedrag blijft hoog na het uitschakelen van versies: Bestaande versies blijven bestaan totdat je ze handmatig verwijdert.

  • Ik kan versiebeheer niet uitschakelen. Objectreplicatie kan op het account worden geconfigureerd. Verwijder eerst alle beleidsregels voor objectreplicatie en schakel daarna versiebeheer uit. Alternatief kan er een Immutability (WORM)-beleid bestaan op een container of account waarvoor versiebeheer niet kan worden uitgeschakeld.

Zie ook

  • Laatst bijgewerkt om