Udostępnij za pomocą

Ponowne wypełnianie obiektów blob z warstwy Archiwum

Chociaż obiekt blob znajduje się w warstwie dostępu archiwum, jest uważany za offline i nie można go odczytać ani zmodyfikować. Aby odczytywać lub modyfikować dane w zarchiwizowanym blobie, należy najpierw przywrócić go do warstwy online, do gorącej lub chłodnej warstwy. Istnieją dwie dostępne opcje rehydratacji obiektu blob przechowywanego w warstwie archiwum:

Ważne

Migawki i poprzednie wersje nie mogą być ponownie przywrócone do warstwy gorącej lub chłodnej po przeniesieniu do warstwy archiwum. Aby uzyskać dostęp do danych z zarchiwizowanej migawki lub poprzedniej wersji, należy skopiować je do nowego bloba w warstwie online (Gorącej lub Chłodnej) przy użyciu operacji kopiowania bloba. Bezpośrednie przywracanie migawek lub poprzednich wersji nie jest obsługiwane.

Ponowne nawodnienie bloba z warstwy archiwum może potrwać kilka godzin. Firma Microsoft zaleca archiwizowanie większych obiektów blob w celu uzyskania optymalnej wydajności podczas ponownego wypełniania. 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że zostać odtworzone w ciągu godziny przy użyciu pobierania priorytetowego.

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

Priorytet nawodnienia

Podczas rehydratacji obiektu blob można ustawić priorytet dla tej operacji za pomocą opcjonalnego nagłówka x-ms-rehydrate-priority w operacji Ustawiania warstwy obiektu blob lub Kopiowania obiektu 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. Nawodnienie o wysokim priorytecie jest szybsze, ale również kosztuje więcej niż nawodnienie o standardowym priorytecie. Ponowne uwodnienie o wysokim priorytecie może trwać dłużej niż jedną godzinę, w zależności od rozmiaru bloba i aktualnego zapotrzebowania. Firma Microsoft zaleca rezerwowanie ponownego wypełniania o wysokim priorytcie do użytku w sytuacjach awaryjnych przywracania 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ż przedziały czasowe, takie jak "do 15 godzin" dla standardowego priorytetu, mogą odnosić się do pojedynczych obiektów blob w idealnych warunkach, nie skalują się liniowo w przypadku operacji zbiorczych. Klienci odtwarzający duże ilości danych powinni spodziewać się dłuższego czasu trwania procesu i odpowiednio to uwzględnić w planach. Przepływność jest współdzielona we wszystkich obiektach blob, które są ponownie wypełnianie na tym samym koncie, a przekroczenie limitu godzinowego może spowodować ograniczenie przepustowości lub rozszerzone opóźnienia. Aby uzyskać optymalną wydajność, rozważ grupowanie żądań rehydratacji i monitorowanie aktywności na poziomie konta.

Nie można obniżyć ustawienia priorytetu ponownego nawadniania z High do Standard dla operacji oczekującej. Należy pamiętać, że aktualizowanie ustawienia priorytetu ponownego uwodnienia może mieć wpływ na koszty rozliczeń.

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

Pierwszą opcją przeniesienia obiektu blob z warstwy archiwalnej do warstwy natychmiast dostępnej jest skopiowanie zarchiwizowanego obiektu blob do nowego docelowego obiektu blob, który znajduje się w warstwie Gorącej, Chłodnej lub Zimnej. Aby skopiować obiekt blob, możesz użyć operacji kopiowania obiektu blob . Podczas kopiowania zarchiwizowanego obiektu blob do nowego obiektu blob w warstwie online źródłowy obiekt blob pozostaje niezmodyfikowany 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.

Ta opcja może również mieć sens, jeśli istnieje polityka zarządzania cyklem życia dla konta magazynowego, a daysAfterLastTierChangeGreaterThan warunek nie jest dodawany do każdej tierToArchive akcji działania. W takim przypadku ponowne wypełnianie obiektu blob z operacją Ustaw warstwę obiektu blob może spowodować, że zasady cyklu życia przenoszą obiekt blob z powrotem do warstwy archiwum po ponownym wypełnianiu, ponieważ czas ostatniej modyfikacji przekracza próg ustawiony dla zasad. Operacja kopiowania pozostawia źródłowy obiekt blob w warstwie archiwum i tworzy nowy obiekt blob o innej nazwie oraz z nowym czasem ostatniej modyfikacji, więc nie ma ryzyka, że zreaktywowany obiekt blob zostanie przeniesiony z powrotem do warstwy archiwum przez zasady cyklu życia.

Kopiowanie obiektu blob z warstwy archiwum może potrwać kilka godzin w zależności od wybranego priorytetu ponownego udostępnienia. W tle operacja kopiowania obiektów blob odczytuje zarchiwizowany źródłowy obiekt blob, aby utworzyć nowy obiekt blob online w wybranej warstwie docelowej. Nowy obiekt blob może być widoczny po wyświetleniu listy obiektów blob w kontenerze nadrzędnym przed zakończeniem operacji ponownego wypełniania, ale jej warstwa zostanie ustawiona na archiwum. Dane nie są dostępne, dopóki nie zostanie ukończona operacja odczytu z źródłowego blobu w warstwie archiwum i zawartość tego blobu nie zostanie zapisana do nowego miejsca docelowego w warstwie online. Nowy obiekt blob jest niezależną kopią, więc modyfikowanie go lub usuwanie nie ma wpływu na źródłowy obiekt blob w warstwie archiwum.

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łowego obiektu blob do momentu pomyślnego zakończenia rehydratacji. Jeśli źródłowy obiekt blob zostanie usunięty, docelowy obiekt blob może nie zakończyć kopiowania. Można obsługiwać zdarzenie wywołane po zakończeniu operacji kopiowania, aby wiedzieć, kiedy można bezpiecznie usunąć źródłowy obiekt blob. Aby uzyskać więcej informacji, zobacz Obsługa zdarzenia podczas ponownego napełniania obiektów blob.

Przed wersją usługi 2021-02-12 przywracanie zarchiwizowanego bloba przez skopiowanie go do warstwy docelowej online było obsługiwane tylko w ramach tego samego konta magazynowego. Począwszy od wersji 2021-02-12 lub nowszej, można również przywrócić ponownie, kopiując obiekt blob na inne konto magazynu w tym samym regionie. Począwszy od wersji usługi 2021-02-12, można przywrócić zarchiwizowany obiekt blob, kopiując go do innego konta magazynu, o ile konto docelowe znajduje się w tym samym regionie co konto źródłowe. Ponowne udostępnianie między kontami magazynowymi umożliwia rozgraniczenie danych produkcyjnych od danych kopii zapasowej, przechowując je na oddzielnych kontach. Izolowanie zarchiwizowanych danych na osobnym koncie może również pomóc zmniejszyć koszty z niezamierzonego ponownego wypełniania.

Docelowy obiekt blob operacji kopiowania musi znajdować się w warstwie online (gorąca lub chłodna). 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 poziomu archiwizacji
Lokalizacja docelowa warstwy Gorąca 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 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 Nieobsługiwane

Ponowne wypełnianie z regionu pomocniczego

Jeśli skonfigurowałeś swoje konto magazynu do używania geograficznie nadmiarowego magazynu z dostępem tylko do odczytu (RA-GRS), możesz użyć operacji Kopiuj Blob w celu rehydratacji obiektów blob w regionie wtórnym do innego konta magazynu znajdującego się w tym samym regionie wtórnym. 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ę. Dzięki tej operacji można zmienić warstwę zarchiwizowanego obiektu blob na gorącą lub chłodną.

Żądanie Ustaw Warstwę Obiektu Blob nie może być anulowane, gdy już zostanie zainicjowane. Podczas operacji ponownego wypełniania ustawienie warstwy dostępu obiektu blob będzie nadal wyświetlane jako zarchiwizowane do momentu zakończenia procesu ponownego wypełniania. Po zakończeniu operacji ponownej aktywacji właściwość warstwy dostępu obiektu danych blob zostanie zaktualizowana, aby odzwierciedlić nową warstwę.

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 istnieją zasady zarządzania cyklem życia dla konta magazynu, ponowne wypełnianie obiektu blob z ustawioną warstwą obiektu blob może spowodować, że zasady cyklu życia przenoszą obiekt blob z powrotem do warstwy archiwum po ponownym wypełnianiu, ponieważ czas ostatniej modyfikacji przekracza próg ustawiony dla zasad.

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 powoduje utworzenie nowego wystąpienia obiektu blob z zaktualizowanym czasem ostatniej modyfikacji, dlatego nie zostanie uruchomiona zasada 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 podczas przywracania obiektu blob do pełnej funkcjonalności

Ponowne odzyskiwanie zarchiwizowanego obiektu blob może potrwać do 15 godzin i nieefektywne jest wielokrotne sondowanie Get Blob Properties w celu określenia, czy odzyskiwanie zostało ukończone. Firma Microsoft zaleca używanie usługi Azure Event Grid do przechwytywania zdarzenia, które jest uruchamiane po zakończeniu ponownego wypełniania w celu uzyskania lepszej wydajności i optymalizacji kosztów.

Usługa Azure Event Grid zgłasza zdarzenie Microsoft.Storage.BlobTierChanged po zakończeniu rehydratacji obiektu blob.

  • Zdarzenie Microsoft.Storage.BlobTierChanged występuje, gdy zmienia się warstwa obiektu blob. W kontekście ponownego wypełniania obiektów blob to zdarzenie jest uruchamiane, gdy warstwa dostępu docelowego obiektu blob została pomyślnie zmieniona z warstwy archiwum na warstwę online (gorąca, chłodna lub zimna). Do zmiany warstwy dostępu archiwalnego obiektu blob można użyć operacji Set Blob Tier.

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. Zdarzenie Microsoft.Storage.BlobCreated jest wyzwalane natychmiast po rozpoczęciu operacji kopiowania, gdy warstwa obiektu blob jest ustawiona na Archiwum.

  2. Po pomyślnym skopiowaniu i rehydratacji obiektu blob do docelowej warstwy Microsoft.Storage.BlobTierChanged online zostanie wyzwolone zdarzenie wskazujące zmianę warstwy z Archiwum na docelową warstwę 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).

Aby uzyskać więcej informacji na temat obsługi zdarzeń w usłudze Blob Storage, zobacz Reagowanie na zdarzenia usługi Azure Blob Storage i Usługa Azure Blob Storage jako źródło usługi Event Grid.

Ceny i rozliczenia

Operacja rehydratacji z użyciem Set Blob Tier jest rozliczana na podstawie transakcji odczytu danych oraz rozmiaru pobranych danych. Ponowne nawodnienie o wysokim priorytecie ma wyższe koszty operacji i pobierania danych w porównaniu ze standardowym priorytetem. Rehydratacja o wysokim priorytecie jest wyświetlana jako oddzielna pozycja na rachunku. Jeśli żądanie o wysokim priorytcie w celu zwrócenia zarchiwizowanego obiektu blob o rozmiarze mniejszym niż 10 GB trwa dłużej niż pięć godzin, nie zostanie naliczona opłata za pobieranie o wysokim priorytcie. Jednak standardowe stawki pobierania nadal obowiązują. Aby uzyskać przykładowe oszacowanie kosztów, zobacz Szacowanie kosztów: Przenoszenie danych z magazynu archiwum.

Kopiowanie zarchiwizowanego obiektu blob do warstwy online z Copy Blob jest rozliczane na podstawie transakcji odczytu danych i wielkości pobieranych danych. Tworzenie docelowego obiektu blob w warstwie online wiąże się z naliczaniem opłat za transakcje zapisu danych. Opłaty za wczesne usunięcie nie mają zastosowania podczas kopiowania do obiektu blob online, ponieważ źródłowy obiekt blob pozostaje niezmodyfikowany w warstwie archiwum. Opłaty za pobieranie o wysokim priorytcie mają zastosowanie w przypadku wybrania opcji . 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. Jeśli na przykład obiekt blob zostanie przeniesiony do warstwy archiwum, a następnie usunięty lub przeniesiony do warstwy gorącej po 45 dniach, opłata za wcześniejsze usunięcie zostanie naliczona, równoważna 135 (180 minus 45) dniom przechowywania tego obiektu blob w warstwie archiwum. Aby uzyskać więcej informacji, zobacz Warstwa dostępu Archiwum.

Aby uzyskać więcej informacji na temat cen bloków blobów i przywracania danych, zapoznaj się z Cennikiem usługi Azure Storage. Aby uzyskać więcej informacji na temat opłat za transfer danych wychodzących, zobacz Szczegóły cennika transferów danych.

Zobacz też

  • Last updated on