Azure Storage redundancia

Azure Storage mindig több másolatot tárol az adatokról, hogy megvédje őket a tervezett és nem tervezett eseményektől. Ilyen események például az átmeneti hardverhibák, a hálózati vagy áramkimaradások, valamint a súlyos természeti katasztrófák. A redundancia biztosítja, hogy a tárolószámlád megfeleljen a rendelkezésre állási és tartóssági céljainak még meghibásodás esetén is.

Amikor eldönti, hogy melyik redundancialehetőség a legjobb a forgatókönyvhöz, vegye figyelembe az alacsonyabb költségek és a magasabb rendelkezésre állás közötti kompromisszumot. Azokat a tényezőket, amelyek segítenek meghatározni, hogy melyik redundancia lehetőséget válasszuk:

• Hogyan történik az adatok replikálása az elsődleges régión belül.
• Azt jelzi, hogy az adatok replikálva lesznek-e egy elsődleges régióból egy második, földrajzilag távoli régióba a regionális katasztrófák (georeplikálás) elleni védelem érdekében.
• Az alkalmazás igényel-e olvasási hozzáférést a másodlagos régióban lévő replikált adatokhoz az elsődleges régió meghibásodása esetén (olvasási hozzáféréssel rendelkező georeplikáció esetén)?

Feljegyzés

A cikkben leírt funkciók és regionális elérhetőség elérhető olyan fiókok számára is, amelyek hierarchikus névtérrel rendelkeznek (Azure Blob Storage).

A Azure Storage álló szolgáltatásokat egy storage-fiók nevű közös Azure erőforrás kezeli. A tárolófiók egy megosztott tárolókészletet képvisel, amelyet használhatsz tárolási erőforrások telepítésére, mint például a blob konténerek (Blob Storage), fájlmegosztások (Azure Files), táblák (Table Storage) vagy sorok (Queue Storage). A Azure Storage fiókokról további információt a Storage-fiók áttekintése talál.

A tárfiók redundanciabeállítása meg van osztva az adott fiók által közzétett összes tárolási szolgáltatás esetében. Az ugyanabban a tárfiókban üzembe helyezett összes tárolási erőforrás ugyanazzal a redundanciával rendelkezik. Fontolja meg a különböző típusú erőforrások elkülönítését külön tárfiókokban, ha eltérő redundanciára vonatkozó követelményekkel rendelkeznek.

Redundancia az elsődleges régióban

Azure Storage két lehetőséget kínál az adatok elsődleges régióban való replikálásáról:

• A helyileg redundáns tárolás (LRS) a tárfiókokban lévő adatokat egyetlen fizikai adatközpontba replikálja, amely a választott elsődleges régióban található.

• Zone-redundáns tárolás (ZRS) szinkronizálva másolja az adatokat az elsődleges régió három vagy több Azure rendelkezésre állási zónájában. A magas rendelkezésre állást igénylő alkalmazások esetében a Microsoft a ZRS használatát javasolja az elsődleges régióban, valamint egy másodlagos régióba való replikálást.

Feljegyzés

Microsoft a ZRS használatát javasolja az elsődleges régióban Azure Data Lake Storage számítási feladatokhoz.

Helyileg redundáns tárolás

A helyileg redundáns tárolás (LRS) a tárfiókokban lévő adatokat egyetlen fizikai adatközpontba replikálja a választott elsődleges régióban. Bár a rendelkezésre állási zóna kiválasztása nem támogatott, Azure áthelyezheti vagy kibonthatja az LRS-fiókokat a zónák között a terheléselosztás javítása érdekében. Az LRS legalább 99,9999999999% (11 9s) tartósságot biztosít egy adott év alatt. A rendelkezésre állási zónák megbízhatóságáról a Az Azure rendelkezésre állási zónák cikkben talál további információt.

Az LRS a legalacsonyabb költségű redundancia lehetőség, és a többi lehetőséghez képest a legkevésbé tartósságot biztosítja. Az LRS védi az adatokat a meghajtó-, kiszolgáló- és állványhibáktól. Azonban, ha katasztrófa történik, például tűz vagy árvíz az adatközpontban, az LRS-t használó tárolófiók összes replikája elveszhet vagy felújíthatatlan lehet. Ha egy ideiglenes esemény, például hő esemény történik az adatközpontban, minden replika ideiglenesen elérhetetlen lehet, amíg az esemény meg nem oldódik. A kockázatok csökkentése érdekében Microsoft zónaredundáns tárolás (ZRS), georedundáns tárolás (GRS) vagy geo-zónaredundáns tárolás (GZRS) használatát javasolja.

Minden replika ugyanazt az aktuális állapotot tükrözi: a törlések és felülírások egyszerre kerülnek minden példányra. A redundancia védelmet nyújt a hardverhibák ellen, nem pedig az adatmódosítási műveletek ellen.

Az alábbi ábra bemutatja, hogyan replikálják az adataidat egyetlen adatközponton belül LRS-vel:

Az LRS a következő forgatókönyvekhez jó választás:

• Ha az alkalmazás olyan adatokat tárol, amelyek könnyen rekonstruálhatók adatvesztés esetén, fontolja meg az LRS kiválasztását.
• Ha az alkalmazás az adatszabályozási követelmények miatt csak egy régión belüli adatok replikálására van korlátozva, fontolja meg az LRS kiválasztását. Bizonyos esetekben a párosított régiók, amelyeken az adatok georeplikáltak, egy másik régión belül lehetnek. További információ a párosított régiókról: Azure régiók.
• Ha a forgatókönyv Azure nem felügyelt lemezeket használ, fontolja meg az LRS használatát. Bár létrehozhat egy tárfiókot Azure GRS-t használó nem felügyelt lemezekhez, az aszinkron georeplikálás konzisztenciájával kapcsolatos lehetséges problémák miatt nem ajánlott.

Zónaredundáns tárolás

A zónaredundáns tárolás (ZRS) a tárfiókokban lévő adatokat három vagy több Azure rendelkezésre állási zónába replikálja, amely az Ön által választott elsődleges régióban található. Minden rendelkezésreállási zóna egy fizikailag elkülönített, független áramforrással, hűtéssel és hálózatkezelési megoldással rendelkező hely. A ZRS egy adott évben legalább 99,99999999999999%-os (12 9s) tárolási erőforrások tartósságát biztosítja. A rendelkezésre állási zónák megbízhatóságáról a Az Azure rendelkezésre állási zónák cikkben talál további információt.

Amikor ZRS-t használsz, az adataid elérhetőek maradnak olvasási és írási műveletekhez is, még akkor is, ha egy zóna elérhetetlenné válik. Ha egy zóna elérhetetlenné válik, Azure olyan hálózati frissítéseket hajt végre, mint a tartománynévrendszer (DNS) újrapontozása. Ezek a frissítések hatással lehetnek az alkalmazásra, ha a frissítések befejeződése előtt hozzáfér az adatokhoz. A ZRS-alkalmazások tervezésekor kövesse az átmeneti hibakezelés gyakorlatát, beleértve az újrapróbálkozási szabályzatok exponenciális visszakapcsolással történő implementálását is.

A ZRS-t használó tárfiókra irányuló írási kérések szinkron módon történnek. Az írási művelet csak akkor lesz sikeres, ha az adatok a három rendelkezésre állási zónában lévő összes replikához meg lesznek írva. Ha egy rendelkezésre állási zóna átmenetileg nem érhető el, a művelet sikeresen visszaáll, miután az adatok az összes elérhető zónába meg vannak írva.

Microsoft javasolja a ZRS használatát az elsődleges régióban a magas rendelkezésre állást igénylő forgatókönyvekhez. Javasolt a ZRS használata az adatreplikálás egy adott régióra való korlátozására, hogy megfeleljen az adatszabályozási követelményeknek.

Microsoft a ZRS használatát javasolja Azure Files számítási feladatokhoz. Ha egy zóna elérhetetlenné válik, nincs szükség az Azure fájlmegosztások újracsatlakoztatására a csatlakoztatott kliens oldalakról.

Az alábbi ábra bemutatja, hogyan replikálja az adatokat az elsődleges régió rendelkezésre állási zónái között a ZRS használatával:

A ZRS kiváló teljesítményt, alacsony késést és rugalmasságot biztosít az adatok számára, ha az ideiglenesen elérhetetlenné válik. Előfordulhat azonban, hogy a ZRS önmagában nem védi teljesen az adatokat egy olyan regionális katasztrófa ellen, amely több zónát érint véglegesen. A geozónaredundáns tárolás (GZRS) az elsődleges régióban ZRS-t használ, és georeplikálással egy másodlagos régióba replikálja az adatokat. A GZRS számos régióban elérhető, és ajánlott a regionális katasztrófák elleni védelemhez.

A Blob Storage archív szintje jelenleg nem támogatott ZRS, GZRS vagy RA-GZRS-fiókok esetében. A nem felügyelt lemezek nem támogatják a ZRS-t vagy a GZRS-t.

További információ arról, hogy mely régiók támogatják a ZRS-t: Azure rendelkezésre állási zónákkal rendelkező régiók.

Redundancia egy másodlagos régióban

A redundancia opciók nagy tartósságot biztosítanak az alkalmazásaidhoz. Számos régióban átmásolhatja a tárfiókban lévő adatokat egy másodlagos régióba, amely több száz kilométerre található az elsődleges régiótól. A tárfiók másodlagos régióba másolása biztosítja, hogy az adatok tartósak maradnak egy teljes regionális kimaradás vagy olyan katasztrófa során, amelyben az elsődleges régió nem állítható helyre.

Tárfiók létrehozásakor kiválaszthatja a fiók elsődleges régióját. A párosított másodlagos régió az elsődleges régió alapján van meghatározva, és nem módosítható. A Azure által támogatott régiókról további információt a Azure régiók listájában talál.

Azure Storage két lehetőséget kínál az adatok másodlagos régióba való másolására:

• A georedundáns tárolás (GRS) szinkronosan másolja az adataidat egy vagy több Azure elérhetőségi zónán belül az elsődleges régióban, LRS használatával. Ezután aszinkron módon másolja az adatokat a másodlagos régióba. A másodlagos régióban az adataidat szinkronban másolják LRS segítségével.

• A geo-zóna-redundáns tárolás (GZRS) szinkronban másolja az adataidat három vagy több Azure elérhetőségi zónán keresztül az elsődleges régióban, ZRS segítségével. Ezután aszinkron módon másolja az adatokat a másodlagos régióba. A másodlagos régióban az adataidat szinkronban másolják LRS segítségével.

Feljegyzés

A GRS és a GZRS közötti elsődleges különbség az adatok replikálása az elsődleges régióban. A másodlagos régióban az adatokat mindig szinkronban replikálják LRS használatával. A másodlagos régió LRS-jei védik az adatokat a hardverhibáktól.

Amikor GRS-t vagy GZRS-t használsz, a másodlagos régióban lévő adatok nem elérhetők olvasási vagy írási hozzáférésre, kivéve, ha nincs egy visszacsatolás a másodlagos régióhoz. A másodlagos régióhoz való olvasási hozzáféréshez konfigurálja a tárfiókot írásvédett georedundáns tárolás (RA-GRS) vagy írásvédett geo-zónaredundáns tárolás (RA-GZRS) használatára. További információ: Olvasási hozzáférés az adatokhoz a másodlagos régióban.

Ha az elsődleges régió elérhetetlenné válik, választhatja a másodlagos régióba történő átkapcsolást. A feladatátvételi művelet befejezése után a másodlagos régió lesz az elsődleges régió, és ön képes adatokat olvasni és írni. A vészhelyreállításról és a másodlagos régióba történő feladatátvételről további információt a Vészhelyreállítás és tárfiók feladatátvétele című témakörben talál.

Fontos

Mivel az adatok aszinkron módon replikálódnak a másodlagos régióba, az elsődleges régiót érintő hiba adatvesztést okozhat, ha az elsődleges régió nem állítható helyre. Az elsődleges régióba történő legutóbbi írások és a másodlagos régióba történő utolsó írás közötti időközt helyreállítási pont célkitűzésnek (RPO) nevezzük. Az RPO azt az időpontot jelzi, ahová az adatok helyreállíthatók. Az Azure Storage Geo prioritású replikációt kínál, amely biztosítja, hogy a Block Blobs RPO kevesebb vagy egyenlő legyen 15 perc. További információt a Azure Storage geoprioritású replikáció cikkben talál.

Georedundáns tárolás

A georedundáns tárolás (GRS) szinkronosan másolja az adataidat egy vagy több elérhetőségi zónára az elsődleges régióban az LRS használatával. Ezután aszinkron módon másolja az adatokat egy másodlagos régióba, amely több száz kilométerre van az elsődleges régiótól. A GRS a tárolási erőforrások tartósságát legalább 99,99999999999999%-ra (16 darab 9-es) biztosítja egy adott év során.

Egy írási műveletet először az elsődleges helyre köteleznek be, és LRS segítségével replikálják. Ezt követően a rendszer aszinkron módon replikálja a frissítést a másodlagos régióba. Amikor az adatokat a másodlagos helyre írják, az LRS segítségével is replikál azon belül.

Az alábbi ábra bemutatja, hogyan replikálja az adatokat GRS vagy RA-GRS használatával:

Zóna- és georedundáns tárolás

A geozónaredundáns tárolás (GZRS) egyesíti a rendelkezésre állási zónák közötti redundancia által biztosított magas rendelkezésre állást a georeplikálás által biztosított regionális kimaradások elleni védelemmel. A GZRS-fiók adatai három vagy több Azure rendelkezésre állási zónába át lesznek másolva az elsődleges régióban. Emellett egy másodlagos földrajzi régióba is replikálja a regionális katasztrófák elleni védelem érdekében. A Microsoft olyan alkalmazásokhoz javasolja, amelyek magas konzisztenciát, tartósságot, elérhetőséget és ellenálló képességet igényelnek a katasztrófa-helyreállításhoz.

GZRS-fiókkal továbbra is olvashat és írhat adatokat, ha egy rendelkezésre állási zóna elérhetetlenné válik vagy helyreállíthatatlanná válik. Emellett az adatok tartósak maradnak egy teljes regionális kimaradás vagy katasztrófa során, amelyben az elsődleges régió nem állítható helyre. A GZRS-t úgy tervezték, hogy legalább 99,99999999999999999%-os (16 9s) tartósságot biztosítson az objektumoknak egy adott évben.

Az alábbi diagram bemutatja, hogyan replikálja az adatokat a GZRS vagy az RA-GZRS használatával:

Annak megállapításához, hogy egy régió támogatja-e a GZRS-t, tekintse meg a Azure régiók listáját. A GZRS támogatásához a régiónak támogatnia kell a rendelkezésre állási zónákat, és párosított régióval kell rendelkeznie.

Olvasási hozzáférés az adatokhoz a másodlagos régióban

A georedundáns tárolás (GRS vagy GZRS használatával) replikálja az adatokat egy másik fizikai helyre a másodlagos régióban a regionális kimaradások elleni védelem érdekében. A GRS-hez vagy GZRS-hez konfigurált fiókkal a másodlagos régióban lévő adatok nem érhetők el közvetlenül a felhasználók vagy alkalmazások számára, ha az elsődleges régióban kimaradás történik, kivéve, ha feladatátvétel történik. A feladatátvételi folyamat frissíti a Azure Storage által biztosított DNS-bejegyzést, így a másodlagos régióban lévő tárolási szolgáltatásvégpontok lesznek a tárfiók új elsődleges végpontjai. A feladatátvételi folyamat során az adatok nem érhetők el. A feladatátvétel befejezése után olvashat és írhat adatokat az új primer régióba. További információkért tekintse meg, hogyan működik az ügyfél által kezelt tárolófiók feladatátvétele a leállásból való helyreállítás során.

Ha az alkalmazásaid magas elérhetőséget igényelnek, beállíthatod a tárfiókodat olvasási hozzáférésre a másodlagos régióhoz. Amikor engedélyezed az olvasási hozzáférést a másodlagos régióhoz, az adataid mindig elérhetők a másodlagos régióból, beleértve azokat az állapotokat is, amikor az elsődleges régió elérhetetlenné válik. Az olvasási hozzáférésű georedundáns tárolás (RA-GRS) vagy az olvasási hozzáférésű geo-zónaredundáns tárolás (RA-GZRS) konfigurációi olvasási hozzáférést biztosítanak a másodlagos régióhoz.

Feljegyzés

Azure Files nem támogatja az olvasási hozzáférésű georedundáns tárolást (RA-GRS) vagy az olvasási hozzáférésű geo-zóna-redundáns tárolást (RA-GZRS).

Tervezze meg alkalmazásait, hogy olvasási hozzáférést biztosítsanak a másodlagos erőforrásokhoz.

Ha a tárfiókja olvasási hozzáférésre van konfigurálva a másodlagos régióhoz, akkor úgy tervezheti meg az alkalmazásokat, hogy zökkenőmentesen áttérjenek az adatok olvasására a másodlagos régióból, ha az elsődleges régió bármilyen okból elérhetetlenné válik.

A másodlagos régió az RA-GRS vagy az RA-GZRS engedélyezése után érhető el olvasási hozzáféréshez. Ez a rendelkezésre állás lehetővé teszi az alkalmazás előzetes tesztelését annak biztosítása érdekében, hogy megfelelően olvassa be az alkalmazást a másodlagos régióból egy üzemkimaradás során. A georedundancia előnyeinek kihasználásához az alkalmazások tervezésével kapcsolatos további információkért lásd : Magas rendelkezésre állású alkalmazások tervezése georedundanciával.

Ha engedélyezve van a másodlagoshoz való olvasási hozzáférés, az alkalmazás a másodlagos és az elsődleges végpontról is olvasható. A másodlagos végpont hozzáfűzi a -secondary utótagot a fiók nevéhez. Például, ha a Blob Storage myaccount.blob.core.windows.netelsődleges végpontja , akkor a másodlagos végpont myaccount-secondary.blob.core.windows.net. A tárfiók fiókhozzáférés-kulcsai megegyeznek az elsődleges és a másodlagos végpontok esetében is.

Adatvesztés megtervezése

Mivel az adatok aszinkron módon replikálódnak az elsődleges régióból a másodladi régióba, a másodlagos régió általában az elsődleges régió mögött van az írási műveletekhez. Ha egy katasztrófa az elsődleges régiót sújtja, valószínű, hogy egyes adatok elvesznek, és a címtárban vagy tárolóban lévő fájlok nem lesznek konzisztensek. A lehetséges adatvesztés megtervezéséről további információt az adatvesztés és az inkonzisztenciák című témakörben talál.

A redundancia beállításainak összegzése

A következő szakaszok táblázatai összefoglalják a Azure Storage elérhető redundancialehetőségeket.

Tartóssági és rendelkezésre állási paraméterek

Az alábbi táblázat az egyes redundancialehetőségek fő paramétereit ismerteti:

Paraméter	LRS	ZRS	GRS/RA-GRS	GZRS/RA-GZRS
Objektumok tartósságának százalékos aránya egy adott évben	legalább 99,99999999999% (11 9s)	legalább 99,9999999999999% (12 9s)	legalább 99,99999999999999999% (16 9s)	legalább 99,99999999999999999% (16 9s)
Olvasási kérelmek rendelkezésre állása	Legalább 99,9%; 99% ritka/ritka/archív hozzáférési szintekhez	Legalább 99,9%; 99% a ritka/ritka elérésű hozzáférési szinthez	GRS esetén legalább 99,9%; 99% ritka/ritka/archív hozzáférési szintekhez Legalább 99,99% az RA-GRS esetében; 99,9% ritka/ritka/archív hozzáférési szintekhez	GZRS esetén legalább 99,9%; 99% a ritka/ritka elérésű hozzáférési szinthez Legalább 99,99% RA-GZRS esetén; 99,9% a ritka/ritka elérésű hozzáférési szinthez
Írási kérelmek rendelkezésre állása	Legalább 99,9%; 99% ritka/ritka/archív hozzáférési szintekhez	Legalább 99,9%; 99% a ritka/ritka elérésű hozzáférési szinthez	Legalább 99,9%; 99% ritka/ritka/archív hozzáférési szintekhez	Legalább 99,9%; 99% a ritka/ritka elérésű hozzáférési szinthez

Megjegyzés: A GRS földrajzi replikációt biztosít, de nem teszi lehetővé az olvasási hozzáférést a másodlagos régióból. Az olvasási elérhetőség fenntartásához elsődleges régiókimaradás idején RA-GRS vagy RA-GZRS kell használni.

További információért tekintse meg a tárfiókok szolgáltatási szintű megállapodását.

Tartósság és rendelkezésre állás kimaradás esetén

Az alábbi táblázat azt jelzi, hogy az adatok tartósak-e és elérhetők-e egy adott forgatókönyvben attól függően, hogy milyen típusú redundancia van érvényben a tárfiókban:

Üzemkimaradási forgatókönyv	LRS	ZRS	GRS/RA-GRS	GZRS/RA-GZRS
Egy adatközponton belüli csomópont elérhetetlenné válik	Igen	Igen	Igen	Igen
Egy teljes adatközpont (zóna vagy nem zóna) elérhetetlenné válik	Nem	Igen	Igen1	Igen
Régiószintű kimaradás történik az elsődleges régióban	Nem	Nem	Igen1	Igen1
A másodlagos régió olvasási hozzáférése akkor érhető el, ha az elsődleges régió elérhetetlenné válik	Nem	Nem	Igen (RA-GRS-szel)	Igen (RA-GZRS használatával)

¹ Fiókátállás szükséges az írási rendelkezésre állás visszaállításához, ha az elsődleges régió elérhetetlenné válik. További információkért lásd Vészhelyreállítás és tárfiók feladatátvétele.

Támogatott Azure Storage szolgáltatások

Az alábbi táblázat az egyes Azure Storage-szolgáltatások által támogatott redundanciabeállításokat mutatja be.

Szolgáltatás	LRS	ZRS	GRS	RA-GRS	GZRS	RA-GZRS
Blob Storage (beleértve a Data Lake Storage)	✅	✅	✅	✅	✅	✅
Queue Storage	✅	✅	✅	✅	✅	✅
Table Storage	✅	✅	✅	✅	✅	✅
Azure Files	✅ 1	✅ 1	✅		✅
Azure-felügyelt lemezek	✅	✅ 2
Azure Elastic SAN	✅	✅

^Az LRS és a ZRS 1 SSD-fájlmegosztást támogat.
^{A 2} ZRS által felügyelt lemezekre bizonyos korlátozások vonatkoznak. A részletekért tekintse meg a felügyelt lemezek redundanciabeállításainak korlátozásokkal foglalkozó szakaszát.

Feljegyzés

Okos szintet használó tárolófiókok esetén a redundancia átalakításoknak és a fiók failover forgatókönyveknek vannak függőségei. További információ: Költségek optimalizálása intelligens szinttel

Támogatott tárfióktípusok

Az alábbi táblázat azt mutatja be, hogy mely redundanciabeállítások támogatottak az egyes tárfiók-típusokhoz. További információért a tárolószámla típusokról lásd: Tárhelyfiók áttekintés.

Tárfióktípusok	LRS	ZRS	GRS/RA-GRS	GZRS/RA-GZRS
Ajánlott	Szabványos általános célú v2 (StorageV2)1 Prémium szintű blokkblobok (BlockBlobStorage)1 SSD-fájlmegosztások (FileStorage) Prémium szintű lapblobok (StorageV2)	Szabványos általános célú v2 (StorageV2)1 Prémium szintű blokkblobok (BlockBlobStorage)1 SSD-fájlmegosztások (FileStorage)	Szabványos általános célú v2 (StorageV2)1	Szabványos általános célú v2 (StorageV2)1
Örökség	Standard általános célú v1 (Storage) Régi blob (BlobStorage)	n/a	Standard általános célú v1 (Storage) Régi blob (BlobStorage)	n/a

¹ A hierarchikus névtérrel rendelkező ilyen típusú fiókok a megadott redundanciabeállítást is támogatják.

Az összes tárfiók összes adata az elsődlegesről a másodlagosra lesz másolva a tárfiók redundanciabeállításának megfelelően. Objektumok, például blokkblobok, hozzáfűző blobok, oldalblobok, üzenetsorok, táblák és fájlok kerülnek másolásra.

A georeplikálás során az összes réteg adatai, beleértve az archív szintet is, mindig át lesznek másolva az elsődlegesről a másodlagosra. Az Blob Storage archív szintje támogatott az LRS, GRS és RA-GRS fiókokhoz, de ZRS, GZRS vagy RA-GZRS fiókokhoz nem. A blobszintekről további információt a blobadatok hozzáférési szintjei című témakörben talál.

A nem felügyelt lemezek nem támogatják a ZRS-t vagy a GZRS-t.

Az egyes redundancialehetőségekre vonatkozó díjszabási információkért lásd: Azure Storage díjszabás.

Feljegyzés

A blokkblobtárfiókok bizonyos régiókban támogatják a helyileg redundáns tárolást (LRS) és a zónaredundáns tárolást (ZRS).

Adatintegritás

Az Azure Storage rendszeresen ellenőrzi a tárolt adatok integritását ciklikus redundanciaellenőrzésekkel (CRC-k), és a felismert adatkorrupciót redundáns adatok segítségével javítja ki. Azure Storage az összes hálózati forgalom ellenőrzőösszegeit is kiszámítja, hogy észlelje az adatcsomagok sérülését az adatok tárolásakor vagy lekérésekor.

Lásd még

• Tárfiók redundanciabeállításának módosítása
• Geo replikáció (GRS/GZRS/RA-GRS/RA-GZRS)
  • Tárfiók utolsó szinkronizálási ideje tulajdonságának ellenőrzése
  • Katasztrófa utáni helyreállítás és tárolófiók átvitele
• Árképzés
  • Blob Storage
  • Azure Files
  • Táblatároló
  • Sorok tárolása
  • Azure lemezek