Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
U kunt versiebeheer van Blob Storage inschakelen om automatisch eerdere versies van een object te onderhouden. 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. Als u kosten wilt minimaliseren, gebruikt u een levenscyclusbeheerbeleid om oude versies automatisch te verwijderen. Voor meer informatie over levenscyclusbeheer, zie Optimize costs by automating Azure Blob Storage access tiers.
Hoe blobversiebeheer functioneert
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:
Belangrijk
Als u een groot aantal versies per blob hebt, kan de latentie voor bewerkingen in blobvermeldingen toenemen. Microsoft raadt aan om minder dan 1000 versies per blob te onderhouden. U kunt levenscyclusbeheer gebruiken om oude versies automatisch te verwijderen. Voor meer informatie over levenscyclusbeheer, zie Optimize costs by automating Azure Blob Storage access tiers.
Blob-versies zijn onveranderbaar. U kunt de inhoud of metagegevens van een bestaande blobversie niet wijzigen.
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.
Belangrijk
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 versie-ID-waarde 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 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 van de huidige versie van de blob die door de schrijfoperatie wordt 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.
Notitie
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:
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 (append-blob)
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 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. 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:
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.
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, gebruik je blob lifecycle management. Voor meer informatie over levenscyclusbeheer, zie Beheer de levenscyclus van Azure Blob-opslag.
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.
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.
Blob-versiebeheer en 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 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 zacht verwijderde momentopnamen gemaakt.
Een blob of versie verwijderen
Als je versiebeheer en 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 voor voorlopig verwijderen gemarkeerde snapshots aan. De retentieperiode voor zachte verwijdering geldt niet voor de verwijderde blob.
Soft delete biedt extra bescherming bij het verwijderen van blobversies. Wanneer je een eerdere versie van de blob verwijdert, wordt die versie zacht verwijderd. De zacht verwijderde versie blijft behouden tot de behoudsperiode voor zacht verwijderen eindigt, waarna deze permanent 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 Blob ongedaan maken-bewerking gebruiken om zacht verwijderde versies te herstellen tijdens de bewaarperiode voor zachte verwijdering. 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.
Het volgende diagram toont hoe je zacht verwijderde blob-versies kunt herstellen met de Undelete Blob-operatie , en hoe je de huidige versie van de blob kunt herstellen met de Copy Blob-operatie .
Nadat de retentieperiode voor soft delete is verstreken, worden alle via soft delete verwijderde blobversies permanent verwijderd.
Blob-versiebeheer en blobmomentopnamen
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 tijdens een schrijf- of verwijderingsoperatie wanneer je blob-versie-inschakeling voor je opslagaccount inschakelt.
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 je versiebeheer inschakelt voor je opslagaccount, worden alle updates van blok-blobs en verwijderingen met behulp van versies vastgelegd en bewaard. Het maken van snapshots biedt geen extra bescherming aan je block blob-data als blobversiebeheer is ingeschakeld, en het kan de kosten en 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 momentopname maakt van een blob met versiebeheer, maak je tegelijkertijd ook een nieuwe versie aan. 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.
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. |
Prijzen en facturering
Het inschakelen van blobversiebeheer kan leiden tot extra opslagkosten voor je account. Wees bij het ontwerpen van je applicatie bewust van hoe deze kosten kunnen worden opgebouwd zodat je de kosten kunt minimaliseren.
Blob-versies, zoals blob-momentopnamen, worden gefactureerd met hetzelfde tarief als actieve gegevens. Hoe je betaalt voor versies hangt af van of je expliciet de tier instelt 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 tiers van een blob of versie niet verandert, betaal je 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 tiers van een blob of versie verandert, betaal je voor het hele object, ongeacht of de blob en versie uiteindelijk weer in dezelfde tier zitten. Voor meer informatie, zie Facturering als het blobniveau expliciet is ingesteld.
Notitie
Het inschakelen van versiebeheer voor data die vaak wordt overschreven, kan de opslagcapaciteit verhogen en de latentie tijdens lijstprocessen verhogen. Om deze problemen te verhelpen, slaat u regelmatig overschreven gegevens op in een afzonderlijk opslagaccount waarbij versiebeheer is uitgeschakeld.
Door versies in te schakelen voor opslagaccounts waarvan vaak een back-up wordt gemaakt, kunnen er kosten ontstaan voor het ophalen van gegevens wanneer de versies worden opgeslagen in koel- of archieftoegangslaag.
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 een versie van een blob, betaal je voor unieke blokken of pagina's over alle versies, en eventuele snapshots die het heeft. Je betaalt voor gedeelde data tussen blob-versies maar één keer. Wanneer je een blob bijwerkt, wijkt de data in de nieuwe huidige versie af van de data die in eerdere versies is opgeslagen, en betaal je voor de unieke data per blok of pagina.
Wanneer je een blok binnen een blok vervangt, betaal je voor dat blok als een uniek blok. Deze regel geldt zelfs als het blok dezelfde blok-ID en dezelfde gegevens heeft als in de vorige versie. Nadat je het blok opnieuw committ, wijkt het af van het tegenhanger in de vorige versie, en betaal je voor de data. 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 betaalt voor unieke blokken, houd er rekening mee dat het bijwerken van een blob wanneer versiebeheer is ingeschakeld resulteert in meer unieke blokken en extra kosten.
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. 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.
Scenario 2
In scenario 2 werk je één blok (blok 3 in het diagram) bij in de blob. Hoewel het bijgewerkte blok dezelfde gegevens en dezelfde id bevat, is het niet hetzelfde als blok 3 in de vorige versie. Daardoor betaal je voor vier blokken.
Scenario 3
In scenario 3 update je de blob, maar je werkt de versie niet bij. Je vervangt blok 3 door blok 4 in de huidige blob, maar de vorige versie weerspiegelt nog steeds blok 3. Daardoor betaal je voor vier blokken.
Scenario 4
In scenario 4 update je de huidige versie volledig en bevat deze geen van de originele blokken. Daardoor betaal je voor alle acht unieke blokken - vier in de huidige versie, en vier samen 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.
Factureren wanneer de blob-laag expliciet is ingesteld
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, zelfs als het blokken deelt met een object in de originele 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 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 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.
In het volgende diagram wordt getoond hoe objecten worden gefactureerd wanneer een geversioneerde blob naar een andere laag wordt verplaatst.
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:
- Set Blob Tier (Blob-tier instellen)
- Blob plaatsen met gespecificeerde tier
- Lijst met blokken plaatsen met opgegeven laag
- Blob kopiëren met gespecificeerde laag
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 expliciet een toegangsniveau is ingesteld, betaal je voor alle eerdere versies van de soft-deleted blob op basis van de volledige inhoudslengte. Voor meer informatie over hoe blobversiebeheer en voorlopig verwijderen samenwerken, zie Blob-versiebeheer en voorlopig verwijderen.
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.
Versiebeheer wordt niet ondersteund voor blobs die je uploadt met Data Lake Storage API's.