zapasowość Azure Storage

Azure Storage zawsze przechowuje wiele kopii danych, aby chronić je przed zaplanowanymi i nieplanowanymi zdarzeniami. Przykłady tych zdarzeń obejmują przejściowe awarie sprzętu, awarie sieci lub zasilania oraz ogromne klęski żywiołowe. Redundancja zapewnia, że Twoje konto magazynowe spełnia swoje cele dotyczące dostępności i trwałości nawet podczas awarii.

Podczas podejmowania decyzji, która opcja nadmiarowości jest najlepsza dla danego scenariusza, rozważ kompromisy między niższymi kosztami a wyższą dostępnością. Czynniki, które pomagają określić, którą opcję nadmiarowości należy wybrać, obejmują:

  • Jak dane są replikowane w regionie podstawowym.
  • Czy dane są replikowane z regionu podstawowego do drugiego, odległego geograficznie regionu w celu ochrony przed awariami regionalnymi (replikacja geograficzna).
  • Czy aplikacja wymaga dostępu do odczytu do replikowanych danych w regionie pomocniczym podczas awarii w regionie podstawowym (replikacja geograficzna z dostępem do odczytu).

Uwaga

Funkcje i dostępność regionalna opisane w tym artykule są również dostępne dla kont posiadających hierarchiczną przestrzeń nazw (Azure Blob Storage).

Usługi, które składają się na Azure Storage, są zarządzane za pośrednictwem wspólnego zasobu Azure nazywanego kontem storage. Konto pamięci to wspólna pula pamięci, którą możesz wykorzystać do wdrażania zasobów pamięci masowej, takich jak kontenery blob (Blob Storage), udostępnione pliki (Azure Files), tabele (Table Storage) lub kolejki (Queue Storage). Aby uzyskać więcej informacji na temat kont Azure Storage, zobacz Przegląd konta magazynowania.

Ustawienie nadmiarowości dla konta przechowywania jest wspólne dla wszystkich usług przechowywania oferowanych przez to konto. Wszystkie zasoby magazynu, które znajdują się na tym samym koncie magazynu, mają to samo ustawienie nadmiarowości. Rozważ izolowanie różnych typów zasobów na oddzielnych kontach magazynu, jeśli mają różne wymagania dotyczące nadmiarowości.

Redundancja w podstawowym regionie

Azure Storage oferuje dwie opcje replikacji danych w regionie podstawowym:

  • Lokalnie nadmiarowa pamięć masowa (LRS) replikuje dane w ramach kont pamięci masowej do pojedynczego fizycznego centrum danych znajdującego się w wybranym przez ciebie podstawowym regionie.

  • Zone-redundant Storage (ZRS) kopiuje dane synchronicznie w co najmniej trzech strefach dostępności Azure w regionie podstawowym. W przypadku aplikacji wymagających wysokiej dostępności Microsoft zaleca używanie ZRS w regionie podstawowym oraz replikowanie do regionu wtórnego.

Uwaga

Microsoft zaleca używanie magazynu ZRS w regionie podstawowym na potrzeby obciążeń Azure Data Lake Storage.

Lokalnie nadmiarowe przechowywanie

Magazyn lokalnie nadmiarowy (LRS) replikuje dane w ramach kont magazynu do jednego fizycznego centrum danych w wybranym regionie podstawowym. Mimo że wybranie strefy dostępności nie jest obsługiwane, Azure może przenosić lub rozszerzać konta LRS między strefami, aby poprawić równoważenie obciążenia. LRS zapewnia co najmniej 99,99999999999% (11 9s) trwałości obiektów w ciągu danego roku. Zapoznaj się z artykułem Czym są strefy dostępności Azure, aby dowiedzieć się więcej o niezawodności stref dostępności.

LRS to najtańsza opcja nadmiarowości i oferuje najmniejszą niezawodność w porównaniu z innymi opcjami. LRS chroni twoje dane przed awariami dysków, serwerów i całych szaf. Jednak jeśli w centrum danych dojdzie do katastrofy, takiej jak pożar lub powódź, wszystkie repliki konta pamięci masowej korzystające z LRS mogą zostać utracone lub nie do odzyskania. Jeśli w centrum danych wystąpi tymczasowe zdarzenie, takie jak termiczne, wszystkie repliki mogą być tymczasowo niedostępne, dopóki zdarzenie nie zostanie rozwiązane. Aby ograniczyć te zagrożenia, Microsoft zaleca użycie magazynu z nadmiarowością strefową (ZRS), magazynu geograficznie redundantnego (GRS) lub magazynu geograficzno-strefowo redundantnego (GZRS).

Wszystkie repliki odzwierciedlają ten sam aktualny stan: usuwania i nadpisywania są stosowane do wszystkich kopii jednocześnie. Nadmiarowość chroni przed awariami sprzętowymi, a nie przed operacjami modyfikowania danych.

Poniższy diagram pokazuje, jak Twoje dane są replikowane w jednym centrum danych za pomocą LRS:

Diagram pokazujący, jak dane są replikowane w jednym centrum danych z lokalnie redundantnym magazynem LRS.

LRS jest dobrym wyborem w następujących sytuacjach:

  • Jeśli aplikacja przechowuje dane, które można łatwo odtworzyć w przypadku utraty danych, rozważ wybór LRS.
  • Jeśli aplikacja jest ograniczona do replikowania danych tylko w regionie ze względu na wymagania związane z zarządzaniem danymi, rozważ wybór LRS. W niektórych przypadkach sparowane regiony, w których dane są replikowane geograficznie, mogą znajdować się w innym regionie. Aby uzyskać więcej informacji na temat sparowanych regionów, zobacz regiony Azure.
  • Jeśli w Twoim scenariuszu masz dyski niezarządzane w Azure, rozważ użycie Lokalnej Redundancji Magazynowej (LRS). Chociaż istnieje możliwość utworzenia konta magazynowego dla niezarządzanych dysków Azure używających GRS, nie jest to zalecane ze względu na potencjalne problemy ze spójnością podczas asynchronicznej replikacji geograficznej.

Magazyn nadmiarowy strefowy

Magazyn strefowo nadmiarowy (ZRS) replikuje dane na twoich kontach magazynu do trzech lub więcej stref dostępności Azure, znajdujących się w wybranym regionie podstawowym. Każda strefa dostępności jest oddzielną lokalizacją fizyczną z niezależnym zasilaniem, chłodzeniem i siecią. ZRS oferuje trwałość zasobów magazynowych na poziomie 99,999999999999% (12 dziewiątek) w danym roku. Zapoznaj się z artykułem Czym są strefy dostępności Azure, aby dowiedzieć się więcej o niezawodności stref dostępności.

Gdy używasz ZRS, Twoje dane pozostają dostępne zarówno do odczytu, jak i zapisu, nawet jeśli strefa stanie się niedostępna. Jeśli strefa stanie się niedostępna, Azure podejmuje aktualizacje sieciowe, takie jak przeadresowanie DNS. Te aktualizacje mogą mieć wpływ na aplikację, jeśli uzyskujesz dostęp do danych przed ukończeniem aktualizacji. Podczas projektowania aplikacji dla ZRS postępuj zgodnie z praktykami dotyczącymi obsługi błędów przejściowych, w tym implementując zasady ponawiania z zastosowaniem wykładniczego wycofywania się.

Żądanie zapisu na koncie magazynu z użyciem ZRS odbywa się synchronicznie. Operacja zapisu kończy się pomyślnie dopiero po zapisaniu danych do wszystkich replik we wszystkich trzech strefach dostępności. Jeśli strefa dostępności jest tymczasowo niedostępna, operacja zakończy się pomyślnie po zapisaniu danych we wszystkich dostępnych strefach.

Microsoft zaleca używanie ZRS w regionie podstawowym w scenariuszach wymagających wysokiej dostępności. ZRS jest również zalecane do ograniczania replikacji danych do jednego regionu w celu spełnienia wymagań dotyczących ładu danych.

Microsoft zaleca używanie magazynu ZRS dla obciążeń Azure Files. Jeśli strefa stanie się niedostępna, nie jest wymagane ponowne instalowanie udziałów plików Azure z połączonych klientów.

Na poniższym diagramie przedstawiono sposób replikacji danych między strefami dostępności w regionie podstawowym za pomocą ZRS.

Diagram pokazujący, jak dane są replikowane w strefach dostępności z wykorzystaniem strefowo-redundantnego magazynu ZRS.

Usługa ZRS zapewnia doskonałą wydajność, niskie opóźnienia i odporność, które chronią Twoje dane nawet w przypadku tymczasowej niedostępności. Jednak samo ZRS może nie w pełni chronić Twoich danych przed awarią regionalną, gdzie wiele stref jest trwale dotkniętych. Magazyn geograficznie nadmiarowy (GZRS) używa strefowego magazynu nadmiarowego (ZRS) w regionie podstawowym, a także georeplikuje dane do regionu pomocniczego. GZRS jest dostępny w wielu regionach i jest zalecany do ochrony przed regionalnymi katastrofami.

Warstwa archiwum dla Blob Storage nie jest obecnie obsługiwana dla kont ZRS, GZRS ani RA-GZRS. Dyski niezarządzane nie obsługują ZRS ani GZRS.

Aby uzyskać więcej informacji na temat regionów obsługujących ZRS, zobacz regiony platformy Azure ze strefami dostępności.

Redundancja w regionie pomocniczym

Opcje redundancji pomagają zapewnić wysoką trwałość dla Twoich zastosowań. W wielu regionach można skopiować dane z konta magazynu do regionu pomocniczego znajdującego się setki kilometrów od regionu podstawowego. Kopiowanie konta przechowywania do regionu zapasowego zapewnia trwałość danych podczas całkowitej awarii regionalnej lub awarii, która uniemożliwia odzyskanie regionu podstawowego.

Podczas tworzenia konta magazynu należy wybrać region podstawowy dla konta. Sparowany region pomocniczy jest określany na podstawie regionu podstawowego i nie można go zmienić. Aby uzyskać więcej informacji na temat regionów obsługiwanych przez Azure, zobacz listę regionów Azure.

Azure Storage oferuje dwie opcje kopiowania danych do regionu pomocniczego:

  • Geo-redundantna pamięć (GRS) kopiuje Twoje dane synchronicznie w jednej lub kilku strefach dostępności Azure w regionie podstawowym, korzystając z LRS. Następnie kopiuje dane asynchronicznie do regionu pomocniczego. W regionie wtórnym twoje dane są kopiowane synchronicznie za pomocą LRS.

  • Geo-zone-redundant storage (GZRS) kopiuje Twoje dane synchronicznie przez trzy lub więcej stref dostępności Azure w regionie podstawowym, korzystając z ZRS. Następnie kopiuje dane asynchronicznie do regionu pomocniczego. W regionie wtórnym twoje dane są kopiowane synchronicznie za pomocą LRS.

Uwaga

Podstawową różnicą między GRS i GZRS jest sposób replikacji danych w regionie podstawowym. W obrębie regionu wtórnego dane są zawsze replikowane synchronicznie za pomocą LRS. LRS w pomocniczym regionie chroni Twoje dane przed awariami sprzętowymi.

Gdy używasz GRS lub GZRS, dane w regionie wtórnym nie są dostępne do odczytu ani zapisu, chyba że nastąpi awaryjne przełączenie do regionu wtórnego. Aby uzyskać dostęp do odczytu do regionu pomocniczego, skonfiguruj konto magazynu do korzystania z nadmiarowego magazynowania geograficznego dostępnego do odczytu (RA-GRS) lub magazynowania w strefach geograficznych dostępnego do odczytu (RA-GZRS). Aby uzyskać więcej informacji, zobacz Dostęp do odczytu danych w regionie dodatkowym.

Jeśli region podstawowy stanie się niedostępny, możesz przejść w tryb failover do regionu pomocniczego. Po zakończeniu operacji failover region pomocniczy stanie się regionem podstawowym i będziesz mógł odczytywać oraz zapisywać dane. Aby uzyskać więcej informacji na temat odzyskiwania po awarii i dowiedzieć się, jak wykonać przełączenie awaryjne do regionu pomocniczego, zapoznaj się z Odzyskiwanie po awarii i przełączanie awaryjne konta magazynu.

Ważne

Ponieważ dane są replikowane do regionu pomocniczego asynchronicznie, awaria, która ma wpływ na region podstawowy, może spowodować utratę danych, jeśli nie można odzyskać regionu podstawowego. Interwał między najnowszymi zapisami w regionie podstawowym i ostatnim zapisem w regionie pomocniczym jest znany jako cel punktu odzyskiwania (RPO). Punkt docelowy odzyskiwania (RPO) wskazuje punkt w czasie, do którego można odzyskać dane. Azure Storage oferuje replikację priorytetową Geo, która zapewnia, że RPO dla blokowych blobów jest mniej lub równe 15 minutam. Aby uzyskać więcej informacji, zobacz artykuł Azure Storage Replikacja priorytetu geograficznego.

Pamięć masowa georedundantna

Geo-redundantna pamięć masowa (GRS) kopiuje Twoje dane synchronicznie do jednej lub więcej stref dostępności w regionie podstawowym, korzystając z LRS. Następnie dane są kopiowane asynchronicznie do regionu wtórnego, który znajduje się setki kilometrów od regionu podstawowego. GRS oferuje trwałość zasobów przechowywania na poziomie co najmniej 99,99999999999999% (16 dziewiątek) na rok.

Operacja zapisu jest najpierw zatwierdzana w lokalizacji głównej i replikowana za pomocą LRS. Aktualizacja jest następnie replikowana asynchronicznie do regionu pomocniczego. Gdy dane są zapisywane do lokalizacji drugorzędnej, replikują się one również w tej lokalizacji za pomocą LRS.

Na poniższym diagramie przedstawiono, jak dane są replikowane z użyciem GRS lub RA-GRS.

Diagram pokazujący, jak dane są replikowane do regionu pomocniczego przy użyciu magazynu geograficznie nadmiarowego GRS lub RA-GRS.

Magazyn geograficznie i strefowo redundantny

Magazyn redundantny w strefach geograficznych (GZRS) łączy wysoką dostępność dzięki nadmiarowości w strefach dostępności z ochroną przed regionalnymi awariami zapewnianą przez replikację geograficzną. Dane na koncie GZRS są kopiowane w co najmniej trzech stref dostępności Azure w regionie podstawowym. Ponadto replikuje również do drugiego regionu geograficznego w celu ochrony przed katastrofami regionalnymi. Microsoft zaleca stosowanie GZRS w aplikacjach wymagających wysokiej spójności, trwałości, dostępności i odporności na odzyskiwanie po awariach.

Za pomocą konta GZRS można nadal odczytywać i zapisywać dane, jeśli strefa dostępności stanie się niedostępna lub jest nieodwracalna. Ponadto dane pozostają trwałe podczas całkowitej awarii regionalnej lub awarii, w której region podstawowy nie jest możliwy do odzyskania. GZRS jest przeznaczony do zapewnienia co najmniej 99,99999999999999999% (16 9s) trwałości obiektów w danym roku.

Na poniższym diagramie przedstawiono, jak Twoje dane są replikowane za pomocą GZRS lub RA-GZRS.

Diagram pokazujący, jak dane są replikowane za pomocą pamięci geo-strefowej redundantnej GZRS lub RA-GZRS.

Aby określić, czy region obsługuje GZRS, zobacz listę regionów Azure. Aby obsługiwać GZRS, region musi wspierać strefy dostępności i mieć sparowany region.

Dostęp do odczytu danych w regionie pomocniczym

Georedundantne przechowywanie (za pomocą GRS lub GZRS) replikuje dane do innej lokalizacji fizycznej w regionie zapasowym, aby chronić przed awariami regionalnymi. W przypadku konta skonfigurowanego dla GRS lub GZRS, dane w regionie pomocniczym nie są bezpośrednio dostępne dla użytkowników ani aplikacji, gdy w regionie podstawowym wystąpi awaria, chyba że nastąpi przełączenie awaryjne. Procedura failover aktualizuje wpis DNS udostępniany przez Azure Storage, aby punkty końcowe usługi magazynu w regionie pomocniczym zostały nowymi podstawowymi punktami końcowymi dla twojego konta magazynu. Podczas procesu przełączania awaryjnego dane są niedostępne. Po zakończeniu przełączenia awaryjnego można odczytywać i zapisywać dane w nowym, głównym regionie. Aby uzyskać więcej informacji, zobacz Jak działa przełączanie trybu awaryjnego konta magazynu zarządzanego przez klienta w celu odzyskiwania po awarii.

Jeśli Twoje aplikacje wymagają wysokiej dostępności, możesz skonfigurować konto pamięci do odczytu do regionu wtórnego. Gdy włączysz dostęp do odczytu w regionie wtórnym, Twoje dane są zawsze dostępne do odczytu z regionu wtórnego, także w sytuacji, gdy region pierwotny staje się niedostępny. Konfiguracje magazynu geograficznie redundantnego dostępnego do odczytu (RA-GRS) lub magazynu geograficznie strefowo redundantnego dostępnego do odczytu (RA-GZRS) zezwalają na dostęp odczytu w regionie pomocniczym.

Uwaga

Azure Files nie obsługuje georedundantnego magazynu z dostępem tylko do odczytu (RA-GRS) ani geozonowego georedundantnego magazynu z dostępem tylko do odczytu (RA-GZRS).

Projektowanie aplikacji pod kątem dostępu do odczytu do wtórnego

Jeśli konto magazynu jest skonfigurowane do odczytu danych z regionu pomocniczego, możesz zaprojektować swoje aplikacje tak, aby bezproblemowo przełączały się na odczyt danych z regionu pomocniczego, kiedy region podstawowy stanie się niedostępny z dowolnego powodu.

Region pomocniczy jest dostępny do odczytu po włączeniu RA-GRS lub RA-GZRS. Ta dostępność pozwala przetestować aplikację z wyprzedzeniem, aby upewnić się, że odczytuje prawidłowo z regionu pomocniczego podczas awarii. Aby uzyskać więcej informacji na temat projektowania aplikacji w celu korzystania z nadmiarowości geograficznej, zobacz Projektowanie aplikacji o wysokiej dostępności przy użyciu nadmiarowości geograficznej.

Po włączeniu dostępu do odczytu elementu pomocniczego, Twoja aplikacja może odczytywać dane zarówno z pomocniczych, jak i podstawowych punktów końcowych. Pomocniczy punkt końcowy dołącza sufiks -secondary do nazwy konta. Na przykład, jeśli Twój główny punkt końcowy dla Blob Storage to myaccount.blob.core.windows.net, to punkt końcowy wtórny to myaccount-secondary.blob.core.windows.net. Klucze dostępu do konta przechowywania są takie same zarówno dla podstawowych, jak i pomocniczych interfejsów końcowych.

Planowanie utraty danych

Ponieważ dane są replikowane asynchronicznie z regionu pierwotnego do wtórnego, region wtórny zazwyczaj znajduje się za regionem pierwotnym dla operacji zapisu. Jeśli awaria uderzy w region podstawowy, prawdopodobnie niektóre dane zostaną utracone, a pliki w katalogu lub kontenerze nie będą spójne. Aby uzyskać więcej informacji na temat planowania potencjalnej utraty danych, zobacz Utrata danych i niespójności.

Podsumowanie opcji redundancji

Tabele w poniższych sekcjach zawierają podsumowanie opcji nadmiarowości dostępnych dla Azure Storage.

Parametry trwałości i dostępności

W poniższej tabeli opisano kluczowe parametry każdej opcji nadmiarowości:

Parametr LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Procent trwałości obiektów w danym roku co najmniej 99,999999999999% (11 9s) co najmniej 99,9999999999999% (12 9s) co najmniej 99,9999999999999999999% (16 9s) co najmniej 99,9999999999999999999% (16 9s)
Dostępność żądań odczytu Co najmniej 99,9%; 99% dla warstw dostępu Chłodna/Chłodna/Archiwum Co najmniej 99,9%; 99% dla warstwy dostępu chłodnego/zimnego Co najmniej 99,9% dla magazynu GRS; 99% dla warstw dostępu Chłodna/Chłodna/Archiwum

Co najmniej 99,99% dla RA-GRS; 99,9% dla warstw dostępu Zimna/Chłodna/Archiwum
Co najmniej 99,9% dla GZRS; 99% dla warstwy dostępu chłodnego/zimnego

Co najmniej 99,99% dla ra-GZRS; 99.9% dla warstwy dostępu chłodnego/zimnego
Dostępność żądań zapisu Co najmniej 99,9%; 99% dla warstw dostępu Chłodna/Chłodna/Archiwum Co najmniej 99,9%; 99% dla warstwy dostępu chłodnego/zimnego Co najmniej 99,9%; 99% dla warstw dostępu Chłodna/Chłodna/Archiwum Co najmniej 99,9%; 99% dla warstwy dostępu chłodnego/zimnego

Uwaga: GRS zapewnia replikację geograficzną, ale nie pozwala na odczyt danych z regionu zapasowego. Aby utrzymać dostępność odczytu podczas przerwy w regionie głównym, należy używać RA-GRS lub RA-GZRS.

Aby uzyskać więcej informacji, zobacz SLA dla kont magazynu.

Trwałość i dostępność według scenariusza awarii

W poniższej tabeli przedstawiono trwałość i dostępność danych w danym scenariuszu, w zależności od typu nadmiarowości dla konta magazynowego.

Scenariusz awarii LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Węzeł w centrum danych staje się niedostępny do użytku Tak Tak Tak Tak
Całe centrum danych (strefowe lub niezonowe) staje się niedostępne Nie. Tak Tak1 Tak
Awaria obejmująca cały region występuje w regionie podstawowym Nie. Nie. Tak1 Tak1
Możliwość odczytu danych z regionu pomocniczego jest zapewniona, gdy region podstawowy stanie się niedostępny. Nie. Nie. Tak (z RA-GRS) Tak (z RA-GZRS)

1 Przełączenie awaryjne konta jest wymagane do przywrócenia dostępności zapisu, jeśli region podstawowy stanie się niedostępny. Aby uzyskać więcej informacji, zobacz Odzyskiwanie po awarii i przełączenie awaryjne konta magazynu.

Obsługiwane usługi Azure Storage

W poniższej tabeli przedstawiono opcje nadmiarowości obsługiwane przez każdą usługę Azure Storage.

Usługa LRS ZRS GRS RA-GRS GZRS RA-GZRS
Blob Storage
(w tym Data Lake Storage)
Queue Storage
Magazyn tabel
Azure Files 1 1
dyski zarządzane przez Azure 2
Azure Elastic SAN

1 Udziały plików SSD są obsługiwane w magazynach LRS i ZRS.
2 Dyski zarządzane ZRS mają pewne ograniczenia. Aby uzyskać szczegółowe informacje, zobacz sekcję Ograniczenia opcji nadmiarowości dla dysków zarządzanych.

Uwaga

W przypadku kont magazynowych korzystających z warstwy inteligentnej konwersje typu redundancji i scenariusze przełączenia awaryjnego konta wiążą się z pewnymi zależnościami. Aby uzyskać więcej informacji, zobacz Optymalizowanie kosztów za pomocą warstwy inteligentnej

Obsługiwane typy kont magazynu

W poniższej tabeli przedstawiono, które opcje nadmiarowości są obsługiwane dla każdego typu konta magazynu. Więcej informacji o typach kont magazynowych można znaleźć w przeglądzie konta magazynowego.

Typy konta magazynu LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Zalecane Standard ogólnego przeznaczenia v2 (StorageV2)1

Blokowe obiekty blob w warstwie Premium (BlockBlobStorage)1

Udziały plików SSD (FileStorage)

Bloby stronicowe warstwy Premium (StorageV2)
Standard ogólnego przeznaczenia v2 (StorageV2)1

Blokowe obiekty blob w warstwie Premium (BlockBlobStorage)1

Udziały plików SSD (FileStorage)
Standard ogólnego przeznaczenia v2 (StorageV2)1 Standard ogólnego przeznaczenia v2 (StorageV2)1
Dziedzictwo Standardowa wersja ogólnego przeznaczenia w wersji 1 (Storage)

Przestarzały obiekt blob (BlobStorage)
Nie dotyczy Standardowa wersja ogólnego przeznaczenia w wersji 1 (Storage)

Przestarzały obiekt blob (BlobStorage)
Nie dotyczy

1 Konta tego typu z włączoną hierarchiczną przestrzenią nazw obsługują również określoną opcję nadmiarowości.

Wszystkie dane dla wszystkich kont magazynowych są kopiowane z konta głównego na konto zapasowe zgodnie z opcją nadmiarowości dla konta magazynowego. Obiekty, w tym bloby blokowe, bloby uzupełniające, bloby stronicowe, kolejki, tabele i pliki, są kopiowane.

Dane we wszystkich warstwach, w tym warstwa archiwum, są zawsze kopiowane z warstwy podstawowej do pomocniczej podczas replikacji geograficznej. Archiwalna warstwa w usłudze Blob Storage jest obsługiwana dla kont LRS, GRS i RA-GRS, ale nie dla kont ZRS, GZRS ani RA-GZRS. Aby uzyskać więcej informacji na temat warstw obiektów blob, zobacz Warstwy dostępu dla danych obiektów blob.

Dyski niezarządzane nie obsługują ZRS ani GZRS.

Aby uzyskać informacje o cenach dla każdej opcji nadmiarowości, zobacz cennik Azure Storage.

Uwaga

Konta magazynowania blokowych obiektów blob obsługują składnice z lokalną nadmiarowością (LRS) i ze strefową nadmiarowością (ZRS) w niektórych regionach.

Integralność danych

Azure Storage regularnie weryfikuje integralność przechowywanych danych, stosując cykliczne kontrole redundancji (CRC), a także naprawia wykryte uszkodzenia danych za pomocą danych redundantnych. Azure Storage oblicza również sumy kontrolne dla całego ruchu sieciowego w celu wykrywania uszkodzenia pakietów danych podczas przechowywania lub pobierania danych.

Zobacz też