Průběžné zálohování s obnovením k určitému bodu v čase ve službě Azure Cosmos DB

PLATÍ PRO: NoSQL MongoDB Gremlin Tabulka

Funkce obnovení k určitému bodu v čase ve službě Azure Cosmos DB pomáhá ve více scénářích, mezi které patří:

  • Obnovení z náhodné operace zápisu nebo odstranění v rámci kontejneru
  • Obnovení odstraněného účtu, databáze nebo kontejneru
  • Obnovení do libovolné oblasti (kde existovaly zálohy) v bodu obnovení v čase.

Azure Cosmos DB provádí zálohování dat na pozadí, aniž by spotřebovává dodatečnou zřízenou propustnost (RU) nebo ovlivnila výkon a dostupnost vaší databáze. Průběžné zálohy se provádějí v každé oblasti, ve které účet existuje. Účet může mít například oblast zápisu v oblasti USA – západ a číst oblasti v oblasti USA – východ a USA – východ 2. Tyto oblasti repliky je pak možné zálohovat do vzdáleného účtu služby Azure Storage v každé příslušné oblasti. Ve výchozím nastavení každá oblast ukládá zálohování do místně redundantních účtů úložiště. Pokud má tato oblast povolené zóny dostupnosti, záloha se uloží v účtech zónově redundantního úložiště.

Diagram znázorňující způsob zálohování kontejneru napříč několika oblastmi

Časové období dostupné pro obnovení (označované také jako doba uchovávání) je nižší hodnota následujících dvou možností: 30denní a 7denní.

Vybraná možnost závisí na zvolené úrovni průběžného zálohování. Bod v čase pro obnovení může být libovolné časové razítko v období uchovávání informací, a to až po vytvoření prostředku. V režimu silné konzistence jsou zálohy pořízené v oblasti zápisu v porovnání s oblastmi čtení aktuální. Oblasti čtení můžou zpožďovat kvůli síťovým nebo jiným přechodným problémům. Při obnovování můžete získat nejnovější obnovitelné časové razítko pro daný prostředek v konkrétní oblasti. Odkazování na nejnovější obnovovatelné časové razítko pomáhá potvrdit, že zálohy prostředků jsou v daném časovém razítku a můžou se v této oblasti obnovit.

V současné době můžete obnovit obsah účtu služby Azure Cosmos DB (API pro NoSQL nebo MongoDB, rozhraní API pro tabulky, rozhraní API pro Gremlin) v určitém časovém okamžiku do jiného účtu. Tuto operaci obnovení můžete provést prostřednictvím webu Azure Portal, Azure CLI (Azure CLI), Azure PowerShellu nebo šablon Azure Resource Manageru.

Redundance úložiště zálohování

Azure Cosmos DB ve výchozím nastavení ukládá data průběžného zálohování v místně redundantních objektech blob úložiště. Pro oblasti, které mají nakonfigurovanou redundanci zóny, se záloha ukládá v zónově redundantních objektech blob úložiště. V režimu průběžného zálohování nemůžete aktualizovat redundanci úložiště zálohování.

Různé způsoby obnovení

Režim průběžného zálohování podporuje dva způsoby obnovení odstraněných kontejnerů a databází. Můžete je obnovit do nového účtu , jak je popsáno tady, nebo je můžete obnovit do existujícího účtu, jak je popsáno tady. Volba mezi těmito dvěma režimy závisí na scénářích. Ve většině případů je vhodnější obnovit odstraněné kontejnery a databáze do existujícího účtu. Tím se vyhnete nákladům na přenos dat, které se vyžadují v případě, že se obnoví na nový účet. Pro scénář, kdy byla provedena náhodná úprava dat, může být upřednostňovanou možností obnovení do nového účtu.

Obnovení účtu zápisu do více oblastí (Preview)

Všechny zápisy prováděné v oblasti centra se okamžitě potvrdí a zazálohují asynchronně během 100 sekund. Do oblasti centra se za účelem potvrzení odesílají mutace prováděné na satelitní oblasti (oblast řešení konfliktů). Oblast centra zkontroluje, jestli je potřeba nějaké řešení konfliktů, a po vyřešení konfliktů přiřadí časové razítko vyřešené konfliktem a odešle zpět do satelitní oblasti. Satelitní oblast zálohuje entity pouze po přijetí potvrzení z oblasti centra.
Proces obnovení obnoví pouze entity, které jsou potvrzeny časovým razítkem řešení konfliktů z oblasti centra.

Poznámka:

Další informace o účtech více oblastí zápisu najdete tady, oblast centra je první oblastí na portálu.

Co se neobnoví pro obnovení účtu zápisu do více oblastí (Preview)?

Muty, které ještě nejsou potvrzeny časovým razítkem obnovení, se neobnoví. Kolekce s vlastní zásadou řešení konfliktů se resetují na základě časového razítka posledního zapisovače.

Příklad: Vzhledem k účtu oblasti s více zápisy se dvěma oblastmi – usa – východ a USA – západ, z nichž usa – východ je oblast centra, zvažte následující posloupnost událostí:

Pokud je v tomto scénáři časové razítko obnovení T3, obnoví se pouze entita 1. Entita Entity2 nebyla potvrzena oblastí centra podle T3. Pouze pokud časové razítko > obnovení T4, entita2 bude obnovena. T1: Klient zapíše dokument Doc1 do USA – východ. (Vzhledem k tomu, že USA – východ je oblast centra, zápis se okamžitě potvrdí)
T2: Klient zapíše dokument Doc2 do usa – západ. T3: USA – západ odešle dokument č. 2 do USA – východ s žádostí o potvrzení. T4: Usa – východ obdrží dokument Doc2, potvrdí dokument a odešle dokument zpět do oblasti USA – západ. T5: Usa – západ obdrží potvrzený dokument 2.

Pokud je v tomto scénáři zadané časové razítko obnovení T3, obnoví se pouze Doc1. Doc2 nebylo potvrzeno centrem T3. Pouze pokud se obnoví časové razítko > obnovení T4, dokument2 se obnoví.

Poznámka:

Obnovení v oblasti centra je podporováno ve verzi Public Preview.

Co se obnoví do nového účtu?

V stabilním stavu se všechny mutací prováděné na zdrojovém účtu (včetně databází, kontejnerů a položek) zálohují asynchronně během 100 sekund. Pokud je záložní médium Azure Storage mimo provoz nebo je nedostupné, místně se mutaci uchovávají, dokud nebude k dispozici médium. Pak se muty vyprázdní, aby se zabránilo ztrátě věrnosti operací, které lze obnovit.

Můžete obnovit jakoukoli kombinaci kontejnerů se zřízenou propustností a databází se sdílenou propustností nebo celý účet. Akce obnovení provede obnovení všech dat a vlastností indexu do nového účtu. Proces obnovení zajišťuje konzistenci všech obnovených dat v účtu, databázi nebo kontejneru až do zadané doby obnovení. Doba potřebná k obnovení závisí na objemu dat, která je potřeba obnovit. Nastavení konzistence nově obnoveného databázového účtu bude stejné jako nastavení konzistence zdrojového databázového účtu.

Poznámka:

V režimu průběžného zálohování se zálohy provádějí v každé oblasti, ve které je váš účet Azure Cosmos DB dostupný. Zálohy pořízené pro každý účet oblasti jsou ve výchozím nastavení místně redundantní a zónově redundantní, pokud má váš účet pro danou oblast povolenou funkci zóny dostupnosti. Akce obnovení vždy obnoví data do nového účtu.

Co se neobnoví?

Po obnovení k určitému bodu v čase se neobnoví následující konfigurace:

  • Podmnožinu kontejnerů v databázi se sdílenou propustností nejde obnovit. Celou databázi je možné obnovit jako celek.
  • Brána firewall, virtuální síť virtuální sítě, řízení přístupu na základě role nebo nastavení privátního koncového bodu.
  • Všechny oblasti ze zdrojového účtu.
  • Uložené procedury, triggery, funkce definované uživatelem.
  • Přiřazení řízení přístupu na základě role

Tyto konfigurace můžete přidat do obnoveného účtu po dokončení obnovení.

Obnovitelné časové razítko pro živé účty

Pokud chcete obnovit živé účty Azure Cosmos DB, které se neodstraní, doporučujeme vždy identifikovat nejnovější obnovovatelné časové razítko kontejneru. Toto časové razítko pak můžete použít k obnovení účtu na nejnovější verzi.

Scénáře obnovení

Funkce obnovení k určitému bodu v čase podporuje následující scénáře. Scénáře [1] až [3] ukazují, jak aktivovat obnovení, pokud je časové razítko obnovení známé předem. Existují však scénáře, kdy neznáte přesný čas náhodného odstranění nebo poškození. Scénáře [4] a [5] ukazují, jak zjistit časové razítko obnovení pomocí nového rozhraní API kanálu událostí v obnovitelné databázi nebo kontejnerech.

Události životního cyklu s časovými razítky pro obnovitelný účet

  1. Obnovit odstraněný účet – Všechny odstraněné účty, které můžete obnovit, jsou viditelné v podokně Obnovit . Pokud je například účet A odstraněn v časovém razítku T3. V takovém případě časové razítko těsně před T3, umístěním, názvem cílového účtu, skupinou prostředků a názvem cílového účtu stačí k obnovení z webu Azure Portal, PowerShellu nebo rozhraní příkazového řádku.

    Události životního cyklu s časovými razítky pro obnovitelnou databázi a kontejner

  2. Obnovte data účtu v konkrétní oblasti – například pokud účet A existuje ve dvou oblastech USA – východ a USA – západ v časovém razítku T3. Pokud potřebujete kopii účtu A v oblasti USA – západ, můžete provést obnovení k určitému bodu v čase z webu Azure Portal, PowerShellu nebo rozhraní příkazového řádku s oblastí USA – západ jako cílovým umístěním.

  3. Obnovení z náhodné operace zápisu nebo odstranění v kontejneru se známým časovým razítkem obnovení – například pokud víte, že obsah kontejneru 1 v databázi 1 byl omylem změněn v časovém razítku T3. Obnovení k určitému bodu v čase můžete provést z webu Azure Portal, PowerShellu nebo rozhraní příkazového řádku do jiného účtu v časovém razítku T3 a obnovit požadovaný stav kontejneru.

  4. Obnovení účtu k určitému bodu v čase před náhodným odstraněním databáze – Na webu Azure Portal můžete pomocí podokna informačního kanálu událostí určit, kdy byla databáze odstraněna, a zjistit čas obnovení. Podobně můžete pomocí Azure CLI a PowerShellu zjistit událost odstranění databáze tak, že vyčíslíte informační kanál událostí databáze a pak aktivujete příkaz restore s požadovanými parametry.

  5. Obnovte účet k určitému bodu v čase před náhodným odstraněním nebo úpravou vlastností kontejneru. – Na webu Azure Portal můžete pomocí podokna informačního kanálu událostí určit, kdy byl kontejner vytvořen, změněn nebo odstraněn, a zjistit čas obnovení. Podobně můžete pomocí Azure CLI a PowerShellu zjistit všechny události kontejneru tak, že vyčíslíte kanál událostí kontejneru a pak aktivujete příkaz restore s požadovanými parametry.

Oprávnění

Azure Cosmos DB umožňuje izolovat a omezit oprávnění k obnovení účtu průběžného zálohování na konkrétní roli nebo objekt zabezpečení. Další informace najdete v článku Oprávnění .

Ceny

Účet služby Azure Cosmos DB s průběžným 30denním zálohováním má měsíční poplatek za uložení zálohy. 30denní i 7denní úroveň průběžného obnovení se účtují poplatky za obnovení dat. Náklady na obnovení se přidají při každém zahájení operace obnovení. Pokud nakonfigurujete účet s průběžným zálohováním, ale data neobnovíte, budou na faktuře zahrnuty pouze náklady na úložiště zálohování.

Následující příklad vychází z ceny účtu služby Azure Cosmos DB nasazeného v oblasti USA – západ. Ceny a výpočty se můžou lišit v závislosti na používané oblasti. Nejnovější informace o cenách najdete na stránce s cenami služby Azure Cosmos DB.

  • Za všechny účty povolené zásady průběžného zálohování s 30denními platbami se účtují měsíční poplatky za úložiště zálohování, které se vypočítá takto:

    $0,20/GB * Velikost dat v GB v účtu * Počet oblastí

  • Při každém vyvolání rozhraní API pro obnovení se účtuje jednorázové poplatky. Poplatek je funkce množství obnovených dat:

    $0,15/GB * Velikost dat v GB.

Pokud máte například 1 TB dat ve dvou oblastech, pak:

  • Náklady na úložiště zálohování se počítají jako (1000 × 0,20 × 2) = 400 USD za měsíc

  • Náklady na obnovení se počítají jako (1000 × 0,15) = 150 USD na obnovení.

Tip

Další informace o měření aktuálního využití dat účtu služby Azure Cosmos DB najdete v tématu Prozkoumání přehledů služby Azure Cosmos DB služby Azure Monitor. Průběžná 7denní úroveň neúčtuje poplatky za zálohování dat.

Nepřetržitá 30denní úroveň vs. průběžná 7denní úroveň

  • Doba uchovávání pro jednu úroveň je 30 dnů vs. 7 dnů pro jinou úroveň.
  • 30denní úroveň uchovávání se účtuje za úložiště zálohování. 7denní úroveň uchovávání se neúčtuje.
  • Obnovení se vždy účtuje v obou úrovních.

Klíče spravované zákazníkem

Podívejte se, jak mají klíče spravované zákazníkem vliv na průběžné zálohování?

  • Jak nakonfigurovat účet služby Azure Cosmos DB při používání klíčů spravovaných zákazníkem s průběžnými zálohami.
  • Jak mají klíče spravované zákazníkem vliv na obnovení?

Aktuální omezení

V současné době má funkce obnovení k určitému bodu v čase následující omezení:

  • Rozhraní API služby Azure Cosmos DB pro SQL, MongoDB, Gremlin a Tabulku podporovaná pro průběžné zálohování Rozhraní API pro Cassandra se teď nepodporuje.

  • V současné době je možné službu Azure Synapse Link povolit v účtech databáze průběžného zálohování. Opačná situace se ale zatím nepodporuje, není možné zapnout průběžné zálohování v účtech databáze s podporou Synapse Linku. A analytické úložiště není součástí záloh. Další informace o zálohování a analytickém úložišti najdete v tématu Zálohování analytického úložiště.

  • Obnovený účet se vytvoří ve stejné oblasti, ve které se nacházel zdrojový účet. Nemůžete obnovit účet do oblasti, ve které zdrojový účet neexistoval.

  • Okno obnovení je pouze 30 dnů pro nepřetržitou 30denní úroveň a sedm dní pro nepřetržitou 7denní úroveň. Tyto úrovně je možné přepínat, ale skutečné množství (7 nebo 30) nelze změnit. Pokud navíc přepnete z 30denní vrstvy na 7denní úroveň, může dojít ke ztrátě dat ve dnech nad sedmou úrovní.

  • Zálohy nejsou automaticky odolné vůči geografické havárii. Pro odolnost účtu a zálohování by se měla explicitně přidat jiná oblast.

  • Během obnovení neupravujte ani neodstraňovat zásady správy identit a přístupu (IAM). Tyto zásady udělují oprávnění účtu ke změně jakékoli virtuální sítě, konfigurace brány firewall.

  • Účty Azure Cosmos DB pro MongoDB s průběžným zálohováním nepodporují vytvoření jedinečného indexu pro existující kolekci. Pro takový účet musí být vytvořeny jedinečné indexy společně s jejich kolekcí; můžete ho provést pomocí příkazů pro vytvoření rozšíření kolekce.

  • Funkce obnovení k určitému bodu v čase se vždy obnoví do nového účtu služby Azure Cosmos DB. Obnovení do existujícího účtu se v současné době nepodporuje. Pokud chcete poskytnout zpětnou vazbu k místní obnově, obraťte se na tým služby Azure Cosmos DB prostřednictvím zástupce vašeho účtu.

  • Po obnovení je možné, že u některých kolekcí se konzistentní index může znovu sestavit. Stav operace opětovného sestavení můžete zkontrolovat pomocí vlastnosti IndexTransformationProgress .

  • Proces obnovení obnoví všechny vlastnosti kontejneru, včetně jeho konfigurace TTL ve výchozím nastavení, můžete předat parametr, který zakáže hodnotu TTL při obnovení. V důsledku toho je možné, že se obnovená data okamžitě odstraní, pokud jste to nakonfigurovali. Pokud chcete této situaci zabránit, časové razítko obnovení musí předcházet přidání vlastností TTL do kontejneru.

  • Jedinečné indexy v rozhraní API pro MongoDB nejde přidat ani aktualizovat při vytváření účtu režimu průběžného zálohování. Při migraci účtu z pravidelného do průběžného režimu je také nejde upravit.

  • Obnovení průběžného režimu nemusí obnovit nastavení propustnosti platné pro bod obnovení.

Další kroky