Zálohování skupin dostupnosti Always On v SQL Serveru

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ů.

Pokud chcete zobrazit scénáře zálohování a obnovení, které dnes podporujeme, podívejte se na matici podpory. Nejčastější dotazy najdete v nejčastějších dotazech.

Poznámka:

Azure Backup nepodporuje zálohování databází skupiny dostupnosti Basic.

Chování předvoleb zálohování podle verze SQL Server

Podpora úplného a rozdílového zálohování na sekundárních replikách závisí na SQL Server verzi. Předvolba zálohování AG a verze SQL Serveru určují, který uzel se zvolí pro jednotlivé typy zálohování.

SQL Server 2022 a starší

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í AG Úplné a rozdílové zálohy běží na Copy-Only a zálohy protokolů jsou pořízeny 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é/Jakékoliv Primární replika Libovolná replika

SQL Server 2025 a novější

V SQL Server 2025 a novějších podporují sekundární repliky také úplné a rozdílové zálohy. Předvolba zálohování teď řídí oba typy zálohování jednotně. Pokud nastavíte pouze sekundární nebo preferovat sekundární, úplné a rozdílové zálohy už nevyžadují primární uzel.

Předvolba zálohování AG Úplné a rozdílové zálohy běží na Copy-Only a zálohy protokolů jsou pořízeny z
Primární Primární replika Primární replika
Pouze sekundární Libovolná ze sekundárních replik Libovolná ze sekundárních replik
Preferovat sekundární Upřednostňované jsou sekundární repliky, ale zálohy se můžou spouštět i na primární replice. Upřednostňované jsou sekundární repliky, ale zálohy se můžou spouštět i na primární replice.
Žádné/Jakékoliv Libovolná replika Libovolná replika

Když zaregistrujete uzel ve službě Azure Backup, nainstalujete na tento uzel rozšíření zálohování úloh. Když nakonfigurujete databázi skupiny dostupnosti pro zálohování, plány zálohování se rozdistribuují na všechny registrované uzly skupiny dostupnosti. Plány se spouštějí na všech uzlech AG a rozšíření pro zálohování úloh na těchto uzlech se vzájemně synchronizují, aby určila, který uzel může provést zálohování. Výběr uzlu závisí na typu zálohování a předvolbě zálohování popsané v chování předvoleb zálohování podle verze SQL Server.

Vybraný uzel pokračuje v úloze zálohování, zatímco úloha spuštěná na ostatních uzlech se zastaví, tedy se 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ů AG 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.

SQL Server 2022 a starší:

  • Zaregistrujte primární uzel do trezoru (jinak nebude možné provést úplné zálohování).
  • Pokud je předvolba zálohování pouze sekundární, zaregistrujte alespoň jeden sekundární uzel do úložiště (jinak nemůže dojít k úplnému zálohování logu nebo kopírování).

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

SQL Server 2025 a novější:

  • Pro konfiguraci zálohování AG již není registrace primárního uzlu povinná. Vzhledem k tomu, že úplné a rozdílové zálohy se teď dají spouštět na sekundárních replikách, můžete nakonfigurovat zálohování pouze se sekundárními uzly zaregistrovanými (pokud je předvolba zálohování pouze sekundární nebo preferovaná sekundární).
  • Pro předvolbu primárního zálohování musí být primární uzel stále zaregistrovaný.
  • Zaregistrujte alespoň jeden uzel, který splňuje zvolenou předvolbu zálohování.

Poznámka:

Uvolnění požadavku na registraci primárního uzlu je podmíněno verzí serveru SQL Server zjištěnou během zjišťování databází skupiny dostupnosti. Pokud některá replika v AG běží na serveru SQL Server 2022 nebo starší verzi, požadavek na registraci primárního uzlu pro danou AG nadále platí.

Podívejme se na následující nasazení AG jako vzor.

Diagram nasazení AG jako referenční

Na základě dané ukázky nasazení AG je třeba zvážit různé aspekty:

  • Protože primární uzel je v oblasti 1 a předplatném 1, musí být trezor služby Recovery Services (Trezor 1) také v oblasti 1 a předplatném 1 pro ochranu této AG.
  • VM3 Ve službě Vault 1 se nedá zaregistrovat, protože se jedná o jiné předplatné.
  • VM4 nelze zaregistrovat do Vault 1, protože se nachází v jiném regionu.
  • Pokud je předvolba zálohování jenom sekundární, zaregistrujte virtuální počítač 1 (primární) a virtuální počítač 2 (sekundární) do trezoru 1. Na SQL Server 2022 a starších verzích vyžadují úplné zálohování primární uzel, takže zaregistrujte oba uzly; na SQL Server 2025 a novějších je samotný virtuální počítač VM2 dostatečný. Pro další předvolby zálohování zaregistrujte virtuální počítač 1 (primární) do trezoru 1; Virtuální počítač 2 je volitelný.
  • I když můžete zaregistrovat virtuální počítač 3 do trezoru 2 v předplatném 2 a databáze skupiny dostupnosti (AG) se pak zobrazí jako dostupné pro ochranu v trezoru 2, nastavení zálohování se v SQL Serveru 2022 a starších verzích nezdaří kvůli tomu, že v trezoru 2 chybí primární uzel. V SQL Serveru 2025 a novějších verzích můžete nakonfigurovat zálohování v trezoru 2, pokud je předvolba zálohování nastavena na Secondary Only nebo Prefer Secondary.
  • Podobně platí, že i když můžete zaregistrovat virtuální počítač VM4 do trezoru 4 v oblasti 2, konfigurace zálohování u SQL Serveru 2022 a starších verzí selže, protože primární uzel není zaregistrován v trezoru 4. V SQL Server 2025 a novějších můžete nakonfigurovat zálohy v trezoru 4, pokud je předvolba zálohování pouze sekundární nebo preferovaná sekundární.

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

Poté, co skupina dostupnosti selhala a přešla na jeden ze sekundárních uzlů:

  • SQL Server 2022 a starší: Úplné a rozdílové zálohování pokračuje z nového primárního uzlu, pokud je zaregistrovaný v trezoru.
  • SQL Server 2025 a novější: Úplné a rozdílové zálohování pokračuje z uzlu, který splňuje předvolbu zálohování. Při nastavení Pouze sekundární nebo Preferovat sekundární lze tyto zálohy spouštět na sekundární replice.
  • Úplné zálohy logů a kopie pouze úplné zálohy budou prováděny z primárního nebo sekundárního uzlu na základě nastavení zálohování.

Poznámka:

K přerušení řetězu protokolů nedojde při přepnutí při selhání, pokud se toto 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 na virtuální stroj 2
    • Úplné a rozdílové zálohování proběhne z virtuálního počítače VM2.
    • Úplné zálohování záznamů a pouze kopírujících plných záloh bude probíhat z virtuálního počítače VM1 nebo VM2 podle preferencí zálohování.
  • Přepnutí na VM3 (jiné předplatné)
    • Vzhledem k tomu, že se v trezoru 2 nenakonfigurují zálohy, nedojde k žádným zálohám.
    • Pokud v SQL Server 2022 a starších verzích není předvolba zálohování pouze sekundární, můžete teď nakonfigurovat zálohy ve službě Vault 2, protože primární uzel je v tomto trezoru zaregistrovaný. Na SQL Server 2025 a novějších můžete také nakonfigurovat zálohy, když registrovaný uzel v trezoru 2 splňuje vybranou předvolbu zálohování. Tato podmínka může vést ke konfliktům nebo selháním zálohování. Další informace najdete v tématu Konfigurace záloh pro AG s více oblastmi.
  • Přepnutí na VM4 (jiný region)
    • Vzhledem k tomu, že se zálohy ve službě Vault 4 nenakonfigurují, nedojde k žádným zálohám.
    • Pokud v SQL Server 2022 a starších verzích není předvolba zálohování pouze sekundární, můžete teď nakonfigurovat zálohy ve službě Vault 4, protože primární uzel je v tomto trezoru zaregistrovaný. Na SQL Server 2025 a novějších můžete také nakonfigurovat zálohy, když zaregistrovaný uzel ve službě Vault 4 splňuje vybranou předvolbu zálohování. Tato podmínka může vést ke konfliktům nebo selháním zálohování. Další informace najdete v tématu Konfigurace záloh pro více oblastí skupiny dostupnosti.

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 z oblastí nebo předplatných většinu AG uzlů a převzetí při selhání k jiným uzlům dochází velmi zřídka, může být nastavení zálohování v první oblasti dostačující. Pokud k přepojení do jiné oblasti nebo předplatného dochází často a na delší dobu, možná byste měli v této jiné oblasti proaktivně nastavit i zálohy.

  • 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.

  • SQL Server 2022 a starší verze: Úplné a rozdílové zálohy fungují pouze v trezoru, který obsahuje primární uzel. Tyto zálohy v jiných trezorech selhávají. V SQL Serveru 2025 a novějších verzích se toto chování mění pro nastavení Secondary Only a Prefer Secondary – viz SQL Server 2025: Multi-Region AG backup changes.

  • 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ů, po jehož překročení začnou zálohy protokolů selhávat.

  • Zálohy typu pouze kopírování budou fungovat ve všech trezorech.

  • Ochrana v každém trezoru je považována za samostatný zdroj dat a je účtována 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ů.

SQL Server 2025: Změny v zálohování AG ve více regionech

U SQL Server 2025 už úplné a rozdílové zálohy nevyžadují primární uzel. Tato změna znamená:

  • Registrace primárního uzlu není nutná – pokud je předvolba zálohování pouze sekundární nebo preferovaná sekundární, můžete nakonfigurovat a spustit zálohy z jakéhokoli registrovaného sekundárního uzlu, i když je primární uzel v jiné oblasti nebo předplatném.

  • Snížení dopadu převzetí služeb při selhání – Po převzetí služeb při selhání na uzel v jiné oblasti můžou zálohy pokračovat v původním úložišti, pokud je k dispozici registrovaný uzel splňující nastavení zálohování.

Základní omezení koordinace mezi trezory však zůstává – zálohy není možné koordinovat mezi několika trezory. Pokud zaregistrujete uzly AG v různých trezorech v různých oblastech, mohou se plány zálohování spouštět současně, vzájemně se dostat do konfliktu a způsobit přerušení řetězce transakčních protokolů nebo duplicitní zálohy.

Doporučení, aby nedocházelo ke konfliktům mezi trezory:

  • Skupina dostupnosti 2 uzlů: Nastavte předvolbu zálohování pouze sekundární nebo primární.
  • Skupina dostupnosti 3 a více uzlů: Nastavte předvolbu zálohování na primární.

Tato konfigurace zajišťuje, že kdykoli lze pro zálohování použít pouze uzel jednoho trezoru.

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: Povolte zálohy v Regionu 1, Předplatné 1 (Trezor 1)

Vzhledem k tomu, že primární uzel je v oblasti a v rámci předplatného, budou fungovat obvyklé kroky pro aktivaci záloh.

Krok 2: Aktivace záloh v oblasti 1, předplatné 2 (Úložiště 2)

  1. Přepněte AG na virtuální počítač 3, aby byl primární uzel v trezoru 2.
  2. Nakonfigurujte zálohy pro databáze AG ve službě Vault 2.
  3. V tomto okamžiku:
    1. Úplné nebo rozdílové zálohy v trezoru 1 selžou, protože tuto zálohu nemůže provést žádný z registrovaných uzlů.
    2. Zálohování protokolů bude v trezoru Vault 1 úspěšné dokud se nespustí záloha protokolu ve trezoru Vault 2 a přeruší řetěz protokolů pro trezor Vault 1.
  4. Přepněte AG zpět na VM1.

Krok 3: Povolení záloh v Regionu 2, Předplatné 1 (Vault 4)

Stejné jako krok 2.

Zálohujte skupinu 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ěna uzly v Azure, můžete postupovat podle výše uvedených pokynů pro skupiny dostupnosti napříč regiony 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ávat. Zálohování protokolů může pokračovat, dokud nedojde k přerušení řetězu protokolů nebo neuplyne 15 dní.

Omezování úloh zálohování v databázi AG

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 začnou spouštět zařazené úlohy.

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. Jelikož je omezování na úrovni uzlu, nevyvážené uzly skupiny dostupnosti (AG) mohou vést k problémům se synchronizací zálohování. Abyste tomu porozuměli, zvažte například 2 uzly dostupnostní skupiny.

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á naplánováno 55 úloh zálohování databáze, zatímco uzel 2 má pouze 5. Všechny tyto zálohy se také konfigurují tak, aby běžely současně každou hodinu. V určitém okamžiku bude všech 55 záloh aktivováno na uzlu 1 a 35 z nich bude zařazeno do fronty. Některé z nich by byly zálohy databáze AG. Na uzlu 2 by ale zálohy databáze AG pokračovaly bez jakéhokoli řazení do fronty.

Protože se úlohy databáze ve skupině dostupnosti (AG) na jednom uzlu zařazují do fronty a spouštějí na jiném, synchronizace záloh nefunguje správně. Uzel 2 může předpokládat, že uzel 1 je mimo provoz, a proto úlohy z uzlu 1 nejdou synchronizovat. Tento problém může vést k přerušení řetězu protokolů nebo dalším zálohám, protože oba uzly mohou provádět zálohy nezávisle.

Podobný problém může nastat, pokud je počet chráněných databází dostupnostní skupiny větší než hranice omezování. V takovém případě může být zálohování například databáze DB1 zařazeno do fronty na uzlu 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ě 2 uzlové skupiny dostupnosti 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ý se vždy vzdá.
  • V případě skupiny dostupnosti s více než 2 uzly nastavte předvolbu zálohování na Primární – poté může zálohování provádět pouze primární uzel, ostatní se nebudou podílet.

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á velikost přední části všech chráněných databází v instanci je zpoplatněna. Zvažte následující nasazení:

Diagram znázorňující výpočet chráněných instancí databází

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
AG2 DB4
Virtuální počítač 2 DB3
VM3 DB6
Virtuální počítač 4 DB5

Přesuňte chráněnou databázi do nebo z AG

Azure Backup považuje název instance SQL nebo název skupiny dostupnosti\Název databáze 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 AG, název se změní na AGName\DBName. Zálohy pro samostatnou databázi začnou selhávat s kódem chyby: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

Databáze musí být nakonfigurovaná pro ochranu pod AG. To bude považováno za nový zdroj dat s odděleným řetězem bodů obnovení. Aby se zabránilo aktivaci a selhání budoucích záloh, starší ochranu nezávislé databáze lze zastavit při zachování dat. 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í. Původní ochrana databáze skupiny dostupnosti může být zastavena s možností uchování dat, aby se předešlo aktivaci a selhání budoucích záloh.

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ž je tento nový uzel zaregistrován pro zálohování do stejného trezoru služby Recovery Services jako ostatní existující uzly, služba Azure Backup spustí pracovní postup, který nakonfiguruje tento nový uzel s potřebnými metadaty pro provádění záloh dostupnostních skupin.

Po tomto kroku nový uzel synchronizuje ze služby Azure Backup informace o naplánování zálohování AG a začne se podílet na procesu synchronizovaného zálohování. Pokud nový uzel nedokáže synchronizovat harmonogramy zálohování a účastnit se zálohovacích procesů, spuštění opětovné registrace uzlu vynutí také jeho rekonfiguraci pro zálohy v rámci skupiny dostupnosti. Podobně při odebrání uzlu rozšíření úloh detekují změnu topologie skupiny dostupnosti a informují službu Azure Backup. Služba spustí na odebraném uzlu proces zrušení konfigurace uzlu, který vymaže harmonogramy zálohování pro databáze AG a odstraní metadata související s AG.

Zrušit registraci uzlu skupiny dostupnosti ve službě 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í odregistraci 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 z AG. 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 (AG), duplicitních skupin AG a zálohovaných položek se zobrazí jako položky k ochraně 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 (AG) můžete znovu vytvořit po provedení některého z výše uvedených procesů ukončení zabezpečení, abyste předešli selhání zálohování.

Požadavky na zálohování AG v SQL Serveru 2025

Změny předvoleb zálohování po konfiguraci

Pokud změníte předvolby zálohování skupiny dostupnosti, ale nezaregistrujete požadovaný uzel v trezoru, zálohování se nezdaří. Pokud například změníte předvolbu z Primární na Pouze sekundární, ale není zaregistrován žádný sekundární uzel, zálohy protokolu a úplné nebo rozdílové zálohy selžou. Před provedením změny vždy zajistěte, aby uzly splňující novou předvolbu zálohování byly zaregistrované v trezoru.

Meziregionální koordinace zálohování AG

Když chráníte uzly AG v několika trezorech v různých oblastech, trezory nemůžou koordinovat zálohování mezi sebou bez ohledu na verzi SQL Serveru. Pokyny k nastavení předvoleb zálohování, které v tomto scénáři zabrání narušení řetězení transakčních protokolů a duplicitním zálohám, najdete v článku SQL Server 2025: Změny zálohování AG pro více oblastí.

Podpora zálohování snímků

Zálohování snímků není podporováno na sekundárních replikách skupiny dostupnosti. Pokud povolíte zálohování snímků v zásadách zálohování, registrace primárního uzlu zůstane povinná bez ohledu na SQL Server verzi.

Další kroky

Naučte se jak:

Související obsah

  • Last updated on