Rehydratatie van blobs vanuit de archieflaag

Een gearchiveerde blob is offline en kan niet worden gelezen of gewijzigd. Om toegang te krijgen tot de gegevens, rehydrateer je eerst de blob naar een online tier: heet, koel of koud. Gebruik een van de volgende rehydratatiemethoden:

Belangrijk

Je kunt gearchiveerde snapshots of eerdere versies niet direct rehydrateren. Om data te benaderen van een gearchiveerde snapshot of eerdere versie, moet je deze kopiëren naar een nieuwe blob in een online laag (warm, koel of koud) via de Copy Blob-operatie .

Het kan enkele uren duren voordat het reactiveren van een blob vanuit de archieflaag is voltooid. Archiveer grotere blobs voor optimale rehydratatieprestaties. Het reactiveren van een groot aantal kleine blobs kan extra tijd vergen vanwege de verwerkingsbelasting per blob. Maximaal 10 GiB per opslagaccount kan per uur worden gerehydrateerd met prioriteitsopvraging.

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

Rehydratatieprioriteit

Wanneer je een blob rehydrateert, kun je de bewerkingsprioriteit instellen met behulp van de optionele x-ms-rehydrate-priority-header voor een Set Blob Tier- 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 meer dan een standaardprioriteitsrehydratatie. Een rehydratatie met hoge prioriteit kan langer dan een uur duren, afhankelijk van de grootte van de blob en de huidige vraag. Reserveer rehydratie met hoge prioriteit voor herstel van gegevens in noodgevallen.

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.

Belangrijk

De limiet van 10 GiB/uur is van toepassing op opslagaccountniveau, niet per blob. Hoewel tijdlijnen zoals "tot 15 uur" voor standaardprioriteit onder ideale omstandigheden kunnen gelden voor individuele blobs, schalen ze niet lineair voor bulkoperaties. Als je grote hoeveelheden data rehydrateert, verwacht dan langere periodes en plan dienovereenkomstig. De doorvoersnelheid wordt gedeeld door alle blobs die in hetzelfde account worden gerehydrateerd, en als de uurlimiet wordt overschreden, kan dit leiden tot snelheidsbeperking of langdurigere vertragingen. Voor optimale prestaties kunt u rehydratatieaanvragen batchgewijs verwerken en activiteiten op accountniveau bewaken.

Je kunt de rehydratatieprioriteit niet van Hoog naar Standaard verlagen voor een lopende operatie. Het bijwerken van de prioriteit kan invloed hebben op 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

Om een gearchiveerde blob te rehydrateren door deze te kopiëren, gebruik je de Copy Blob-operatie om een nieuwe bestemmingsblob te creëren in de warme, koele of koude tier. De bronblob blijft 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.

Vermijd herarchivering van levenscyclusbeleid

Kopiëren kan ook voorkomen dat een levenscyclusbeheerbeleid een gerehydrateerde blob terug naar de archieflaag verplaatst. Dit risico bestaat wanneer de tierToArchive actie van het beleid de daysAfterLastTierChangeGreaterThan voorwaarde niet bevat en de laatste gewijzigde tijd van de blob de beleidsdrempel overschrijdt. Een kopieeroperatie laat de bronblob achter in de archieflaag en maakt een nieuwe blob aan met een andere naam en een nieuwe laatste gewijzigde tijd.

Voltooiing van kopiëren bewaken

Het kopiëren van een blob uit de archieflaag kan uren duren, afhankelijk van de gekozen rehydratatieprioriteit. De kopieeroperatie leest de gearchiveerde bronblob en creëert een nieuwe blob in de geselecteerde online tier. De nieuwe blob kan in de oudercontainer verschijnen voordat de rehydratatie voltooid is, maar de laag blijft archief. De data wordt beschikbaar nadat de service de bronblob heeft gelezen en de inhoud naar de bestemmingsblob heeft geschreven. De nieuwe blob is een onafhankelijke kopie, dus het wijzigen of verwijderen ervan beïnvloedt de gearchiveerde bronblob niet.

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 bronblob niet totdat de rehydratatie succesvol is voltooid. Als je de bronblob verwijdert, is het mogelijk dat de bestemmingsblob het kopieën niet afmaakt. Monitor het voltooiingsevent om te bepalen wanneer je de bronblob veilig kunt verwijderen. Voor meer informatie raadpleegt u een blob-rehydratatiegebeurtenis afhandelen.

Kopiëren tussen opslagaccounts

Serviceversie 2021-02-12 en later ondersteunt rehydratie door een gearchiveerde blob te kopiëren naar een ander opslagaccount in dezelfde regio. Eerdere serviceversies ondersteunden rehydratatie alleen binnen hetzelfde opslagaccount. Met rehydratie tussen opslagaccounts kunt u uw productiegegevens scheiden van uw back-upgegevens door deze in afzonderlijke accounts onder te brengen. Het isoleren van gearchiveerde gegevens in een apart account kan ook helpen om kosten van onbedoelde rehydratatie te beperken.

De doelgroep voor de kopieeroperatie moet zich in een online tier bevinden (warm, koel of koud). 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 Koude laagbron Bron van archiefniveau
Bestemming van hot tier Ondersteund 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 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.
Koude-tier bestemming Ondersteund 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 Ondersteund Niet ondersteund

Rehydrateer vanuit een secundaire regio

Als je opslagaccount gebruikmaakt van geo-redundante opslag met leestoegang (RA-GRS), gebruik dan de bewerking Copy Blob om blobs vanuit de secundaire regio naar een ander opslagaccount in die regio te rehydrateren. 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 naar een online-toegangslaag

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 kun je de laag van de gearchiveerde blob veranderen naar warm, koel of koud.

Je kunt een Set Blob Tier-verzoek niet annuleren nadat het is begonnen. Tijdens rehydratatie blijft het toegangsniveau van de blob archief. Wanneer de rehydratatie is voltooid, wordt in de eigenschap voor de toegangslaag de nieuwe laag weergegeven.

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 het opslagaccount een levenscyclusbeheerbeleid heeft, kan het beleid de blob na rehydratie terugverplaatsen naar het archiefniveau wanneer de laatste gewijzigde tijd de beleidsdrempel overschrijdt.

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. Het uitvoeren van een kopieeroperatie creëert een nieuwe instantie van de blob met een bijgewerkte laatst gewijzigde tijd, waardoor het lifecycle management-beleid 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.

Behandel een blob-rehydratie-gebeurtenis

Het rehydrateren van een gearchiveerde blob kan tot 15 uur duren, en het herhaaldelijk pollen van Get Blob Properties is inefficiënt. Gebruik Azure Event Grid om het voltooiingsevent vast te leggen voor betere prestaties en lagere kosten.

Azure Event Grid activeert de Microsoft.Storage.BlobTierChanged gebeurtenis wanneer de rehydratie van blobs is voltooid:

  • Het Microsoft.Storage.BlobTierChanged evenement wordt geactiveerd wanneer de tier van een blob verandert. Voor blobrehydratatie wordt de gebeurtenis geactiveerd wanneer de bestemmingsblob met succes wijzigt van de archieflaag naar een onlinelaag (warm, koel of koud).

Wanneer u de kopieer-blobbewerking gebruikt om een blob uit de archieflaag te kopiëren naar een nieuwe doel-blob in een onlinelaag (dynamisch, statisch of koud) voor rehydratatie:

  1. Azure Event Grid activeert een Microsoft.Storage.BlobCreated gebeurtenis wanneer de kopieeroperatie begint. De laag van de blob is Archief.

  2. Nadat de blob is gekopieerd en opnieuw gehydrateerd, start Azure Event Grid een Microsoft.Storage.BlobTierChanged gebeurtenis die de overgang van Archive naar de gespecificeerde online laag aangeeft.

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.

Voor meer informatie over het afhandelen van gebeurtenissen in Blob Storage, zie Reacting to Azure Blob storage events en Azure Blob Storage as Event Grid-bron.

Prijsstelling en facturering

Voor Set Blob Tier rekent Azure Storage kosten voor data-readtransacties en de hoeveelheid opgehaalde data. Rehydratatie met hoge prioriteit kost meer dan standaardprioriteit en verschijnt als een aparte post op je factuur. Als een verzoek met hoge prioriteit voor een gearchiveerde blob kleiner dan 10 GB meer dan vijf uur duurt, rekent Azure Storage het ophaaltarief voor hoge prioriteit niet. Standaard ophaaltarievens zijn nog steeds van toepassing. Zie Kostenraming voor een voorbeeld van een schatting van de kosten: Gegevens uit archiefopslag verplaatsen.

Voor Copy Blob rekent Azure Storage kosten voor data-read-transacties, de hoeveelheid opgehaalde data en data-write-transacties voor de bestemmingsblob. Vroege verwijderingskosten zijn niet van toepassing omdat de bronblob ongewijzigd blijft in de archieflaag. Kosten voor ophalen 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 bijvoorbeeld een blob naar de archieflaag wordt verplaatst en vervolgens na 45 dagen wordt verwijderd of verplaatst naar de hot tier, krijg je een vroegtijdige verwijderingskosten die gelijk staat aan 135 (180 min 45) dagen om die blob in de archieflaag op te slaan. Zie archieftoegangslaag voor meer informatie.

Voor meer informatie over de prijsstelling van blokblobs en datarehydratie, zie Azure Storage pricing. Raadpleeg Prijsdetails voor gegevensoverdracht voor meer informatie over de kosten voor uitgaande gegevensoverdracht.

Zie ook

  • Last updated on