Blobversies
U kunt blobopslagversies inschakelen om automatisch eerdere versies van een object te onderhouden. Wanneer blobversies zijn ingeschakeld, kunt u een eerdere versie van een blob herstellen om uw gegevens te herstellen als deze per ongeluk worden gewijzigd of verwijderd.
Aanbevolen configuratie voor gegevensbeveiliging
Blobversies maken deel uit van een uitgebreide strategie voor gegevensbeveiliging voor blobgegevens. Voor optimale beveiliging voor uw blobgegevens raadt Microsoft u aan om alle volgende functies voor gegevensbeveiliging in te stellen:
- Blobversies, om automatisch eerdere versies van een blob te onderhouden. Wanneer blobversies zijn ingeschakeld, kunt u een eerdere versie van een blob herstellen om uw gegevens te herstellen als deze per ongeluk worden gewijzigd of verwijderd. Zie Blobversies inschakelen en beheren voor meer informatie over het inschakelen van blobversies.
- Container voor het herstellen van een container die is verwijderd. Zie Enable and manage soft delete for containers (Soft Delete inschakelen en beheren voor containers) voor meer informatie over het inschakelen van de functie voor het inschakelen van het verwijderen van containers.
- Blob soft delete om een verwijderde blob, momentopname of versie te herstellen. Zie Enable and manage soft delete for blobs (Soft Delete voor blobs inschakelen en beheren) voor meer informatie over het inschakelen van blobs voor het inschakelen van blobs.
Zie Overzicht van gegevensbescherming voor meer informatie over de aanbevelingen van Microsoft voor gegevensbeveiliging.
Hoe blobversies werken
Een versie legt de status van een blob op een bepaald moment vast. Elke versie wordt aangeduid met een versie-id. Wanneer blobversies zijn 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. Deze 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. Eerdere versies van de blob blijven bestaan.
In het volgende diagram ziet u hoe versies worden gemaakt voor schrijfbewerkingen en hoe een eerdere versie kan worden gepromoveerd tot de huidige versie:
Blobversies zijn onveranderbaar. U kunt de inhoud of metagegevens van een bestaande blobversie niet wijzigen.
Een groot aantal versies per blob kan de latentie voor blobvermeldingsbewerkingen verhogen. Microsoft raadt aan minder dan 1000 versies per blob te onderhouden. U kunt levenscyclusbeheer gebruiken om automatisch oude versies te verwijderen. Zie Kosten optimaliseren door Azure Blob-Storage te automatiseren voor meerinformatie over levenscyclusbeheer.
Blobversies zijn beschikbaar voor standaard algemeen v2-, Premium-blok-blob- en verouderde Blob Storage-accounts. Storage accounts met een hiërarchische naamruimte 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 ondersteuning voor blobversies.
Belangrijk
Blobversies kunnen u niet helpen bij het herstellen van het onbedoeld verwijderen van een opslagaccount of container. Configureer een vergrendeling van de opslagaccountresource om onbedoeld verwijderen van het opslagaccount te voorkomen. Zie Apply an Azure Resource Manager lock to a storage account (Een opslagvergrendeling toepassen op een opslagaccount) voor meer informatie over het vergrendelen van een opslagaccount.
Versie-id
Elke blobversie wordt aangeduid met een unieke versie-id. De waarde van de versie-id is het 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 weglaten, de bewerking wordt uitgevoerd op de huidige versie.
Wanneer u een schrijfbewerking aanroept om een blob te maken of te wijzigen, 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.
Versierbewerkingen voor schrijfbewerkingen
Wanneer blobversies zijn ingeschakeld, maakt elke schrijfbewerking naar een blob een nieuwe versie. Schrijfbewerkingen zijn onder andere Put Blob, Put Block List, Copy Bloben Set Blob Metadata.
Als met de schrijfbewerking een nieuwe blob wordt gemaakt, is de resulterende blob de huidige versie van de blob. Als de schrijfbewerking een bestaande blob wijzigt, wordt de huidige versie een eerdere versie en wordt er een nieuwe huidige versie gemaakt om de bijgewerkte blob vast te leggen.
In het volgende diagram ziet u hoe schrijfbewerkingen invloed hebben op blobversies. Ter vereenvoudiging geven de diagrammen in dit artikel de versie-id weer als een eenvoudig geheel getal. 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 versie-versies werden ingeschakeld voor het opslagaccount 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 vóór de update op te slaan. Aan de versie wordt een versie-id toegewezen die de aanmaaktijd is.
Wanneer blobversies zijn ingeschakeld voor een opslagaccount, activeren alle schrijfbewerkingen op blok-blobs het maken van een nieuwe versie, met uitzondering van de bewerking Put Block.
Voor pagina-blobs en toevoegen-blobs wordt het maken van een versie alleen door een subset van schrijfbewerkingen mogelijk gemaakt. Deze bewerkingen omvatten:
De volgende bewerkingen activeren niet het maken van een nieuwe versie. Als u wijzigingen uit deze bewerkingen wilt vastleggen, maakt u een handmatige momentopname:
- Pagina plaatsen (pagina-blob)
- Blok voor append (blob voor append)
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 versies ervan verwijdert.
Versierbewerkingen voor verwijderbewerkingen
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 versie-blob:
Als u een specifieke versie van een blob wilt verwijderen, geeft u de id voor die versie op bij de verwijderbewerking. Als de functie voor het verwijderen van blobs ook is ingeschakeld voor het opslagaccount, blijft de versie in het systeem behouden totdat de retentieperiode voor het verwijderen van de zachte blob is verstreken.
Als u nieuwe gegevens naar de blob schrijft, wordt er 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, met inbegrip van de huidige versie, verplaatsen naar een andere blob-toegangslaag door de bewerking Bloblaag instellen aan te roepen. U kunt profiteren van lagere capaciteitsprijzen door oudere versies van een blob naar de cool- of archieflaag te verplaatsen. Zie Hot-, Cool- en Archive-toegangslagen voor blobgegevens voor meer informatie.
Als u het proces van het verplaatsen van blok-blobs naar de juiste laag wilt automatiseren, gebruikt u levenscyclusbeheer voor blobs. Zie De levenscyclus van Azure Blob-opslag beheren voor meer informatie over levenscyclusbeheer.
Blobversies in- of uitschakelen
Zie Blobversies inschakelen en beheren voor meer informatie over het in- of uitschakelen van blobversies.
Bij het uitschakelen van blobversies worden bestaande blobs, versies of momentopnamen niet verwijderd. Wanneer u blobversies uit schakelen, blijven alle bestaande versies toegankelijk in uw opslagaccount. Er worden vervolgens geen nieuwe versies gemaakt.
Als er een blob is gemaakt of gewijzigd nadat versien is uitgeschakeld in het opslagaccount, wordt er een nieuwe versie gemaakt door de blob te overschrijven. De bijgewerkte blob is niet langer de huidige versie en heeft geen versie-id. Alle volgende updates voor de blob overschrijven de gegevens zonder de vorige status op te slaan.
U kunt versies lezen of verwijderen met behulp van de versie-id nadat versie-id is uitgeschakeld. U kunt ook de versies van een blob in een lijst zetten nadat versie-uitvoering is uitgeschakeld.
In het volgende diagram ziet u hoe als u een blob wijzigt nadat versie-versie is uitgeschakeld, een blob wordt gemaakt waarop geen versie wordt uitgevoerd. Alle bestaande versies die aan de blob zijn gekoppeld, blijven bestaan.
Blobversies en soft delete
Microsoft raadt u aan zowel versie-als blob-gegevens verwijderen in te stellen voor uw opslagaccounts voor optimale gegevensbeveiliging. Zie Soft delete for Azure Storage blobs (Zacht verwijderen voor blobs) Azure Storage informatie over het verwijderen van blobs.
Een blob overschrijven
Als blobversies en de functie voor het verwijderen van blobs beide zijn ingeschakeld voor een opslagaccount, wordt er automatisch een nieuwe versie gemaakt wanneer een blob wordt overschreven. De nieuwe versie is niet soft-deleted en wordt niet verwijderd wanneer de retentieperiode voor soft-delete is verlopen. Er worden geen zacht verwijderde momentopnamen gemaakt.
Een blob of versie verwijderen
Als versieverdeling en soft delete 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 momentopnamen gemaakt die zijn verwijderd. De retentieperiode voor zacht verwijderen is niet van kracht voor de verwijderde blob.
Met de functies voor het verwijderen van de soft-delete-versie beschikt u over extra beveiliging voor het verwijderen van blobversies. Wanneer u een eerdere versie van de blob verwijdert, wordt die versie definitief verwijderd. De tijdelijke verwijderde versie blijft behouden totdat de retentieperiode voor zacht 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 zacht verwijderde versie herstellen
U kunt de bewerking Blob verwijderen verwijderen gebruiken om zacht verwijderde versies te herstellen tijdens de retentieperiode voor zacht verwijderen. Met de bewerking Blob verwijderen verwijderen worden altijd alle zacht verwijderde versies van de blob hersteld. Het is niet mogelijk om slechts één zacht verwijderde versie te herstellen.
Het herstellen van een zacht verwijderde versie met de bewerking Blob verwijderen verwijderen betekent niet dat een versie de huidige versie wordt. Als u de huidige versie wilt herstellen, herstelt u eerst alle eerder verwijderde versies en gebruikt u vervolgens de bewerking Blob kopiëren om een eerdere versie te kopiëren naar een nieuwe huidige versie.
In het volgende diagram ziet u hoe u blobversies met de bewerking Blob verwijderen verwijderen kunt herstellen en hoe u de huidige versie van de blob kunt herstellen met de bewerking Blob kopiëren.
Nadat de retentieperiode voor het verwijderen van de tijdelijke opslag is verstreken, worden alle blobversies die zijn verwijderd definitief verwijderd.
Blobversies en blob-momentopnamen
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 een blobversie automatisch wordt gemaakt bij een schrijf- of verwijderbewerking wanneer blobversies zijn ingeschakeld voor uw opslagaccount.
Belangrijk
Microsoft raadt u aan om, nadat u blobversies hebt ingeschakeld, ook uw toepassing bij te werken om te stoppen met het maken van momentopnamen van blok-blobs. Als versienummering is ingeschakeld voor uw opslagaccount, worden alle blok-blobupdates en -verwijderingen vastgelegd en bewaard door versies. Het maken van momentopnamen biedt geen extra beveiliging voor uw blok-blobgegevens als blobversies zijn ingeschakeld en kunnen de kosten en complexiteit van de toepassing verhogen.
Een momentopname maken van een blob wanneer versien is ingeschakeld
Hoewel dit niet wordt aanbevolen, kunt u een momentopname maken van een blob met ook een versie. Als u uw toepassing niet kunt bijwerken om te stoppen met het maken van momentopnamen van blobs wanneer u versie-updates inschakelen, kan uw toepassing zowel momentopnamen als versies ondersteunen.
Wanneer u een momentopname van een versie van een 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 van een versie van een blob maakt. In het diagram bevatten blobversies en momentopnamen met versie-id 2 en 3 identieke gegevens.
Bewerkingen in blobversies autor toestemming geven
U kunt op een van de volgende manieren toegang verlenen tot blobversies:
- Door op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) te gebruiken om machtigingen te verlenen aan een Azure Active Directory(Azure AD)-beveiligingsprincipaal. Microsoft raadt u aan Azure AD te gebruiken voor betere beveiliging en gebruiksgemak. Zie Toegang tot gegevens machtigen in Azure Storage voor meer informatie over het gebruik van Azure AD 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 , dat een blobversie vertegenwoordigt, om een
bvSAS-token te maken voor bewerkingen op een specifieke versie. Zie Beperkte toegang verlenen tot uw resources Azure Storage sas (Shared Access Signatures)voor meer informatie over handtekeningen voor gedeelde toegang. - Door de toegangssleutels van het account te gebruiken om bewerkingen te autoreren voor blobversies met een gedeelde sleutel. Zie Autor toestemming geven met gedeelde sleutel voor meer informatie.
Blobversies zijn ontworpen om uw gegevens te beschermen tegen onbedoelde of schadelijke verwijdering. Om de beveiliging te 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 blobversie.
| Description | Blob service bewerking | Azure RBAC-gegevensactie vereist | Ondersteuning voor ingebouwde Azure-rollen |
|---|---|---|---|
| De huidige versie verwijderen | Blob verwijderen | Microsoft. Storage/storageAccounts/blobServices/containers/blobs/delete | Inzender voor Storage Blob-gegevens |
| Een eerdere versie verwijderen | Blob verwijderen | Microsoft. Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action | Eigenaar van opslagblobgegevens |
SAS-parameters (Shared Access Signature)
De ondertekende resource voor een blobversie is bv . Zie Create a service SAS (Een service-SAS maken) of Create a user delegation SAS (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 | Verwijder een blobversie. |
Prijzen en facturering
Het inschakelen van blobversies 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 toenemen, zodat u de kosten kunt minimaliseren.
Blobversies, zoals blob-momentopnamen, worden gefactureerd tegen hetzelfde tarief als actieve gegevens. Hoe versies worden gefactureerd, is afhankelijk van het expliciet instellen van de laag voor de basis-blob of voor een van de versies (of momentopnamen). Zie Hot-, Cool- en Archive-toegangslagen voor blobgegevens voor meer informatie over blob-lagen.
Als u de laag van een blob of versie niet hebt gewijzigd, wordt u gefactureerd voor unieke gegevensblokken in die blob, de versies ervan 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 uiteindelijk weer in dezelfde laag staan. Zie Facturering wanneer de bloblaag expliciet is ingesteld voor meer informatie.
Notitie
Het inschakelen van versiering voor gegevens die vaak worden overschreven, kan leiden tot hogere kosten voor opslagcapaciteit en een verhoogde latentie tijdens de lijstbewerkingen. U kunt deze problemen verhelpen door vaak overschreven gegevens op te slaan in een afzonderlijk opslagaccount met versie-uitvoering uitgeschakeld.
Zie Blob-momentopnamen voor meer informatie over factureringsgegevens voor blob-momentopnamen.
Facturering wanneer de bloblaag niet expliciet is ingesteld
Als u de bloblaag niet expliciet hebt ingesteld voor een basis-blob of een van de versies ervan, worden er kosten in rekening gebracht voor unieke blokken of pagina's in de blob, de versies ervan en eventuele momentopnamen. Gegevens die worden gedeeld via een blob en de versies ervan worden slechts één keer in rekening gebracht. Wanneer een blob wordt bijgewerkt, verschillen gegevens in een basis-blob van de gegevens die zijn opgeslagen in de 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 en dezelfde gegevens heeft als in de vorige versie. Nadat het blok opnieuw is vastgelegd, 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 is bijgewerkt met identieke gegevens.
Blob Storage biedt 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 er kosten in rekening worden gebracht voor unieke blokken, is het belangrijk om er rekening mee te houden dat het bijwerken van een blob wanneer versie-updates is ingeschakeld, leidt tot extra unieke blokken en extra kosten.
Wanneer blobversies zijn ingeschakeld, roept u updatebewerkingen aan voor blok-blobs, zodat ze zo veel mogelijk blokken bijwerken. De schrijfbewerkingen die fijnkeurige controle over blokken toestaan, zijn Put Block en Put Block List. De bewerking Put Blob vervangt daarentegen de volledige inhoud van een blob en kan dus leiden tot extra kosten.
In de volgende scenario's wordt gedemonstreerd hoe de kosten voor een blok-blob en de versies ervan 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 voor het account vier blokken in rekening gebracht.
Scenario 3
In scenario 3 is de blob bijgewerkt, maar de versie niet. Blok 3 is vervangen door blok 4 in de basis-blob, maar de vorige versie weerspiegelt nog steeds blok 3. Als gevolg hiervan worden voor het account vier blokken in rekening gebracht.
Scenario 4
In scenario 4 is de basis-blob volledig bijgewerkt en bevat deze geen van de oorspronkelijke blokken. Als gevolg hiervan worden de kosten voor het account in rekening gebracht voor alle acht unieke blokken vier in de — basis-blob en vier in de vorige versie. Dit scenario kan optreden als u naar een blob schrijft met de bewerking Put Blob, omdat hiermee de volledige inhoud van de basis-blob wordt vervangen.
Facturering wanneer de bloblaag expliciet is ingesteld
Als u de bloblaag expliciet hebt ingesteld voor een blob of versie (of momentopname), worden de volledige inhoudslengte van het object in de nieuwe laag in rekening gebracht, 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. 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 expliciet is ingesteld op... | Vervolgens wordt u gefactureerd voor... |
|---|---|
| Een basis-blob met een eerdere versie | De basis-blob in de nieuwe laag en de oudste versie in de oorspronkelijke laag, plus eventuele unieke blokken in andere versies. 1 |
| Een basis-blob met een vorige versie en een momentopname | De basis-blob in de nieuwe laag, de oudste versie in de oorspronkelijke laag en de oudste momentopname in de oorspronkelijke laag, plus eventuele unieke blokken in andere versies ofmomentopnamen 1. |
| Een eerdere versie | De versie in de nieuwe laag en de basis-blob in de oorspronkelijke laag, plus eventuele unieke blokken in andere versies. 1 |
1 Als 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 versie-blob wordt verplaatst naar een andere laag.
Het expliciet instellen van de laag voor een blob, versie of momentopname kan niet ongedaan worden gemaakt. Als u een blob naar een nieuwe laag verplaatst en deze vervolgens weer naar de oorspronkelijke laag verplaatst, worden de volledige inhoudslengte van het object in rekening gebracht, zelfs als deze blokken deelt met andere objecten in de oorspronkelijke laag.
Bewerkingen die expliciet de laag van een blob, versie of momentopname instellen, zijn onder andere:
- Blob-laag instellen
- Blob met opgegeven laag zetten
- Blokkeringslijst met opgegeven laag
- Blob kopiëren met opgegeven laag
Een blob verwijderen wanneer de functie voor soft delete is ingeschakeld
Wanneer de functie voor het verwijderen van blobs is ingeschakeld en u een basis-blob verwijdert of overschrijft waarop de laag expliciet is ingesteld, worden eventuele eerdere versies van de blob met een zachte verwijderde blob gefactureerd op volledige inhoudslengte. Zie Blob versioning en soft delete voor meer informatie over hoe blobversies en soft delete samenwerken.
In de volgende tabel wordt het factureringsgedrag beschreven voor een blob die op een zachte manier wordt verwijderd, afhankelijk van of versie-uitvoering is ingeschakeld of uitgeschakeld. Wanneer versien is ingeschakeld, wordt er een versie gemaakt wanneer een blob wordt verwijderd. Wanneer versien is uitgeschakeld, wordt er een momentopname gemaakt waarin een blob op een zachte manier wordt verwijderd.
| Wanneer u een basis-blob overschrijft met de laag die expliciet is ingesteld... | Vervolgens wordt u gefactureerd voor... |
|---|---|
| Als de functie voor het verwijderen van blobs en versie-versies beide zijn ingeschakeld | Alle bestaande versies met een volledige inhoudslengte, ongeacht de laag. |
| Als de functie voor het verwijderen van blobs is ingeschakeld, maar versien is uitgeschakeld | Alle bestaande momentopnamen voor het verwijderen van de soft-delete met een volledige inhoudlengte, ongeacht de laag. |
Functieondersteuning
In deze tabel ziet u hoe deze functie wordt ondersteund in uw account en wat de gevolgen zijn voor de ondersteuning wanneer u bepaalde mogelijkheden inschakelen.
| Type opslagaccount | Blob Storage (standaardondersteuning) | Data Lake Storage Gen2 1 | NFS 3.0 1 | SFTP 1 |
|---|---|---|---|---|
| Standaard algemeen gebruik v2 |  |
 |
|
|
| Premium blok-blobs maken | |
|
|
|
Voor 1 Data Lake Storage Gen2, het NFS 3.0-protocol (Network File System) en het Secure File Transfer Protocol (SFTP) is allemaal een opslagaccount vereist waarvoor een hiërarchische naamruimte is ingeschakeld.