Folyamatos biztonsági mentés időponthoz kötött visszaállítással az Azure Cosmos DB-ben

A KÖVETKEZŐKRE VONATKOZIK: Nosql MongoDB Gremlin Táblázat

Az Azure Cosmos DB időponthoz kötött visszaállítási funkciója több forgatókönyvben is segít, például:

• Helyreállítás egy tárolón belüli véletlen írási vagy törlési műveletből.
• Törölt fiók, adatbázis vagy tároló visszaállítása.
• Visszaállítás bármely régióba (ahol biztonsági másolatok léteztek) a visszaállítási időpontban.

Az Azure Cosmos DB anélkül végez adatmentést a háttérben, hogy extra kiosztott átviteli sebességet (RU-kat) használ, vagy befolyásolná az adatbázis teljesítményét és rendelkezésre állását. A rendszer folyamatos biztonsági mentéseket készít minden olyan régióban, ahol a fiók létezik. Egy fiók például rendelkezhet írási régióval az USA nyugati régiójában, és olvasási régiókat az USA keleti régiójában és az USA 2. keleti régiójában. Ezek a replikarégiók ezután biztonsági másolatot készíthetnek egy távoli Azure Storage-fiókról az egyes régiókban. Alapértelmezés szerint minden régió helyileg redundáns tárfiókokban tárolja a biztonsági mentést. Ha a régióban engedélyezve vannak a rendelkezésre állási zónák , a biztonsági mentés zónaredundáns tárfiókokban lesz tárolva.

Az USA nyugati régiójában található írási régióval rendelkező tárolók és az USA 2. keleti és keleti régióinak olvasási régióinak biztonsági mentése. A tárolóról biztonsági másolatot készítünk egy távoli Azure Blob Storage-fiókra az egyes írási és olvasási régiókban.

A visszaállításhoz rendelkezésre álló időkeret (más néven megőrzési idő) a következő két lehetőség alacsonyabb értéke: 30 napos és 7 napos.

A kiválasztott beállítás a folyamatos biztonsági mentés kiválasztott szintjétől függ. A visszaállítás időpontja a megőrzési időszakon belül bármely időbélyeg lehet, amely nem lehet hosszabb az erőforrás létrehozásának időpontjánál. Erős konzisztencia módban az írási régióban készített biztonsági másolatok naprakészebbek az olvasási régiókhoz képest. Az olvasási régiók hálózati vagy egyéb átmeneti problémák miatt elmaradhatnak. A visszaállítás során lekérheti a legújabb visszaállítható időbélyeget egy adott erőforráshoz egy adott régióban. A legújabb visszaállítható időbélyegre hivatkozva ellenőrizheti, hogy az erőforrás-biztonsági másolatok a megadott időbélyegre vannak-e felállítva, és visszaállíthatók-e ebben a régióban.

Jelenleg egy Azure Cosmos DB-fiókot (API for NoSQL vagy MongoDB, API for Table, API for Gremlin) egy adott időpontban visszaállíthat egy másik fiókba. Ezt a visszaállítási műveletet az Azure Portalon, az Azure CLI-vel (Azure CLI), az Azure PowerShell-lel vagy az Azure Resource Manager-sablonokkal hajthatja végre.

A biztonsági mentési tár redundanciája

Az Azure Cosmos DB alapértelmezés szerint helyileg redundáns tárolóblobokban tárolja a folyamatos módú biztonsági mentési adatokat. A zónaredundanciával rendelkező régiók esetében a biztonsági mentés zónaredundáns tárolási blobokban van tárolva. Folyamatos biztonsági mentési módban nem frissítheti a biztonsági mentési tár redundanciát.

A visszaállítás különböző módjai

A folyamatos biztonsági mentési mód két módon támogatja a törölt tárolók és adatbázisok visszaállítását. Visszaállíthatók egy új fiókba az itt dokumentált módon, vagy visszaállíthatók egy meglévő fiókba az itt leírtak szerint. A két mód közötti választás a forgatókönyvtől függ. A legtöbb esetben érdemes visszaállítani a törölt tárolókat és adatbázisokat egy meglévő fiókba. Ez elkerüli az új fiókba való visszaállításhoz szükséges adatátviteli költségeket. Az olyan forgatókönyvek esetében, ahol véletlen adatmódosítás történt, az új fiókba való visszaállítás lehet az előnyben részesített lehetőség.

Többrégiós írási fiók visszaállítása (előzetes verzió)

A központi régióban végrehajtott összes írás azonnal megerősítést nyer, és aszinkron módon, 100 másodpercen belül biztonsági másolatot készít. A műholdrégióban (nem ütközésfeloldási régióban) végrehajtott mutációkat a rendszer megerősítés céljából elküldi a központi régiónak. A központi régió ellenőrzi, hogy szükség van-e ütközésmegoldásra , és az ütközések feloldása után hozzárendel egy ütközéssel feloldott időbélyeget , és visszaküldi a műholdas régiónak. A műholdas régió csak azután készít biztonsági másolatot az entitásokról, hogy a megerősítést megkapta a központi régiótól.
Összefoglalva, a visszaállítási folyamat csak azokat az entitásokat állítja vissza, amelyek a központi régióból származó ütközésfeloldási időbélyeggel vannak megerősítve.

Feljegyzés

A több írási régiós fiókokról itt talál további információt, a hubrégió a portál első régiója.

Mi nem állítható vissza a többrégiós írási fiókok visszaállításához (előzetes verzió)?

A visszaállítási időbélyeg által még megerősítendő mutációk nem lesznek visszaállítva. Az egyéni ütközésfeloldási szabályzattal rendelkező gyűjtemények az időbélyeg alapján az utolsó írói győzelemre lesznek visszaállítva.

Példa: Ha egy több írási régiót tartalmazó fiók az USA keleti régiójával és az USA nyugati régiójával rendelkezik, amelyek közül az USA keleti régiója a központi régió, vegye figyelembe az alábbi események sorozatát:

Ebben az esetben, ha a visszaállítási időbélyeg T3, akkor csak az entity1 lesz visszaállítva. A 2. entitást a T3 nem erősítette meg a központi régióban. Csak akkor, ha a visszaállítási időbélyeg > T4, az entitás2 lesz visszaállítva. T1: Az ügyfél egy Dokumentum1 dokumentumot ír az USA keleti régiójába. (Mivel az USA keleti régiója a központi régió, az írás azonnal megerősítést nyer)
T2: Az ügyfél az USA nyugati régiójába ír egy Dokumentum2 dokumentumot. T3: Az USA nyugati régiója elküldi a Doc2-t az USA keleti régiójába megerősítés céljából. T4: Az USA keleti régiója megkapja a Doc2-t, megerősíti a dokumentumot, és visszaküldi a Doc2-t az USA nyugati régiójába. T5: Az USA nyugati régiója megkapja a megerősített Doc2-t.

Ebben az esetben, ha a megadott visszaállítási időbélyeg T3, akkor csak a Doc1 lesz visszaállítva. A Do2-t a központ nem erősítette meg a T3 által. Csak akkor, ha a visszaállítási időbélyeg > T4, a doc2 lesz visszaállítva.

Feljegyzés

A központi régióban a visszaállítás nyilvános előzetes verzióban támogatott.

Mi lesz visszaállítva egy új fiókba?

Állandó állapotban a forrásfiókon (beleértve az adatbázisokat, tárolókat és elemeket is) végrehajtott összes mutáció aszinkron módon, 100 másodpercen belül biztonsági másolatot készít. Ha az Azure Storage biztonsági mentési adathordozója le van kapcsolva vagy nem érhető el, a mutációk helyileg megmaradnak, amíg az adathordozó el nem érhető. Ezután a mutációk ki vannak ürítve, hogy megakadályozzák a helyreállítható műveletek megbízhatóságának elvesztését.

A kiosztott átviteli tárolókat, a megosztott átviteli adatbázist és a teljes fiókot bármilyen kombinációban visszaállíthatja. A visszaállítási művelet visszaállítja az összes adatot és az indextulajdonságokat egy új fiókba. A visszaállítási folyamat biztosítja, hogy egy fiókban, adatbázisban vagy tárolóban visszaállított összes adat konzisztens legyen a megadott visszaállítási időpontig. A visszaállítás időtartama a visszaállítandó adatok mennyiségétől függ. Az újonnan visszaállított adatbázisfiók konzisztenciabeállítása megegyezik a forrásadatbázis-fiók konzisztenciabeállításával.

Feljegyzés

A folyamatos biztonsági mentési móddal a biztonsági mentések minden olyan régióban készülnek, ahol az Azure Cosmos DB-fiók elérhető. Az egyes régiófiókok biztonsági másolatai alapértelmezés szerint helyileg redundánsak, és zónaredundánsak, ha a fiók rendelkezésre állási zónája engedélyezve van az adott régióban. A visszaállítási művelet mindig új fiókba állítja vissza az adatokat.

Mi nem állítható vissza?

Az időponthoz kötött helyreállítás után a következő konfigurációk nem állíthatók vissza:

• A megosztott átviteli sebesség adatbázisában lévő tárolók egy részhalmaza nem állítható vissza. A teljes adatbázis teljes egészében visszaállítható.
• Tűzfal, virtuális hálózati virtuális hálózat, adatsík szerepköralapú hozzáférés-vezérlési RBAC vagy privát végpont beállításai.
• A forrásfiók összes régiója.
• Tárolt eljárások, eseményindítók, UDF-ek.
• Szerepköralapú hozzáférés-vezérlési hozzárendelések.

Ezeket a konfigurációkat a visszaállítás befejezése után hozzáadhatja a visszaállított fiókhoz.

Visszaállítható időbélyeg élő fiókokhoz

A nem törölt Azure Cosmos DB élő fiókok visszaállításához ajánlott mindig azonosítani a tároló legújabb visszaállítható időbélyegét . Ezt az időbélyeget használva visszaállíthatja a fiókot a legújabb verzióra.

Visszaállítási forgatókönyvek

Az időponthoz kötött visszaállítás funkció a következő forgatókönyveket támogatja. Az [1] és a [3] közötti forgatókönyvek bemutatják, hogyan indítható el visszaállítás, ha a visszaállítási időbélyeg előre ismert. Lehetnek azonban olyan esetek, amikor nem tudja pontosan a véletlen törlés vagy sérülés időpontját. A [4] és az [5] forgatókönyvek bemutatják, hogyan deríthető fel a visszaállítási időbélyeg az új eseménycsatorna API-jaival a visszaállítható adatbázison vagy tárolókon.

1. Törölt fiók visszaállítása – A visszaállítható összes törölt fiók látható a Visszaállítás panelen. Ha például az A fiókot a T3 időbélyegben törlik. Ebben az esetben a T3 előtti időbélyeg, a hely, a célfiók neve, az erőforráscsoport és a célfiók neve elegendő az Azure Portalról, a PowerShellből vagy a parancssori felületről való visszaállításhoz.

   

2. Fiók adatainak visszaállítása egy adott régióban – Például ha az A fiók az USA keleti régiójában és az USA nyugati régiójában található a T3 időbélyegen. Ha az USA nyugati régiójában az A fiók másolatára van szüksége, az Azure Portalról, a PowerShellből vagy a parancssori felületrőlis visszaállíthatja az időpontot, és célhelyként az USA nyugati régióját használhatja.

3. Helyreállítás egy tárolón belüli véletlen írási vagy törlési műveletből ismert visszaállítási időbélyeggel – Ha például tudja, hogy az 1. adatbázis 1. tárolójának tartalma véletlenül módosult a T3 időbélyeggel. Az Azure Portalról, a PowerShellből vagy a parancssori felületről egy időponthoz kötött visszaállítást végezhet egy másik fiókba a T3 időbélyegen a tároló kívánt állapotának helyreállításához.

4. Fiók visszaállítása egy korábbi időpontra az adatbázis véletlen törlése előtt – Az Azure Portalon az eseménycsatorna panelen meghatározhatja, hogy mikor törölték az adatbázist, és megkeresheti a visszaállítási időt. Az Azure CLI-vel és a PowerShell-lel hasonlóképpen felfedezheti az adatbázis-törlési eseményt az adatbázis eseménycsatornájának számbavételével, majd aktiválhatja a visszaállítási parancsot a szükséges paraméterekkel.

5. A fiók visszaállítása egy korábbi időpontra a tároló tulajdonságainak véletlen törlése vagy módosítása előtt. – Az Azure Portalon az eseménycsatorna panel használatával meghatározhatja, hogy mikor lett létrehozva, módosítva vagy törölve egy tároló a visszaállítási idő megkereséséhez. Hasonlóképpen, az Azure CLI és a PowerShell használatával az összes tárolóeseményt felderítheti a tárolóesemény-hírcsatorna számbavételével, majd aktiválhatja a visszaállítási parancsot a szükséges paraméterekkel.

Engedélyek

Az Azure Cosmos DB lehetővé teszi a folyamatos biztonsági mentési fiók visszaállítási engedélyeinek elkülönítését és korlátozását egy adott szerepkörre vagy egyszerű fiókra. További információért tekintse meg az Engedélyek című cikket.

Díjszabás

A folyamatos, 30 napos biztonsági mentéssel rendelkező Azure Cosmos DB-fiók havi díjat számít fel a biztonsági mentés tárolásához. A 30 napos és a 7 napos folyamatos visszalépési szint is díjakat von maga után az adatok visszaállításához. A visszaállítási költség minden alkalommal hozzáadódik, amikor a visszaállítási műveletet elindítják. Ha folyamatos biztonsági mentéssel konfigurál egy fiókot, de nem állítja vissza az adatokat, csak a biztonsági mentés tárolási költségeit tartalmazza a számla.

Az alábbi példa az USA nyugati régiójában üzembe helyezett Azure Cosmos DB-fiók árán alapul. A díjszabás és a számítás a használt régiótól függően változhat. A legfrissebb díjszabási információkért tekintse meg az Azure Cosmos DB díjszabási oldalát .

• A 30 napos folyamatos biztonsági mentési szabályzattal engedélyezett összes fiók havi díjat számít fel a biztonsági mentési tárterületért, amely az alábbiak szerint van kiszámítva:

  0,20 USD/GB * Adatméret GB-ban a fiókban * Régiók száma

• Minden visszaállítási API-hívás egyszeri díjat von maga után. A díj a visszaállított adatok mennyiségének függvénye:

  0,15 USD/GB * Adatméret GB-ban.

Ha például két régióban 1 TB adat található, akkor:

• A biztonsági mentés tárolási költségeinek kiszámítása a következőképpen történik: (1000 * 0,20 * 2) = 400 USD havonta

• A visszaállítás költsége (1000 * 0,15) = 150 USD visszaállításonként

Tipp.

Az Azure Cosmos DB-fiók aktuális adathasználatának méréséről további információt az Azure Monitor Azure Cosmos DB-elemzések felfedezése című témakörben talál. A folyamatos 7 napos szint nem jár díjakkal az adatok biztonsági mentéséért.

Folyamatos 30 napos szint és folyamatos 7 napos szint

• Az egyik szint megőrzési ideje 30 nap és egy másik szint esetében 7 nap.
• A biztonsági mentési tárterületért 30 napos megőrzési szintet kell fizetni. A 7 napos megőrzési szint nem kerül felszámításra.
• A visszaállítás minden esetben mindkét szinten díjköteles

Felhasználó által kezelt kulcsok

További információ: Hogyan befolyásolják az ügyfél által felügyelt kulcsok a folyamatos biztonsági mentéseket?

• Az Azure Cosmos DB-fiók konfigurálása ügyfél által felügyelt kulcsok folyamatos biztonsági mentéssel történő használatakor.
• Hogyan befolyásolják az ügyfél által felügyelt kulcsok a visszaállításokat?

Jelenlegi korlátozások

Az időponthoz kötött visszaállítási funkció jelenleg a következő korlátozásokkal rendelkezik:

• Az SQL, a MongoDB, a Gremlin és a Table azure Cosmos DB API-jai a folyamatos biztonsági mentéshez támogatottak. A Cassandra API jelenleg nem támogatott.

• Az Azure Synapse Link jelenleg folyamatos biztonsági mentési adatbázisfiókokban engedélyezhető. Az ellenkező helyzet azonban még nem támogatott, a Synapse Link-kompatibilis adatbázisfiókokban nem lehet bekapcsolni a folyamatos biztonsági mentést. Az elemzési tár nem szerepel a biztonsági másolatokban. A biztonsági mentésről és az elemzési tárról további információt az elemzési tár biztonsági mentésében talál.

• A visszaállított fiók ugyanabban a régióban jön létre, ahol a forrásfiók található. Nem állíthat vissza fiókot olyan régióba, ahol a forrásfiók nem létezett.

• A visszaállítási időszak csak 30 nap folyamatos 30 napos szint esetén, a folyamatos 7 napos szint esetén pedig hét nap. Ezek a szintek válthatók, de a tényleges mennyiségek (7 vagy 30) nem módosíthatók. Továbbá, ha a 30 napos szintről a 7 napos szintre vált, az adatvesztés a hetediket követő napokon is fennállhat.

• A biztonsági másolatok nem automatikusan georeduktúra-rezisztensek. A fiók és a biztonsági mentés rugalmassága érdekében explicit módon hozzá kell adni egy másik régiót.

• Amíg a visszaállítás folyamatban van, ne módosítsa vagy törölje az Identitás- és hozzáférés-kezelési (IAM-) szabályzatokat. Ezek a szabályzatok engedélyt adnak a fióknak a virtuális hálózatok, tűzfalkonfigurációk módosítására.

• A MongoDB-hez készült Azure Cosmos DB-fiókok folyamatos biztonsági mentéssel nem támogatják egy meglévő gyűjtemény egyedi indexének létrehozását. Ilyen fiók esetén egyedi indexeket kell létrehozni a gyűjteményükkel együtt; ez a gyűjteménybővítmény-parancsok létrehozásával végezhető el.

• Az időponthoz kötött visszaállítási funkció mindig egy új Azure Cosmos DB-fiókra áll vissza. A már meglévő fiókba történő visszaállítás jelenleg nem támogatott. Ha visszajelzést szeretne küldeni a helyszíni visszaállításról, lépjen kapcsolatba az Azure Cosmos DB csapatával a fiók képviselőjén keresztül.

• A visszaállítás után előfordulhat, hogy bizonyos gyűjtemények esetében a konzisztens index újraépíthető. Az újraépítési művelet állapotát az IndexTransformationProgress tulajdonságon keresztül ellenőrizheti.

• A visszaállítási folyamat alapértelmezés szerint visszaállítja egy tároló összes tulajdonságát, beleértve annak TTL-konfigurációját is. A visszaállítás során a TTL letiltása paramétert adhat meg. Ennek eredményeképpen előfordulhat, hogy a visszaállított adatok azonnal törlődnek, ha így konfigurálta. Ennek elkerülése érdekében a visszaállítási időbélyegnek korábbinak kell lennie a TTL-tulajdonságok tárolóba való felvételének időpontjánál.

• A MongoDB API-ban lévő egyedi indexek nem vehetők fel és nem frissíthetők folyamatos biztonsági mentési módú fiók létrehozásakor. Nem módosíthatók, ha egy fiókot időszakosról folyamatos módba migrál.

• Előfordulhat, hogy a folyamatos módú visszaállítás nem állítja vissza a visszaállítási ponttól érvényes átviteli sebességet.

Következő lépések

• Folyamatos biztonsági mentés engedélyezése az Azure Portal, a PowerShell, a parancssori felület vagy az Azure Resource Manager használatával.
• Szerezze be az SQL- és MongoDB-fiókok legújabb visszaállítható időbélyegét .
• Állítsa vissza a folyamatos biztonsági mentési fiókot az Azure Portal, a PowerShell, a parancssori felület vagy az Azure Resource Manager használatával.
• Migrálás egy fiókba rendszeres biztonsági mentésről folyamatos biztonsági mentésre.
• Az adatok folyamatos biztonsági mentési móddal történő visszaállításához szükséges engedélyek kezelése.
• A folyamatos biztonsági mentési mód erőforrásmodellje