Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Azure Backup egy beépített Azure szolgáltatás, amely biztonságosan védi a felhőbeli és a helyszíni számítási feladatokat. A biztonsági mentés több számítási feladatra skálázhatja a védelmet, és natív módon integrálható Azure feladatokkal, beleértve a virtuális gépeket (VM-ek), az SAP HANA-t Azure virtuális gépeken, az SQL-t Azure virtuális gépeken, az Azure Files-t, az Azure Blob Storage-t, az Azure Data Lake Storage-t, az Azure felügyelt lemezeket, az Azure Elastic SAN köteteket és az Azure Kubernetes Service-t (AKS). Nem kell automatizálást vagy infrastruktúrát kezelnie, szkripteket írnia vagy tárolót kiépítenie.
Azure használatakor a megbízhatóság közös felelősség. Microsoft számos képességet biztosít a rugalmasság és a helyreállítás támogatására. Ön a felelős azért, hogy megértse, hogyan működnek ezek a képességek az összes használt szolgáltatáson belül, és válassza ki azokat a képességeket, amelyekre szüksége van az üzleti célok és az üzemidő céljainak eléréséhez.
Ez a cikk azt ismerteti, hogy a biztonsági mentés hogyan lehet rugalmas a lehetséges kimaradásokkal és problémákkal szemben, beleértve az átmeneti hibákat, a rendelkezésre állási zónák kimaradásait és a régiókimaradásokat. Emellett kiemel néhány fontos információt a biztonsági mentési szolgáltatásiszint-szerződésről (SLA).
Megjegyzés:
Ez a cikk azt ismerteti, hogy maga a biztonsági mentési szolgáltatás hogyan rugalmas a különböző problémákhoz, és hogyan teheti rugalmasabbá. Ez nem magyarázza meg, hogyan használhatja a Biztonsági mentést a virtuális gépek, adatok vagy egyéb eszközök védelmére. A biztonsági mentés használatáról a biztonsági mentés áttekintésében olvashat.
A termelési üzembe helyezési javaslatok a megbízhatóság érdekében
Az éles számítási feladatok biztonsági mentéséhez javasoljuk, hogy a tárolót a következő módokon konfigurálja:
Használja a zónaredundáns tárolást (ZRS) a biztonsági mentések minimális redundanciaszintjeként. A ZRS replikálja a biztonsági másolatokat több rendelkezésre állási zónára, hogy visszaállíthassa a biztonsági másolatokat a rendelkezésre állási zónák kimaradása során.
Ha georedundáns tárolást (GRS) használ a biztonsági másolatok párosított Azure régióba való replikálásához, engedélyezze a régiók közötti visszaállítást (CRR) a támogatott adatforrásokhoz. A CRR segítségével bármikor visszaállíthatja a biztonsági másolatokat a párosított régióba.
A cikk következő szakaszai részletesebben ismertetik ezeket a konfigurációkat.
Megjegyzés:
Ezek a tárolási redundanciajavaslatok azokra a helyekre vonatkoznak, ahol a biztonsági másolatok replikálódnak, nem pedig a biztonsági mentési szolgáltatásra vagy a biztonsági mentési erőforrásokra. A biztonsági mentések védelme és a tárolási redundancia kiegészítik egymást. A biztonsági másolatok védelmet nyújtanak az adatvesztés ellen, a redundancia pedig az infrastruktúra meghibásodása ellen.
A biztonsági mentésre vonatkozó egyéb javaslatok listájáért, beleértve a megbízhatóságra vonatkozó javaslatokat, tekintse meg a felhő biztonsági mentése és a helyszíni számítási feladatok felhőbe történő mentése című témakört.
A megbízhatósági architektúra áttekintése
Ez a szakasz a szolgáltatás megbízhatóság szempontjából leginkább releváns működésének néhány fontos aspektusát ismerteti. A szakasz bemutatja a logikai architektúrát, amely tartalmazza a telepített és használt erőforrásokat és funkciókat. Emellett a fizikai architektúrát is ismerteti, amely részletesen bemutatja, hogyan működik a szolgáltatás a borítók alatt.
Logikai architektúra
A biztonsági mentés számos különböző adatforrás biztonsági mentésére és visszaállítására használható. A biztonsági mentéseket a használt adatforrástól függően másképpen konfigurálhatja. A következő adatforrások gyakoriak:
- Azure virtuális gépek
- Különböző adatbázisok
- Blob Storage fiókok
- AKS klaszterek
- Helyszíni kiszolgálók a Microsoft Azure Recovery Services (MARS) ügynökön keresztül
A biztonsági mentés tárolókban tárolja a biztonsági mentési adatokat. Az Azure-ban a tárolók olyan online tárolási entitások, amelyek adatokat tartalmaznak, például biztonsági másolatokat, helyreállítási pontokat és biztonsági mentési szabályzatokat. A Recovery Services-tárolók és a Backup-tárolók kétféle tárolótípust jelentenek. Attól függően, hogy mit szeretnél megvédeni, használhatsz egy vagy mindkét típust. Az egyes tárolótípusok által támogatott adatforrások listájáért tekintse meg a biztonsági mentéshez és visszaállításhoz támogatott tárolókkal kapcsolatos gyakori kérdéseket.
A feladatok az adatok biztonsági mentésének vagy visszaállításának tevékenységét jelölik. A biztonsági mentési feladatok közé tartoznak az ütemezett vagy igény szerinti műveletek, amelyek az adatokat a forrásból a tárolóba másolják. A visszaállítási feladatok közé tartoznak azok a műveletek, amelyek helyreállítják az adatokat a biztonsági mentési tárból egy célhelyre. Minden feladat egyedi azonosítóval és állapotkövetéssel rendelkezik, így nyomon követheti a biztonsági mentési és visszaállítási műveletek során felmerülő előrehaladást és hibaelhárítást. A feladatokhoz társított biztonsági mentési szabályzatokat is létrehozhat. A szabályzatok olyan konfigurációt határoznak meg, mint a biztonsági mentés ütemezése, és hogy mennyi ideig szeretné megőrizni az adatokat.
A tárolók a biztonsági mentési szabályzatokat és a konfigurációt, valamint a feladatok metaadatait tárolják, így nyomon követheti a feladatokat és a hibaelhárítást.
Fizikai architektúra
Microsoft kezeli az alapvető Biztonsági mentési szolgáltatás infrastruktúráját. Ez az infrastruktúra felelős a szolgáltatás felügyeletéért és működéséért, beleértve a feladatok aktiválását és monitorozását is.
A biztonsági mentések a tárolóban vannak tárolva. A boltozatok az Azure Storage-ra épülnek. A tárolók automatikusan replikálják a biztonsági mentési adatokat, és a biztonsági mentés tartóssága és rugalmassága a tárolók tárolási redundanciájától függ.
Locally redundáns tárolás (LRS) replikálja a tárolón belüli adatokat egy vagy több, a választott elsődleges régióban található Azure rendelkezésre állási zónába. Nem választhatja ki a kívánt rendelkezésre állási zónát, de 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 adatok nem garantáltan a zónák között oszlanak el. További információ: A rendelkezésre állási zónák áttekintése.
A ZRS és a GRS további védelmet nyújt. Ez a cikk részletesen ismerteti ezeket a beállításokat.
Megjegyzés:
Egyes adatforrások támogatják a működési szintű biztonsági mentéseket, amelyek az adatokat nem a tárolóban, hanem más helyen tárolják. Például Azure felügyelt lemezek biztonsági mentése és AKS biztonsági másolatok támogatják a lemez pillanatképeiben tárolt üzemeltetési szintű biztonsági mentéseket. Ez a cikk nem foglalkozik a működési szintű biztonsági mentési tárterülettel, de az ebben a cikkben szereplő rugalmassági útmutatást alkalmazhatja az ilyen típusú biztonsági mentési műveletekre és munkafolyamatokra.
Rugalmasság átmeneti hibákhoz
Az átmeneti hibák rövid, időszakos meghibásodások a komponensekben. Gyakran előfordulnak elosztott környezetben, például a felhőben, és ezek a műveletek szokásos részei. Az átmeneti hibák rövid idő elteltével kijavítják magukat. Fontos, hogy az alkalmazások kezelni tudják az átmeneti hibákat, általában az érintett kérések újrapróbálásával.
Minden felhőalapú alkalmazásnak követnie kell az Azure átmeneti hibakezelési útmutatást, amikor a felhőben üzemeltetett API-kkal, adatbázisokkal és más összetevőkkel kommunikálnak. További információ: Átmeneti hibák kezelésére vonatkozó javaslatok.
A Biztonsági mentés használata esetén a biztonsági mentési és visszaállítási munkafolyamatok rugalmasak az időszakos hibákra. A szolgáltatás automatikusan újrapróbálkozza, amikor átmeneti hálózati hibák vagy átmeneti szolgáltatáskimaradások lépnek fel. Nem konfigurál újrapróbálkozásos logikát. Ha ismétlődő hibákat tapasztal, tekintse meg a Biztonsági mentési tároló kezelési műveleteinek hibaelhárítása részt.
Rugalmasság a rendelkezésre állási zóna hibáival szemben
A rendelkezésre állási zónák fizikailag különálló adatközpont-csoportok egy Azure régión belül. Ha egy zóna meghibásodik, a szolgáltatások a fennmaradó zónák egyikére is át tudnak adni feladatokat.
A biztonsági mentés külön kezeli a szolgáltatás rendelkezésre állási zónájának konfigurációját és az adatait.
Szolgáltatás: A biztonsági mentési szolgáltatás automatikusan rugalmas zónát biztosít a támogatott régiókban. Ez a beépített zónarugalmasság azonban nem vonatkozik a biztonsági mentési adatokra.
Biztonsági mentési tár redundancia: A Recovery Services-tároló vagy a Backup-tároló konfigurálásával válassza ki a biztonsági mentési adatokhoz szükséges redundanciaszintet. Ha a ZRS-t választja, a biztonsági mentési adatok másolatait a rendszer automatikusan több rendelkezésre állási zónában tárolja a használt Azure régióban.
Ha nem használja a ZRS-t, a biztonsági mentési adatok nem zónaalapúnak minősülnek, és bármely zónában tárolhatók. Ha a régió bármely zónájában probléma merül fel, előfordulhat, hogy a nem zónabeli biztonsági mentési adatok nem érhetők el.
Az automatikusan zónatűrő biztonsági mentési alapszolgáltatást és zónaredundáns biztonsági mentési tárhelyet bemutató diagram.
Az ábra a biztonsági mentés zónaálló architektúráját mutatja be három rendelkezésre állási zónában. A három oszlop az 1. rendelkezésre állási zónát, a 2. rendelkezésre állási zónát és a 3. rendelkezésre állási zónát jelöli. A Backup core service címkével ellátott mező mindhárom zónára kiterjed. A mező alatt a diagram egyetlen, ZRS címkével ellátott sort mutat be, amely mindhárom rendelkezésre állási zónára kiterjed. A ZRS sor alatt egy másik mező mind a három rendelkezésre állási zónára kiterjed. Ez a mező két felhőikont tartalmaz, amelyek egy Backup-tárolót és egy Recovery Services-tárolót jelölnek.
Requirements
Régiótámogatás: A szolgáltatás automatikusan zónareziliens minden olyan régióban, ahol rendelkezésre állási zónák vannak. A ZRS-tárolókat ugyanazokban a régiókban támogatják.
Csak új tárolók: Konfigurálja a ZRS-t a tárolón az első biztonsági mentés előtt.
Költség
Ha engedélyezi a ZRS-t a biztonsági mentésekhez, a többletreplikációs és tárolási többletterhelés miatt az LRS-hez képest eltérő díjat kell fizetnie. További információ: Biztonsági mentés díjszabása.
A rendelkezésre állási zóna támogatásának konfigurálása
Hozzon létre egy új tárolót, amely ZRS-t használ: Tároló létrehozásakor konfigurálja a tárredundanciát. A tároló típusától függően különböző lépéseket kell végrehajtania. További információkért lásd a következő cikkeket:
ZRS konfigurálása meglévő tárolókon: Biztonsági mentési tárolók esetén konfigurálja a tároló létrehozásakor a tároló redundanciát. A Backup-tároló létrehozása után a beállítás zárolva van, és nem módosíthatja.
A Recovery Services-tárolók esetében a számítási feladatok védelme előtt konfigurálnia kell a tárolóredundanciát. A számítási feladatok védelme után a beállítás zárolva van, és nem módosíthatja.
Létrehozhat egy ZRS használatára konfigurált új tárolót, és hozzárendelheti a számítási feladatokat az új tárolóhoz. Ez a megközelítés azonban állásidőt igényel. További információ: Alapértelmezett beállítások módosítása. A meglévő helyreállítási pontok és egyéb adatok manuális törléséért is felelős, mert a régi tároló adatmegőrzési szabályzatai már nem érvényesek. További információ: Backup-tároló törlése vagy Recovery Services-tároló törlése.
Viselkedés, ha minden zóna kifogástalan
Ez a szakasz azt ismerteti, hogy mire számíthat a tárolók ZRS-hez való konfigurálásakor, és az összes zóna működőképes.
Zónák közötti művelet: A biztonsági mentési feladatok zónák között replikált infrastruktúrán futnak. Azure bármely zónában lévő infrastruktúrából felügyeli a feladatokat.
Zónaközi adatreplikálás: A ZRS a zónák között replikálja a biztonsági másolatokat. A replikáció szinkron módon történik, ami azt jelenti, hogy több zóna nyugtázza az egyes írási műveleteket, mielőtt befejeződne.
Viselkedés zónahiba esetén
Ez a szakasz azt ismerteti, hogy mire számíthat, amikor tárhelyeket konfigurál ZRS-hez, és kimaradás van az egyik zónában.
Észlelés és reagálás: Maga a biztonsági mentési szolgáltatás esetében a Microsoft felelős a rendelkezésre állási zónák hibáinak észleléséért és a válaszadásért. Nem kell semmit tennie a zóna átváltásának kezdeményezéséhez.
Fontos
Minden olyan adat vagy erőforrás esetében, amely a zónakimaradás miatt nem érhető el, ön a felelős a kimaradás észleléséért és a helyreállítási műveletek végrehajtásáért, beleértve a biztonsági másolatok kifogástalan zónába való visszaállítását.
- Értesítés: A Microsoft nem értesíti automatikusan, ha egy zóna nem elérhető. A Azure Resource Health használatával azonban figyelheti az egyes erőforrások állapotát, és beállíthat Resource Health riasztásokat a problémákról való értesítéshez. A Azure Service Health használatával is megismerheti a szolgáltatás általános állapotát, beleértve a zónahibákat is, és beállíthat Service Health-riasztásokat a problémákról való értesítéshez.
Aktív kérések: Az aktív feladatok viselkedése attól függ, hogy melyik zóna meghibásodik.
A sikertelen rendelkezésre állási zónában lévő adatforrások esetében a zónahiba miatt az adatforrások nem érhetők el. Az aktív feladatok szünetelhetnek vagy meghiúsulhatnak.
Azokban az egészséges rendelkezésre állási zónákban lévő adatforrások, amelyek aktív feladatokat futtatnak, előfordulhat, hogy rövid állásidő, általában néhány másodperc, következik be, miközben a platform átvált az egészséges rendelkezésre állási zónákra a Backup szolgáltatás számára.
Várható adatvesztés: Az adatvesztés várható mennyisége a helyreállítási pont célkitűzése (RPO) néven is ismert. A biztonsági mentési adatok RPO-jának több tényezőtől függ, beleértve a biztonsági mentés ütemezését is. A zónakimaradások esetében általában nem várható biztonsági mentési adatvesztés, mert minden adat szinkron módon replikálódik a zónák között.
Várható állásidő: A várható állásidőt helyreállítási idő célkitűzésnek (RTO) is nevezik. Az RTO az alábbi forgatókönyvek mindegyikéhez eltérő:
A sikertelen rendelkezésre állási zónában lévő adatforrások esetében előfordulhat, hogy az adatforrások nem érhetők el, amíg a zóna helyre nem áll. Előfordulhat, hogy a biztonsági mentési feladatok nem futnak, amíg az adatforrás újra el nem érhető. Az RTO nincs meghatározva.
Bármely egészséges rendelkezésre állási zónában lévő adatforrás esetében előfordulhat, hogy kis mennyiségű állásidő (általában néhány másodperc) következik be, miközben a platform a Backup szolgáltatás számára egészséges rendelkezésre állási zónákra vált.
Újraelosztás: A következő feladatfuttatások automatikusan használják az infrastruktúrát kifogástalan állapotú zónákban, amíg az adatforrások elérhetők.
Ön felel azért, hogy visszaállítsa a biztonsági mentést egy kifogástalan állapotú zónában lévő infrastruktúrára, valamint a terheléselosztók, az ügyfelek és más rendszerek újrakonfigurálásával átirányítsa a forgalmat az új zóna kifogástalan infrastruktúrájához.
Zóna helyreállítása
A rendelkezésre állási zóna helyreállításakor a biztonsági mentés automatikusan visszaállítja a rendelkezésre állási zónában lévő műveleteket, és a szokásos módon átirányítja a zónák közötti forgalmat. A feladatok továbbra is futnak, és az adatok továbbra is elérhetők maradnak.
Zónahibák tesztelése
A Backup rendszer kezeli a forgalom útválasztását, az adatreplikálást, a feladatátvételt és a feladatvisszaállítást. Ez a funkció teljes mértékben felügyelt, így nem kell kezdeményeznie vagy ellenőriznie a rendelkezésre állási zónák meghibásodási folyamatait.
Rugalmasság régiószintű hibákhoz
A biztonsági mentés támogatja a georedundanciát és a feladatátvételt a GRS és a CRR használatával.
Fontos
A GRS for Backup csak paired Azure régión belül működik.
Georedundáns tárolás és régiók közötti visszaállítás
A biztonsági másolatok regionális redundanciájának eléréséhez használja a GRS-t, hogy replikálja a biztonsági másolatokat egy Azure párosított régióba. A GRS védi a biztonsági másolatokat a regionális kimaradásoktól.
A tárolót üzembe helyező régiót elsődleges régiónak nevezzük. Az adatforrásnak az elsődleges régióban kell lennie. Nem konfigurálhat biztonsági mentéseket egy másik régióban lévő tárolóba.
A párosított régiót másodlagos régiónak is nevezik.
Ha nem konfigurálja a GRS-t, és a tároló régiójában kimaradás történik, előfordulhat, hogy hozzáférhet a tárolóhoz, és megtekintheti a biztonsági mentési elemeket. Regionális redundancia nélkül azonban a mögöttes biztonsági mentési adatok nem érhetők el a visszaállítási műveletekhez.
Régiók közötti visszaállítás
Ha a GRS-t egy tárolón konfigurálja, Microsoft elérhetővé teszi a párosított régió biztonsági másolatait, miután az elsődleges régióban kimaradás történt. Ha az adatforrás támogatja a CRR-t, akkor a másodlagos régió helyreállítási pontjairól akkor is helyreállíthatja az adatokat, ha az elsődleges régióban nem történik szolgáltatáskimaradás. A CRR emellett lehetővé teszi a regionális kimaradásokkal szembeni rugalmasság felmérésére irányuló gyakorlatok futtatását is. A CRR bekapcsolásakor a Microsoft frissíti a biztonsági mentési tárolót GRS-ről az olvasás-hozzáférésű georedundáns tárolásra (RA-GRS).
Requirements
Region support: A biztonsági mentéshez készült GRS csak párosított Azure régiókon belül működik.
Csak új tárolók: Az első biztonsági mentés előtt konfigurálnia kell a GRS-t a tárolón.
Megfontolások
- CRR: A CRR bekapcsolása után a biztonsági mentési elemek akár 48 órát is igénybe vehetnek, amíg elérhetők lesznek a másodlagos régióban.
Költség
A GRS-tárolók további költségeket okoznak a regionális replikáció és a másodlagos régióban történő tárolás miatt. A Azure régiók közötti adatátvitelt a standard régiók közötti sávszélesség alapján számítjuk fel. A CRR díjszabása eltérő, mivel a Microsoft a tárhelyet GRS-ről RA-GRS-re frissíti. További információ: Biztonsági mentés díjszabása.
Többrégiós támogatás konfigurálása
Hozzon létre egy új tárolót, amely GRS-t és CRR-t használ: Tároló létrehozásakor a tároló redundanciát is konfigurálnia kell. A GRS kiválasztása után opcionálisan engedélyezheti a CRR-t a biztonsági táron. A lépések, amelyeket követ, a tároló típusától függenek. További információkért lásd a következő cikkeket:
GRS és CRR konfigurálása meglévő tárolókon: A Backup-tárolók esetében a tároló létrehozásakor konfigurálnia kell a tároló redundanciát.
A Recovery Services-tárolók esetében a számítási feladatok védelme előtt konfigurálnia kell a tárolóredundanciát. A számítási feladatok védelme után a beállítás zárolva van, és nem módosíthatja.
A CRR a meglévő GRS-tárolókon engedélyezhető. A CRR engedélyezése után nem tilthatja le.
Viselkedés, ha minden régió kifogástalan
Ez a szakasz azt ismerteti, hogy mire számíthat, ha a tárolókat GRS használatára konfigurálja, és minden régió működőképes.
Régiók közötti művelet: A biztonsági mentések mindig az elsődleges régióban fejeződnek be, amely az a régió, ahol a tároló és az adatforrás üzembe van helyezve.
Régiók közötti adatreplikálás: Amikor a tárolót GRS használatára konfigurálja, a biztonsági másolatok először az elsődleges régióra lesznek véglegesve az LRS használatával. Az elsődleges régió sikeres befejezése után a rendszer aszinkron módon replikálja az adatokat a másodlagos régióba. A másodlagos régió az LRS használatával tárolja az adatokat. A biztonsági mentési adatok replikálása az elsődleges régióból a másodlagos régióba akár 12 órát is igénybe vehet.
Viselkedés régióhiba esetén
Ez a szakasz azt ismerteti, hogy mire számíthat, ha az adattárolókat GRS használatra konfigurálja, és az elsődleges régióban leállás történik.
Észlelés és válasz: A CRR-t támogató és a tárolón a CRR-t engedélyező adatforrások esetében bármikor kezdeményezhet saját CRR-t a párosított régióba, például egy régiókimaradás vagy katasztrófa során. Ön a felelős a kimaradás észleléséért és a helyreállítási műveletekért, beleértve a biztonsági mentések kifogástalan állapotú régióba való visszaállítását.
Minden más forgatókönyv esetében a másodlagos régióba replikált adatok csak akkor állíthatók vissza a másodlagos régióban, ha Azure az elsődleges régióban vészhelyzetet deklarál. Microsoft felelős a katasztrófa kikiáltásáért. A katasztrófa bejelentéséhez szükséges idő az incidens súlyosságától és a helyzet értékeléséhez szükséges időtől függ. Microsoft általában csak hosszabb idő elteltével deklarál katasztrófahelyzetet.
Értesítés: Microsoft nem értesíti Önt automatikusan, ha egy régió leáll. Azonban:
A Azure Resource Health használatával figyelheti az egyes erőforrások állapotát, és beállíthat Resource Health riasztásokat a problémákról való értesítéshez.
A Azure Service Health használatával megismerheti a szolgáltatás általános állapotát, beleértve a régióhibákat is, és beállíthatja a Service Health-riasztásokat a problémák értesítésére.
Várható adatvesztés: A biztonsági mentési adatok RPO-jának több tényezőtől függ, beleértve a biztonsági mentés ütemezését is. Általánosságban elmondható, hogy egy régió kimaradása esetén akár 36 órányi adatvesztésre is számíthat, mivel az elsődleges régióban az RPO 24 óra, és akár 12 órát is igénybe vehet a biztonsági mentési adatok replikálása az elsődleges régióból a másodlagos régióba.
Várható állásidő: Az RTO az alábbi különböző forgatókönyvek mindegyikénél eltérő:
Előfordulhat, hogy a sikertelen régióban lévő adatforrások és egyéb erőforrások nem érhetők el, amíg a régió helyre nem áll, ezért az RTO nincs meghatározva.
Előfordulhat, hogy a biztonsági mentés nem képes biztonsági mentési vagy visszaállítási műveleteket végrehajtani a sikertelen régióban, amíg a régió helyre nem áll, ezért az RTO nincs meghatározva.
CRR használata esetén a párosított régióba már replikált biztonsági másolatok visszaállításának kezdeményezésére szolgáló RTO nulla. Ha nem használja a CRR-t, az RTO attól függ, hogy mennyi ideig tart, amíg a Microsoft katasztrófát hirdet a meghibásodott régióban.
Újraelosztás: Az elsődleges régió offline állapotában nem futtathatók biztonsági mentési feladatok. A tárolóban visszaállíthatja az adatokat, de nem adhat hozzá új adatokat.
Ön felel a párosított régió infrastruktúrájának biztonsági mentéséért, valamint a terheléselosztók, az ügyfelek és más rendszerek újrakonfigurálásáért, hogy a forgalmat a párosított régió kifogástalan infrastruktúrájához irányíthassa.
Régió helyreállítása
Amikor az elsődleges régió helyreáll, a biztonsági mentés automatikusan visszaállítja a régió műveleteit. A feladatok folytatódnak, és az adatok továbbra is elérhetők maradnak.
Régióhibák tesztelése
A CRR használatával visszaállítási műveletet hajthat végre a párosított régióban. Ezzel a módszerrel ellenőrizheti a visszaállítást és az egyéb helyreállítási folyamatokat.
A biztonsági mentési adatok elvesztésének rugalmassága
A biztonsági mentés két kulcsfontosságú helyreállítási funkciót biztosít a biztonsági mentési adatok véletlen vagy rosszindulatú törlésének megakadályozásához:
A "soft delete" lehetővé teszi, hogy a törölt objektumokat és tárolókat helyreállítsuk egy konfigurálható megőrzési időszak alatt. Alapértelmezés szerint ez az időszak 14 nap, de szerkesztheti. A helyreállítható törlést a biztonsági másolatok és tárolók lomtáraként tekintheti. További információ: Alapértelmezetten biztonságos, soft delete-vel támogatott mentés. A nem módosítható tárolók segíthetnek a biztonsági mentési adatok védelmében azáltal, hogy blokkolják azokat a műveleteket, amelyek helyreállítási pontok elvesztéséhez vezethetnek. A nem módosítható tárolóbeállítást úgy zárolhatja, hogy az visszafordíthatatlanná válik. Biztonsági mentésekhez használhat WORM (Write Once, Read Many) adattárolót is, hogy megakadályozza a támadókat abban, hogy letiltsák a nem módosíthatóságot és töröljék a mentéseket. További információ: Nem módosítható tároló a biztonsági mentéshez.
Szolgáltatásiszint-szerződés
A Azure szolgáltatások szolgáltatásiszint-szerződése (SLA) leírja az egyes szolgáltatások várható elérhetőségét, valamint azokat a feltételeket, amelyeket a megoldásnak teljesítenie kell az adott rendelkezésre állási elvárás eléréséhez. További információ: SLAs for online szolgáltatások.
A biztonsági mentési SLA a szolgáltatás rendelkezésre állását tartalmazza a biztonsági mentési és visszaállítási műveletekhez is. Ahhoz, hogy az SLA hatálya alá essen, legalább 30 percenként újra meg kell próbálnia a sikertelen biztonsági mentést vagy visszaállítási feladatot.