Folyamatos biztonsági mentés időponthoz időben való visszaállítással a Azure Cosmos DB

A következőkre vonatkozik: SQL API Azure Cosmos db API a MongoDB

Azure Cosmos DB időponthoz időben történő visszaállítási funkciója több forgatókönyvben is segít, például a következőkben:

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

Azure Cosmos DB biztonsági mentést végez a háttérben anélkül, hogy további átviteli sebességet (RU-t) használ, vagy befolyásolná az adatbázis teljesítményét és rendelkezésre állását. A folyamatos biztonsági mentések minden olyan régióban meg vannak készítve, ahol a fiók létezik. Az alábbi kép bemutatja, hogy az USA nyugati régiójában található írási régióval és az USA 2. keleti régiójában található olvasási régiókról egy távoli Azure Blob Storage-fiókba van biztonságiolva a megfelelő 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, akkor a biztonsági másolat Zone-Redundant tárfiókban.

Azure Cosmos DB adatok biztonsági mentését az Azure Blob Storage.

A visszaállításhoz rendelkezésre álló időkeret (más néven megőrzési időtartam) a következő két érték alacsonyabb értéke: 30 nappal korábbi, mostantól vagy az erőforrás-létrehozási időpontig. A visszaállítási időpont bármilyen időbélyegző lehet a megőrzési időtartamon belül.

Jelenleg az SQL API vagy MongoDB tartalomponthoz használt Azure Cosmos DB-fiókot visszaállíthatja egy másik fiókba az Azure Portal,az Azure parancssori felület (az CLI), az Azure PowerShellvagy a Azure Resource Manager használatával.

Tárhely-redundancia biztonsági mentése

Alapértelmezés szerint a Azure Cosmos DB módú biztonsági mentési adatokat helyileg redundáns tárolóblobokban tárolja. A zónaredundanitával konfigurált régiók esetében a biztonsági mentés zónaredundáns tárolóblobban van tárolva. Folyamatos biztonsági mentési módban nem frissítheti a biztonsági mentési tárhely redundanciát.

Mi lesz visszaállítva?

Stabil állapotban a forrásfiókon (beleértve az adatbázisokat, tárolókat és elemeket) végrehajtott összes szinkronizációról 100 másodpercen belül a rendszer aszinkron módon biztonsági mentése történik. Ha a biztonsági mentési adathordozó (vagyis az Azure Storage) nem érhető el vagy nem érhető el, a rendszer helyben megmarad, amíg az adathordozó vissza nem érhető, majd ki nem üríti őket, hogy megelőzhető legyen a visszaállítható műveletek teljessége.

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.

Megjegyzés

A folyamatos biztonsági mentési móddal a biztonsági mentések minden olyan régióban meg vannak készítve, ahol Azure Cosmos DB fiók elérhető. Az egyes régiófiókok biztonsági mentései alapértelmezés szerint helyileg redundánsak, és zónaredundánsak, ha a fiókon engedélyezve van a rendelkezésre állási zóna funkció az egyes régiókhoz. A visszaállítási művelet mindig visszaállítja az adatokat egy új fiókba.

Mit nem érint a visszaállítás?

A következő konfigurációk nem állíthatók vissza az időponthoz időben való helyreállítás után:

  • Tűzfal, virtuális hálózat, privát végpont beállításai.
  • Konzisztenciabeállítások. Alapértelmezés szerint a fiók visszaállítása munkamenet-konzisztenciával történik.  
  • Régiók.
  • Tárolt eljárások, eseményindítók, TF-ek.

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

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

Az alábbiakban néhány olyan kulcsfontosságú forgatókönyvet mutatunk be, amelyekre az időponthoz való visszaállítási funkció kivesz lehetőséget. Az [a] és [c] között forgatókönyv bemutatja, hogyan indítható visszaállítás, ha a visszaállítás időbélyege előre ismert. Előfordulhatnak azonban olyan helyzetek, amikor nem ismeri a véletlen törlés vagy sérülés pontos idejét. A ([d] és [e] forgatókönyvek bemutatják, hogyan deríthető fel a visszaállítás időbélyege a visszaállítható adatbázis vagy tárolók új eseménycsatorna API-ival.

Visszaállítható fiók időbélyegekkel való életciklus-eseményei.

  1. Törölt fiók visszaállítása – Minden visszaállítható törölt fiók látható a Visszaállítás panelen. Ha például az A fiókot törlik a T3 időbélyegzővel. Ebben az esetben a T3 előtti időbélyegző, a hely, a célfiók neve, az erőforráscsoport és a célfiók neve elegendő a visszaállításhoz a Azure Portal, a PowerShellvagy a parancssori felülethasználatával.

Visszaállítható adatbázis és tároló időbélyegeit tartalmazó életciklus-események.

  1. Egy adott régióban található fiók adatainak visszaállítása – Ha például az A fiók két régióban található, az USA keleti régiója és az USA nyugati régiója a T3 időbélyegzővel. Ha szüksége van az A fiók másolatára az USA nyugati részén, akkor a célhelyként egy időponthoz Azure Portal, PowerShellvagy parancssori felület használatával, ahol az USA nyugati régiója található.

  2. 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élyegzővel – Ha például tudja, hogy az 1. tároló tartalma az 1. adatbázisban véletlenül módosult a T3 időbélyegzővel. A tároló kívánt állapotának helyreállításához a T3időbélyegzővel egy Azure Portal, a PowerShellbőlvagy a parancssori felületről egy másik fiókba is visszaállíthat egy adott időpontra vonatkozó visszaállítást.

  3. Fiók visszaállítása az adatbázis véletlen törlése előtti időpontra – A Azure Portal-benaz eseménycsatorna panelen megállapíthatja, hogy mikor lett törölve egy adatbázis, és megkeresheti a visszaállítási időt. Hasonlóképpen, az Azure CLI és a PowerShellhasználatával az adatbázis-eseménycsatorna számbavételével felderítheti az adatbázis-törlési eseményt, majd elindíthatja a visszaállítási parancsot a szükséges paraméterekkel.

  4. 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. - A Azure Portalaz eseménycsatorna panelen megállapíthatja, hogy mikor lett létrehozva, módosítva vagy törölve a visszaállítási idő megállapítása érdekében. Hasonlóképpen, az Azure CLI és a PowerShellhasználatával az összes tárolóeseményt felderítheti a tárolóesemények hírcsatornája számbavételével, majd a visszaállítási parancsot a szükséges paraméterekkel aktiválva.

Engedélyek

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 egy adott szerepkörre vagy rendszerbiztonsági tagra való korlátozását. A fiók tulajdonosa visszaállítást aktiválhat, és hozzárendelhet egy szerepkört más rendszerbiztonsági taghoz a visszaállítási művelet végrehajtásához. További tudnivalókért tekintse meg az Engedélyek cikket.

Árképzés

Azure Cosmos DB folyamatos biztonsági mentést engedélyező fiókok esetében a biztonsági másolat tárolása és az adatok visszaállítása további havi díjat fog fizetni. A visszaállítási költség a visszaállítási művelet minden elindításakor hozzáadódik. Ha folyamatos biztonsági mentéssel konfigurál egy fiókot, de nem állította vissza az adatokat, a számlán csak a biztonsági mentés tárolási költsége szerepel.

Az alábbi példa egy nem kormányzati régióban üzembe helyezett Azure Cosmos-fiók árát veszi alapul. A díjszabás és a számítás a használt régiótól függően változhat. A legújabb díjszabási információkért tekintse meg Azure Cosmos DB díjszabást.

  • A folyamatos biztonsági mentési szabályzat által engedélyezett összes fiók esetében további havi díj kerül fel a biztonsági mentési tárterületért, amely a következőképpen lesz kiszámítva:

    0,20 USD/GB * Fiók adatmérete GB-ban * Régiók száma

  • Minden visszaállítási API-híváshoz egy idődíjat kell fizetni. A díj az adat-visszaállítás mennyiségének függvénye, és a következőképpen számítható ki:

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

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

  • A biztonsági másolat tárolási költsége a következőképpen számítható ki: (1000 * 0,20 * 2) = 400 USD havonta

  • A visszaállítási költség számítása: (1000 * 0,15) = 150 USD visszaállításonként

Aktuális korlátozások

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

  • A folyamatos biztonsági mentés esetében kizárólag az SQL-hez és a MongoDB-hez készült Azure Cosmos DB API-k támogatottak. A Cassandra, Table és Gremlin API-k még nem támogatottak.

  • Az Azure szuverén és Azure Government felhőrégiói még nem támogatottak.

  • Ügyfél által felügyelt kulcsokkal rendelkező fiókok esetében a folyamatos biztonsági mentés nem támogatott.

  • A többrégiós írási fiókok nem támogatottak.

  • A Azure Synapse fiókok esetében az elemzésitár-adatok nem szerepelnek a biztonsági mentések és a visszaállítások között. Ha Synapse Link engedélyezve van, Azure Cosmos DB a rendszer továbbra is automatikusan biztonsági másolatot készít a tranzakciós tárolóban tárolt adatairól egy ütemezett biztonsági mentési időközzel. Az elemzési tárolóban található adatok automatikus biztonsági mentése és visszaállítása jelenleg nem támogatott.

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

  • A visszaállítási ablak csak 30 nap, és nem módosítható.

  • A biztonsági mentések nem védettek automatikusan a katasztrófákkal szemben. Explicit módon fel kell vennie egy másik régiót, hogy rugalmassá tegye a fiókot és a biztonsági mentést.

  • Amíg a visszaállítás folyamatban van, ne módosítsa vagy törölje azokat az identitás- és hozzáférés-kezelési (IAM-) szabályzatokat, amelyek megszabadják a fiók engedélyeit, vagy módosítják a VNET- és tűzfalkonfigurációkat.

  • Azok az SQL-hez vagy MongoDB-hez készült Azure Cosmos DB API-fiókok, amelyek a tároló létrehozása után egyedi indexet hoznak létre, nem támogatottak a folyamatos biztonsági mentés esetében. Csak olyan tárolók támogatottak, amelyek a tároló kezdeti létrehozásának részeként hoznak létre egyedi indexet. MongoDB-fiókok esetében a bővítményparancsok használatával hozhat létre egyedi indexet.

  • Az időponthoz kötött visszaállítási funkció esetében a visszaállítás mindig új Azure Cosmos-fiókba történik. 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 helyi visszaállításról, lépjen kapcsolatba a Azure Cosmos DB a fiók képviselőjével.

  • A visszaállítás után előfordulhat, hogy bizonyos gyűjtemények esetében a konzisztens index újraépíti az indexet. Az újraépítési művelet állapotát az IndexTransformationProgress tulajdonság segítségével ellenőrizheti.

  • Az újjáépítési művelet visszaállítja a tároló összes tulajdonságát, beleértve az élettartam (TTL) konfigurációját is. Ennek következtében előfordulhat, hogy a visszaállított adatok azonnal törlődnek, ha Ön ú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-jában az egyedi indexek nem adhatóak hozzá vagy nem frissíthetők, ha folyamatos biztonsági mentési módú fiókot hoz létre, vagy rendszeres időközönkénti módból folyamatos módba milegál egy fiókot.

Következő lépések