Wersjonowanie blobów

Możesz włączyć wersjonowanie blobów, aby automatycznie utrzymywać wcześniejsze wersje obiektu. Gdy włączysz wersjonowanie blobów, możesz uzyskać dostęp do wcześniejszych wersji bloba, aby odzyskać dane, jeśli zostaną zmodyfikowane lub usunięte.

Uwaga

Po włączeniu wersjonowania obiektów blob dla konta magazynowego, każda operacja zapisu w obiekcie blob tego konta powoduje utworzenie nowej wersji. Z tego powodu włączenie wersji blob może skutkować dodatkowymi kosztami. Aby zminimalizować koszty, użyj polityki Lifecycle Management lub zadania Storage Actions , aby automatycznie usuwać poprzednie wersje.

Wersjonowanie BLOB to jedna z kilku funkcji ochrony danych. Wybór odpowiedniej funkcji lub ich kombinacji zależy od Twojego obciążenia pracą i tego, przed czym się chronisz. Aby dowiedzieć się więcej o zaleceniach Microsoft dotyczących ochrony danych, zobacz Przegląd Ochrony Danych.

Wersje a migawki

Wersja blob jest podobna do snapshota, ale różnią się sposobem tworzenia i tym, do czego są najlepiej przystosowane. Wersja jest automatyczna i zarządzana systemowo: Azure Storage tworzy nową wersję przy każdym zapisie lub usuwaniu po włączeniu wersjonowania blobów, bez potrzeby stosowania logiki aplikacji. Snapshot jest ręczny i sterowany aplikacją: jawnie tworzysz kopię stanu z określonego momentu w czasie, gdy aplikacja uzna ją za potrzebną.

Używaj wersjonowania, gdy chcesz mieć automatyczną, ciągłą ochronę przed przypadkowymi lub złośliwymi nadpisaniami i usuwaniami. Używaj migawek, gdy chcesz mieć zamierzone kopie utworzone w danym momencie, na przykład znany dobry punkt kontrolny przed planowaną aktualizacją. Microsoft zaleca, aby przestać tworzyć migawki blokowych obiektów blob po włączeniu wersjonowania.

Jak działa wersjonowanie obiektów blob

Wersja przechwytuje stan obiektu blob w danym punkcie w czasie. Każda wersja ma identyfikator wersji. Gdy włączasz wersjonowanie blob dla konta storage, Azure Storage automatycznie tworzy nową wersję z unikalnym ID przy pierwszym tworzeniu blobu i za każdym razem, gdy go modyfikujesz.

Identyfikator wersji może zidentyfikować bieżącą wersję lub poprzednią wersję. Blob może mieć tylko jedną aktualną wersję naraz; jest to jego aktualny stan. Blob może mieć kilka wcześniejszych wersji.

Podczas tworzenia nowego bloba istnieje pojedyncza wersja, a ta wersja jest bieżącą wersją. Podczas modyfikowania istniejącego obiektu blob bieżąca wersja stanie się poprzednią wersją. Utworzono nową wersję w celu przechwycenia zaktualizowanego stanu, a nowa wersja jest bieżącą wersją. Po usunięciu obiektu blob bieżąca wersja obiektu blob stanie się poprzednią wersją i nie ma już bieżącej wersji. Wszelkie poprzednie wersje obiektu blob są utrwalane.

Poniższy diagram pokazuje, jak wersje są tworzone podczas operacji zapisu oraz jak wcześniejsza wersja może być promowana do obecnej:

Diagram pokazujący, jak działa wersjonowanie blobów. Poprzednie wersje blobów są niezmienne, co oznacza, że nie można modyfikować treści ani metadanych.

Ważne

  • Posiadanie dużej liczby wersji na obiekt blob może zwiększyć opóźnienie operacji wyświetlania listy obiektów blob. Microsoft zaleca utrzymywanie mniej niż 1000 wersji na blob. Możesz użyć zasad Lifecycle Management lub zadania Storage Actions, aby automatycznie usuwać stare wersje.

  • Wersjonowanie BLOB nie pomoże ci odzyskać wyniku przypadkowego usunięcia konta pamięci lub kontenera. Aby zapobiec przypadkowemu usunięciu konta magazynu, skonfiguruj blokadę zasobu konta magazynu. Aby uzyskać więcej informacji na temat blokowania konta magazynu, zobacz Aplikowanie blokady Azure Resource Manager do konta magazynu.

Identyfikator wersji

Każda wersja blob ma unikalny identyfikator wersji. Wartość ID wersji to znacznik czasu aktualizacji bloba. Przypisujesz identyfikator wersji podczas tworzenia wersji.

Możesz odczytać lub usunąć konkretną wersję bloba, używając jej ID wersji. Jeśli nie podasz ID wersji, operacja celuje w aktualną wersję.

Gdy wykonujesz operację zapisu w celu utworzenia lub modyfikacji bloba, Azure Storage zwraca nagłówek x-ms-version-id w odpowiedzi. Ten nagłówek zawiera identyfikator wersji aktualnej wersji bloba, którą utworzyła operacja zapisu.

Identyfikator wersji pozostaje taki sam przez cały okres życia wersji.

Wersjonowanie podczas operacji zapisu

Gdy włączasz wersjonowanie blobów, każda operacja zapisu do bloba tworzy nową wersję. Operacje zapisu obejmują umieszczanie obiektów blob, umieszczanie listy bloków, kopiowanie obiektu blob i ustawianie metadanych obiektu blob.

Jeśli operacja zapisu tworzy nowy obiekt blob, powstały obiekt blob jest bieżącą wersją tego obiektu blob. Jeśli operacja zapisu modyfikuje istniejący blob, obecna wersja staje się poprzednią, a nowa, aktualna wersja przechwytuje zaktualizowany blob.

Na poniższym diagramie pokazano, jak operacje zapisu wpływają na wersje obiektów blob. Dla uproszczenia, diagramy w tym artykule pokazują ID wersji jako prostą wartość całkowitą. W rzeczywistości identyfikator wersji jest znacznikiem czasu. Bieżąca wersja jest wyświetlana na niebiesko, a poprzednie wersje są wyświetlane w kolorze szarym.

Diagram przedstawiający wpływ operacji zapisu na wersjonowane obiekty blob.

Uwaga

Blob, który utworzyłeś przed włączeniem wersjonowania dla konta pamięci, nie ma identyfikatora wersji. Gdy modyfikujesz ten blob, zmodyfikowany blob staje się nową, aktualną wersją, a stan bloba przed aktualizacją staje się poprzednią wersją. Obecna wersja otrzymuje identyfikator wersji, który odpowiada jej czasowi utworzenia.

Gdy włączasz wersjonowanie blob dla konta pamięci, wszystkie operacje zapisu na blokach blokowych wywołują utworzenie nowej wersji, z wyjątkiem operacji Put Block .

W przypadku stronicowych obiektów blob i uzupełnialnych obiektów blob, tylko niektóre operacje zapisu wyzwalają tworzenie wersji. Te operacje obejmują:

Następujące operacje nie uruchamiają utworzenia nowej wersji:

Aby uchwycić zmiany z tych operacji, zrób ręczną migawkę. Więcej informacji można znaleźć w artykule migawki obiektów blob.

Wszystkie wersje blobu muszą mieć ten sam typ blob. Jeśli obiekt blob ma poprzednie wersje, nie można zastąpić obiektu blob jednego typu innym typem, chyba że najpierw usuniesz obiekt blob i wszystkie jego wersje.

Wersjonowanie operacji usuwania

Gdy wykonasz operację Usuń Blob bez podania ID wersji, obecna wersja staje się poprzednią wersją i nie ma już aktualnej wersji. Operacja ta zachowuje wszystkie istniejące wcześniejsze wersje blobu.

Na poniższym diagramie przedstawiono wpływ operacji usuwania na wersję obiektu blob:

Diagram przedstawiający usuwanie wersjonowanego obiektu blob.

Aby usunąć określoną wersję obiektu blob, podaj identyfikator tej wersji w ramach operacji usuwania. Jeśli włączysz też miękkie usuwanie blob dla konta pamięci, system zachowuje wersję do czasu upływu okresu przechowywania miękkiego usuwania.

Zapisywanie nowych danych w obiekcie blob powoduje utworzenie nowej bieżącej wersji obiektu blob. To działanie nie wpływa na żadną istniejącą wersję, co pokazano na poniższym diagramie.

Diagram przedstawiający utworzenie na nowo wersjonowanego obiektu blob po jego usunięciu.

Poziomy dostępu

Możesz przenieść dowolną wersję blokowego obiektu blob, w tym bieżącą wersję, do innej warstwy dostępu do obiektu blob, wywołując operację Ustaw warstwę obiektu blob. Przenosząc starsze wersje bloba do poziomu cool lub archiwalnego, możesz skorzystać z niższych cen przepustowości. Aby uzyskać więcej informacji, zobacz Warstwy dostępu Gorąca, Chłodna, Zimna i Archiwum dla danych typów blob.

Aby zautomatyzować proces przenoszenia blokowych obiektów blob na odpowiedni poziom, stwórz zasady zarządzania cyklem życia, utwórz zadanie Storage Actions lub włącz Smart Tier.

Włączanie lub wyłączanie przechowywania wersji obiektów blob

Instrukcje dotyczące włączania lub wyłączania wersjonowania blob znajdziesz w artykule Włącz i zarządzaj wersjonowaniem blobów.

Wyłączenie przechowywania wersji obiektów blob nie powoduje usunięcia istniejących obiektów blob, wersji ani migawek. Gdy wyłączysz wersjonowanie blobów, nie możesz tworzyć nowych wersji.

Po wyłączeniu wersjonowania, modyfikacja aktualnej wersji tworzy blob, który nie jest wersją. Wszystkie kolejne aktualizacje obiektu blob zastępują jego dane bez zapisywania poprzedniego stanu. Wszystkie istniejące wersje są utrwalane jako poprzednie wersje.

Możesz czytać lub usuwać wersje, używając ID wersji po wyłączeniu wersjonowania. Można również wyświetlić listę wersji obiektu blob po wyłączeniu przechowywania wersji.

Replikacja obiektów zależy od wersjonowania obiektów blob. Przed wyłączeniem wersjonowania obiektów blob należy usunąć wszystkie zasady replikacji obiektów na koncie. Aby uzyskać więcej informacji na temat replikacji obiektów, zobacz Replikacja obiektów blob blokowych.

Na poniższym diagramie pokazano, jak modyfikowanie obiektu blob po wyłączeniu wersjonowania generuje obiekt blob, który nie jest wersjonowany. Wszystkie istniejące wersje skojarzone z obiektem blob są zachowane.

Diagram przedstawiający, że modyfikacja bieżącej wersji po wyłączeniu wersjonowania powoduje utworzenie obiektu blob, który nie jest wersją.

Obsługa funkcji

Może to mieć wpływ na obsługę tej funkcji przez włączenie protokołu Data Lake Storage Gen2, sieciowego systemu plików (NFS) 3.0 lub protokołu SSH File Transfer Protocol (SFTP). Jeśli włączono dowolną z tych funkcji, zobacz Obsługę funkcji Blob Storage w kontach Azure Storage w celu oceny obsługi tej funkcji.

Przechowywanie wersji obiektów blob jest dostępne dla standardowych kont ogólnego przeznaczenia w wersji 2, blokowych obiektów blob w warstwie Premium i starszych kont usługi Blob Storage. Konta magazynowe z hierarchiczną przestrzenią nazw włączoną do użytku z Azure Data Lake Storage nie są obecnie obsługiwane.

Wersja 2019-10-10 i nowsze wersje interfejsu API REST Azure Storage obsługują wersjonowanie obiektów blob.

Wersjonowanie nie jest obsługiwane dla blobów, które przesyłasz za pomocą API Data Lake Storage.

Autoryzacja operacji na wersjach obiektów blob

Możesz autoryzować dostęp do wersji obiektów blob, przy użyciu jednego z następujących sposobów:

  • Użyj kontroli dostępu opartej na rolach na platformie Azure (Azure RBAC), aby przyznać uprawnienia podmiotowi zabezpieczeń Microsoft Entra. Microsoft zaleca korzystanie z Microsoft Entra ID w celu zapewnienia doskonałego bezpieczeństwa i łatwości użycia. Aby uzyskać więcej informacji na temat używania Microsoft Entra ID z operacjami na obiektach blob, zobacz Autoryzowanie dostępu do danych w Azure Storage.
  • Użyj sygnatury współdzielonego dostępu (SAS), aby delegować dostęp do wersji blob. Określ identyfikator wersji dla podpisanego typu zasobu bv, który oznacza wersję obiektu blob, aby utworzyć token SAS do operacji na określonej wersji. Aby uzyskać więcej informacji na temat sygnatur dostępu współdzielonego, zobacz Grant ograniczony dostęp do zasobów Azure Storage przy użyciu sygnatur dostępu współdzielonego (SAS).
  • Użyj kluczy dostępu do konta, aby autoryzować operacje na wersjach blob, używając klucza współdzielonego. Aby uzyskać więcej informacji, zobacz Autoryzacja za pomocą klucza współdzielonego.

Wersjonowanie obiektów blob jest przeznaczone do ochrony danych przed przypadkowym lub złośliwym usunięciem. Aby zwiększyć ochronę, usunięcie wersji obiektu blob wymaga specjalnych uprawnień. W poniższych sekcjach opisano uprawnienia wymagane do usunięcia wersji obiektu blob.

Akcja RBAC platformy Azure służąca do usunięcia wersji obiektu blob

W poniższej tabeli przedstawiono, które akcje Azure RBAC obsługują usuwanie bloba lub wersji bloba.

opis Operacja usługi Blob Service Wymagane działanie dotyczące danych Azure RBAC Azure wbudowane wsparcie dla ról
Usuwanie bieżącej wersji Usuń obiekt blob Microsoft. Storage/storageAccounts/blobServices/containers/blobs/delete Współautor danych w usłudze Blob Storage
Usuwanie poprzedniej wersji Usuń obiekt blob Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action Właściciel danych obiektu BLOB Storage

Parametry sygnatury dostępu współdzielonego (SAS)

Podpisany zasób dla wersji obiektu blob to bv. Aby uzyskać więcej informacji, zobacz Tworzenie usługi SAS lub Tworzenie SAS delegowania użytkownika.

Poniższa tabela przedstawia uprawnienia wymagane dla sygnatury dostępu współdzielonego (SAS) do usunięcia wersji obiektu blob.

Uprawnienie Symbol identyfikatora URI Dozwolone operacje
Usuń x Usuń wersję obiektu blob.

Istniejące uwagi dotyczące obciążenia

  • Usunięcie blobu nie zwalnia już miejsca. Gdy włączasz wersjonowanie, usunięcie bloba nie usuwa jego danych. Obecna wersja staje się poprzednią wersją, która pozostaje i nadal naliczane są za nią opłaty. Obciążenia polegające na operacjach usuwania w celu odzyskania pamięci nadal są obciążone opłatami, dopóki nie usuniesz wyraźnie tych wersji.

  • Obciążenia z dużą liczbą nadpisań mogą kumulować wersje. Wersje pozostają, dopóki ich wyraźnie nie usuniesz. Ta trwałość może prowadzić do nagromadzenia wersji, jeśli nie zarządzasz nimi właściwie. Aby obniżyć koszty, wprowadź zmiany na poziomie bloku, które będą naliczane na poziomie bloku w różnych wersjach, minimalizując koszty poszczególnej wersji.

Interakcje funkcji

Miękkie usuwanie

Wersjonowanie obiektów blob i miękkie usuwanie obiektów blob są częścią zalecanej konfiguracji ochrony danych dla kont magazynowych. Aby uzyskać więcej informacji na temat zaleceń Microsoft dotyczących ochrony danych, zobacz Omówienie ochrony danych.

Zastępowanie blobu

Jeśli włączysz zarówno wersjonowanie blobów, jak i miękkie usuwanie blob dla konta pamięciowego, to nadpisanie bloba automatycznie tworzy nową, poprzednią wersję, która odzwierciedla stan blob-a sprzed operacji zapisu. Nowa wersja nie jest oznaczana jako usunięta i pozostaje do momentu wyraźnego usunięcia. Nie są tworzone żadne nietrwałe migawki.

Usuwanie obiektu blob lub wersji

Jeśli włączysz zarówno wersjonowanie, jak i miękkie usuwanie dla konta pamięci, po usunięciu bloba obecna wersja blobu staje się wcześniejszą. Operacja nie tworzy nowej wersji ani żadnych migawek usuniętych nietrwale. Okres przechowywania miękkiego usuwania nie dotyczy usuniętego bloba.

Soft delete zapewnia dodatkową ochronę podczas usuwania wersji obiektów blob. Gdy usuwasz poprzednią wersję bloba, operacja usuwa tę wersję nietrwale. Wersja usunięta w trybie miękkim jest zachowywana do czasu wygaśnięcia okresu przechowywania, po którym zostaje trwale usunięta.

Aby usunąć poprzednią wersję obiektu blob, wywołaj operację Usuń obiekt blob i określ identyfikator wersji.

Przywracanie miękko usuniętej wersji

Użyj operacji Undelete Blob , aby przywrócić wersje miękko usunięte podczas okresu przechowywania miękkiego usuwania. Operacja Cofnij usunięcie blob zawsze przywraca wszystkie tymczasowo usunięte wersje blob. Nie możesz przywrócić tylko jednej wersji oznaczonej jako usunięta.

Przywracanie wersji usuniętych programowo za pomocą operacji Undelete Blob nie powoduje, że jakakolwiek wersja staje się wersją bieżącą. Aby przywrócić bieżącą wersję, najpierw przywróć wszystkie miękko usunięte wersje, a następnie użyj operacji Kopiowanie obiektu Blob, aby skopiować poprzednią wersję do nowej bieżącej wersji.

Po upływie okresu przechowywania po usunięciu nietrwałym system na stałe usuwa wszelkie nietrwale usunięte wersje blobów.

Migawki blobów

Migawka blobu to kopia tylko do odczytu blobu wykonana w określonym momencie. Migawki blobów i wersje są podobne, ale ty lub twoja aplikacja tworzycie migawkę ręcznie, podczas gdy wersja blob jest tworzona automatycznie podczas zapisu lub usuwania, gdy włączysz wersjonowanie blob dla swojego konta pamięciowego.

Ważne

Po włączeniu wersjonowania blobów zaktualizuj aplikację, aby przestała robić migawki blokowych blobów. Jeśli włączysz wersjonowanie dla swojego konta magazynu, wersje przechwytują i zachowują wszystkie aktualizacje i usunięcia obiektów blob blokowych. Robienie migawek nie zapewnia dodatkowej ochrony dla danych blokowych blobów, jeśli jest włączone wersjonowanie blobów, a może zwiększyć koszty i złożoność aplikacji.

Tworzenie migawki dla obiektu blob po włączeniu wersjonowania

Chociaż nie jest to zalecane, możesz utworzyć migawkę obiektu blob, który również podlega wersjonowaniu. Jeśli nie możesz zaktualizować aplikacji, aby zaprzestać tworzenia migawek obiektów blob podczas włączania wersjonowania, aplikacja może obsługiwać zarówno migawki, jak i wersje.

Gdy robisz migawkę zwersjonowanego blobu, tworzysz nową wersję jednocześnie z migawką. Tworzysz też nową aktualną wersję, gdy robisz snapshot.

Na poniższym diagramie przedstawiono, co się dzieje, gdy uchwycisz migawkę obiektu blob z wersjonowaniem. Na tym diagramie wersje obiektów blob i migawki z identyfikatorami wersji 2 i 3 zawierają identyczne dane.

Schemat pokazujący migawki wersjonowanego bloba.

Znane ograniczenia

  • Nie jest obsługiwane na kontach z hierarchiczną przestrzenią nazw (Azure Data Lake Storage) ani dla blobów przesyłanych za pomocą interfejsów API usługi Data Lake Storage.

  • Nie chroni przed usuwaniem kontenera ani konta. Wersjonowanie działa tylko na poziomie blobów. Usunięcie kontenera usuwa wszystkie bloby i ich wersje. Odzyskanie po takim usunięciu wymaga nietrwałego usuwania kontenera. Ochrona przed usunięciem konta wymaga blokady zasobu.

  • Wersje są niezmienne. Nie możesz zmieniać treści ani metadanych istniejącej wersji.

  • Wszystkie wersje blobu muszą mieć ten sam typ blob. Nie możesz nadpisać bloba innym typem bloba, gdy ma on wcześniejsze wersje, chyba że najpierw usuniesz blob i wszystkie jego wersje.

  • Nie wszystkie zapisy tworzą wersję. Zapoznaj się z informacjami wcześniej w tym artykule, które opisują wyjątki. Aby uchwycić te stany, użyj ręcznego snapshota.

  • Nie można wyłączyć wersjonowania, dopóki na koncie istnieją polityki replikacji obiektów . Najpierw musisz usunąć wszystkie polityki replikacji obiektów.

  • Undelete Blob Przywraca wszystkie miękko usunięte wersje bloba, a nie tylko jedną. Nie można selektywnie przywrócić usuniętej wersji. Undelete nigdy nie ustawia wersji jako bieżącej.

  • Zalecany górny pułap 1000 wersji na blob. Przekroczenie tego limitu pogarsza wydajność listowania obiektów blob.

Ceny i rozliczenia

Włączając wersjonowanie blobów, możesz ponieść dodatkowe koszty przechowywania danych. Projektując swoją aplikację, zastanów się, jak te koszty mogą się sumować, aby utrzymać niskie koszty.

Za wersje blobów, takie jak migawki blobów, naliczana jest opłata według tej samej stawki co za aktywne dane. Sposób rozliczania wersji zależy od tego, czy wyraźnie ustawiłeś tier dla obecnych czy poprzednich wersji blobu (lub migawki). Aby uzyskać więcej informacji na temat warstw obiektów blob, zobacz Warstwy dostępu Gorąca, Chłodna, Zimna i Archiwum dla danych obiektów blob.

Jeśli nie zmienisz warstwy dostępu obiektu blob lub jego wersji, opłaty są naliczane za unikalne bloki danych w obrębie tego obiektu blob, jego wersji oraz wszystkich migawek, które może zawierać. Więcej informacji znajdziesz w sekcji Rozliczenia, gdy poziom blob nie jest wyraźnie ustawiony.

Jeśli zmienisz poziom dostępu obiektu blob lub jego wersji, zostanie naliczona opłata za cały obiekt, niezależnie od tego, czy obiekt blob i jego wersja znów trafią do tego samego poziomu. Więcej informacji znajduje się w artykule Rozliczanie, gdy warstwa obiektu blob jest jawnie ustawiona.

Uwaga

Jeśli włączysz wersjonowanie danych, które często nadpisujesz, możesz zauważyć wzrost opłat za pojemność pamięci oraz zwiększone opóźnienia podczas operacji listowania. Aby zaradzić tym problemom, przechowuj często nadpisywane dane na osobnym koncie magazynu z wyłączonym wersjonowaniem.

Jeśli włączysz wersje na kontach magazynowych, dla których często tworzy się kopie zapasowe, możesz wywołać opłaty za odzyskiwanie danych, gdy wersje są przechowywane na poziomach dostępu chłodnego lub zimnego.

Aby uzyskać więcej informacji na temat szczegółów rozliczeń migawek obiektów blob, zobacz Migawki obiektów blob.

Dla kont magazynowych korzystających ze smart tier płacisz za wersje i snapshoty w pełnej długości zawartości. Aby uzyskać więcej informacji, zobacz Optymalizowanie kosztów za pomocą warstwy inteligentnej.

Rozliczenia, gdy nie ustawiasz wyraźnie poziomu blob

Jeśli nie ustawisz wyraźnie warstwy dostępu obiektu blob dla żadnej wersji obiektu blob, opłaty są naliczane za unikalne bloki lub strony we wszystkich wersjach oraz za wszelkie migawki, które może on zawierać. Opłata za dane udostępniane między wersjami blobów jest naliczana tylko raz. Gdy aktualizujesz blob, dane w nowej aktualnej wersji różnią się od danych przechowywanych w poprzednich wersjach, więc opłata jest naliczana za unikatowe dane za każdy blok lub stronę.

Gdy zastąpisz blok w obiekcie blob blokowym, opłata zostanie naliczona za ten blok jako za unikalny blok. Ta zasada obowiązuje nawet wtedy, gdy blok ma ten sam identyfikator bloku i te same dane, co w poprzedniej wersji. Po ponownym zatwierdzeniu bloku odbiega on od odpowiednika w poprzedniej wersji i naliczana jest opłata za jego dane. Ta sama zasada dotyczy również strony w stronicowym obiekcie blob, którą aktualizujesz tymi samymi danymi.

Blob storage nie ma sposobu na określenie, czy dwa bloki zawierają identyczne dane. Każdy blok, który przesyłasz i commitujesz, jest traktowany jako unikalny, nawet jeśli ma te same dane i ten sam identyfikator bloku. Ponieważ opłaty są naliczane za unikalne bloki, pamiętaj, że aktualizacja bloba po włączeniu wersjonowania skutkuje dodatkowymi unikalnymi blokami i dodatkowymi opłatami.

Gdy włączysz wersjonowanie blobów, wywołaj operacje aktualizacji bloków tak, aby aktualizowały jak najmniej bloków. Operacje zapisu, które zezwalają na precyzyjną kontrolę nad blokami, to Put Block i Put Block List. Put Block przygotowuje zmiany, ale faktyczna modyfikacja i tworzenie wersji odbywa się w operacji Put Block List. Operacja Put Blob natomiast zastępuje całą zawartość bloba, co może prowadzić do dodatkowych ładunków.

Poniższe scenariusze pokazują, jak naliczają się opłaty dla blobu blokowego i jego wersji, gdy nie ustawiasz wyraźnie poziomu blobów.

Scenariusz 1

W scenariuszu 1 obiekt blob ma poprzednią wersję. Blob nie jest aktualizowany od momentu utworzenia tej wersji, więc opłaty są pobierane tylko za unikalne bloki 1, 2 i 3.

Schemat 1 przedstawiający rozliczenia dla unikalnych bloków w bazowym blobie i poprzedniej wersji.

Scenariusz 2

W scenariuszu 2 jeden blok (blok 3 na diagramie) w blobie zostaje zaktualizowany. Mimo że zaktualizowany blok zawiera te same dane i ten sam identyfikator, nie jest taki sam jak blok 3 w poprzedniej wersji. W związku z tym opłaty za konto są naliczane za cztery bloki.

Schemat 2 pokazujący rozliczenia dla unikalnych bloków w bazowym blobie i poprzedniej wersji.

Scenariusz 3

W scenariuszu 3 blob jest aktualizowany, ale wersja nie. Blok 3 został zastąpiony blokiem 4 w obecnym blobie, ale poprzednia wersja nadal odzwierciedla blok 3. W związku z tym opłaty za konto są naliczane za cztery bloki.

Schemat 3 pokazujący rozliczenia dla unikalnych bloków w bazowym blobie i poprzedniej wersji.

Scenariusz 4

W scenariuszu 4 obecna wersja jest całkowicie zaktualizowana i nie zawiera żadnych oryginalnych bloków. W rezultacie konto jest obciążane za wszystkie osiem unikalnych bloków – cztery w obecnej wersji i cztery połączone w dwóch poprzednich wersjach. Ten scenariusz może się zdarzyć, gdy zapisujesz do bloba za pomocą operacji Put Blob , ponieważ zastępuje ona całą zawartość bloba.

Schemat 4 pokazujący rozliczenia dla unikalnych bloków w bazowym blobie i poprzedniej wersji.

Rozliczenia, gdy wyraźnie ustawiasz poziom blob

Jeśli wyraźnie ustawisz warstwę dostępu obiektu blob dla bloba, wersji lub migawki, płacisz za pełną długość zawartości obiektu w nowej warstwie, niezależnie od tego, czy współdzieli on bloki z obiektem w oryginalnej warstwie. Płacisz też za całą zawartość najstarszej wersji z pierwotnego poziomu. Za wszelkie inne wcześniejsze wersje lub migawki, które pozostają w oryginalnej warstwie, płacisz za unikalne bloki, które współdzielą, zgodnie z opisem w Rozliczanie, gdy warstwa obiektu blob nie jest jawnie ustawiona.

Przenoszenie obiektu blob do nowej warstwy

Poniższa tabela opisuje zachowanie rozliczeń dla blobu lub wersji po przeniesieniu go na nowy poziom.

Kiedy ustawiasz poziom blobów... Następnie są naliczane opłaty za...
Wyraźnie ustawione na wersji, obecnej czy poprzedniej Pełna długość zawartości tej wersji. Wersje, które nie mają wyraźnie ustawionego poziomu, są naliczane tylko za unikatowe bloki.1
Ustawiono do archiwizacji Pełna długość zawartości wszystkich wersji i migawek.1

1Jeśli istnieją inne wcześniejsze wersje lub snapshoty, których nie przeniosłeś z oryginalnego tieru, te wersje lub snapshoty są obciążane na podstawie liczby unikalnych bloków, które zawierają, jak opisano w Billing, gdy poziom blob nie jest wyraźnie ustawiony.

Poniższy diagram pokazuje, jak obiekty są rozliczane po przeniesieniu wersjonowanego bloba na inny poziom.

Diagram przedstawiający sposób naliczania opłat za obiekty, gdy wersjonowany obiekt blob jest jawnie przypisany do warstwy.

Nie da się cofnąć wyraźnego ustawienia tieru dla blobu, wersji czy migawki. Jeśli przeniesiesz blob na nowy poziom, a potem wrócisz do oryginalnego tieru, płacisz za pełną długość zawartości obiektu, nawet jeśli dzieli bloki z innymi obiektami z oryginalnego tieru.

Operacje, które jawnie ustawiają warstwę obiektu blob, wersji lub migawki, obejmują:

Usuwanie obiektu blob przy włączonym miękkim usuwaniu

Gdy włączasz miękkie usuwanie blobów, płacisz za wszystkie miękko usunięte jednostki w takim samym tempie, jak dane na żywo. Jeśli usuniesz lub nadpiszesz aktualną wersję, dla której wyraźnie ustawiono warstwę, płacisz za wcześniejsze wersje miękko usuniętego obiektu blob w pełnym rozmiarze zawartości. Więcej informacji o tym, jak wersjonowanie blob i soft delete działają razem, zobacz Interakcje z funkcjami.

Monitorowanie i rozwiązywanie problemów

  • Moja polityka LCM nie usuwa wersji, gdy tego oczekuję: Wiek wersji zależy od momentu pierwotnego zapisania danych, a nie od momentu, gdy stała się poprzednią wersją. Zegar zaczyna się od tworzenia blobu, a nie od nadpisania, które wprowadziło go do historii wersji. W efekcie blob, który był aktualny przez długi czas przed nadpisaniem, może wygenerować wcześniejszą wersję, która już w momencie utworzenia przekracza próg daysAfterCreationGreaterThan, powodując jej niemal natychmiastowe usunięcie. Z kolei wersje niedawno utworzonych blobów mogą utrzymywać się dłużej niż oczekiwano. Aby potwierdzić, sprawdź rzeczywisty znacznik czasu tworzenia wersji, zamiast zakładać, że pokrywa się z czasem nadpisania. Jeśli musisz oprzeć zasady przechowywania na momencie, gdy dana wersja stała się nieaktualna, lub chcesz bardziej szczegółowej kontroli niż pozwalają dzienne progi zarządzania cyklem życia, rozważ użycie Azure Storage Actions. Więcej informacji można znaleźć w Storage Actions.

  • Mój rachunek nadal jest wysoki po wyłączeniu wersji: Istniejące wersje pozostają, dopóki nie usuniesz ich ręcznie.

  • Nie mogę wyłączyć wersjonowania. Replikacja obiektów może być skonfigurowana na koncie. Najpierw usuń wszystkie polityki replikacji obiektów, a następnie wyłącz wersjonowanie. Alternatywnie, na kontenerze lub koncie może istnieć polityka Immutability (WORM), w przypadku których nie można wyłączyć wersjonowania.

Zobacz też

  • Ostatnia aktualizacja o