Dela via

Blobrehydrering från arkivnivån

När en blob finns på arkivåtkomstnivån anses den bloben vara offline och kan inte läsas eller ändras. För att kunna läsa eller ändra data i en arkiverad blob måste du först rehydrera bloben till en onlinenivå, antingen den varma eller kalla nivån. Det finns två alternativ för att återställa en blob som lagras på arkivnivån:

Det kan ta flera timmar att återställa en blob från arkivnivån. Microsoft rekommenderar arkivering av stora blobar för prestandaoptimering vid återhydrering. Att rehydrera ett stort antal små blobar kan kräva extra tid på grund av bearbetningsbelastningen för varje blob. Högst 10 GiB per lagringskonto kan rehydreras per timme med prioriterad hämtning.

Information om hur du rehydrerar en arkiverad blob till en onlinenivå finns i Återfukta en arkiverad blob till en onlinenivå.

Rehydreringsprioritet

När du rehydrerar en blob kan du ange prioriteten för rehydreringsoperationen via den valfria rubriken x-ms-rehydrate-priority i en Set Blob-nivå eller kopiera blob-operation. Bland alternativen för återfuktningsprioritet finns:

  • Standardprioritet: Begäran om återfuktning bearbetas i den ordning den togs emot och kan ta upp till 15 timmar att slutföra för objekt under 10 GB i storlek.
  • Hög prioritet: Begäran om återfuktning prioriteras framför standardprioritetsbegäranden och kan slutföras på mindre än en timme för objekt under 10 GB i storlek.

Om du vill kontrollera rehydreringens prioritet medan rehydreringsprocessen pågår anropar du Hämta blobegenskaper för att returnera värdet för x-ms-rehydrate-priority rubriken. Egenskapen rehydreringsprioritet returnerar antingen Standard eller High.

Standardprioritet är standardalternativet för återfuktning. En högprioriterad rehydrering är snabbare, men kostar också mer än en standardprioritetsrehydrering. En högprioriterad rehydrering kan ta längre tid än en timme, beroende på blobstorlek och aktuell efterfrågan. Microsoft rekommenderar att du reserverar högprioriterad rehydrering för användning i nödsituationssituationer för dataåterställning.

Medan en rehydreringsåtgärd med standardprioritet väntar kan du uppdatera inställningen för rehydreringsprioritet för en blob till Hög för att rehydrera den bloben snabbare. Om du till exempel rehydrerar en stor mängd blobbar i bulk kan du ange Standard prioritet för alla blobbar för den inledande åtgärden, och sedan höja prioriteten till Hög för individuella blobbar som behöver aktiveras snabbare, upp till en maxgräns på 10 GiB i timmen.

Inställningen för rehydreringsprioritet kan inte sänkas från Hög till Standard för en väntande åtgärd. Tänk på att uppdatering av inställningen för återfuktningsprioritet kan ha en faktureringspåverkan.

Information om hur du konfigurerar och uppdaterar inställningen för rehydreringsprioritet finns i Rehydrate an archived blob to an online tier (Extrahera en arkiverad blob till en online-nivå).

Mer information om prisskillnader mellan begäranden med standardprioritet och hög prioritet finns i Priser för Azure Blob Storage.

Kopiera en arkiverad blob till onlinenivå

Det första alternativet för att flytta en blob från arkivnivån till en onlinenivå är att kopiera den arkiverade bloben till en ny målblob som finns på antingen frekvent, lågfrekvent eller kall nivå. Du kan använda åtgärden Kopiera blob för att kopiera bloben. När du kopierar en arkiverad blob till en ny blob på en onlinenivå förblir källbloben oförändrad på arkivnivån.

Du måste kopiera den arkiverade bloben till en ny blob med ett annat namn eller till en annan container. Du kan inte skriva över källbloben genom att kopiera till samma blob.

Genom att kopiera en blob från arkivnivån till en onlinenivå kan du undvika den avgift för tidig borttagning som utvärderas om du ändrar nivån för en blob från arkivnivån innan den nödvändiga 180-dagarsperioden förflutit. Mer information finns i Arkivåtkomstnivå.

Det här alternativet kan också vara meningsfullt om det finns en livscykelhanteringsprincip som gäller för lagringskontot och villkoret daysAfterLastTierChangeGreaterThan inte läggs till i varje tierToArchive åtgärd i principen. I så fall kan uthydrering av en blob med åtgärden Ange blobnivå resultera i ett scenario där livscykelprincipen flyttar tillbaka blobben till arkivnivån efter rehydrering eftersom den senaste ändrade tiden ligger över tröskelvärdet som angetts för principen. En kopieringsåtgärd lämnar källblobben på arkivnivån, skapar en ny blob med ett annat namn, och en ny tidsstämpel för senaste ändring, så det finns ingen risk att den återskapade blobben flyttas tillbaka till arkivnivån av livscykelpolicyn.

Att kopiera en blob från arkivnivå kan ta flera timmar beroende på den återhydreringsprioritet du har valt. I bakgrunden läser en blobkopieringsåtgärd din arkiverade källblob för att skapa en ny online-blob på den valda destinationsnivån. Den nya bloben kan vara synlig när du listar blobarna i den överordnade containern innan återfuktningsåtgärden är klar, men dess nivå kommer att vara inställd på arkivering. Data är inte tillgängliga förrän läsåtgärden från källbloben på arkivnivån är klar och blobens innehåll har skrivits till den nya målbloben på en onlinenivå. Den nya bloben är en oberoende kopia, så att ändra eller ta bort den påverkar inte källbloben på arkivnivån.

För att lära dig hur du återställer en blob genom att kopiera den till en online nivå, se Återskapa en blob med en kopieringsåtgärd.

Viktigt!

Ta inte bort källbloben förrän uttorkningen har slutförts. Om källbloben tas bort kanske målbloben inte slutför kopieringen. Du kan hantera händelsen som utlöses när kopieringsåtgärden slutförs för att veta när det är säkert att ta bort källbloben. För mer information, se Hantera en händelse vid blobåterställning.

Det är endast möjligt att rehydrera en arkiverad blob genom att kopiera den till online-destinationens nivå inom samma lagringskonto, och detta stöds endast för tjänstversioner före 2021-02-12. Från och med tjänstversion 2021-02-12 kan du rehydrera en arkiverad blob genom att kopiera den till ett annat lagringskonto, under förutsättning att målkontot är i samma region som källkontot. Med återfuktning mellan lagringskonton kan du separera dina produktionsdata från dina säkerhetskopierade data genom att underhålla dem i separata konton. Att isolera arkiverade data i ett separat konto kan också bidra till att minska kostnaderna från oavsiktlig rehydrering.

Målblobben för kopieringsåtgärden måste finnas på en online-nivå (hot eller cool). Du kan inte kopiera en arkiverad blob till en målblob som också finns på arkivnivån.

I följande tabell visas beteendet för en blobkopieringsåtgärd, beroende på nivåerna för käll- och målbloben.

Aktiv nivåkälla Källa av hög nivå Arkivnivåkälla
Destination för högprestandanivå Stöttad Stöttad Stöds för konton i samma region med version 2021-02-12 och senare. Stöds endast i samma lagringskonto för tidigare versioner. Kräver blobrehydrering.
Häftigt resmål Stöttad Stöttad Stöds för konton i samma region med version 2021-02-12 och senare. Stöds endast i samma lagringskonto för tidigare versioner. Kräver blobrehydrering.
Arkivnivådestination Stöttad Stöttad Stöds inte

Rehydrera från en sekundär region

Om du har konfigurerat ditt lagringskonto för att använda geo-redundant lagring med läsåtkomst (RA-GRS) kan du använda åtgärden Kopiera blob för att extrahera blobar i den sekundära regionen till ett annat lagringskonto som finns i samma sekundära region. Se Rehydrera från en sekundär region.

Mer information om hur du skaffar läsåtkomst till sekundära regioner finns i Läs åtkomst till data i den sekundära regionen.

Ändra åtkomstnivån för en blob till en onlinenivå

Det andra alternativet för att återställa en blob från arkivnivån till en onlinenivå är att ändra blobens nivå genom att anropa Ange blobnivå. Med den här åtgärden kan du ändra nivån för den arkiverade bloben till antingen frekvent eller lågfrekvent.

När en begäran om att ställa in blob-nivå har initierats kan den inte avbrytas. Under rehydreringsåtgärden fortsätter blobens åtkomstnivåinställning att visas som arkiverad tills rehydreringsprocessen är klar. När rehydreringsåtgärden är klar uppdateras blobens åtkomstnivåegenskap så att den återspeglar den nya nivån.

Information om hur du återställer en blob genom att ändra dess nivå till en onlinenivå finns i Återställ en blob genom att ändra dess nivå.

Varning

Att ändra en blob-nivå påverkar inte den senaste ändrade tiden. Om det finns en princip för livscykelhantering som gäller för lagringskontot kan uthydrering av en blob med Ange blobnivå resultera i ett scenario där livscykelprincipen flyttar blobben tillbaka till arkivnivån efter uttorkning eftersom den senaste ändrade tiden ligger över tröskelvärdet som angetts för principen.

Undvik det här scenariot genom att lägga till villkoret daysAfterLastTierChangeGreaterThan i tierToArchive principens åtgärd. Du kan också återställa den arkiverade bloben genom att kopiera den istället, enligt beskrivningen i avsnittet Kopiera en arkiverad blob till en online-nivå. När du utför en kopieringsåtgärd skapas en ny instans av bloben med en uppdaterad senast ändrad tid, så att den inte utlöser livscykelhanteringsprincipen.

Kontrollera statusen för en blobrehydreringsåtgärd

Under blobrehydreringsåtgärden kan du anropa åtgärden Hämta blobegenskaper för att kontrollera dess status. Information om hur du kontrollerar status för en rehydreringsåtgärd finns i Kontrollera status för en rehydreringsåtgärd.

Hantera en händelse vid blob-rehydrering

Rehydrering av en arkiverad blob kan ta upp till 15 timmar och det är ineffektivt att upprepade gånger avsöka Hämta blobegenskaper för att avgöra om rehydreringen är klar. Microsoft rekommenderar att du använder Azure Event Grid för att samla in händelsen som utlöses när rehydrering är klar för bättre prestanda och kostnadsoptimering.

Azure Event Grid genererar händelsen Microsoft.Storage.BlobTierChanged när blobrehydrering har slutförts :

  • Händelsen Microsoft.Storage.BlobTierChanged utlöses när en blobnivå ändras. I samband med blobrehydrering utlöses den här händelsen när åtkomstnivån för en målblob har ändrats från arkivnivå till en onlinenivå (frekvent, lågfrekvent eller kall nivå). Du kan använda åtgärden Ange blobnivå för att ändra åtkomstnivån för en arkiverad blob eller använda åtgärden Kopiera blob för att kopiera en arkiverad blob till en ny målblob på en onlinenivå.

Information om hur du fångar upp en händelse vid återställning och skickar den till en händelsehanterare för Azure Functions finns i köra en Azure-funktion som svar på en blobåterställningshändelse.

Mer information om hur du hanterar händelser i Blob Storage finns i Reacting to Azure Blob Storage events and Azure Blob Storage as Event Grid source (Reagera på Azure Blob Storage-händelser och Azure Blob Storage som Event Grid-källa).

Prissättning och fakturering

En rehydreringsåtgärd med Set Blob Tier debiteras för dataläsningstransaktioner och datahämtningsstorlek. En högprioriterad rehydrering har högre kostnader för drift och datahämtning jämfört med standardprioritet. Högprioriterad vätsketillförsel visas som en separat post på din faktura. Om en högprioriterad begäran om att returnera en arkiverad blob som är mindre än 10 GB i storlek tar mer än fem timmar debiteras du inte hämtningshastigheten med hög prioritet. Standardhämtningsfrekvensen gäller dock fortfarande. En exempelkostnadsuppskattning finns i Kostnadsuppskattning: Flytta data från arkivlagring.

Kopiering av en arkiverad blob till en onlinenivå med Kopieringsblob debiteras för dataläsningstransaktioner och datahämtningsstorlek. När du skapar målbloben på en onlinenivå debiteras du för dataskrivningstransaktioner. Avgifter för tidig borttagning gäller inte när du kopierar till en onlineblob eftersom källbloben förblir oförändrad på arkivnivån. Avgifter för hämtning med hög prioritet tillämpas om det väljs. En exempeluppskattning finns i Kostnadsuppskattning: Hämta data från arkivlagring för analys.

Blobar på arkivnivån ska lagras i minst 180 dagar. Om du tar bort eller ändrar nivån för en arkiverad blob innan 180-dagarsperioden förflutit medför det en avgift för tidig radering. Om en blob till exempel flyttas till arkivnivån och sedan tas bort eller flyttas till den frekventa nivån efter 45 dagar debiteras du en avgift för tidig borttagning som motsvarar 135 (180 minus 45) dagar efter lagring av blobben på arkivnivån. Mer information finns i Arkivåtkomstnivå.

Mer information om priser för blockblobar och dataåterställning finns i Prissättning för Azure Storage. Mer information om avgifter för utgående dataöverföring finns i Prisinformation för dataöverföringar.

Se även