Sdílet prostřednictvím


Zálohování SQL Serveru vždy ve skupinách dostupnosti

Azure Backup nabízí kompletní podporu zálohování SQL Serveru vždy ve skupinách dostupnosti (AG), pokud jsou všechny uzly ve stejné oblasti a předplatném jako trezor služby Recovery Services. Pokud jsou ale uzly skupiny dostupnosti rozložené mezi oblasti, předplatná nebo místní prostředí a Azure, je potřeba vzít v úvahu několik aspektů.

Poznámka:

  • Služba Azure Backup nepodporuje zálohování databází skupiny dostupnosti Basic.
  • Další informace o podporovaných konfiguracích a scénářích najdete v matici podpory zálohování SQL.

Předvolba zálohování používaná službou Azure Backup SQL AG podporuje úplné a rozdílové zálohy pouze z primární repliky. Tyto úlohy zálohování se proto vždy spouštějí na primárním uzlu bez ohledu na předvolbu zálohování. Pro úplné zálohování protokolů kopírování a transakčních protokolů se při rozhodování o uzlu, na kterém se bude spouštět zálohování, se považuje předvolba zálohování skupiny dostupnosti.

Předvolba zálohování skupiny dostupnosti Úplné a rozdílové zálohy běží na Zálohy jen pro kopírování a protokoly jsou převzaty z
Primární Primární replika Primární replika
Pouze sekundární Primární replika Libovolná ze sekundárních replik
Preferovat sekundární Primární replika Upřednostňované jsou sekundární repliky, ale zálohy se můžou spouštět i na primární replice.
Žádné/žádné Primární replika Libovolná replika

Rozšíření zálohování úloh se nainstaluje na uzel, když je zaregistrované ve službě Azure Backup. Při konfiguraci databáze skupiny dostupnosti pro zálohování se plány zálohování nasdílí do všech registrovaných uzlů skupiny dostupnosti. Plány se aktivují na všech uzlech skupiny dostupnosti a rozšířeních zálohování úloh na těchto uzlech se synchronizují, aby se rozhodl, který uzel provede zálohování. Výběr uzlu závisí na typu zálohování a předvolbě zálohování, jak je vysvětleno v části 1.

Vybraný uzel pokračuje s úlohou zálohování, zatímco úloha aktivovaná na ostatních uzlech se tím přeskočí.

Poznámka:

Azure Backup při rozhodování mezi sekundárními replikami nebere v úvahu priority zálohování ani repliky.

Registrace uzlů skupiny dostupnosti do trezoru služby Recovery Services

Trezor služby Recovery Services podporuje zálohování databází pouze z virtuálních počítačů ve stejné oblasti a předplatném jako trezor.

  • Primární uzel je nutné zaregistrovat do trezoru (jinak k úplnému zálohování nedojde).
  • Pokud je předvolba zálohování jenom sekundární, musíte do trezoru zaregistrovat alespoň jeden sekundární uzel (jinak k úplnému zálohování protokolu nebo kopírování nedojde).

Konfigurace záloh pro databáze skupiny dostupnosti selže s kódem chyby FabricSvcBackupPreferenceCheckFailedUserError , pokud nejsou splněny výše uvedené podmínky.

Podívejme se na následující nasazení skupiny dostupnosti jako referenci.

Diagram for AG deployment as reference.

Na základě výše uvedeného ukázkového nasazení skupiny dostupnosti je potřeba vzít v úvahu různé aspekty:

  • Vzhledem k tomu, že primární uzel je v oblasti 1 a předplatném 1, musí být trezor služby Recovery Services (Trezor 1) v oblasti 1 a předplatné 1 pro ochranu této skupiny dostupnosti.
  • VM3 nejde zaregistrovat do trezoru 1, protože se jedná o jiné předplatné.
  • VM4 nejde zaregistrovat do trezoru 1, protože je v jiné oblasti.
  • Pokud je předvolba zálohování jenom sekundární, virtuální počítač VM1 (primární) a virtuální počítač 2 (sekundární) musí být zaregistrované v trezoru 1 (protože úplné zálohování vyžaduje primární uzel a protokoly vyžadují sekundární uzel). V případě jiných předvoleb zálohování musí být virtuální počítač 1 (primární) zaregistrovaný ve službě Vault 1, virtuální počítač 2 je volitelný (protože všechny zálohy můžou běžet na primárním uzlu).
  • I když se virtuální počítač 3 může zaregistrovat do trezoru 2 v předplatném 2 a databáze skupiny dostupnosti se pak zobrazí pro ochranu v trezoru 2, ale kvůli absenci primárního uzlu v trezoru 2 by konfigurace záloh selhala.
  • Podobně i když je možné virtuální počítač 4 zaregistrovat do trezoru 4 v oblasti 2, konfigurace záloh selže, protože primární uzel není zaregistrovaný v trezoru 4.

Zpracování převzetí služeb při selhání

Po převzetí služeb při selhání skupiny dostupnosti na jeden ze sekundárních uzlů:

  • Úplné a rozdílové zálohy budou pokračovat z nového primárního uzlu, pokud je zaregistrovaný do trezoru.
  • Úplné zálohy protokolu a kopírování budou pokračovat z primárního nebo sekundárního uzlu na základě předvolby zálohování.

Poznámka:

K přerušení řetězu protokolů nedojde při převzetí služeb při selhání, pokud se převzetí služeb při selhání neshoduje se zálohováním.

Na základě výše uvedeného ukázkového nasazení skupiny dostupnosti existují různé možnosti převzetí služeb při selhání:

  • Převzetí služeb při selhání na virtuální počítač 2
    • Úplné a rozdílové zálohování proběhne z virtuálního počítače VM2.
    • Úplné zálohování protokolů a kopírování proběhne z virtuálního počítače VM1 nebo VM2 na základě předvoleb zálohování.
  • Převzetí služeb při selhání na virtuální počítač 3 (jiné předplatné)
    • Vzhledem k tomu, že se v trezoru 2 nenakonfigurují zálohy, nedojde k žádným zálohám.
    • Pokud předvolba zálohování není jenom sekundární, je možné nyní v trezoru 2 nakonfigurovat zálohy, protože primární uzel je v tomto trezoru zaregistrovaný. To ale může vést ke konfliktům nebo selháním zálohování. Další informace najdete v tématu Konfigurace záloh skupiny dostupnosti ve více oblastech.
  • Převzetí služeb při selhání na virtuální počítač 4 (jiná oblast)
    • Vzhledem k tomu, že se zálohy ve službě Vault 4 nenakonfigurují, nedojde k žádným zálohám.
    • Pokud předvolba zálohování není jenom sekundární, je možné zálohování nakonfigurovat v trezoru 4, protože primární uzel je v tomto trezoru zaregistrovaný. To ale může vést ke konfliktům nebo selháním zálohování. Další informace najdete v tématu Konfigurace záloh skupiny dostupnosti ve více oblastech.

Konfigurace záloh pro více oblastí skupiny dostupnosti

Trezor služby Recovery Services nepodporuje zálohování mezi předplatnými ani mezi oblastmi. Tato část shrnuje, jak povolit zálohování skupin AG, které pokrývají předplatná nebo oblasti Azure, a související aspekty.

  • Vyhodnoťte, jestli opravdu potřebujete povolit zálohování ze všech uzlů. Pokud má jedna oblast nebo předplatné většinu uzlů skupiny dostupnosti a převzetí služeb při selhání k jiným uzlům dochází velmi zřídka, může být nastavení zálohování v této první oblasti dostačující. Pokud k převzetí služeb při selhání do jiné oblasti nebo předplatného dochází často a po delší dobu, možná budete chtít proaktivně nastavit zálohy i v jiné oblasti.

  • Každý trezor, ve kterém se zálohování povolí, bude mít vlastní sadu řetězů bodů obnovení. Obnovení z těchto bodů obnovení je možné provést pouze na virtuální počítače zaregistrované v daném trezoru.

  • Úplné nebo rozdílové zálohování proběhne úspěšně pouze v trezoru, který má primární uzel. Tyto zálohy v jiných trezorech zůstanou neúspěšné.

  • Zálohy protokolů budou dál fungovat v předchozím trezoru, dokud se v novém trezoru nespustí záloha protokolu (to znamená v trezoru, kde je k dispozici nový primární uzel) a přeruší řetěz protokolů pro starý trezor.

    Poznámka:

    Existuje pevný limit 15 dnů, za který se začnou selhávající zálohování protokolů.

  • Úplné zálohy pouze kopírování budou fungovat ve všechtrezorchch

  • Ochrana v každém trezoru se považuje za samostatný zdroj dat a účtuje se samostatně.

Pokud se chcete vyhnout konfliktům zálohování protokolů mezi těmito dvěma trezory, doporučujeme nastavit předvolbu zálohování na primární. Podle toho, který trezor má primární uzel, pak také provede zálohování protokolů.

Tady je postup povolení zálohování ze všech uzlů na základě výše uvedeného ukázkového nasazení skupiny dostupnosti. Předpokladem je, že předvolba zálohování je ve všech krocích splněná.

Krok 1: Povolení záloh v oblasti 1, předplatné 1 (trezor 1)

Vzhledem k tomu, že primární uzel je v oblasti a předplatném, budou fungovat obvyklé kroky pro povolení zálohování.

Krok 2: Povolení záloh v oblasti 1, předplatné 2 (trezor 2)

  1. Převzetí služeb při selhání skupiny dostupnosti na virtuální počítač 3, aby byl primární uzel v trezoru 2.
  2. Nakonfigurujte zálohy pro databáze skupiny dostupnosti ve službě Vault 2.
  3. V tomto okamžiku:
    1. Úplné nebo rozdílové zálohy se v trezoru 1 nezdaří, protože toto zálohování nemůže provést žádný z registrovaných uzlů.
    2. Zálohování protokolů bude ve službě Vault 1 úspěšné, dokud se v trezoru 2 nespustí záloha protokolu a přeruší řetěz protokolů pro Trezor 1.
  4. Navrácení služeb po obnovení skupiny dostupnosti na virtuální počítač 1

Krok 3: Povolení záloh v oblasti 2, předplatné 1 (trezor 4)

Stejné jako krok 2.

Zálohování skupiny dostupnosti, která zahrnuje Azure a místní prostředí

Azure Backup pro SQL Server nejde spustit místně. Pokud je primární uzel v Azure a předvolba zálohování je splněná uzly v Azure, můžete postupovat podle výše uvedených pokynů pro skupiny dostupnosti ve více oblastech a povolit zálohování replik v Azure. Pokud dojde k převzetí služeb při selhání do místního uzlu, úplné a rozdílové zálohy v Azure se začnou selhávají. Zálohování protokolů může pokračovat, dokud nedojde k přerušení řetězu protokolů za 15 dnů.

Omezování úloh zálohování v databázi skupiny dostupnosti

Limity omezování zálohování se v současné době vztahují na úrovni jednotlivých počítačů. Výchozí limit je 20 – pokud se souběžně aktivuje více než 20 záloh, spustí se prvních 20 a ostatní se zařadí do fronty. Po dokončení spuštěných úloh se spustí fronty.

Tuto hodnotu můžete změnit na menší hodnotu, pokud souběžné zálohování způsobuje zatížení paměti, vstupně-výstupních operací a procesoru na uzlu. Vzhledem k tomu, že omezování je na úrovni uzlu, může mít nevyvážené uzly skupiny dostupnosti vést k problémům se synchronizací zálohování. Abyste tomu porozuměli, zvažte například 2 uzly skupiny dostupnosti.

První uzel má například 50 samostatných databází chráněných a oba uzly mají chráněnou 5 databází skupiny dostupnosti. Uzel 1 má v podstatě naplánované 55 úloh zálohování databáze, zatímco Node 2 má pouze 5. Všechny tyto zálohy se také konfigurují tak, aby běžely současně každou hodinu. V okamžiku se všech 55 záloh aktivuje na uzlu 1 a 35 z nich se zařadí do fronty. Některé z nich by byly zálohy databáze skupiny dostupnosti. V uzlu 2 by se ale zálohy databáze skupiny dostupnosti dostaly do fronty.

Protože se úlohy databáze skupiny dostupnosti zařadí do fronty na jednom uzlu a běží na druhém, synchronizace zálohování (uvedená v části 6) nebude správně fungovat. Uzel 2 může předpokládat, že uzel 1 je mimo provoz, a proto se nechystá synchronizace úloh. To může vést k přerušení řetězu protokolů nebo dalším zálohám, protože oba uzly mohou nezávisle provádět zálohy.

Podobný problém může nastat, pokud je počet chráněných databází skupiny dostupnosti větší než limit omezování. V takovém případě může být zálohování databáze DB1 zařazeno do fronty na Node 1, zatímco běží na uzlu 2.

Doporučujeme použít následující předvolby zálohování, abyste se vyhnuli těmto problémům se synchronizací:

  • V případě skupiny dostupnosti 2 uzlů nastavte předvolbu zálohování pouze na primární nebo sekundární – pak zálohy může provádět pouze jeden uzel, druhý bude vždy platit.
  • V případě skupiny dostupnosti s více než 2 uzly nastavte předvolbu zálohování na Primární – pak zálohy můžou provádět jenom primární uzel, ostatní se budou zálohovat.

Fakturace záloh skupiny dostupnosti

Stejně jako samostatná instance SQL se jedna zálohovaná instance skupiny dostupnosti považuje za jednu chráněnou instanci. Celková front-endová velikost všech chráněných databází v instanci se účtuje. Zvažte následující nasazení:

Diagram showing the calculation of protected instances of databases.

Chráněné instance se počítají takto:

Chráněná instance nebo instance fakturace Databáze, které se považují za výpočet velikosti front-endu
Skupina dostupnosti 1 DB1, DB2
Skupina dostupnosti 2 DB4
VM2 DB3
Virtuální počítač 3 DB6
Virtuální počítač 4 DB5

Přesunutí chráněné databáze do skupiny dostupnosti nebo mimo ji

Azure Backup považuje instanci SQL nebo název skupiny dostupnosti za jedinečný název databáze. Když byla samostatná databáze chráněna, její jedinečný název byl StandAloneInstanceName\DBName. Když se přesune pod skupiny dostupnosti, jedinečný název se změní na název skupiny dostupnosti\DBName. Zálohy pro samostatnou databázi začnou selhávají s kódem chyby: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

Databáze musí být nakonfigurovaná pro ochranu před skupinami dostupnosti. To bude považováno za nový zdroj dat s odděleným řetězem bodů obnovení. Starší ochrana samostatné databáze může být zastavena se zachováním dat, aby se zabránilo budoucím zálohám v aktivaci a selhání. Podobně platí, že když se chráněná databáze skupiny dostupnosti přesune mimo skupinu dostupnosti a stane se samostatnou databází, její zálohy začnou selhávají s kódem chyby: UserErrorBackupFailedDatabaseMovedOutOfAG.

Databáze musí být nakonfigurována pro ochranu ze samostatné instance. To bude považováno za nový zdroj dat s odděleným řetězem bodů obnovení. Starší ochrana databáze skupiny dostupnosti může být zastavena se zachováním dat, aby se zabránilo budoucím zálohám v aktivaci a selhání.

Přidání nebo odebrání uzlu do skupiny dostupnosti

Když se do skupiny dostupnosti, která je nakonfigurovaná pro zálohování, přidá nový uzel, rozšíření zálohování úloh spuštěná na již registrovaných uzlech skupiny dostupnosti zjistí změnu topologie skupiny dostupnosti a během další naplánované úlohy zjišťování databáze informuje službu Azure Backup. Když se tento nový uzel zaregistruje pro zálohy do stejného trezoru služby Recovery Services jako ostatní existující uzly, služba Azure Backup aktivuje pracovní postup, který tento nový uzel nakonfiguruje s potřebnými metadaty pro provádění záloh skupiny dostupnosti.

Potom nový uzel synchronizuje informace o plánu zálohování skupiny dostupnosti ze služby Azure Backup a začne se účastnit synchronizovaného procesu zálohování. Pokud nový uzel nedokáže synchronizovat plány zálohování a účastnit se záloh, aktivace opětovné registrace uzlu vynutí také rekonfiguraci uzlu pro zálohy skupiny dostupnosti. Podobně rozšíření úloh detekují změnu topologie skupiny dostupnosti v tomto případě a informují službu Azure Backup. Služba spustí pracovní postup zrušení konfigurace uzlu na odebraném uzlu, který vymaže plány zálohování pro databáze skupiny dostupnosti a odstraní metadata související se skupinami dostupnosti.

Zrušení registrace uzlu skupiny dostupnosti ze služby Azure Backup

Pokud je uzel součástí skupiny dostupnosti, která má jednu nebo více databází nakonfigurovaných pro zálohování, azure Backup nepovolí registraci tohoto uzlu. Tím zabráníte budoucím selháním zálohování v případě, že se předvolba zálohování nedá splnit bez tohoto uzlu. Pokud chcete zrušit registraci uzlu, musíte ho nejprve odebrat ze skupiny dostupnosti. Jakmile se pracovní postup zrušení konfigurace uzlu dokončí, můžete ho vyčistit a zrušit jeho registraci.

Obnovení databáze ze služby Azure Backup do skupin dostupnosti SQL skupiny dostupnosti nepodporuje přímé obnovení databáze do skupiny dostupnosti. Databázi je potřeba obnovit do samostatné instance SQL a pak je potřeba ji připojit ke skupině dostupnosti.

Scénáře opětovného vytvoření skupiny dostupnosti pro databázový server SQL

Opětovné vytvoření skupiny dostupnosti, duplicitních skupin dostupnosti a zálohovaných položek se zobrazí jako chráněné položky nebo chráněné položky v následujících scénářích:

  • Opětovné vytvoření skupin AG, které jsou již chráněné, se zobrazí jako duplicitní skupiny AG na stránce Konfigurovat zálohování a v seznamu Chráněné položky . Pokud chcete zachovat zálohovaná data, která už existují ve starší skupině dostupnosti, zastavte zálohování pomocí možnosti Zastavit ochranu a zachovat data před opětovným vytvořením a plánováním záloh u nových položek skupiny dostupnosti.

    Služba Azure Backup vypíše duplicitní položky v seznamu chráněných položek a na stránce Konfigurovat zálohování nebo seznam chráněných položek a zobrazí tyto položky, dokud nebudete chtít zachovat zálohovaná data.

  • Pokud nechcete zálohovat data ze starší skupiny dostupnosti, zastavte operaci zálohování pomocí možnosti Zastavit ochranu a odstranit data pro starší položku před opětovným vytvořením a plánováním záloh v nové skupině dostupnosti.

    Upozornění

    Zastavení ochrany a odstranění dat je destruktivní operace.

  • Skupinu dostupnosti můžete znovu vytvořit po provedení některého z výše uvedených procesů zastavení ochrany, abyste se vyhnuli selháním zálohování.

Další kroky

Naučte se: