Zálohování a obnovení ve službě Azure Database for MySQL

Flexibilní server Azure Database for MySQL automaticky vytváří zálohy serverů a bezpečně je ukládá do místního redundantního úložiště v rámci oblasti. Pomocí záloh obnovte server k určitému bodu v čase. Zálohování a obnovení jsou základní části jakékoli strategie provozní kontinuity, protože chrání vaše data před náhodným poškozením nebo odstraněním.

Přehled služby Backup

Flexibilní server Azure Database for MySQL podporuje dva typy záloh, které poskytují vylepšenou flexibilitu při údržbě záloh důležitých obchodních dat.

Automatizované zálohování

Flexibilní server Azure Database for MySQL vytváří zálohy snímků datových souborů a ukládá je do místního redundantního úložiště. Server také zálohuje transakční protokoly a ukládá je do místního redundantního úložiště. Tyto zálohy umožňují obnovit server k jakémukoli bodu v čase v rámci nakonfigurované doby uchovávání záloh. Výchozí doba uchovávání záloh je sedm dnů. Volitelně můžete nakonfigurovat zálohování databáze od 1 do 35 dnů. Všechny zálohy používají 256bitové šifrování AES pro neaktivní uložená data.

Zálohování na vyžádání

Kromě automatizovaných záloh umožňuje flexibilní server Azure Database for MySQL aktivovat zálohy produkční úlohy na vyžádání a uložit je v souladu se zásadami uchovávání záloh serveru. Tyto zálohy použijte jako nejrychlejší bod obnovení k provedení obnovení k určitému bodu v čase a zkrácení doby obnovení až o 90%. Výchozí doba uchovávání záloh je sedm dnů. Volitelně můžete nakonfigurovat zálohování databáze od 1 do 35 dnů. Z portálu můžete aktivovat celkem 50 záloh na vyžádání. Všechny zálohy používají 256bitové šifrování AES pro neaktivní uložená data.

Tyto záložní soubory nelze exportovat. Zálohy můžete použít pouze pro operace obnovení na flexibilním serveru Azure Database for MySQL. Ke kopírování databáze můžete také použít mysqldump z klienta MySQL.

Frekvence zálohování

Záložní kopie na flexibilních serverech používají snímky (snapshots). První zálohování snímků se naplánuje hned po vytvoření serveru. Systém vytváří zálohy snímků jednou denně. Zálohování transakčních protokolů probíhá každých pět minut.

Pokud naplánované zálohování selže, služba zálohování se pokusí provést zálohování každých 20 minut, dokud nebude úspěšná. Velké transakční produkční zatížení instance serveru může způsobit tyto selhání zálohování.

Pokud chcete zvýšit frekvenci automatizovaných denních záloh, zvyšte interval zálohování. Tato změna je užitečná zejména v případě, že očekáváte velké transakce, protože výrazně zkracuje dobu obnovení snížením počtu binlogů, které je potřeba přehrát během operace obnovení k určitému bodu v čase. V typickém procesu obnovení k určitému bodu v čase systém nejprve obnoví data z nejbližšího úplného snímku (pořízeného denně) a pak znovu přehraje binární protokoly (zachycené každých pět minut), aby dosáhl přesné doby obnovení. Pokud je čas cílového obnovení daleko od snímku, je potřeba přehrát velký počet binlogů, což může výrazně zvýšit dobu obnovení. Tato nová funkce optimalizuje proces tím, že zavádí častější snímky, což snižuje počet binlogů, které je potřeba přehrát, a minimalizuje celkovou dobu obnovení.

Součástí této funkce je také nová logika oříznutí zálohování snímků, která pomáhá efektivněji spravovat zálohy tím, že uchovává všechny snímky za posledních 24 hodin a pouze jeden snímek za den pro starší zálohy. Tato logika zajišťuje maximální flexibilitu a pokrytí pro nedávné operace okamžité obnovy (PITR). Zároveň pomáhá optimalizovat náklady na zálohování tím, že zajistí, že zvýšení frekvence snímků výrazně nezvýší celkové náklady na úložiště zálohování, i když nastavíte interval zálohování na jinou hodnotu než 24 hodin.

Pokud chcete změnit interval zálohování, přejděte na Nastavení > výpočetních prostředků a úložiště a nastavte pole Interval zálohování . Výchozí interval je 24 hodin, ale můžete ho změnit na 12 nebo 6 hodin.

Poznámka:

• Pokud na serveru dochází k vysokému zatížení transakcí, což vede k větším a rychlejším souborům binlogu, služba zálohování provádí více záloh za den, aby se zajistilo spolehlivé a rychlejší obnovení pomocí těchto záloh.
• U 5.7 serverů může dlouhotrvající nebo velké transakce zabránit získání zámku na úrovni globální instance, což je vyžadováno pro úspěšné denní zálohování. V takových scénářích může denní zálohování selhat. Pokud chcete tento problém vyřešit, ukončete dlouhotrvající transakci nebo restartujte server. Pokud chcete zajistit plynulejší provoz, upgradujte servery MySQL 5.7 na verzi 8.0 pomocí upgradu hlavní verze.

možnosti redundantního zálohování

Flexibilní server Azure Database for MySQL ukládá několik kopií záloh, aby vaše data byla chráněna před plánovanými a neplánovanými událostmi. Mezi tyto události patří přechodné selhání hardwaru, výpadky sítě nebo napájení a masivní přírodní katastrofy. Flexibilní server Azure Database for MySQL nabízí flexibilitu při výběru mezi místně redundantním, zónově redundantním nebo geograficky redundantním úložištěm zálohování v úrovních Basic, General Purpose a Memory-Optimized. Flexibilní server Azure Database for MySQL ve výchozím nastavení používá místně redundantní úložiště zálohování pro servery s vysokou dostupností se stejnou zónou nebo bez konfigurace vysoké dostupnosti a pro servery s zónově redundantní konfigurací vysoké dostupnosti používá zónově redundantní úložiště zálohování.

Redundance zálohování zajišťuje, aby vaše databáze splňovala cíle dostupnosti a stálosti i v případě selhání. Flexibilní server Azure Database for MySQL nabízí tři možnosti:

• Místně redundantní úložiště zálohování : Pokud používáte místně redundantní úložiště zálohování, systém ukládá více kopií záloh ve stejném datacentru. Tato možnost chrání vaše data před selháním serverového racku (stojanu) a disku. Poskytuje také alespoň 99,999999999999% (11 9) odolnosti objektů Backups za daný rok. Ve výchozím nastavení je úložiště zálohování pro servery s vysokou dostupností (HA) ve stejné zóně nebo bez konfigurace vysoké dostupnosti nastaveno na místně redundantní.

• Zónově redundantní úložiště zálohování : Pokud používáte zónově redundantní úložiště zálohování, systém ukládá více kopií v rámci zóny dostupnosti, ve které je váš server hostovaný. Také replikuje zálohy do jiné zóny dostupnosti ve stejné oblasti. Tuto možnost použijte pro scénáře, které vyžadují vysokou dostupnost nebo omezení replikace dat do určité země nebo oblasti, aby splňovaly požadavky na rezidenci dat. Poskytuje alespoň 99,9999999999999% (12 9) odolnosti objektů Backups za daný rok. Vyberte možnost Zone-Redundant Vysoká dostupnost při vytváření serveru, abyste zajistili zónově redundantní úložiště zálohování. Vysokou dostupnost serveru můžete po vytvoření zakázat, ale úložiště zálohování zůstává zónově redundantní.

• Geograficky redundantní úložiště zálohování : Pokud používáte geograficky redundantní úložiště zálohování, systém ukládá více kopií v rámci oblasti, ve které je váš server hostovaný. Replikuje také zálohy do geograficky spárované oblasti. Tato možnost poskytuje lepší ochranu a možnost obnovení serveru v jiné oblasti v případě havárie. Poskytuje alespoň 99,99999999999999999999% (16 9) stálost objektů Backups za daný rok. Při vytváření serveru můžete povolit možnost Geo-Redundancy, abyste zajistili geograficky redundantní úložiště zálohování. Kromě toho můžete po vytvoření serveru přejít z místně redundantního úložiště na geograficky redundantní úložiště. Geografická redundance je podporovaná pro servery hostované ve kterékoli ze spárovaných oblastí Azure.

Poznámka:

Možnost zónové redundance pro vysokou dostupnost, která podporuje redundanci zón, je aktuálně dostupná pouze při vytváření. V současné době můžete pro zónově redundantní server s vysokou dostupností povolit nebo zakázat geografickou redundanci pouze při vytváření serveru.

Přechod z jiných možností úložiště zálohování na geograficky redundantní úložiště zálohování

Pokud chcete přesunout stávající úložiště záloh do geograficky redundantního úložiště, použijte následující metody:

• Přechod z místně redundantního do geograficky redundantního úložiště zálohování – Pokud chcete přesunout úložiště záloh z místního redundantního úložiště do geograficky redundantního úložiště, změňte konfiguraci serveru Compute + Storage z webu Azure Portal, aby se povolila geografická redundance pro místně redundantní zdrojový server. Můžete také obnovit stejné zónově redundantní servery vysoké dostupnosti jako geograficky redundantní server podobným způsobem, jako je základní záložní úložiště místně redundantní pro stejné.

• Přechod z zónově redundantního úložiště na geograficky redundantní úložiště zálohování – Flexibilní server Azure Database for MySQL nepodporuje převod z zónově redundantního úložiště na geograficky redundantní úložiště prostřednictvím změny nastavení compute + úložiště po zřízení serveru. Pokud chcete přesunout úložiště záloh z zónově redundantního úložiště do geograficky redundantního úložiště, máte dvě možnosti: a) K obnovení serveru s požadovanou konfigurací použijte pitR (obnovení k určitému bodu v čase). b) Vytvořte nový server s požadovanou konfigurací a migrujte data pomocí výpisu a obnovení.

Uchování záloh

Nastavení doby uchovávání záloh serveru určuje, jak dlouho se mají uchovávat zálohy. Můžete vybrat dobu uchovávání od 1 do 35 dnů a výchozí doba uchovávání je sedm dnů. Nastavte dobu uchovávání během vytváření serveru nebo později aktualizací konfigurace zálohování na webu Azure Portal.

Doba uchovávání záloh určuje, jak daleko zpět může operace obnovení do určitého časového bodu přejít, protože vychází z dostupných záloh. Doba uchovávání záloh si také můžete představit jako časové okno pro obnovení z pohledu obnovy dat. Úložiště záloh uchovává všechny zálohy potřebné k obnovení k určitému bodu v čase během doby uchovávání záloh. Pokud například nastavíte dobu uchovávání záloh na sedm dnů, okno obnovení je posledních sedm dnů. V tomto scénáři si úložiště záloh uchovává všechny zálohy potřebné k obnovení serveru za posledních 7 dnů. V intervalu uchovávání záloh sedmi dnů se snímky databáze a zálohy transakčních protokolů ukládají po dobu posledních osmi dnů (jeden den před oknem).

Náklady na zálohovací úložiště

Flexibilní server Azure Database for MySQL poskytuje až 100% zřízeného úložiště serveru jako úložiště záloh bez dalších poplatků. Platíte za jakékoli další úložiště zálohování, které používáte v GB za měsíc. Pokud například zřídíte server s 250 GB úložiště, získáte 250 GB úložiště pro zálohování serverů bez dalších poplatků. Pokud je denní využití zálohování 25 GB, můžete mít až 10 dnů bezplatného úložiště zálohování. Platíte za úložiště spotřebované za zálohy, které podle cenového modelu překračují 250 GB.

Pokud chcete monitorovat úložiště zálohování spotřebované serverem, použijte metriku flexibilního serveru Azure Database for MySQL ve službě Azure Monitor dostupnou na webu Azure Portal. Použitá metrika Úložiště zálohování představuje součet úložiště spotřebovaného všemi zálohami databáze a zálohami protokolů, které se uchovávají na základě doby uchovávání záloh nastavené pro server. Silná transakční aktivita na serveru může způsobit zvýšení využití úložiště zálohování bez ohledu na celkovou velikost databáze. Úložiště zálohování používané pro geograficky redundantní server je dvojnásobné ve srovnání s úložištěm pro místně redundantní server.

Nastavte odpovídající dobu uchovávání záloh, abyste mohli řídit náklady na úložiště zálohování. Můžete vybrat dobu uchovávání mezi 1 a 35 dny.

Důležité

Primární databázový server zpracovává zálohy databázového serveru nakonfigurovaného v konfiguraci zónově redundantní vysoké dostupnosti. Primární server má při použití záloh snímků minimální režii.

Zobrazení dostupných úplných záloh

Stránka Zálohování a obnovení na webu Azure Portal poskytuje úplný seznam úplných záloh, které máte k dispozici v libovolném časovém okamžiku. Tento seznam obsahuje automatizované zálohy i zálohy na vyžádání. Tato stránka slouží k zobrazení časových razítek dokončení pro všechny dostupné úplné zálohy v rámci doby uchování serveru a k provádění operací obnovení pomocí těchto úplných záloh. Seznam dostupných záloh zahrnuje všechny úplné zálohy v rámci doby uchovávání, časové razítko, které ukazuje úspěšné dokončení, časové razítko, které označuje, jak dlouho se záloha uchovává, a akci obnovení.

Obnovení

Na flexibilním serveru Azure Database for MySQL se obnovením vytvoří nový server ze záloh původního serveru. K dispozici jsou dva typy obnovení:

• Obnovení k určitému časovému bodu: Je dostupné s jakoukoli možností redundance zálohování. Vytvoří nový server ve stejné oblasti jako původní server.
• Geografické obnovení: Dostupné pouze v případě, že jste server nakonfigurovali pro geograficky redundantní úložiště. Obnoví server do geograficky spárované oblasti nebo jakékoli jiné podporované oblasti Azure, kde je flexibilní server dostupný.

Odhadovaný čas obnovení serveru ovlivňuje několik faktorů:

• Velikost databází
• Počet zahrnutých transakčních protokolů
• Množství aktivity, kterou je potřeba přehrát k obnovení do obnovovacího bodu
• Šířka pásma sítě, pokud je obnovení v jiné oblasti
• Počet souběžných žádostí o obnovení zpracovávaných v cílové oblasti
• Přítomnost primárního klíče v tabulkách v databázi. Pro rychlejší obnovení zvažte přidání primárního klíče pro všechny tabulky v databázi.

Poznámka:

Po obnovení se server s funkcí vysoké dostupnosti stane serverem bez vysoké dostupnosti (vysoká dostupnost je deaktivována) pro obnovení k určitému okamžiku a geografické obnovení.

Obnovení k určitému bodu v čase

Když na flexibilním serveru Azure Database for MySQL provedete obnovení k určitému bodu v čase, vytvoříte nový server ze záloh flexibilního serveru ve stejné oblasti jako zdrojový server. Nový server má původní konfiguraci serveru pro výpočetní úroveň, počet virtuálních jader, velikost úložiště, dobu uchovávání záloh a možnost redundance zálohování. Obnovený server také dědí tagy a nastavení, například virtuální síť a brána firewall ze zdrojového serveru. Po dokončení obnovení můžete změnit výpočetní úroveň a úroveň úložiště obnoveného serveru, konfiguraci a nastavení zabezpečení.

Poznámka:

Dva parametry serveru se resetují na výchozí hodnoty a po operaci obnovení se nezkopírují z primárního serveru:

• time_zone - Tato hodnota se nastaví na výchozí hodnotu SYSTEM.
• event_scheduler – Pro servery MySQL verze 5.7 se parametr event_scheduler serveru automaticky zapne OFF při zahájení zálohování a parametr event_scheduler serveru se po úspěšném dokončení zálohování vrátí zpět ON . Ve verzi MySQL 8.0 pro Azure Database for MySQL - flexibilní server zůstává event_scheduler během zálohování nedotčeno. Pokud chcete zajistit plynulejší provoz, upgradujte servery MySQL 5.7 na verzi 8.0 pomocí upgradu hlavní verze.

Obnovení k určitému bodu v čase je užitečné v několika scénářích. Mezi běžné případy použití patří:

• Uživatel omylem odstraní data v databázi.
• Uživatel zahodí důležitou tabulku nebo databázi.
• Uživatelská aplikace omylem přepíše dobrá data chybnými daty kvůli vadě aplikace.

Můžete si vybrat mezi nejnovějším bodem obnovení, vlastním bodem obnovení a nejrychlejším bodem obnovení (obnovení pomocí úplného zálohování) prostřednictvím obnovení k určitému bodu v čase ve službě Azure Database for MySQL – Flexibilní server pomocí webu Azure Portal.

• Nejnovější bod obnovení: Obnovte server do časového razítka při aktivaci operace obnovení. Tato možnost je užitečná k rychlému obnovení serveru do nejaktuálnějšího stavu.
• Vlastní bod obnovení: Zvolte libovolný bod v čase v období uchovávání definovaném pro tento server. Tato možnost je užitečná k obnovení serveru v přesném časovém okamžiku, aby se zotavil z chyby uživatele.
• Nejrychlejší bod obnovení: Obnovte server v nejrychlejším čase, který je pro daný den možný během doby uchovávání definované pro server. Nejrychlejší obnovení je možné zvolením bodu obnovení v čase, kdy je úplná záloha dokončena. Tato operace obnovení jednoduše obnoví úplnou zálohu snímku a nezaručuje obnovení ani obnovu protokolů, díky čemuž je rychlejší. Vyberte časové razítko úplné zálohy, které je větší než nejstarší bod obnovení v čase pro úspěšnou operaci obnovení.

Odhadovaná doba obnovení závisí na několika faktorech, včetně velikostí databáze, velikosti zálohování transakčního protokolu, velikosti výpočetních prostředků skladové položky a času obnovení. Obnovení transakčního protokolu je časově nejnáročnější součástí procesu obnovení. Pokud zvolíte čas obnovení blíže plánu zálohování snímků, operace obnovení jsou rychlejší, protože aplikace transakčního protokolu je minimální. Pokud chcete odhadnout přesný čas obnovení pro váš server, otestujte ho ve vašem prostředí, protože má mnoho proměnných specifických pro prostředí.

Důležité

Pokud obnovíte instanci flexibilního serveru Azure Database for MySQL nakonfigurovanou s zónově redundantní vysokou dostupností, obnovený server se nakonfiguruje ve stejné oblasti a zóně jako primární server a nasadí se jako jeden server v režimu bez vysoké dostupnosti. Další informace najdete v tématu zónově redundantní vysoká dostupnost pro flexibilní server.

Důležité

Odstraněný prostředek flexibilního serveru Azure Database for MySQL můžete obnovit do pěti dnů od odstranění serveru. Podrobný průvodce obnovením odstraněného serveru najdete v zdokumentovaných krocích. K ochraně prostředků serveru po nasazení před náhodným odstraněním nebo neočekávanými změnami můžou správci používat zámky správy.

Geografické obnovení

Pokud nakonfigurujete server tak, aby používal geograficky redundantní zálohy, můžete ho obnovit do geograficky spárované oblasti nebo do jakékoli jiné podporované oblasti Azure, kde je flexibilní server Azure Database for MySQL dostupný (s výjimkou Brazil SouthUSGov Virginiaa West US 3). Možnost obnovení geograficky redundantní zálohy do jakékoli oblasti se označuje jako Univerzální geografické obnovení.

Geografické obnovení je výchozí možností obnovení v případě, že incident v oblasti, kde je server hostovaný, znepřístupňuje váš server. Pokud velký incident v oblasti vede k nedostupnosti vaší databázové aplikace, můžete obnovit server z geograficky redundantních záloh na server v jakékoli jiné oblasti. Geografické obnovení používá nejnovější zálohu serveru. Mezi odesláním zálohy a replikací do jiné oblasti dochází ke zpoždění. Toto zpoždění může být až hodinu, takže pokud dojde k havárii, může dojít až k hodinové ztrátě dat.

Geografické obnovení můžete provést také na zastaveném serveru pomocí Azure CLI. Další informace najdete v tématu Obnovení k určitému bodu v čase na flexibilním serveru Azure Database for MySQL pomocí Azure CLI.

Odhadovaná doba obnovení závisí na několika faktorech, včetně velikostí databáze, velikosti transakčního protokolu, šířky pásma sítě a celkového počtu databází, které se najednou obnoví ve stejné oblasti.

Poznámka:

Pokud geograficky obnovujete instanci flexibilního serveru Azure Database for MySQL nakonfigurovanou s zónově redundantní vysokou dostupností, obnovený server se nakonfiguruje v geograficky spárované oblasti a stejné zóně jako primární server. Je nasazena jako jedna instance flexibilního serveru Azure Database for MySQL v režimu bez HA. Další informace najdete v tématu zónově redundantní vysoká dostupnost flexibilního serveru Azure Database for MySQL.

Důležité

Když je primární oblast mimo provoz, nemůžete v příslušné geograficky spárované oblasti vytvářet geograficky redundantní servery, protože úložiště není možné zřídit v primární oblasti. Musíte počkat, až primární oblast zřídí geograficky redundantní servery v geograficky spárované oblasti.
Když je primární oblast mimo provoz, můžete zdrojový server stále geograficky obnovit do geograficky spárované oblasti tak, že v rozhraní portálu obnovení zakážete možnost geografické redundance. Obnovení jako místně redundantního serveru za účelem zajištění kontinuity podnikových procesů

Provádění úloh po obnovení

Po obnovení z nejnovějšího bodu obnovení nebo vlastního mechanismu obnovení bodu obnovení proveďte následující úlohy, abyste mohli uživatele a aplikace zálohovat a spustit:

• Pokud nový server nahradí původní server, přesměrujte klienty a klientské aplikace na nový server.
• Ujistěte se, že jsou pro připojení uživatelů zavedená příslušná pravidla brány firewall a virtuální sítě na úrovni serveru.
• Ujistěte se, že jsou zavedená příslušná přihlášení a oprávnění na úrovni databáze.
• Podle potřeby nakonfigurujte upozornění.

Dlouhodobé uchovávání (Preview)

Poznámka:

Funkce Preview – Řešení dlouhodobého uchovávání pro ochranu flexibilních serverů Azure Database for MySQL pomocí služby Azure Backup je aktuálně pozastavené. Nekonfigurujte žádné nové zálohy do odvolání. Všechna existující zálohovaná data jsou bezpečná a dostupná k obnovení.

Flexibilní serverové služby Azure Backup a Azure Database for MySQL vytvořily podnikové řešení dlouhodobého zálohování pro instance flexibilního serveru Azure Database for MySQL, které uchovávají zálohy po dobu až 10 let. Dlouhodobé uchovávání můžete používat nezávisle nebo kromě automatizovaného řešení zálohování nabízeného flexibilním serverem Azure Database for MySQL, které nabízí uchovávání až 35 dnů. Automatizované zálohy jsou zálohy snímků vhodné pro provozní obnovení, zejména pokud chcete provést obnovení z nejnovějších záloh. Dlouhodobé zálohy vám pomůžou s vašimi potřebami dodržování předpisů a potřebami auditování. Kromě dlouhodobého uchovávání nabízí řešení následující schopnosti:

• Plánované zálohování řízené zákazníkem a zálohování na vyžádání
• Spravujte a monitorujte všechny operace a úlohy související se zálohováním napříč servery, skupinami prostředků, umístěními, předplatnými a tenanty z jednoho centrálního řídicího panelu s názvem Centrum zálohování.
• Zálohy se ukládají v samostatných doménách zabezpečení a selhání. Pokud dojde k ohrožení zabezpečení zdrojového serveru nebo předplatného, zálohy zůstanou v trezoru služby Backup (ve spravovaných účtech úložiště Azure Backup) v bezpečí.

Omezení a důležité informace

• Ve verzi Preview je obnovení LTR aktuálně k dispozici jako RestoreasFiles pro úložné účty. Funkce RestoreasServer bude přidána v budoucnu.
• Podpora vytváření a správy LTR prostřednictvím Azure CLI se v současné době nepodporuje.

Další informace o provádění dlouhodobého zálohování najdete v průvodci postupy.

Nejčastější dotazy (FAQ)

Dotazy související se zálohováním

• Jak zálohuji svůj server?

  Flexibilní server Azure Database for MySQL ve výchozím nastavení umožňuje automatizované zálohování celého serveru (včetně všech vytvořených databází) s výchozí sedmidenní dobou uchovávání. Ruční zálohování můžete aktivovat také pomocí funkce zálohování na vyžádání. Dalším způsobem ručního zálohování je použití komunitních nástrojů, jako je mysqldump zdokumentovaný zde nebo mydumper zdokumentovaný zde. Pokud chcete zálohovat instanci flexibilního serveru Azure Database for MySQL do úložiště objektů blob, přečtěte si blog technické komunity o zálohování flexibilního serveru Azure Database for MySQL do úložiště objektů blob.

• Můžu nakonfigurovat automatické zálohování, které se mají uchovávat dlouhodobě?

  Ne, flexibilní server Azure Database for MySQL v současné době podporuje až 35 dnů automatického uchovávání záloh. Můžete provádět ruční zálohování a používat je k dlouhodobému uchovávání.

• Jaká jsou okna zálohování pro můj server? Můžu je přizpůsobit?

  První záloha snímků je naplánována okamžitě po vytvoření serveru. Snímkové zálohy se pořizují jednou denně. Zálohování transakčních protokolů probíhá každých pět minut. Azure spravuje okna zálohování a nemůžete je přizpůsobit.

• Jsou zálohy šifrované?

  Všechna data, zálohy a dočasné soubory flexibilního serveru Azure Database for MySQL vytvořená během provádění dotazů se šifrují pomocí 256bitového šifrování AES. Šifrování úložiště je vždy zapnuté a není možné ho zakázat.

• Můžu obnovit jednu nebo několik databází?

  Obnovení jedné nebo několika databází nebo tabulek se nepodporuje. Pokud chcete obnovit konkrétní databáze, proveďte obnovení k určitému bodu v čase a extrahujte potřebné tabulky nebo databáze.

• Je můj server během okna zálohování dostupný?

  Ano. Zálohy jsou online operace a jsou založené na snímcích. Operace vytvoření snímku trvá jenom několik sekund a nezasahuje do produkčních úloh a zajišťuje vysokou dostupnost serveru.

• Když nastavím údržbové okno pro server, musím brát v úvahu i okno pro zálohování?

  Ne, zálohy se aktivují interně jako součást spravované služby a nemají žádný vliv na časové období spravované údržby.

• Kde jsou moje automatizované zálohy uložené a jak se spravují jejich uchovávání?

  Flexibilní server Azure Database for MySQL automaticky vytváří zálohy serveru a ukládá je do uživatelem nakonfigurovaného, místně redundantního úložiště nebo v geograficky redundantním úložišti. Tyto záložní soubory nelze exportovat. Výchozí doba uchovávání záloh je sedm dnů. Volitelně můžete nakonfigurovat zálohování databáze od 1 do 35 dnů.

• Jak můžu ověřit zálohy?

  Nejlepším způsobem, jak ověřit dostupnost úspěšně dokončených záloh, je zobrazit úplné automatizované zálohy provedené v období uchovávání v okně Zálohování a obnovení. Pokud se zálohování nezdaří, není uvedené v seznamu dostupných záloh a služba zálohování se pokusí provést zálohování každých 20 minut, dokud se neprovede úspěšná záloha. Tato selhání zálohování jsou způsobená velkým transakčním provozním zatížením na serveru.

• Kde se zobrazuje využití zálohování?

  Na webu Azure Portal na kartě Monitorování – Metriky najdete metriku Azure Database for MySQL – Flexibilní server , která vám může pomoct monitorovat celkové využití zálohování.

• Co se stane se zálohami, když odstraním server?

  Pokud odstraníte server, všechny zálohy patřící k tomuto serveru se také odstraní a nebude možné je obnovit. K ochraně prostředků serveru po nasazení před náhodným odstraněním nebo neočekávanými změnami můžou správci používat zámky správy.

• Co se stane se zálohami při obnovení serveru?

  Pokud obnovíte server, operace vždy způsobí vytvoření nového serveru, který se obnoví pomocí záloh původního serveru. Původní záloha z původního serveru se nezkopíruje na nově obnovený server a zůstane s původním serverem. U nově vytvořeného serveru se ale první zálohování snímků naplánuje okamžitě po vytvoření serveru a služba zajistí, aby se denní automatizované zálohy pořídily a uložily podle nakonfigurované doby uchovávání serveru.

• Jak mi jsou účtovány poplatky za využití záloh?

  Flexibilní server Azure Database for MySQL poskytuje až 100 % zřízeného úložiště serveru jako úložiště záloh bez poplatků. Všechna další využitá úložiště záloh se účtují v GB za měsíc podle cenového modelu. Fakturace úložiště zálohování se také řídí vybranou možností uchovávání záloh a zvolenou možností redundance zálohování kromě transakční aktivity na serveru, která má vliv na celkové využité úložiště zálohování přímo.

• Jak se zálohy uchovávají pro zastavené servery?

  Pro zastavené servery se neprovádí žádné nové zálohy. Služba uchovává všechny starší zálohy (v rámci okna uchovávání informací) v době zastavení serveru, dokud se server nerestartuje. Po restartování serveru se uchovávání záloh pro aktivní server řídí jeho oknem uchovávání záloh.

• Jak se mi účtují zálohy zastaveného serveru?

  Zatímco je instance serveru zastavena, jsou vám účtovány náklady za poskytnuté úložiště (včetně poskytnutých IOPS) a úložiště záloh (záloh uložených ve vaší specifikované době uchovávání). Bezplatné úložiště zálohování je omezené na velikost zřízené databáze a vztahuje se pouze na aktivní servery.

• Jak jsou moje zálohovaná data chráněná?

  Flexibilní server Azure Database for MySQL chrání vaše zálohovaná data tím, že blokuje všechny operace, které by mohly vést ke ztrátě bodů obnovení po dobu nakonfigurované doby uchovávání. Zálohy pořízené během doby uchovávání je možné číst pouze pro účely obnovení a po uplynutí doby uchovávání se odstraní. Všechny zálohy na flexibilním serveru Azure Database for MySQL se navíc šifrují pomocí 256bitového šifrování AES pro neaktivní uložená data.

• Jak operace obnovení k určitému bodu v čase (PITR) ovlivňuje využití IOPS?

  Během operace PITR na flexibilním serveru Azure Database for MySQL vytvoří služba nový server a zkopíruje data z úložiště zdrojového serveru do úložiště nového serveru. Tento proces zvyšuje využití IOPS na zdrojovém serveru. Toto zvýšení využití IOPS (vstupně-výstupních operací za sekundu) je běžným jevem a nenaznačuje žádné problémy se zdrojovým serverem nebo operací PITR. Po dokončení operace PITR se využití IOPS na zdrojovém serveru vrátí na obvyklé úrovně.

Dotazy související s obnovením

• Jak obnovím svůj server? Azure Portal podporuje obnovení k určitému bodu v čase pro všechny servery, takže můžete provést obnovení k nejnovějšímu nebo vlastnímu bodu obnovení. Pokud chcete server obnovit ručně ze záloh vytvořených nástrojem mysqldump MyDumper, přečtěte si téma Obnovení databáze pomocí nástroje myLoader.

• Proč obnovení trvá tolik času?

  Odhadovaný čas obnovení serveru ovlivňuje několik faktorů:

  • Velikost databází. V rámci procesu obnovení se databáze obnovuje z poslední fyzické zálohy. Proto je doba potřebná k obnovení úměrná velikosti databáze.
  • Aktivní část aktivity transakce, kterou proces potřebuje k obnovení. Obnovení může trvat déle v závislosti na přidané aktivitě transakce z posledního úspěšného kontrolního bodu.
  • Šířka pásma sítě, pokud se obnovení provádí do jiné oblasti
  • Počet souběžně zpracovávaných žádostí o obnovení v cílové oblasti
  • Přítomnost primárních klíčů v tabulkách v databázi. Pro rychlejší obnovení zvažte přidání primárních klíčů pro všechny tabulky v databázi.

• Má úprava databázových proměnných na úrovni relace vliv na obnovení?

  Úprava proměnných na úrovni relace a spouštění příkazů DML v relaci klienta MySQL může ovlivnit operaci obnovení k určitému bodu v čase (PITR). Tyto úpravy se nezaznamenají do binárního protokolu, který používá operace zálohování a obnovení. Například foreign_key_checks je proměnná na úrovni relace. Pokud ho zakážete ke spuštění příkazu DML, který porušuje omezení cizího klíče, operace obnovení k určitému bodu v čase selže. Jediným řešením v tomto scénáři je vybrat obnovení určitého časového bodu (PITR) dříve, než byl foreign_key_checks zakázán. Neupravujte žádné proměnné relace pro úspěšnou operaci obnovení k určitému bodu v čase (PITR).

Související obsah

• provozní kontinuita
• zónově redundantní vysoká dostupnost
• zálohování a obnovení