Ponowne wypełnianie obiektów blob z warstwy Archiwum

Zarchiwizowany blob jest offline i nie można go odczytać ani modyfikować. Aby uzyskać dostęp do danych, najpierw nawilż blob do poziomu online: gorącego, chłodnego lub zimnego. Stosuj jedną z następujących metod nawodniania:

Ważne

Nie można bezpośrednio nawodniać archiwalnych snapshotów ani wcześniejszych wersji. Aby uzyskać dostęp do danych z archiwalnego snapshotu lub poprzedniej wersji, musisz skopiować je do nowego blobu w poziomie online (gorący, chłodny lub zimny) za pomocą operacji Kopiuj Blob .

Ponowne nawodnienie bloba z warstwy archiwum może potrwać kilka godzin. Archiwizuj większe grudki dla optymalne właściwości nawodnienia. Ponowne uwadnianie dużej liczby małych blobów może wymagać dodatkowego czasu ze względu na obciążenie związane z przetwarzaniem każdego bloba. Maksymalnie 10 GiB na konto magazynowe można nawodnić na godzinę przy priorytetowym pobieraniu.

Aby dowiedzieć się, jak przywrócić zarchiwizowany obiekt blob do wersji online, zobacz Przywracanie zarchiwizowanego obiektu blob do wersji online.

Priorytet nawodnienia

Podczas ponownego nawadniania bloba możesz ustawić priorytet operacji, używając opcjonalnego x-ms-rehydrate-priority nagłówka w operacji Set Blob Tier lub Copy Blob . Opcje priorytetowe nawodnienia obejmują:

  • Standardowy priorytet: Żądanie ponownej aktywizacji jest przetwarzane w kolejności odebrania i może potrwać do 15 godzin w przypadku obiektów o rozmiarze mniejszym niż 10 GB.
  • Wysoki priorytet: Żądanie ponownego nawodnienia ma wyższy priorytet w stosunku do standardowych żądań priorytetu i może zostać ukończone w czasie krótszym niż jedna godzina dla obiektów o rozmiarze poniżej 10 GB.

Aby sprawdzić priorytet ponownego wypełniania podczas wykonywania operacji ponownego wypełniania, wywołaj metodę Pobierz właściwości obiektu blob, aby zwrócić wartość nagłówka x-ms-rehydrate-priority . Właściwość priorytetu nawodnienia zwraca wartość Standard lub Wysoki.

Domyślną opcją jest standardowe ponowne nawodnienie. Rehydratacja o wysokim priorytecie jest szybsza, ale kosztuje więcej niż standardowa rehydratacja. Rehydratacja o wysokim priorytecie może trwać dłużej niż godzinę, w zależności od wielkości grudki i aktualnego zapotrzebowania. Zarezerwuj rehydratację o wysokim priorytecie na awaryjne przywracanie danych.

Mimo że operacja rekonwersji o standardowym priorytecie jest w toku, możesz zaktualizować ustawienie priorytetu dla obiektu na Wysoki, aby przyspieszyć jego rekonwersję. Na przykład, jeśli dokonujesz rehydratacji dużej liczby obiektów blob, możesz określić priorytet standardowy dla wszystkich obiektów podczas operacji początkowej, a następnie zwiększyć priorytet na Wysoki dla pojedynczych obiektów blob, które muszą być szybciej udostępnione, do maksymalnego limitu 10 GiB na godzinę.

Ważne

Limit 10 GiB na godzinę ma zastosowanie na poziomie konta magazynu, a nie na obiekt blob. Chociaż czasy takie jak „do 15 godzin” w przypadku standardowego priorytetu mogą mieć zastosowanie do pojedynczych blobów w idealnych warunkach, nie przekładają się liniowo na operacje masowe. Jeśli nawodniasz duże ilości danych, spodziewaj się dłuższych okresów i planuj odpowiednio. Przepustowość jest współdzielona między wszystkie bloby poddawane rehydratacji na tym samym koncie, a przekroczenie limitu godzinowego może skutkować ograniczeniem przepustowości lub dłuższymi opóźnieniami. Aby uzyskać optymalną wydajność, rozważ grupowanie żądań rehydratacji i monitorowanie aktywności na poziomie konta.

Nie możesz obniżyć priorytetu nawodnienia z wysokiego do standardowego dla oczekującej operacji. Aktualizacja priorytetu może wpłynąć na rozliczenia.

Aby dowiedzieć się, jak ustawić i zaktualizować ustawienie priorytetu ponownego wypełniania, zobacz Rehydrate an archived blob to an online tier (Ponowne wypełnianie zarchiwizowanego obiektu blob do warstwy online).

Aby uzyskać więcej informacji na temat różnic cenowych między standardowymi a wysokimi priorytetowymi żądaniami odtwarzania, zobacz Cennik usługi Azure Blob Storage.

Skopiuj archiwalny blob do warstwy online

Aby ponownie nawodnić zarchiwizowany blob przez kopiowanie, użyj operacji Copy Blob , aby utworzyć nowy docelowy blob na poziomie gorący, chłodny lub zimny. Źródłowy blob pozostaje niezmieniony w warstwie archiwalnej.

Należy skopiować zarchiwizowany blob do nowego bloba pod inną nazwą lub do innego kontenera. Nie można zastąpić źródłowego obiektu blob przez skopiowanie do tego samego obiektu blob.

Kopiując obiekt blob z warstwy archiwum do warstwy online, można uniknąć wcześniejszej opłaty za usunięcie, która jest naliczana, jeśli warstwa obiektu blob zmienia się z warstwy archiwum przed upływem wymaganego 180-dniowego okresu. Aby uzyskać więcej informacji, zobacz Warstwa dostępu Archiwum.

Unikaj archiwizacji polityki cyklu życia

Kopiowanie może również zapobiec przeniesieniu nawilżonej bryły z powrotem do poziomu archiwum przez politykę zarządzania cyklem życia. To ryzyko występuje, gdy działanie zasady tierToArchive nie zawiera warunku daysAfterLastTierChangeGreaterThan, a czas ostatniej modyfikacji obiektu blob przekracza próg określony w zasadzie. Operacja kopiowania pozostawia źródłowy blob w warstwie archiwum i tworzy nowy blob o innej nazwie i nowym czasie ostatniej modyfikacji.

Monitoruj uzupełnianie kopii

Skopiowanie bloba z poziomu archiwum może zająć godziny, w zależności od wybranego priorytetu nawodnienia. Operacja kopiowania odczytuje zarchiwizowany blob źródłowy i tworzy nowy blob w wybranym poziomie online. Nowa plama może pojawić się w kontenerze nadrzędnym przed zakończeniem nawodnienia, ale jej poziom pozostaje archiwalny. Dane stają się dostępne po odczytaniu przez usługę źródłowego blobu i zapisaniu jego zawartości do docelowego blobu. Nowy blob jest niezależną kopią, więc jego modyfikacja lub usunięcie nie wpływa na archiwizowany blob źródłowy.

Aby dowiedzieć się, jak przywrócić obiekt blob przez skopiowanie go do warstwy online, zobacz Rehydratacja obiektu blob za pomocą operacji kopiowania.

Ważne

Nie usuwaj źródłowej bryły, dopóki rehydracja nie zakończy się pomyślnie. Jeśli usuniesz źródłowy blob, docelowy blob może nie skończyć kopiowania. Monitoruj zdarzenie zakończenia, aby określić, kiedy możesz bezpiecznie usunąć źródłowy blob. Więcej informacji można znaleźć w artykule Obsługa zdarzenia rehydratacji plam.

Kopiowanie między kontami pamięci masowej

Wersja usługi 2021-02-12 i późniejsza obsługuje rehydratację poprzez kopiowanie zarchiwizowanego bloba na inne konto pamięci w tym samym regionie. Wcześniejsze wersje usług obsługują rehydratację tylko w obrębie tego samego konta pamięci. Rehydratacja między kontami pamięci masowej pozwala oddzielić dane produkcyjne od danych zapasowych, utrzymując je w osobnych kontach. Izolowanie zarchiwizowanych danych na osobnym koncie może również pomóc ograniczyć koszty wynikające z niezamierzonego nawodnienia.

Docelowy blob dla operacji kopiowania musi należeć do poziomu online (gorący, chłodny lub zimny). Nie można skopiować zarchiwizowanego obiektu blob do docelowego obiektu blob, który znajduje się również w warstwie archiwum.

W poniższej tabeli przedstawiono zachowanie operacji kopiowania obiektów blob w zależności od warstw źródłowego i docelowego obiektu blob.

Źródło gorącej warstwy Źródło warstwy Chłodna Źródło warstwy zimnej Źródło poziomu archiwizacji
Lokalizacja docelowa warstwy Gorąca Wspierane Wspierane Wspierane Obsługiwane dla kont w tym samym regionie w wersji 2021-02-12 lub nowszej. Obsługiwane na tym samym koncie magazynu tylko w przypadku wcześniejszych wersji. Wymaga ponownego wypełniania obiektów blob.
Atrakcyjna destynacja Wspierane Wspierane Wspierane Obsługiwane dla kont w tym samym regionie w wersji 2021-02-12 lub nowszej. Obsługiwane na tym samym koncie magazynu tylko w przypadku wcześniejszych wersji. Wymaga ponownego wypełniania obiektów blob.
Docelowa lokalizacja warstwy chłodnej Wspierane Wspierane Wspierane Obsługiwane dla kont w tym samym regionie w wersji 2021-02-12 lub nowszej. Obsługiwane na tym samym koncie magazynu tylko w przypadku wcześniejszych wersji. Wymaga ponownego wypełniania obiektów blob.
Lokalizacja docelowa warstwy Archiwum Wspierane Wspierane Wspierane Nieobsługiwane

Ponowne wypełnianie z regionu pomocniczego

Jeśli twoje konto pamięci używa read-access geo-redundant storage (RA-GRS), użyj operacji Copy Blob , aby przeprowadzić bloby z regionu drugorzędnego na inne konto w tym regionie. Zobacz Ponowne wypełnianie z regionu pomocniczego.

Aby dowiedzieć się więcej na temat uzyskiwania dostępu do odczytu do regionów pomocniczych, zobacz Odczyt danych w regionach pomocniczych.

Zmiana warstwy dostępu obiektu blob na warstwę internetową

Drugą opcją przywracania obiektu blob z warstwy archiwalnej do warstwy aktywnej jest zmiana warstwy obiektu blob przez wywołanie funkcji Ustaw warstwę. Za pomocą tej operacji możesz zmienić warstwę bloba zarchiwizowanego na gorącą, chłodną lub zimną.

Nie możesz anulować żądania Set Blob Tier po jego rozpoczęciu. Podczas nawodnienia poziom dostępu bloba pozostaje archiwalny. Po zakończeniu rehydratacji właściwość poziomu dostępu pokazuje nowy poziom.

Aby dowiedzieć się, jak zrehydratować obiekt blob, zmieniając jego poziom na poziom online, zobacz Zrehydratowanie obiektu blob przez zmianę poziomu.

Uwaga

Zmiana warstwy obiektu blob nie wpływa na czas ostatniej modyfikacji. Jeśli konto magazynowe ma politykę zarządzania cyklem życia , polityka może przenieść blob z powrotem do poziomu archiwum po ponownym nawodnieniu, gdy ostatnia modyfikacja przekroczy próg polityki.

Aby uniknąć tego scenariusza, dodaj daysAfterLastTierChangeGreaterThan warunek do tierToArchive działania polityki. Alternatywnie można przywrócić zarchiwizowany blob, kopiując go, jak opisano w sekcji Kopiowanie zarchiwizowanego blobu do warstwy Online. Wykonanie operacji kopiowania tworzy nowe wystąpienie obiektu blob ze zaktualizowanym czasem ostatniej modyfikacji, więc nie powoduje wyzwolenia zasad zarządzania cyklem życia.

Sprawdzanie stanu operacji ponownego wypełniania obiektu blob

Podczas operacji ponownego wypełniania obiektu blob można wywołać operację Pobierz właściwości obiektu blob, aby sprawdzić jego stan. Aby dowiedzieć się, jak sprawdzić stan operacji ponownego wypełniania, zobacz Sprawdzanie stanu operacji ponownego wypełniania.

Obsługa zdarzenia rehydratacji obiektu blob

Rehydratowanie zarchiwizowanej blobki może zająć nawet do 15 godzin, a powtarzające się sprawdzanie Get Blob Properties jest nieefektywne. Użyj Azure Event Grid, aby rejestrować zdarzenie ukończenia, zwiększając wydajność i obniżając koszty.

Azure Event Grid podnosi zdarzenieMicrosoft.Storage.BlobTierChanged, gdy zakończy się rehydracja blobów:

  • Wydarzenie Microsoft.Storage.BlobTierChanged uruchamia się, gdy poziom bloba zmienia się. W przypadku rehydratacji obiektu blob zdarzenie jest wyzwalane, gdy docelowy obiekt blob zostanie pomyślnie przeniesiony z warstwy archiwum do warstwy online (gorącej, chłodnej lub zimnej).

W przypadku użycia operacji kopiowania obiektu blob do kopiowania obiektu blob z warstwy Archiwum do nowego docelowego obiektu blob w warstwie online (gorąca, chłodna lub zimna) na potrzeby ponownego wypełniania:

  1. Azure Event Grid wywołuje zdarzenie Microsoft.Storage.BlobCreated podczas rozpoczęcia operacji kopiowania. Poziom bloba to Archiwum.

  2. Po skopiowaniu i ponownym nawodnieniu bloba, Azure Event Grid uruchamia Microsoft.Storage.BlobTierChanged zdarzenie sygnalizujące zmianę z Archiwum na określony poziom online.

Aby dowiedzieć się, jak przechwycić zdarzenie podczas ponownego wypełniania i wysłać je do programu obsługi zdarzeń funkcji platformy Azure, zobacz Run an Azure Function in response to a blob rehydration event (Uruchamianie funkcji platformy Azure w odpowiedzi na zdarzenie ponownego wypełniania obiektu blob).

Więcej informacji o obsłudze zdarzeń w usłudze Blob Storage można znaleźć w artykułach Reacting to Azure Blob storage events i Azure Blob Storage as Event Grid source.

Ceny i rozliczenia

W przypadku Set Blob Tier Azure Storage pobiera opłaty za transakcje odczytu danych oraz ilość pobranych danych. Rehydratacja o wysokim priorytecie kosztuje więcej niż rehydratacja o standardowym priorytecie i jest wyświetlana jako osobna pozycja na fakturze. Jeśli realizacja żądania pobrania z wysokim priorytetem dotyczącego zarchiwizowanego obiektu blob o rozmiarze mniejszym niż 10 GB trwa dłużej niż pięć godzin, usługa Azure Storage nie nalicza opłaty za pobieranie z wysokim priorytetem. Standardowe stawki za pobranie nadal obowiązują. Aby uzyskać przykładowe oszacowanie kosztów, zobacz Szacowanie kosztów: Przenoszenie danych z magazynu archiwum.

W przypadku Copy Blob Azure Storage pobiera opłaty za transakcje odczytu danych, ilość pobranych danych oraz transakcje zapisu danych dla docelowego blobu. Opłaty za wcześniejsze usunięcie nie są naliczane, ponieważ blob źródłowy pozostaje niezmieniony w warstwie archiwum. W przypadku wybrania opcji priorytetowego pobierania naliczane są dodatkowe opłaty. Aby uzyskać przykładowe oszacowanie, zobacz Szacowanie kosztów: pobieranie danych z magazynu archiwum na potrzeby analizy.

Obiekty blob w warstwie archiwum powinny być przechowywane przez co najmniej 180 dni. Usunięcie lub zmiana warstwy zarchiwizowanego pliku blob przed upływem 180-dniowego okresu powoduje naliczenie opłaty za wcześniejsze usunięcie. Na przykład, jeśli blob zostanie przeniesiony do poziomu archiwalnego, a następnie usunięty lub przeniesiony do gorącego poziomu po 45 dniach, ponosisz opłatę za wcześniejsze usunięcie równą 135 (180 minus 45) dni przechowywania tej tablicy w tierze archiwum. Aby uzyskać więcej informacji, zobacz Warstwa dostępu Archiwum.

Więcej informacji o cenach za bloby bloków i rehydratacji danych można znaleźć w artykule Azure Storage pricecing. Więcej informacji o opłatach za transfer danych wychodzących można znaleźć w szczegółach cen transferu danych.

Zobacz też

  • Last updated on