Blob-versiebeheer
U kunt versiebeheer van Blob Storage inschakelen om automatisch eerdere versies van een object te onderhouden. Wanneer blobversiebeheer is ingeschakeld, hebt u toegang tot eerdere versies van een blob om uw gegevens te herstellen als deze worden gewijzigd of verwijderd.
Aanbevolen configuratie voor gegevensbeveiliging
Blob-versiebeheer maakt deel uit van een uitgebreide strategie voor gegevensbescherming voor blobgegevens. Voor optimale beveiliging van uw blobgegevens raadt Microsoft aan om alle volgende functies voor gegevensbeveiliging in te schakelen:
- Blob-versiebeheer om eerdere versies van een blob automatisch te onderhouden. Wanneer blobversiebeheer is ingeschakeld, kunt u een eerdere versie van een blob herstellen om uw gegevens te herstellen als deze onjuist zijn gewijzigd of verwijderd. Zie Blob-versiebeheer inschakelen en beheren voor meer informatie over het inschakelen van blobversiebeheer.
- Voorlopig verwijderen van container om een container te herstellen die is verwijderd. Zie Voorlopig verwijderen voor containers inschakelen en beheren voor meer informatie over het inschakelen van voorlopig verwijderen van containers.
- Voorlopig verwijderen van blob, om een blob, momentopname of versie te herstellen die is verwijderd. Zie Voorlopig verwijderen voor blobs inschakelen en beheren voor meer informatie over het inschakelen van voorlopig verwijderen van blobs.
Zie het overzicht van gegevensbescherming voor meer informatie over de aanbevelingen van Microsoft voor gegevensbescherming.
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. Daarom kan het inschakelen van blobversiebeheer leiden tot extra kosten. Als u kosten wilt minimaliseren, gebruikt u een levenscyclusbeheerbeleid om oude versies automatisch te verwijderen. Zie Kosten optimaliseren door azure Blob Storage-toegangslagen te automatiseren voor meer informatie over levenscyclusbeheer.
Hoe blobversiebeheer werkt
Een versie legt de status van een blob vast op een bepaald tijdstip. Elke versie wordt geïdentificeerd met een versie-id. Wanneer blobversiebeheer is ingeschakeld voor een opslagaccount, maakt Azure Storage automatisch een nieuwe versie met een unieke id wanneer een blob voor het eerst wordt gemaakt en telkens wanneer de blob vervolgens wordt gewijzigd.
Een versie-id kan de huidige versie of een eerdere versie identificeren. Een blob kan slechts één huidige versie tegelijk 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.
In het volgende diagram ziet u hoe versies worden gemaakt voor schrijfbewerkingen en hoe een eerdere versie kan worden gepromoveerd tot de huidige versie:
Blob-versies zijn onveranderbaar. U kunt de inhoud of metagegevens van een bestaande blobversie niet wijzigen.
Als u een groot aantal versies per blob hebt, kan de latentie voor bewerkingen in blobvermeldingen toenemen. Microsoft raadt aan minder dan 1000 versies per blob te onderhouden. U kunt levenscyclusbeheer gebruiken om oude versies automatisch te verwijderen. Zie Kosten optimaliseren door azure Blob Storage-toegangslagen te automatiseren voor meer informatie over levenscyclusbeheer.
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 Gen2, worden momenteel niet ondersteund.
Versie 2019-10-10 en hoger van de Azure Storage REST API ondersteunt blobversiebeheer.
Belangrijk
Blob-versiebeheer kan u niet helpen om te herstellen van het onbedoeld 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 Een Azure Resource Manager-vergrendeling toepassen op een opslagaccount voor meer informatie over het vergrendelen van een opslagaccount.
Versie-id
Elke blobversie wordt geïdentificeerd met een unieke versie-id. De waarde van de versie-id is de tijdstempel waarop de blob is bijgewerkt. De versie-id wordt toegewezen op het moment dat de versie wordt gemaakt.
U kunt lees- of verwijderbewerkingen uitvoeren op een specifieke versie van een blob door de versie-id op te geven. Als u de versie-id weglaat, werkt de bewerking tegen de huidige versie.
Wanneer u een schrijfbewerking aanroept om een blob te maken of te wijzigen, retourneert Azure Storage de header x-ms-version-id in het antwoord. Deze header bevat de versie-id voor de huidige versie van de blob die is gemaakt door de schrijfbewerking.
De versie-id blijft hetzelfde voor de levensduur van de versie.
Versiebeheer voor schrijfbewerkingen
Wanneer blobversiebeheer is ingeschakeld, maakt elke schrijfbewerking naar een blob een nieuwe versie. Schrijfbewerkingen zijn onder andere Put Blob, Put Block List, Copy Blob en Set Blob Metadata.
Als de schrijfbewerking een nieuwe blob maakt, is de resulterende blob de huidige versie van de blob. Als de schrijfbewerking een bestaande blob wijzigt, wordt de huidige versie een vorige versie en wordt er een nieuwe huidige versie gemaakt om de bijgewerkte blob vast te leggen.
In het volgende diagram ziet u hoe schrijfbewerkingen van invloed zijn op blobversies. Voor het gemak worden in de diagrammen die in dit artikel worden weergegeven, de versie-id weergegeven als een eenvoudige geheel getalwaarde. In werkelijkheid is de versie-id een tijdstempel. De huidige versie wordt blauw weergegeven en eerdere versies worden grijs weergegeven.
Notitie
Een blob die is gemaakt voordat versiebeheer voor het opslagaccount is ingeschakeld, heeft geen versie-id. Wanneer deze blob wordt gewijzigd, wordt de gewijzigde blob de huidige versie en wordt er een versie gemaakt om de status van de blob op te slaan vóór de update. Aan de versie wordt een versie-id toegewezen die de aanmaaktijd is.
Wanneer blobversiebeheer is ingeschakeld voor een opslagaccount, activeren alle schrijfbewerkingen op blok-blobs het maken van een nieuwe versie, met uitzondering van de Put Block-bewerking .
Voor pagina-blobs en toevoeg-blobs activeert alleen een subset schrijfbewerkingen het maken van een versie. Deze bewerkingen omvatten:
Met de volgende bewerkingen wordt het maken van een nieuwe versie niet geactiveerd. Als u wijzigingen van deze bewerkingen wilt vastleggen, maakt u een handmatige momentopname:
- Pagina plaatsen (pagina-blob)
- Toevoegblok (toevoeg-blob)
Alle versies van een blob moeten van hetzelfde blobtype zijn. 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 u de bewerking Blob verwijderen aanroept zonder een versie-id op te geven, wordt de huidige versie een eerdere versie en is er geen huidige versie meer. Alle bestaande eerdere versies van de blob blijven behouden.
In het volgende diagram ziet u het effect van een verwijderbewerking op een geversiede blob:
Als u een specifieke versie van een blob wilt verwijderen, geeft u de id voor die versie op voor de verwijderbewerking. Als voorlopig verwijderen van blobs ook is ingeschakeld voor het opslagaccount, blijft de versie in het systeem behouden totdat de bewaarperiode voor voorlopig verwijderen is verstreken.
Als u nieuwe gegevens naar de blob schrijft, wordt een nieuwe huidige versie van de blob gemaakt. Eventuele bestaande versies worden niet beïnvloed, zoals wordt weergegeven in het volgende diagram.
Toegangslagen
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. U kunt profiteren van lagere capaciteitsprijzen door oudere versies van een blob te verplaatsen naar de statische of archieflaag. Zie de toegangslagen Dynamisch, Statisch, Koud en Archief voor blobgegevens voor meer informatie.
Gebruik bloblevenscyclusbeheer om het proces van het verplaatsen van blok-blobs naar de juiste laag te automatiseren. Zie De levenscyclus van Azure Blob Storage beheren voor meer informatie over levenscyclusbeheer.
Blobversiebeheer in- of uitschakelen
Als u blobversiebeheer uitschakelt, worden bestaande blobs, versies of momentopnamen niet verwijderd. Wanneer u blobversiebeheer uitschakelt, blijven bestaande versies toegankelijk in uw opslagaccount. Er worden vervolgens geen nieuwe versies gemaakt.
Nadat versiebeheer is uitgeschakeld, maakt 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.
U kunt versies lezen of verwijderen met behulp van de versie-id 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.
Blob-versiebeheer en voorlopig verwijderen
Blob-versiebeheer en voorlopig verwijderen van blobs maken deel uit van de aanbevolen configuratie voor gegevensbeveiliging voor opslagaccounts. Zie Aanbevolen configuratie voor gegevensbescherming in dit artikel en overzicht van gegevensbescherming voor meer informatie over de aanbevelingen van Microsoft voor gegevensbescherming.
Een blob overschrijven
Als blobversiebeheer en voorlopig verwijderen van blobs beide zijn ingeschakeld voor een opslagaccount, wordt automatisch een nieuwe versie gemaakt door een blob te overschrijven. De nieuwe versie wordt niet voorlopig verwijderd en wordt niet verwijderd wanneer de bewaarperiode voor voorlopig verwijderen verloopt. Er worden geen voorlopig verwijderde momentopnamen gemaakt.
Een blob of versie verwijderen
Als versiebeheer en voorlopig verwijderen beide zijn ingeschakeld voor een opslagaccount, wordt de huidige versie van de blob een eerdere versie wanneer u een blob verwijdert. Er wordt geen nieuwe versie gemaakt en er worden geen voorlopig verwijderde momentopnamen gemaakt. De bewaarperiode voor voorlopig verwijderen is niet van kracht voor de verwijderde blob.
Voorlopig verwijderen biedt extra beveiliging voor het verwijderen van blobversies. Wanneer u 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.
In het volgende diagram ziet u wat er gebeurt wanneer u een blob of blobversie verwijdert.
Een voorlopig verwijderde versie herstellen
U kunt de bewerking Blob ongedaan maken gebruiken om voorlopig verwijderde versies te herstellen tijdens de bewaarperiode voor voorlopig verwijderen. Met de bewerking Blob ongedaan maken worden altijd alle voorlopig verwijderde versies van de blob hersteld. Het is niet mogelijk om slechts één voorlopig verwijderde versie te herstellen.
Als u voorlopig verwijderde versies herstelt met de bewerking Blob Ongedaan maken, wordt er geen versie gepromoot als 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.
In het volgende diagram ziet u hoe u voorlopig verwijderde blobversies herstelt met de bewerking Blob Ongedaan maken en hoe u de huidige versie van de blob herstelt met de bewerking Blob kopiëren.
Nadat de bewaarperiode voor voorlopig verwijderen is verstreken, worden eventuele voorlopig verwijderde blobversies definitief verwijderd.
Blob-versiebeheer en blobmomentopnamen
Een blob-momentopname is een alleen-lezen kopie van een blob die op een bepaald tijdstip wordt gemaakt. Blob-momentopnamen en blobversies zijn vergelijkbaar, maar er wordt handmatig een momentopname gemaakt door u of uw toepassing, terwijl er automatisch een blobversie wordt gemaakt op een schrijf- of verwijderbewerking wanneer blobversiebeheer is ingeschakeld voor uw opslagaccount.
Belangrijk
Microsoft raadt aan dat u na het inschakelen van blobversiebeheer ook uw toepassing bijwerkt om te stoppen met het maken van momentopnamen van blok-blobs. Als versiebeheer is ingeschakeld voor uw opslagaccount, worden alle blok-blob-updates en -verwijderingen vastgelegd en bewaard door versies. Het maken van momentopnamen biedt geen extra beveiliging voor uw blok-blobgegevens als blobversiebeheer is ingeschakeld en kan de kosten en de complexiteit van de toepassing verhogen.
Momentopname van een blob wanneer versiebeheer is ingeschakeld
Hoewel het niet wordt aanbevolen, kunt u een momentopname maken van een blob die ook is geversieerd. 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 u een momentopname van een geversiede blob maakt, wordt er een nieuwe versie gemaakt op hetzelfde moment dat de momentopname wordt gemaakt. Er wordt ook een nieuwe huidige versie gemaakt wanneer er een momentopname wordt gemaakt.
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.
Bewerkingen voor blobversies autoriseren
U kunt toegang tot blobversies autoriseren met behulp van een van de volgende methoden:
- Door op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) te gebruiken om machtigingen te verlenen aan een Microsoft Entra-beveiligingsprincipaal. Microsoft raadt aan Microsoft Entra ID te gebruiken voor superieure beveiliging en gebruiksgemak. Zie Toegang tot gegevens in Azure Storage autoriseren voor meer informatie over het gebruik van Microsoft Entra-id met blobbewerkingen.
- Door een Shared Access Signature (SAS) te gebruiken om toegang tot blobversies te delegeren. Geef de versie-id op voor het ondertekende resourcetype
bv, dat een blobversie vertegenwoordigt, om een SAS-token te maken voor bewerkingen op een specifieke versie. Zie Beperkte toegang verlenen tot Azure Storage-resources met behulp van Sas (Shared Access Signatures ) voor meer informatie over handtekeningen voor gedeelde toegang. - Door de toegangssleutels van het account te gebruiken om bewerkingen te autoriseren voor blobversies met gedeelde sleutel. 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 voor het verwijderen van een blobversie
In de volgende tabel ziet u welke Azure RBAC-acties ondersteuning bieden voor het verwijderen van een blob of een blobversie.
| Beschrijving | Blob-servicebewerking | Azure RBAC-gegevensactie vereist | Ingebouwde azure-rolondersteuning |
|---|---|---|---|
| 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 |
Sas-parameters (Shared Access Signature)
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 |
|---|---|---|
| Delete | x | Een blobversie verwijderen. |
Prijzen en facturering
Het inschakelen van blobversiebeheer kan leiden tot extra kosten voor gegevensopslag voor uw account. Bij het ontwerpen van uw toepassing is het belangrijk om te weten hoe deze kosten kunnen worden opgebouwd, zodat u de kosten kunt minimaliseren.
Blob-versies, zoals blob-momentopnamen, worden gefactureerd met hetzelfde tarief als actieve gegevens. Hoe versies worden gefactureerd, is afhankelijk van of u de laag expliciet hebt ingesteld voor de huidige of vorige versies van een blob (of momentopnamen). Zie de toegangslagen Dynamisch, Statisch, Koud en Archief voor blobgegevens voor meer informatie over bloblagen.
Als u de laag van een blob of versie niet hebt gewijzigd, wordt u gefactureerd voor unieke gegevensblokken in die blob, de bijbehorende versies en eventuele momentopnamen. Zie Facturering wanneer de bloblaag niet expliciet is ingesteld voor meer informatie.
Als u de laag van een blob of versie hebt gewijzigd, wordt u gefactureerd voor het hele object, ongeacht of de blob en versie zich uiteindelijk opnieuw in dezelfde laag bevinden. Zie Facturering wanneer de bloblaag expliciet is ingesteld voor meer informatie.
Notitie
Het inschakelen van versiebeheer voor gegevens die vaak worden overschreven, kan leiden tot hogere kosten voor opslagcapaciteit en een hogere latentie tijdens het weergeven van bewerkingen. Om deze problemen te verhelpen, slaat u regelmatig overschreven gegevens op in een afzonderlijk opslagaccount waarbij versiebeheer is uitgeschakeld.
Zie Blob-momentopnamen voor meer informatie over factureringsgegevens voor blobmomentopnamen.
Facturering wanneer de bloblaag niet expliciet is ingesteld
Als u de bloblaag niet expliciet hebt ingesteld voor versies van een blob, worden er kosten in rekening gebracht voor unieke blokken of pagina's in alle versies en eventuele momentopnamen. Gegevens die worden gedeeld in blobversies, worden slechts eenmaal in rekening gebracht. Wanneer een blob wordt bijgewerkt, worden de gegevens in de nieuwe huidige versie afgeleid van de gegevens die zijn opgeslagen in eerdere versies en worden de unieke gegevens per blok of pagina in rekening gebracht.
Wanneer u een blok in een blok-blob vervangt, wordt dat blok vervolgens in rekening gebracht als een uniek blok. Dit geldt zelfs als het blok dezelfde blok-id heeft en dezelfde gegevens als in de vorige versie. Nadat het blok opnieuw is doorgevoerd, wijkt het af van de tegenhanger in de vorige versie en worden er kosten in rekening gebracht voor de gegevens. Hetzelfde geldt voor een pagina in een pagina-blob die wordt bijgewerkt met identieke gegevens.
Blob Storage heeft geen manier om te bepalen of twee blokken identieke gegevens bevatten. Elk blok dat wordt geüpload en vastgelegd, wordt beschouwd als uniek, zelfs als het dezelfde gegevens en dezelfde blok-id heeft. Omdat de kosten voor unieke blokken toenemen, is het belangrijk om er rekening mee te houden dat het bijwerken van een blob wanneer versiebeheer is ingeschakeld, leidt tot extra unieke blokken en extra kosten.
Wanneer blobversiebeheer is ingeschakeld, roept u updatebewerkingen aan op blok-blobs, zodat ze het minst mogelijke aantal blokken bijwerken. De schrijfbewerkingen die fijnmazige controle over blokken toestaan, zijn Put Block en Put Block List. De put-blobbewerking vervangt daarentegen de volledige inhoud van een blob en kan leiden tot extra kosten.
In de volgende scenario's ziet u hoe de kosten voor een blok-blob en de bijbehorende versies toenemen wanneer de bloblaag niet expliciet is ingesteld.
Scenario 1
In scenario 1 heeft de blob een eerdere versie. De blob is niet bijgewerkt sinds de versie is gemaakt. Er worden dus alleen kosten in rekening gebracht voor unieke blokken 1, 2 en 3.
Scenario 2
In scenario 2 is éé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 worden er vier blokken in rekening gebracht voor het account.
Scenario 3
In scenario 3 is de blob bijgewerkt, maar de versie niet. Blok 3 is vervangen door blok 4 in de huidige blob, maar de vorige versie weerspiegelt nog steeds blok 3. Als gevolg hiervan worden er vier blokken in rekening gebracht voor het account.
Scenario 4
In scenario 4 is de huidige versie volledig bijgewerkt en bevat deze geen van de oorspronkelijke blokken. Als gevolg hiervan wordt het account in rekening gebracht voor alle acht unieke blokken, vier in de huidige versie en vier gecombineerd in de twee vorige versies. Dit scenario kan optreden als u naar een blob schrijft met de bewerking Put Blob , omdat deze de volledige inhoud van de blob vervangt.
Facturering wanneer de bloblaag expliciet is ingesteld
Als u de bloblaag expliciet hebt ingesteld voor een blob of versie (of momentopname), worden er kosten in rekening gebracht voor de volledige inhoudslengte van het object in de nieuwe laag, ongeacht of deze blokken deelt met een object in de oorspronkelijke laag. Er worden ook kosten in rekening gebracht voor de volledige inhoudslengte van de oudste versie in de oorspronkelijke laag. Eventuele andere eerdere versies of momentopnamen die in de oorspronkelijke laag blijven, worden in rekening gebracht voor unieke blokken die ze kunnen delen, zoals beschreven in Facturering wanneer de bloblaag niet expliciet is ingesteld.
Een blob verplaatsen naar een nieuwe laag
In de volgende tabel wordt het factureringsgedrag voor een blob of versie beschreven wanneer deze wordt verplaatst naar een nieuwe laag.
| Wanneer de bloblaag is ingesteld... | Vervolgens wordt u gefactureerd voor... |
|---|---|
| Expliciet op een versie, of dit nu actueel of eerder is | De volledige inhoudslengte van die versie. Versies die geen expliciet ingestelde laag hebben, worden alleen gefactureerd voor unieke blokken.1 |
| Archiveren | De volledige inhoudslengte van alle versies en momentopnamen.1. |
1Als er andere eerdere versies of momentopnamen zijn die niet zijn verplaatst van de oorspronkelijke laag, worden deze versies of momentopnamen in rekening gebracht op basis van het aantal unieke blokken dat ze bevatten, zoals beschreven in Facturering wanneer de bloblaag niet expliciet is ingesteld.
In het volgende diagram ziet u hoe objecten worden gefactureerd wanneer een geversiede blob naar een andere laag wordt verplaatst.
Het expliciet instellen van de laag voor een blob, versie of momentopname kan niet ongedaan worden gemaakt. Als u een blob verplaatst naar een nieuwe laag en deze vervolgens weer verplaatst naar de oorspronkelijke laag, worden er kosten in rekening gebracht voor de volledige inhoudslengte van het object, zelfs als het blokken deelt met andere objecten in de oorspronkelijke laag.
Bewerkingen die expliciet de laag van een blob, versie of momentopname instellen, zijn onder andere:
- Set Blob Tier (Blob-laag instellen)
- Blob plaatsen met laag opgegeven
- Lijst met blokken plaatsen met opgegeven laag
- Blob kopiëren met laag opgegeven
Een blob verwijderen wanneer voorlopig verwijderen is ingeschakeld
Wanneer voorlopig verwijderen van blobs is ingeschakeld, worden alle voorlopig verwijderde entiteiten gefactureerd op volledige inhoudslengte. Als u een huidige versie verwijdert of overschrijft waarvan de laag expliciet is ingesteld, worden eventuele eerdere versies van de voorlopig verwijderde blob gefactureerd op volledige inhoudslengte. Zie Blob-versiebeheer en voorlopig verwijderen voor meer informatie over hoe blobversiebeheer en voorlopig verwijderen samenwerken.
Functieondersteuning
Ondersteuning voor deze functie kan worden beïnvloed door het inschakelen van Data Lake Storage Gen2, het NFS-protocol (Network File System) 3.0 of het SSH File Transfer Protocol (SFTP). Als u een van deze mogelijkheden hebt ingeschakeld, raadpleegt u de ondersteuning voor Blob Storage-functies in Azure Storage-accounts om ondersteuning voor deze functie te beoordelen.
Versiebeheer wordt niet ondersteund voor blobs die worden geüpload met behulp van Data Lake Storage Gen2-API's .