Rehydratatie van blobs vanuit de archieflaag
Hoewel een blob zich in de archieftoegangslaag bevindt, wordt die blob als offline beschouwd en kan deze niet worden gelezen of gewijzigd. Als u gegevens in een gearchiveerde blob wilt lezen of wijzigen, moet u de blob eerst reactiveren naar een onlinelaag, ofwel de dynamische of statische laag. Er zijn twee opties voor het reactiveren van een blob die is opgeslagen in de archieflaag:
Kopieer een gearchiveerde blob naar een onlinelaag: u kunt een gearchiveerde blob reactiveren door deze te kopiëren naar een nieuwe blob in de dynamische of statische laag met de kopieer-blobbewerking .
Wijzig de toegangslaag van een gearchiveerde blob in een onlinelaag: u kunt een gearchiveerde blob reactiveren naar de dynamische of statische laag door de laag ervan te wijzigen met behulp van de bewerking Blob-laag instellen.
Het kan enkele uren duren voordat het reactiveren van een blob vanuit de archieflaag is voltooid. Microsoft raadt aan om grotere blobs te archiveren voor optimale prestaties bij het reactiveren. Het reactiveren van een groot aantal kleine blobs kan extra tijd vereisen vanwege de verwerkingsoverhead voor elke blob. Een maximum van 10 GiB per opslagaccount kan per uur worden gerehydrateerd met prioriteit ophalen.
Rehydratatieprioriteit
Wanneer u een blob rehydrateerde, kunt u de prioriteit voor de rehydratatiebewerking instellen via de optionele header x-ms-rehydrate-priority op een Set Blob-laag of Copy Blob-bewerking. Opties voor rehydratatieprioriteit zijn onder andere:
- Standaardprioriteit: de rehydratatieaanvraag wordt verwerkt in de volgorde waarin deze is ontvangen en kan tot 15 uur duren voordat objecten van minder dan 10 GB groot zijn.
- Hoge prioriteit: De rehydratatieaanvraag krijgt prioriteit boven aanvragen met standaardprioriteit en kan in minder dan één uur worden voltooid voor objecten die kleiner zijn dan 10 GB.
Als u de rehydratatieprioriteit wilt controleren terwijl de rehydratatiebewerking wordt uitgevoerd, roept u Blob-eigenschappen ophalen aan om de waarde van de x-ms-rehydrate-priority header te retourneren. De eigenschap rehydratatieprioriteit retourneert Standard of High.
Standaardprioriteit is de standaardoptie rehydratatie. Een rehydratatie met hoge prioriteit is sneller, maar kost ook meer dan rehydratatie met standaardprioriteit. Een rehydratatie met een hoge prioriteit kan langer dan één uur duren, afhankelijk van de blobgrootte en de huidige vraag. Microsoft raadt aan om rehydratatie met hoge prioriteit te reserveren voor gebruik in situaties met herstel van noodgegevens.
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 reactiveren. Als u bijvoorbeeld een groot aantal blobs bulksgewijs rehydrateert, kunt u standaardprioriteit opgeven voor alle blobs voor de eerste bewerking, 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 High naar Standard voor een bewerking die in behandeling is. Houd er rekening mee dat het bijwerken van de prioriteitsinstelling voor rehydratatie mogelijk gevolgen heeft voor de facturering.
Zie Een gearchiveerde blob reactiveren naar een onlinelaag voor meer informatie over het instellen en bijwerken van de prioriteitsinstelling voor rehydratatie.
Zie Prijzen voor Azure Blob Storage voor meer informatie over prijsverschillen tussen rehydratatieaanvragen met een standaardprioriteit en reactivatieaanvragen met hoge prioriteit.
Een gearchiveerde blob naar een online laag kopiëren
De eerste optie voor het verplaatsen van een blob van de archieflaag naar een onlinelaag is het kopiëren van de gearchiveerde blob naar een nieuwe doel-blob die zich in de dynamische, statische of koude laag bevindt. U kunt de kopieer-blobbewerking gebruiken om de blob te kopiëren. Wanneer u een gearchiveerde blob naar een nieuwe blob in 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.
Door een blob van de archieflaag naar een onlinelaag te kopiëren, kunt u de kosten voor vroegtijdige verwijdering voorkomen die worden beoordeeld als u de laag van een blob wijzigt uit de archieflaag voordat de vereiste periode van 180 dagen is verstreken. Zie archieftoegangslaag voor meer informatie.
Deze optie kan ook zinvol zijn als er een beleid voor levenscyclusbeheer van kracht is voor het opslagaccount en de daysAfterLastTierChangeGreaterThan voorwaarde niet wordt toegevoegd aan elke tierToArchive actie van het beleid. In dat geval kan het reactiveren van een blob met de bewerking Blob-laag instellen leiden tot een scenario waarin het levenscyclusbeleid de blob na rehydratatie weer naar de archieflaag verplaatst omdat de laatste wijzigingstijd buiten de drempelwaarde valt die voor het beleid is ingesteld. Een kopieerbewerking verlaat de bron-blob in de archieflaag en maakt een nieuwe blob met een andere naam en een nieuwe laatste wijzigingstijd, dus er is geen risico dat de gerehydrateerde blob wordt teruggezet naar de archieflaag door het levenscyclusbeleid.
Het kopiëren van een blob vanuit de archieflaag kan uren duren, afhankelijk van de geselecteerde rehydratatieprioriteit. Achter de schermen leest een blobkopiebewerking uw gearchiveerde bron-blob voor 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 weergeeft voordat de rehydratatiebewerking is voltooid, maar de laag wordt ingesteld op archiveren. De gegevens zijn pas beschikbaar als de leesbewerking van de bron-blob in de archieflaag is voltooid en de inhoud van de blob is geschreven naar de nieuwe doel-blob in een onlinelaag. 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 reactiveren met een kopieerbewerking voor meer informatie over het reactiveren van een blob door deze te kopiëren naar een onlinelaag.
Belangrijk
Verwijder de bron-blob pas nadat de rehydratatie is voltooid. Als de bron-blob wordt verwijderd, kan het kopiëren van de doel-blob niet worden voltooid. U kunt de gebeurtenis afhandelen die wordt gegenereerd wanneer de kopieerbewerking is voltooid om te weten wanneer het veilig is om de bron-blob te verwijderen. Zie Een gebeurtenis afhandelen op rehydratatie van blobs voor meer informatie.
Het reactiveren van een gearchiveerde blob door deze te kopiëren naar een online doellaag wordt alleen ondersteund binnen hetzelfde opslagaccount voor serviceversies vóór 2021-02-12. Vanaf serviceversie 2021-02-12 kunt u een gearchiveerde blob reactiveren door deze te kopiëren naar een ander opslagaccount, zolang het doelaccount zich in dezelfde regio bevindt als het bronaccount. Met rehydratatie tussen opslagaccounts kunt u uw productiegegevens scheiden van uw back-upgegevens door ze in afzonderlijke accounts te onderhouden. Het isoleren van gearchiveerde gegevens in een afzonderlijk account kan ook helpen om kosten te beperken tegen onbedoelde rehydratatie.
De doel-blob voor de kopieerbewerking moet zich in een onlinelaag bevinden (dynamisch of statisch). U kunt een gearchiveerde blob niet kopiëren naar een doel-blob die zich ook in de archieflaag bevindt.
In de volgende tabel ziet u het gedrag van een blobkopiebewerking, afhankelijk van de lagen van de bron- en doel-blob.
| Bron van dynamische laag | Bron van statische laag | Bron van archieflaag | |
|---|---|---|---|
| Doel van dynamische laag | Ondersteund | Ondersteund | Ondersteund voor accounts in dezelfde regio met versie 2021-02-12 en hoger. Wordt alleen ondersteund in hetzelfde opslagaccount voor eerdere versies. Vereist rehydratatie van blobs. |
| Doel van statische laag | Ondersteund | Ondersteund | Ondersteund voor accounts in dezelfde regio met versie 2021-02-12 en hoger. Wordt alleen ondersteund in hetzelfde opslagaccount voor eerdere versies. Vereist rehydratatie van blobs. |
| Doel van archieflaag | Ondersteund | Ondersteund | Niet ondersteund |
Rehydrateer vanuit een secundaire regio
Als u uw opslagaccount hebt geconfigureerd voor het gebruik van geografisch redundante opslag met leestoegang (RA-GRS), kunt u de kopieer-blobbewerking gebruiken om blobs in de secundaire regio te reactiveren naar een ander opslagaccount dat zich in dezelfde secundaire regio bevindt. Zie Rehydrate vanuit een secundaire regio.
Zie Leestoegang tot gegevens in de secundaire regio voor meer informatie over het verkrijgen van leestoegang tot secundaire regio's.
De toegangslaag van een blob wijzigen in een onlinelaag
De tweede optie voor het reactiveren van een blob van de archieflaag naar een onlinelaag is het wijzigen van de bloblaag door set-bloblaag aan te roepen. Met deze bewerking kunt u de laag van de gearchiveerde blob wijzigen in dynamisch of statisch.
Zodra een aanvraag voor de bloblaag instellen is gestart, kan deze niet worden geannuleerd. Tijdens de rehydratatiebewerking blijft de instelling voor de toegangslaag van de blob worden weergegeven als gearchiveerd totdat het rehydratatieproces is voltooid. Wanneer de rehydratatiebewerking is voltooid, wordt de eigenschap van de toegangslaag van de blob bijgewerkt om de nieuwe laag weer te geven.
Zie Een blob reactiveren door de laag te wijzigen in een onlinelaag voor meer informatie over het reactiveren van een blob door de laag te wijzigen.
Let op
Het wijzigen van de laag van een blob heeft geen invloed op de laatste wijzigingstijd. Als er een levenscyclusbeheerbeleid geldt voor het opslagaccount, kan het reactiveren van een blob met de set-bloblaag resulteren in een scenario waarin het levenscyclusbeleid de blob na rehydratatie weer naar de archieflaag verplaatst omdat de laatste wijzigingstijd buiten de drempelwaarde valt die is ingesteld voor het beleid.
Als u dit scenario wilt voorkomen, voegt u de daysAfterLastTierChangeGreaterThan voorwaarde toe aan de tierToArchive actie van het beleid. U kunt de gearchiveerde blob ook reactiveren door deze te kopiëren, zoals beschreven in de sectie Een gearchiveerde blob kopiëren naar een onlinelaagsectie . Als u een kopieerbewerking uitvoert, wordt er een nieuw exemplaar van de blob gemaakt met een bijgewerkte laatste wijzigingstijd, zodat het levenscyclusbeheerbeleid niet wordt geactiveerd.
De status van een rehydratatiebewerking van een blob controleren
Tijdens de rehydratatiebewerking van de blob kunt u de bewerking Blobeigenschappen ophalen 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 afhandelen op rehydratatie van blobs
Rehydratatie van een gearchiveerde blob kan maximaal 15 uur duren en het is inefficiënt om herhaaldelijk blobeigenschappen te peilen om te bepalen of rehydratatie is voltooid. Microsoft raadt u aan Azure Event Grid te gebruiken om de gebeurtenis vast te leggen die wordt geactiveerd wanneer rehydratatie is voltooid voor betere prestaties en kostenoptimalisatie.
Azure Event Grid genereert de gebeurtenis Microsoft.Storage.BlobTierChanged bij het voltooien van rehydratatie van blobs:
- De gebeurtenis Microsoft.Storage.BlobTierChanged wordt geactiveerd wanneer de laag van een blob wordt gewijzigd. In de context van rehydratatie van blobs wordt deze gebeurtenis geactiveerd wanneer de toegangslaag van een doel-blob is gewijzigd van archieflaag naar een onlinelaag (dynamisch, statisch of koud). U kunt de bewerking Blob-laag instellen gebruiken om de toegangslaag van een gearchiveerde blob te wijzigen of de bewerking Blob kopiëren gebruiken om een gearchiveerde blob te kopiëren naar een nieuwe doel-blob in een onlinelaag.
Zie Een Azure-functie uitvoeren als reactie op een rehydratatiegebeurtenis. Zie Een Azure-functie uitvoeren als reactie op een rehydratatiegebeurtenis van een blob voor meer informatie over het vastleggen van rehydratatie en het verzenden ervan naar een Azure Function-gebeurtenis.
Zie Reageren op Azure Blob Storage-gebeurtenissen en Azure Blob Storage als Event Grid-bron voor meer informatie over het verwerken van gebeurtenissen in Blob Storage.
Prijzen en facturering
Een rehydratatiebewerking met de bloblaag instellen wordt gefactureerd voor gegevensleestransacties en de grootte van het ophalen van gegevens. Een rehydratatie met hoge prioriteit heeft hogere bewerkingen en kosten voor het ophalen van gegevens in vergelijking met de standaardprioriteit. Rehydratatie met hoge prioriteit wordt weergegeven als een afzonderlijk regelitem op uw factuur. Als een aanvraag met hoge prioriteit voor het retourneren van een gearchiveerde blob die kleiner is dan 10 GB langer dan vijf uur duurt, worden er geen kosten in rekening gebracht voor het ophalen van hoge prioriteit. Standaard ophaaltarieven zijn echter nog steeds van toepassing.
Het kopiëren van een gearchiveerde blob naar een onlinelaag met Copy Blob wordt gefactureerd voor gegevensleestransacties en de grootte van het ophalen van gegevens. Het maken van de doel-blob in een onlinelaag wordt gefactureerd voor gegevensschrijftransacties. Kosten voor vroegtijdige verwijdering zijn niet van toepassing wanneer u kopieert naar een online-blob, omdat de bron-blob ongewijzigd blijft in de archieflaag. Ophaalkosten met hoge prioriteit zijn van toepassing indien 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 in rekening gebracht voor vroegtijdige verwijdering. Als een blob bijvoorbeeld wordt verplaatst naar de archieflaag en na 45 dagen na 45 dagen naar de dynamische laag wordt verwijderd of verplaatst, worden kosten in rekening gebracht voor vroegtijdige verwijdering die gelijk is aan 135 (180 min 45) dagen voor het opslaan van die blob in de archieflaag. Zie archieftoegangslaag voor meer informatie.
Zie De prijzen van Azure Storage voor meer informatie over prijzen voor blok-blobs en gegevensrehydratatie. Zie Prijsinformatie voor gegevensoverdracht voor meer informatie over uitgaande kosten voor gegevensoverdracht.