Rehydratatie van blobs vanuit de archieflaag
Een blob in de archieftoegangslaag wordt beschouwd als offline en kan niet worden gelezen of gewijzigd. Als u gegevens in een gearchiveerde blob wilt lezen of wijzigen, moet u de blob eerst rehydrateren naar een onlinelaag, ofwel de laag Hot of Cool. Er zijn twee opties voor het rehydrateren van een blob die is opgeslagen in de archieflaag:
Een gearchiveerde blobkopiëren naar een onlinelaag: u kunt een gearchiveerde blob rehydrateren door deze te kopiëren naar een nieuwe blob in de laag Hot of Cool met de bewerking Blob kopiëren. Microsoft raadt deze optie aan voor de meeste scenario's.
De toegangslaagvan een blob wijzigen in een onlinelaag: u kunt een gearchiveerde blob rehydrateren naar de laag Hot of Cool door de laag te wijzigen met behulp van de bewerking Bloblaag instellen.
Het kan enkele uren duren voordat het rehydrateren van een blob uit de archieflaag is voltooid. Microsoft raadt aan grotere blobs te rehydrateren voor optimale prestaties. Het gelijktijdig rehydrateren van verschillende kleine blobs kan extra tijd kosten. Maximaal 10 GiB per opslagaccount kan per uur worden gerehydrateerd.
U kunt een Azure Event Grid om een gebeurtenis te verhogen wanneer u een blob uit de archieflaag rehydrateert naar een online laag en de gebeurtenis naar een gebeurtenis-handler verzendt. Zie Handle an event on blob rehydration (Een gebeurtenis verwerken bij rehydratatie van blobs) voor meer informatie.
Zie Hot-, Cool- en Archive-toegangslagen voor blobgegevens voor meer informatie over toegangslagenin Azure Storage.
Rehydratatieprioriteit
Wanneer u een blob rehydrateert, kunt u de prioriteit voor de rehydratatiebewerking instellen via de optionele header x-ms-rehydrate-priority op een Set Blob Tier of Copy Blob-bewerking. Opties voor prioriteit van rehydratatie zijn onder andere:
- Standaardprioriteit: de rehydratatieaanvraag wordt verwerkt in de volgorde waarin deze is ontvangen en kan maximaal 15 uur duren.
- Hoge prioriteit: de rehydratatieaanvraag krijgt prioriteit boven standaardprioriteitsaanvragen en kan in minder dan één uur worden voltooid voor objecten met een grootte van minder dan 10 GB.
Als u de prioriteit van de rehydratatie wilt controleren terwijl de rehydratatiebewerking wordt uitgevoerd, roept u Blob-eigenschappen op om de waarde van de header te x-ms-rehydrate-priority retourneren. De eigenschap rehydratatieprioriteit retourneert Standard of High.
Standaardprioriteit is de standaardoptie voor rehydratatie. Rehydratatie met hoge prioriteit is sneller, maar kost ook meer dan rehydratatie met standaardprioriteit. Een rehydratatie met hoge prioriteit kan langer duren dan één uur, afhankelijk van de blobgrootte en de huidige vraag. Microsoft raadt aan om rehydratatie met hoge prioriteit te reserveren voor gebruik in situaties waarin gegevens in noodgevallen worden hersteld.
Hoewel een rehydratatiebewerking met standaardprioriteit in behandeling is, kunt u de instelling voor rehydratatieprioriteit voor een blob bijwerken naar Hoog om die blob sneller te rehydrateren. Als u bijvoorbeeld een groot aantal blobs bulksgewijs rehydrateert, kunt u standaardprioriteit voor alle blobs voor de eerste bewerking opgeven en vervolgens de prioriteit verhogen naar Hoog voor afzonderlijke blobs die sneller online moeten worden gebracht, tot de limiet van 10 GiB per uur.
De instelling voor rehydratatieprioriteit kan niet worden verlaagd van Hoog naar Standaard voor een bewerking die in behandeling is. Houd er rekening mee dat het bijwerken van de instelling voor rehydratatieprioriteit mogelijk gevolgen heeft voor de facturering.
Zie Een gearchiveerde blob rehydrateren naar een onlinelaag voor meer informatie over het instellen en bijwerken van de instelling voor rehydratatieprioriteit.
Zie Prijzen voor Azure Blob-Storagevoor meer informatie over prijsverschillen tussen rehydratatieaanvragen met een Storage.
Een gearchiveerde blob naar een online laag kopiëren
De eerste optie voor het verplaatsen van een blob van de archieflaag naar een online laag is het kopiëren van de gearchiveerde blob naar een nieuwe doelblob die zich in de laag Hot of Cool (Hot) of Cool (Hot) of Cool (cool) heeft. U kunt de bewerking Blob kopiëren gebruiken om de blob te kopiëren. Wanneer u een gearchiveerde blob naar een nieuwe blob een onlinelaag kopieert, blijft de bron-blob ongewijzigd in de archieflaag.
U moet de gearchiveerde blob kopiëren naar een nieuwe blob met een andere naam of naar een andere container. U kunt de bron-blob niet overschrijven door naar dezelfde blob te kopiëren.
Microsoft raadt aan in de meeste scenario's een kopieerbewerking uit te voeren waarbij u een blob moet verplaatsen van de archieflaag naar een online laag. Dit heeft de volgende redenen:
- Een kopieerbewerking voorkomt de kosten voor vroegtijdige verwijdering die worden beoordeeld als u de laag van een blob wijzigt van de archieflaag voordat de vereiste periode van 180 dagen is verstreken. Zie Archieftoegangslaag voor meer informatie.
- Als er een beleid voor levenscyclusbeheer van kracht is voor het opslagaccount, kan het rehydrateren van een blob met De bloblaag instellen resulteren in een scenario waarin het levenscyclusbeleid de blob na rehydratatie terug verplaatst naar de archieflaag omdat de laatste wijzigingstijd de drempelwaarde voor het beleid overschrijdt. Een kopieerbewerking verlaat de bron-blob in de archieflaag en maakt een nieuwe blob met een andere naam en een nieuwe laatste wijzigingstijd, zodat er geen risico bestaat dat de gerehydrateerde blob door het levenscyclusbeleid wordt teruggeviveerd naar de archieflaag.
Het kopiëren van een blob uit de archieflaag kan uren duren, afhankelijk van de geselecteerde rehydratatieprioriteit. Achter de schermen leest een blob-kopieerbewerking uw gearchiveerde bron-blob om een nieuwe online blob te maken in de geselecteerde doellaag. De nieuwe blob is mogelijk zichtbaar wanneer u de blobs in de bovenliggende container vermeldt voordat de rehydratatiebewerking is voltooid, maar de laag wordt ingesteld op Archief, De gegevens zijn pas beschikbaar als de leesbewerking van de bron-blob in de archieflaag is voltooid en de inhoud van de blob naar de nieuwe doelblob in een online laag is geschreven. De nieuwe blob is een onafhankelijke kopie, dus het wijzigen of verwijderen ervan heeft geen invloed op de bron-blob in de archieflaag.
Zie Een blob rehydrateren met een kopieerbewerking voor meer informatie over het rehydraterenvan een blob door deze te kopiëren naar een online laag.
Belangrijk
Verwijder de bron-blob pas als de rehydratatie is voltooid. Als de bron-blob wordt verwijderd, is het mogelijk dat de doel-blob niet klaar is met kopiëren. U kunt de gebeurtenis afhandelen die zich voordeed wanneer de kopieerbewerking is voltooid om te weten wanneer het veilig is om de bron-blob te verwijderen. Zie Handle an event on blob rehydration (Een gebeurtenis verwerken bij rehydratatie van blobs) voor meer informatie.
Het kopiëren van een gearchiveerde blob naar een online doellaag wordt alleen ondersteund binnen hetzelfde opslagaccount. U kunt een gearchiveerde blob niet kopiëren naar een doel-blob die zich ook in de archieflaag.
In de volgende tabel ziet u het gedrag van een blob-kopieerbewerking, afhankelijk van de lagen van de bron- en doel-blob.
| Bron van hot-laag | Bron voor cool-laag | Archieflaagbron | |
|---|---|---|---|
| Hot tier-bestemming | Ondersteund | Ondersteund | Ondersteund binnen hetzelfde account. Vereist rehydratatie van blobs. |
| Bestemming van cool-laag | Ondersteund | Ondersteund | Ondersteund binnen hetzelfde account. Vereist rehydratatie van blobs. |
| Doel archieflaag | Ondersteund | Ondersteund | Niet ondersteund |
De toegangslaag van een blob wijzigen in een online laag
De tweede optie voor het rehydrateren van een blob van de archieflaag naar een online laag is het wijzigen van de bloblaag door Set Blob Tier aan te roepen. Met deze bewerking kunt u de laag van de gearchiveerde blob wijzigen in Hot of Cool.
Zodra een aanvraag voor een Set Blob Tier is gestart, kan deze niet meer worden geannuleerd. Tijdens de rehydratatiebewerking blijft de instelling van de toegangslaag van de blob als gearchiveerd worden uitgevoerd totdat het rehydratatieproces is voltooid. Wanneer de rehydratatiebewerking is voltooid, wordt de eigenschap toegangslaag van de blob bijgewerkt met de nieuwe laag.
Zie Een blob rehydrateren door de laag te wijzigen voor meer informatie over het rehydraterenvan een blob door de laag ervan te wijzigen in een online laag.
Waarschuwing
Het wijzigen van de laag van een blob heeft geen invloed op de tijd van de laatste wijziging. Als er een beleid voor levenscyclusbeheer van kracht is voor het opslagaccount, kan het rehydrateren van een blob met De bloblaag instellen resulteren in een scenario waarin het levenscyclusbeleid de blob na rehydratatie terug verplaatst naar de archieflaag omdat de laatste wijzigingstijd de drempelwaarde voor het beleid overschrijdt.
Om dit scenario te voorkomen, moet u de gearchiveerde blob rehydrateren door deze in plaats daarvan te kopiëren, zoals beschreven in de sectie Een gearchiveerde blob kopiëren naar een online laag. Door een kopieerbewerking uit te voeren, wordt er een nieuw exemplaar van de blob gemaakt met een bijgewerkte laatste wijzigingstijd, zodat het beleid voor levenscyclusbeheer niet wordt activeert.
De status van een blob-rehydratatiebewerking controleren
Tijdens de rehydratatiebewerking van de blob kunt u de bewerking Blob-eigenschappen op halen aanroepen om de status ervan te controleren. Zie De status van een rehydratatiebewerking controleren voor meer informatie over het controleren van de status van een rehydratatiebewerking.
Een gebeurtenis verwerken bij rehydratatie van blobs
Rehydratatie van een gearchiveerde blob kan tot 15 uur duren en het herhaaldelijk peilen van eigenschappen van blobs om te bepalen of rehydratatie is voltooid, is inefficiënt. Het Azure Event Grid om de gebeurtenis vast te leggen die wordt aan werking wanneer de rehydratatie is voltooid, biedt betere prestaties en kostenoptimalisatie.
Azure Event Grid een van de volgende twee gebeurtenissen bij het rehydrateren van blobs, afhankelijk van welke bewerking is gebruikt om de blob te rehydrateren:
- Microsoft.Storage. De gebeurtenis BlobCreated wordt aangemaakt wanneer een blob wordt gemaakt. In de context van rehydratatie van blobs wordt deze gebeurtenis uitgevoerd wanneer met een kopieerblobbewerking een nieuwe doel-blob wordt gemaakt in de laag Hot of Cool en de gegevens van de blob volledig worden gerehydrateerd uit de archieflaag.
- Microsoft.Storage. De gebeurtenis BlobTierChanged wordt opgeslagen wanneer de laag van een blob wordt gewijzigd. In de context van rehydratatie van blobs wordt deze gebeurtenis uitgevoerd wanneer een bewerking Set Blob Tier een gearchiveerde bloblaag wijzigt in de laag Hot of Cool.
Zie Een Azure-functie uitvoeren als reactie op een gebeurtenis voor het rehydraterenvan blobs voor meer informatie over het vastleggen van een gebeurtenis bij rehydratatie en het verzenden ervan naar een Gebeurtenis-handler van Azure Function.
Zie Reacting to Azure Blob storage events (Reageren op gebeurtenissen Storage van Azure Blob Storage) en Azure Blob Storage as Event Grid source (Reageren op gebeurtenissen van Azure Blob Storage en Azure Blob Storage als Event Grid bron).
Prijzen en facturering
Een rehydratatiebewerking met set-bloblaag wordt gefactureerd voor leestransacties van gegevens en de grootte van het ophalen van gegevens. Rehydratatie met hoge prioriteit heeft hogere bewerkings- en kosten voor het ophalen van gegevens in vergelijking met de standaardprioriteit. Rehydratatie met hoge prioriteit wordt als een afzonderlijk regelitem op uw factuur weer gegeven. Als een aanvraag met hoge prioriteit om een gearchiveerde blob van een paar gigabytes te retourneren meer dan vijf uur duurt, wordt het ophaaltarief met hoge prioriteit niet in rekening gebracht. De standaardsnelheden voor ophalen zijn echter nog steeds van toepassing.
Het kopiëren van een gearchiveerde blob naar een onlinelaag met Blob kopiëren wordt gefactureerd voor leestransacties en de grootte van het ophalen van gegevens. Het maken van de doel-blob in een onlinelaag wordt gefactureerd voor gegevens schrijftransacties. Kosten voor vroegtijdige verwijdering zijn niet van toepassing wanneer u naar een online-blob kopieert, omdat de bron-blob ongewijzigd blijft in de archieflaag. Kosten voor ophalen met hoge prioriteit zijn van toepassing als deze optie is geselecteerd.
Blobs in de archieflaag moeten minimaal 180 dagen worden opgeslagen. Voor het verwijderen of wijzigen van de laag van een gearchiveerde blob voordat de periode van 180 dagen is verstreken, worden kosten voor vroegtijdige verwijdering in rekening gebracht. Zie Archieftoegangslaag voor meer informatie.
Zie Prijzen voor meer informatie over prijzen voor blok-blobs en gegevensrehydratatie Azure Storage Prijzen. Zie Prijsinformatie voor gegevensoverdracht voor meer informatie over kosten voor uitgaande gegevensoverdracht.