Blob-momentopnamen

Een snapshot is een alleen-lezen kopie van een blob die op een specifiek moment is genomen. Je hoeft de blob snapshots-functie niet in te schakelen. Maak in plaats daarvan snapshots on demand door gebruik te maken van de Snapshot Blob operatie. Voor meer informatie, zie Snapshot Blob Operation. Je kunt snapshotcreatie automatiseren door aangepaste scripts te gebruiken om moment-in-time kopieën van blobs op een schema of voor of na specifieke bewerkingen vast te leggen.

Blob-snapshots zijn 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.

Momentopnamen versus versies

Een snapshot lijkt op een blobversie, maar de twee verschillen in hoe ze worden gemaakt en waar ze het beste voor geschikt zijn. Een snapshot is handmatig en applicatiegestuurd: je maakt expliciet een moment-in-time kopie wanneer je applicatie besluit dat er een nodig is. 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.

Gebruik versiebeheer wanneer je automatische, continue bescherming wilt tegen per ongeluk of kwaadaardige overschrijvingen en verwijderingen. Gebruik snapshots wanneer je doelbewuste kopieën van een specifiek moment wilt, zoals een bewezen goed checkpoint vóór een geplande update, in plaats van alle wijzigingen in de loop van de tijd vast te leggen.

Notitie

Hoewel je het versiebeheer kunt benaderen met snapshots, raadt Microsoft blobversiebeheer aan voor automatische overschrijf- en verwijderbeveiliging op FNS-accounts. Snapshots zijn het meest geschikt voor weloverwogen momentopnamen in plaats van bescherming die elke verandering vastlegt. Voor meer informatie, zie Blob versioning.

Hoe snapshots werken

Een snapshot van een blob is identiek aan de basisblob, behalve dat aan de blob-URI een DateTime-waarde is toegevoegd om het tijdstip aan te geven waarop de snapshot is genomen. Als een pagina-blob-URI bijvoorbeeld is http://storagesample.core.blob.windows.net/mydrives/myvhd, is de momentopname-URI vergelijkbaar met http://storagesample.core.blob.windows.net/mydrives/myvhd?snapshot=2011-03-09T01:42:34.9360000Z.

Wanneer u een momentopname van een blob maakt, worden de systeemeigenschappen van de blob met dezelfde waarden gekopieerd naar de momentopname. De metagegevens van de basisblob worden ook gekopieerd naar de momentopname, tenzij u afzonderlijke metagegevens opgeeft voor de momentopname wanneer u deze maakt. Nadat u een momentopname hebt gemaakt, kunt u deze lezen, kopiëren of verwijderen, maar u kunt deze niet wijzigen. Leases die zijn gekoppeld aan de basis-blob, hebben geen invloed op de momentopname. U kunt geen huurcontract afsluiten voor een momentopname.

Een blob kan een willekeurig aantal momentopnamen bevatten. Snapshots blijven bestaan totdat je ze expliciet verwijdert, hetzij onafhankelijk of als onderdeel van een Delete Blob-operatie voor de basisblob. Je kunt een snapshot maken van een blob in de Hot-, Cool- of Cold-laag. Je kunt geen snapshot maken van een gearchiveerde blob.

Belangrijk

Een groot aantal snapshots per blob kan de latentie voor blob-listing-operaties verhogen. Microsoft raadt aan om minder dan 1.000 snapshots per blob bij te houden. Je kunt levenscyclusbeheer gebruiken om oude snapshots automatisch te verwijderen. Voor meer informatie over levenscyclusbeheer, zie Kosten optimaliseren door de toegangslagen van Azure Blob Storage te automatiseren.

Snapshots zijn vooral nuttig voor blobtypes en -operaties die niet door blob-versiemanagement worden vastgelegd. Omdat sommige schrijfoperaties, zoals Put Page (page blobs) en Append Block (append blobs), geen blobversies creëren, zelfs niet wanneer versieën zijn ingeschakeld, bieden snapshots een manier om de moment-in-tijd status van een blob vast te leggen bij gebruik van deze API's. Een VHD-bestand slaat bijvoorbeeld de huidige informatie en status op voor een VM-schijf. Je kunt een schijf uit de VM loskoppelen of de VM afsluiten, een snapshot maken van het VHD-bestand en die snapshot later gebruiken om het VHD-bestand op dat moment op te halen en de VM opnieuw aan te maken.

Het volgende diagram toont hoe snapshots worden gemaakt en hoe een snapshot gepromoot kan worden tot de huidige blob:

Diagram dat laat zien hoe snapshots worden gemaakt en hoe een snapshot kan worden gepromoot tot de huidige blob.

Beheer en herstel snapshots

Je kunt snapshots maken, weergeven en verwijderen. Je kunt ook een snapshot gebruiken om een basisblob terug te brengen naar een eerdere toestand. De volgende secties beschrijven elke bewerking en de bijbehorende hulpmiddelen.

Een blob herstellen vanuit een momentopname

Omdat je een snapshot niet kunt wijzigen, herstel je een basisblob door er een snapshot overheen te kopiëren. Roep de Copy Blob-operatie aan en specificeer de snapshot-URI als kopieerbron. Dit proces promoveert de status van de snapshot tot de huidige basisblob, terwijl de bestaande snapshots van de blob behouden blijven.

Momentopnamen weergeven

Je kunt de snapshots die aan de basisblob zijn gekoppeld opsommen om je huidige snapshots te volgen door de List Blobs-operatie te gebruiken en de snapshots waarde in de include parameter te specificeren. Standaard levert een lijst blobs-verzoek geen snapshots terug. Stel include=snapshots in dat alle snapshots voor elke blob samen met de basisblob worden teruggegeven. Raadpleeg Blobs weergeven voor meer informatie. Je kunt ook Azure Storage blob-inventaris gebruiken om een gepland rapport te genereren van de blobs in je account, inclusief hun snapshots, door het veld includeSnapshots in te stellen op true in de inventarisregeldefinitie. Voor meer informatie, zie Blob Inventory.

Momentopnamen verwijderen

Je moet een snapshot expliciet verwijderen. Om een individuele snapshot te verwijderen, roep je de Delete Blob-operatie aan en specificeer je de DateTime-waarde van de snapshot in de snapshot-queryparameter.

Je kunt een basisblob niet verwijderen zolang er actieve snapshots zijn. Om een basisblob en al zijn snapshots samen te verwijderen, roep Delete Blob aan met de x-ms-delete-snapshots header ingesteld op include. Om alleen de snapshots te verwijderen en de basisblob te behouden, zet je de header op only.

Beheer snapshots met tools

Je kunt snapshots beheren door gebruik te maken van het portal, Azure CLI en Azure PowerShell.

Om een snapshot van een blob te maken met behulp van het Azure-portaal, volg deze stappen:

  1. Ga in Azure Portal naar uw opslagaccount.
  2. Zoek onder Data storage de optie Containers en selecteer vervolgens de container die de blob bevat.
  3. Selecteer de blob die je wilt snapshoten.
  4. Selecteer op het tabblad Overzicht van de blob Maak snapshot.
  5. Om de snapshots van de blob te bekijken, selecteer je het tabblad Snapshots . Het tabblad geeft elke snapshot weer samen met de datum en het tijdstip waarop het is vastgelegd.

Functieondersteuning

Deze functie is niet ingeschakeld voor Data Lake Storage Gen2-accounts. Daarnaast kan het Network File System (NFS) 3.0-protocol of het SSH File Transfer Protocol (SFTP) de ondersteuning van deze functie beïnvloeden. Als je een van deze mogelijkheden inschakelt, zie dan Blob Storage-feature-ondersteuning in Azure Storage-accounts om de ondersteuning voor deze functie te beoordelen. Overweeg alternatieve mechanismen. Voorbeelden zijn Soft delete voor blobs, AzCopy en Vaulted Backup.

interacties tussen functies

Versioning

Wanneer je versiebeheer inschakelt, zijn snapshots meestal overbodig voor block blobs. Als je zowel versiebeheer als snapshots tegelijk inschakelt, maakt het maken van een snapshot zowel een snapshot als een nieuwe versie. Dit proces vergroot het aantal opgeslagen objecten zonder extra bescherming toe te voegen. Zie Blob-versiebeheer voor meer informatie.

Zacht verwijderen

Soft delete geldt voor snapshots: wanneer je een snapshot verwijdert, wordt deze soft-deleted. Je kunt het herstellen tijdens de retentieperiode door Undelete Blob te gebruiken. Daarnaast verschilt de manier waarop je snapshots maakt en kosten in rekening brengt voor snapshots afhankelijk van of versiebeheer is ingeschakeld. Wanneer versiebeheer is uitgeschakeld, creëert het overschrijven van een blob een soft-delete snapshot. Wanneer versiebeheer is ingeschakeld, wordt er een nieuwe versie aangemaakt. Als je expliciet de tier op een basisblob zet, betaal je de volledige contentlengte voor alle eerdere versies of snapshots van de zacht verwijderde blob. Voor details over dit factureringsgedrag, zie het gedeelte Prijzen en facturering. Voor meer informatie over soft delete, zie Blob Soft Delete.

Objectreplicatie

Je kunt snapshots niet repliceren. Alleen de basisblob wordt gerepliceerd. Voor meer informatie, zie Object Replication.

Levenscyclusbeheer

Lifecycle management kan snapshots targeten en verwijderen door gebruik te maken van het snapshot-subtype in beleidsregels. Voor meer informatie, zie Lifecycle Management.

Prijzen en facturering

Het maken van een momentopname, een alleen-lezen kopie van een blob, kan leiden tot extra kosten voor gegevensopslag voor uw account. Wees bij het ontwerpen van je applicatie bewust van hoe deze kosten kunnen worden opgebouwd zodat je de kosten kunt minimaliseren.

Momentopnamen van blobs, zoals blobversies, worden gefactureerd met hetzelfde tarief als actieve data. Hoe je wordt gefactureerd voor snapshots hangt af van of je expliciet de tier voor de basisblob of voor een van de snapshots (of versies) ervan instelt. Voor meer informatie over bloblagen, zie Toegangslagen voor blobgegevens.

Als je het toegangsniveau van een blob of snapshot niet verandert, word je gefactureerd voor unieke datablokken over die blob, zijn snapshots en eventuele versies die het heeft. Zie Facturering wanneer de bloblaag niet expliciet is ingesteld voor meer informatie.

Als je de tier van een blob of snapshot verandert, word je voor het hele object gefactureerd, ongeacht of de blob en snapshot uiteindelijk weer in dezelfde tier zitten. Zie Facturering wanneer de bloblaag expliciet is ingesteld voor meer informatie.

Voor opslagaccounts die gebruikmaken van slimme laag, worden versies en momentopnamen gefactureerd op volledige inhoudslengte. Zie Kosten optimaliseren met slimme laag voor meer informatie.

Voor meer informatie over factureringsgegevens voor blobversies, zie Blob-versiebeheer.

Kosten minimaliseren met momentopnamebeheer

Om extra kosten te voorkomen, beheer je je snapshots zorgvuldig. Volg deze best practices om de kosten voor het opslaan van je snapshots te minimaliseren:

  • Verwijder en maak nieuwe momentopnamen die aan een blob gekoppeld zijn wanneer u de blob bijwerkt, zelfs als u met identieke gegevens bijwerkt, tenzij uw toepassingsontwerp vereist dat u momentopnamen behoudt. Door de snapshots van de blob te verwijderen en opnieuw aan te maken, zorg je ervoor dat de blob en snapshots niet uit elkaar groeien.
  • Als u momentopnamen voor een blob onderhoudt, vermijdt u het aanroepen van methoden die de hele blob overschrijven wanneer u de blob bijwerkt. Werk in plaats daarvan zo weinig mogelijk blokken bij om de kosten laag te houden.

Factureren wanneer je de blob-tier niet expliciet instelt

Als je de blob-tier niet expliciet instelt voor een basis-blob of een van zijn snapshots, betaal je voor unieke blokken of pagina's over de blob, de snapshots en eventuele versies die het heeft. Je betaalt voor data die een blob en zijn snapshots slechts één keer delen. Wanneer je een blob bijwerkt, wijkt de data in een basisblob af van de data die in de snapshots is opgeslagen, en betaal je voor unieke data per blok of pagina.

Wanneer je een blok binnen een blob met blokken vervangt, betaal je later voor dat blok als een uniek blok. Deze regel geldt zelfs als het blok dezelfde blok-ID en dezelfde data heeft als in de snapshot. Nadat je het blok opnieuw hebt gecommitted, wijkt het af van zijn tegenhanger in de snapshot, en betaal je voor de data. Dezelfde regel geldt voor een pagina in een page blob die wordt bijgewerkt 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, onthoud dat het updaten van een blob wanneer die blob snapshots of versies heeft, resulteert in extra unieke blokken en extra kosten.

Wanneer een blob momentopnamen heeft, 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 Blob-operatie daarentegen vervangt de volledige inhoud van een blob en kan daardoor tot extra kosten leiden.

De volgende scenario's laten zien hoe kosten worden berekend voor een block blob en zijn snapshots wanneer je de bloblaag niet expliciet instelt.

Scenario 1

In scenario 1 is de basis-blob niet bijgewerkt nadat de momentopname is gemaakt. Er worden dus alleen kosten in rekening gebracht voor unieke blokken 1, 2 en 3.

Screenshot van facturering voor unieke blokken in de basisblob en een snapshot in scenario 1.

Scenario 2

In scenario 2 is de basis-blob bijgewerkt, maar de momentopname niet. Blok 3 is bijgewerkt en hoewel deze dezelfde gegevens en dezelfde id bevat, is het niet hetzelfde als blok 3 in de momentopname. Als gevolg hiervan wordt het account belast voor vier blokken.

Diagram 2 met facturering voor unieke blokken in basisblob en momentopname.

Scenario 3

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

Diagram 3 met facturering voor unieke blokken in de base blob en snapshot.

Scenario 4

In scenario 4 is de basis-blob volledig bijgewerkt en bevat deze geen van de oorspronkelijke blokken. Als gevolg hiervan wordt het account in rekening gebracht voor alle acht unieke blokken.

Diagram 4 met kostenberekening voor unieke blokken in basisblob en momentopname.

Aanbeveling

Om de kosten laag te houden, vermijd het aanroepen van methoden die de hele blob overschrijven. Werk in plaats daarvan individuele blokken bij.

Factureren wanneer je expliciet de blob-tier instelt

Als je expliciet de blob-tier instelt voor een blob, snapshot of versie, 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. Je betaalt voor unieke blokken in alle versies of snapshots die in de oorspronkelijke laag blijven, 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 snapshot wanneer je deze naar een nieuwe laag verplaatst.

Wanneer je expliciet de blob-tier instelt op... Vervolgens wordt u gefactureerd voor...
Een basisblob met een momentopname De basis-blob in de nieuwe laag en de oudste momentopname in de oorspronkelijke laag, plus eventuele unieke blokken in andere momentopnamen.1
Een basisblob met een vorige versie en een momentopname De basisblob in de nieuwe tier, de oudste versie in de oorspronkelijke tier, en de oudste snapshot in de oorspronkelijke tier, plus eventuele unieke blokken in andere versies of snapshots. 1
Een momentopname De momentopname in de nieuwe laag en de basis-blob in de oorspronkelijke laag, plus eventuele unieke blokken in andere momentopnamen.1

1 Als er andere eerdere versies of snapshots zijn die je niet van hun oorspronkelijke laag hebt verplaatst, betaal je 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 snapshots naar een andere laag verplaatst.

Diagram waarin wordt getoond hoe objecten worden gefactureerd wanneer een blob met instantafbeeldingen expliciet is verdeeld in lagen.

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 blob soft delete is ingeschakeld, als je een basisblob verwijdert of overschrijft waarvoor je expliciet de tier hebt ingesteld, betaal je voor de volledige inhoudslengte van eerdere versies of snapshots van de zacht verwijderde blob. Voor meer informatie over hoe blob-versiebeheer en soft delete samenwerken, zie Feature-interacties.

De volgende tabel beschrijft het factureringsgedrag voor een blob die voorlopig wordt verwijderd, afhankelijk van of versiebeheer is ingeschakeld of uitgeschakeld. Wanneer versiebeheer is ingeschakeld, wordt er een nieuwe versie gemaakt wanneer een blob voorlopig wordt verwijderd. Wanneer versiebeheer is uitgeschakeld, resulteert het voorlopig verwijderen (soft-delete) van een blob in het maken van een momentopname.

Wanneer u een basis-blob overschrijft met de bijbehorende laag expliciet ingesteld... Vervolgens wordt u gefactureerd voor...
Als soft delete van blobs en versiebeheer beide zijn ingeschakeld Alle bestaande versies met volledige inhoudslengte, ongeacht de laag.
Als blob soft delete is ingeschakeld, maar versiebeheer is uitgeschakeld Alle bestaande momentopnamen voor zachte verwijdering op volledige inhoudslengte, ongeacht de laag.

Bekende beperkingen

  • Je kunt geen snapshots maken voor blobs in de archivetoegangslaag.

  • Ondersteuning voor accountsnapshots van Data Lake Gen2 accepteert geen nieuwe klanten meer. Gebruik in plaats daarvan blob soft delete, AzCopy of Vaulted Backup.

  • Je kunt een blob niet verwijderen terwijl er actieve snapshots zijn, tenzij je x-ms-delete-snapshots opneemt in de delete-aanroep.

  • De objectreplicatie kopieert geen snapshots.

  • Je kunt snapshots niet aanpassen na het aanmaken.

  • U kunt geen huurcontract afsluiten voor een momentopname.

Bewaking en problemen oplossen

  • Ik kan mijn basisblob niet verwijderen: de blob heeft actieve snapshots. Gebruik Delete Blob met x-ms-delete-snapshots: include om beide tegelijk te verwijderen.

  • Mijn snapshot verdween nadat ik de basisblob had verwijderd: het verwijderen van de basisblob verwijdert snapshots permanent, tenzij blob soft delete is ingeschakeld. Schakel soft delete in om te beschermen tegen onbedoelde verwijdering.

  • Mijn snapshotkosten zijn hoger dan verwacht: als je expliciet het toegangsniveau van de blob verandert, betaal je voor de volledige contentlengte in plaats van alleen unieke blokken. Vermijd expliciete tierwijzigingen op blobs met actieve snapshots waar mogelijk.

  • Snapshots bekijken en inventariseren: In het portaal verschijnen snapshots onder de blob in Storage Browser wanneer Blob snapshots weergeven is ingeschakeld. Om het aantal momentopnamen en het opslaggebruik binnen een account te inventariseren, gebruik je Azure Storage Blob Inventory en de BlobCapacity-metriek in Azure Monitor.

Volgende stappen