Delen via

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:

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 herstellen. Het reactiveren van een groot aantal kleine blobs kan extra tijd vergen vanwege de verwerkingsbelasting per blob. Een maximum van 10 GiB per opslagaccount kan per uur worden gerehydrateerd met prioriteit ophalen.

Zie Een gearchiveerde blob reactiveren naar een onlinelaag voor meer informatie over het reactiveren van een gearchiveerde blob naar een onlinelaag.

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 maximaal 15 uur duren voor objecten kleiner dan 10 GB.
  • 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 Standaard of Hoog.

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.

Voor meer informatie over prijsverschillen tussen rehydratatieaanvragen met een standaardprioriteit en een hoge prioriteit, zie Prijzen voor Azure Blob Storage.

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 rehydrateren van een blob met de bewerking Blob-laag instellen leiden tot een scenario waarin het levenscyclusbeleid de blob na rehydratatie weer naar de archieflaag terugstuurt omdat de laatste wijzigingstijd buiten de voor het beleid ingestelde drempelwaarde valt. 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 blobkopie-operatie 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 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 met succes 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 tijdens de 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 afzonderen van uw back-upgegevens door ze in afzonderlijke accounts te bewaren. Het isoleren van gearchiveerde gegevens in een afzonderlijk account kan ook helpen om kosten te besparen op ongewenste rehydratatie.

De doel-blob voor de kopieerbewerking moet zich in een online niveau bevinden (hot of cool). 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 hete laag Bron van koele laag Bron van archiefniveau
Bestemming van hot tier 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 het rehydrateren van blobs.
Geweldige bestemming binnen rang 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 het rehydrateren 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 om de bloblaag te veranderen door het aanroepen van Set Blob Tier. Met deze bewerking kunt u de laag van de gearchiveerde blob wijzigen in dynamisch of statisch.

Zodra een aanvraag voor het Blob-niveau instellen is ingediend, 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 voor instructies over het reactiveren van een blob door de laag naar een online laag te veranderen.

Waarschuwing

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 activeren van een blob met Set Blob Tier resulteren in een scenario waarin het levenscyclusbeheerbeleid de blob na rehydratatie terugplaatst naar de archieflaag omdat de laatste wijzigingstijd buiten de voor het beleid ingestelde drempelwaarde ligt.

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 rehydrateren door deze te kopiëren, zoals beschreven in de sectie Een gearchiveerde blob kopiëren naar een onlinelaag. 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.

Handel een gebeurtenis bij blob-herstel

Rehydratatie van een gearchiveerde blob kan tot 15 uur duren. Het is inefficiënt om steeds te blijven controleren of rehydratatie is voltooid via Blobeigenschappen opvragen. 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 Set Blob Tier-bewerking 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 bestemmingsblob in een online-toegangslaag.

Zie Een Azure-functie uitvoeren als reactie op een rehydratatiegebeurtenis van een blob voor meer informatie over het vastleggen van een rehydratatiegebeurtenis en hoe deze naar een Azure Function-event handler kan worden verzonden.

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.

Prijsstelling en facturering

Een rehydratatiebewerking met Set Blob Tier wordt gefactureerd voor gegevenslezingstransacties en het gegevensopslaggrootte voor ophalen. 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 afzonderlijke regel op uw factuur. Als een aanvraag met hoge prioriteit om een gearchiveerde blob terug te halen die kleiner is dan 10 GB langer dan vijf uur duurt, worden er geen kosten in rekening gebracht voor ophalen met hoge prioriteit. Standaard ophaaltarieven zijn echter nog steeds van toepassing. Zie Kostenraming voor een voorbeeld van een schatting van de kosten: Gegevens uit archiefopslag verplaatsen.

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. Zie Kostenraming voor een voorbeeldraming: Gegevens ophalen uit archiefopslag voor analyse.

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 naar de archieflaag wordt verplaatst en daarna na 45 dagen wordt verwijderd of naar de dynamische laag wordt verplaatst, worden er kosten voor vroegtijdige verwijdering in rekening gebracht die gelijk zijn 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.

Zie ook