Automatizované zálohování ve službě Azure SQL Database

Platí pro: Azure SQL Database

Tento článek popisuje funkci automatizovaného zálohování pro Azure SQL Database.

Pokud chcete změnit nastavení zálohování, přečtěte si téma Změna nastavení. Pokud chcete obnovit zálohu, přečtěte si téma Obnovení s využitím automatizovaných záloh databází.

Co je záloha databáze?

Zálohy databází jsou nezbytnou součástí jakékoli strategie provozní kontinuity a zotavení po havárii, protože pomáhají chránit vaše data před poškozením nebo odstraněním. Tyto zálohy umožňují obnovení databáze k určitému bodu v čase v rámci nakonfigurované doby uchovávání. Pokud vaše pravidla ochrany dat vyžadují, aby vaše zálohy byly k dispozici po delší dobu (až 10 let), můžete nakonfigurovat dlouhodobé uchovávání (LTR) pro jednotlivé databáze i databáze ve fondu.

U jiných úrovní služby než Hyperscale využívá Azure SQL Database k zálohování a obnovení dat technologii SQL Server modulu. Databáze hyperškálování používají zálohování a obnovení na základě snímků úložiště. Díky tradiční technologii SQL Server zálohování mají větší databáze dlouhou dobu zálohování a obnovení. Díky použití snímků poskytuje Hyperscale možnosti okamžitého zálohování a rychlého obnovení bez ohledu na velikost databáze. Další informace najdete v tématu Zálohování hyperškálování.

Frekvence zálohování

Azure SQL Database vytvoří:

Přesná frekvence zálohování transakčních protokolů závisí na velikosti výpočetních prostředků a množství aktivit databáze. Když provedete obnovení databáze, služba určí, které úplné zálohy, rozdílové zálohy a zálohy transakčních protokolů je potřeba obnovit.

Architektura Hyperscale nevyžaduje úplné, rozdílové zálohování ani zálohování protokolů. Další informace najdete v tématu Zálohování hyperškálování.

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

Ve výchozím nastavení Azure SQL Database ukládá zálohy do geograficky redundantních objektů blob úložiště, které se replikují do spárované oblasti. Geografická redundance pomáhá chránit před výpadky, které mají vliv na úložiště zálohování v primární oblasti. Umožňuje také obnovit databáze v jiné oblasti v případě výpadku oblasti.

Mechanismus redundance úložiště ukládá několik kopií vašich dat, aby byla chráněná před plánovanými a neplánovanými událostmi. Tyto události můžou zahrnovat přechodné selhání hardwaru, výpadky sítě nebo napájení nebo rozsáhlé přírodní katastrofy.

Pokud chcete zajistit, aby zálohy zůstaly ve stejné oblasti, ve které je vaše databáze nasazená, můžete změnit redundanci úložiště zálohování z výchozího geograficky redundantního úložiště na jiné typy úložiště, které uchovávají vaše data v této oblasti. Nakonfigurovaná redundance úložiště zálohování se používá pro zálohy s krátkodobým uchováváním (STR) i pro zálohy LTR. Další informace o redundanci úložiště najdete v tématu Redundance dat.

Redundanci úložiště zálohování můžete nakonfigurovat při vytváření databáze a později ji aktualizovat. Změny provedené v existující databázi se použijí pouze pro budoucí zálohy. Po aktualizaci redundance úložiště zálohování existující databáze může trvat až 48 hodin, než se změny projeví.

Pro zálohy můžete zvolit jednu z následujících redundancí úložiště:

  • Místně redundantní úložiště (LRS): Kopíruje zálohy synchronně třikrát v rámci jednoho fyzického umístění v primární oblasti. LRS je nejlevnější možnost úložiště, ale nedoporučujeme ji pro aplikace, které vyžadují odolnost vůči oblastním výpadkům nebo záruku vysoké odolnosti dat.

    Diagram znázorňující možnost místně redundantního úložiště (LRS)

  • Zónově redundantní úložiště (ZRS): Kopíruje zálohy synchronně napříč třemi zónami dostupnosti Azure v primární oblasti. V současné době je k dispozici pouze v určitých oblastech.

    Diagram znázorňující možnost zónově redundantního úložiště (ZRS)

  • Geograficky redundantní úložiště (GRS): Kopíruje zálohy synchronně třikrát v rámci jednoho fyzického umístění v primární oblasti pomocí LRS. Potom data asynchronně třikrát zkopíruje do jednoho fyzického umístění ve spárované sekundární oblasti.

    Výsledek je následující:

    • Tři synchronní kopie v primární oblasti
    • Tři synchronní kopie ve spárované oblasti, které byly asynchronně zkopírovány z primární oblasti do sekundární oblasti.

    Diagram znázorňující možnost geograficky redundantního úložiště (GRS)

Upozornění

  • Geografické obnovení se zakáže, jakmile se databáze aktualizuje, aby používala místně redundantní nebo zónově redundantní úložiště.
  • Diagramy redundance úložiště ukazují všechny oblasti s více zónami dostupnosti (multi-az). Některé oblasti ale poskytují pouze jednu zónu dostupnosti a nepodporují zónově redundantní zónu.
  • Redundanci úložiště zálohování pro databáze Hyperscale je možné nastavit pouze během vytváření. Po zřízení prostředku nemůžete toto nastavení změnit. Pokud chcete aktualizovat nastavení redundance úložiště zálohování pro existující databázi Hyperscale s minimálními výpadky, použijte aktivní geografickou replikaci. Alternativně můžete použít kopírování databáze. Další informace najdete v tématu Zálohování hyperškálování a redundance úložiště.

Využití záloh

Automaticky vytvořené zálohy můžete použít v následujících scénářích:

  • Obnovte existující databázi k určitému bodu v čase v rámci doby uchovávání pomocí Azure Portal, Azure PowerShell, Azure CLI nebo rozhraní REST API. Tato operace vytvoří novou databázi na stejném serveru jako původní databáze, ale používá jiný název, aby se zabránilo přepsání původní databáze.

    Po dokončení obnovení můžete volitelně odstranit původní databázi a přejmenovat obnovenou databázi na původní název databáze. Případně můžete původní databázi místo odstranění přejmenovat a poté přejmenovat obnovenou databázi na původní název databáze.

  • Obnovení odstraněné databáze k určitému bodu v čase v rámci doby uchovávání, včetně času odstranění. Odstraněnou databázi je možné obnovit pouze na stejném serveru, na kterém jste vytvořili původní databázi. Před odstraněním databáze služba provede konečnou zálohu transakčního protokolu, aby se zabránilo ztrátě dat.

  • Obnovení databáze do jiné geografické oblasti Geografické obnovení umožňuje provést zotavení po oblastním výpadku, když nemáte přístup k databázi nebo zálohám v primární oblasti. Vytvoří novou databázi na libovolném existujícím serveru v jakékoli oblasti Azure.

    Důležité

    Geografické obnovení je k dispozici pouze pro databáze, které jsou nakonfigurované s geograficky redundantním úložištěm zálohování. Pokud aktuálně nevyužíváte geograficky replikované zálohy databáze, můžete to změnit konfigurací redundance úložiště zálohování.

  • Obnovení databáze z konkrétní dlouhodobé zálohy izolované databáze nebo databáze ve fondu, pokud byla pro databázi nakonfigurovaná zásada LTR. LTR umožňuje obnovit starší verzi databáze pomocí Azure Portal, Azure CLI nebo Azure PowerShell za účelem splnění požadavku na dodržování předpisů nebo spuštění starší verze aplikace. Další informace najdete v tématu Dlouhodobé uchovávání.

Obnovení možností a funkcí

Tato tabulka shrnuje možnosti a funkce obnovení k určitému bodu v čase (PITR),geografického obnovení a dlouhodobého uchovávání.

Vlastnost Backup  Obnovení k určitému bodu v čase Geografické obnovení Dlouhodobé uchovávání
Typy zálohování SQL Plný, rozdílový, protokol. Replikované kopie záloh PITR Pouze úplné zálohy
Cíl bodu obnovení (RPO)  10 minut v závislosti na velikosti výpočetních prostředků a objemu aktivit databáze.   Až 1 hodina v závislosti na geografické replikaci.*  Jeden týden (nebo podle zásad uživatele).
Plánovaná doba obnovení (RTO) Obnovení obvykle trvá méně než 12 hodin, ale v závislosti na velikosti a aktivitě může trvat déle. Viz Obnovení Obnovení obvykle trvá méně než 12 hodin, ale v závislosti na velikosti a aktivitě může trvat déle. Viz Obnovení. Obnovení obvykle trvá méně než 12 hodin, ale v závislosti na velikosti a aktivitě může trvat déle. Viz Obnovení.
Uchování Ve výchozím nastavení je to 7 dní, je možné konfigurovat až 35 dnů.  Ve výchozím nastavení povoleno; stejně jako u zdroje.** Ve výchozím nastavení není povoleno. Doba uchování je až 10 let.
Azure Storage   Ve výchozím nastavení geograficky redundantní. Volitelně můžete nakonfigurovat zónově redundantní nebo místně redundantní úložiště. K dispozici v případě, že je nastavená geografická redundance úložiště zálohování PITR. Není k dispozici, pokud je úložiště zálohování PITR zónově redundantní nebo místně redundantní.  Ve výchozím nastavení geograficky redundantní. Můžete nakonfigurovat zónově redundantní nebo místně redundantní úložiště.
Obnovení nové databáze ve stejné oblasti Podporováno Podporováno  Podporováno
Obnovení nové databáze v jiné oblasti Nepodporováno Podporováno v jakékoli oblasti Azure Podporováno v jakékoli oblasti Azure
Obnovení nové databáze v jiném předplatném Nepodporováno Nepodporuje se*** Nepodporuje se***
Obnovení prostřednictvím Azure Portal Yes Yes Yes
Obnovení prostřednictvím PowerShellu Yes Yes Yes
Obnovení prostřednictvím Azure CLI Yes Yes Yes

* Pro důležité obchodní aplikace, které vyžadují velké databáze a musí zajistit provozní kontinuitu, použijte skupiny automatického převzetí služeb při selhání.

** Všechny zálohy pitr se ve výchozím nastavení ukládají v geograficky redundantním úložišti, takže geografické obnovení je ve výchozím nastavení povolené.

Alternativním řešením je provést obnovení na nový server a pomocí přesunu prostředků přesunout server do jiného předplatného nebo použít kopii databáze mezi předplatnými.

Obnovení databáze ze zálohy

Pokud chcete provést obnovení, přečtěte si téma Obnovení databáze ze záloh. S využitím následujících příkladů můžete prozkoumat operace konfigurace zálohování a obnovení.

Operace portál Azure Azure CLI Azure PowerShell
Změna uchovávání záloh SQL Database
Spravovaná instance SQL
SQL Database
Spravovaná instance SQL
SQL Database
Spravovaná instance SQL
Změna dlouhodobého uchovávání záloh SQL Database
Spravovaná instance SQL
SQL Database
Spravovaná instance SQL
SQL Database
Spravovaná instance SQL
Obnovení databáze z časového bodu SQL Database
Spravovaná instance SQL
SQL Database
Spravovaná instance SQL
SQL Database
Spravovaná instance SQL
Obnovení odstraněné databáze SQL Database
Spravovaná instance SQL
SQL Database
Spravovaná instance SQL
SQL Database
Spravovaná instance SQL

Plánování zálohování

První úplné zálohování se naplánuje okamžitě po vytvoření nové databáze nebo po obnovení databáze. Toto zálohování se obvykle dokončí během 30 minut, ale pokud je databáze velká, může to trvat déle. Například u obnovené databáze nebo její kopie může prvotní zálohování trvat déle, což je obvykle větší než nová databáze.

Po prvním úplném zálohování se všechny další zálohy plánují a spravují automaticky. Přesné načasování všech záloh databáze určuje služba SQL Database, protože musí vyrovnat celkové zatížení systému. Nemůžete změnit plán úloh zálohování ani je zakázat.

Důležité

  • U nové, obnovené nebo zkopírované databáze je možnost obnovení k určitému bodu v čase k dispozici při vytvoření počáteční zálohy transakčního protokolu, která následuje po počáteční úplné záloze.
  • Databáze hyperškálování jsou chráněny okamžitě po vytvoření, na rozdíl od jiných databází, kde počáteční zálohování nějakou dobu trvá. Ochrana je okamžitá, i když byla databáze Hyperscale vytvořena s velkým množstvím dat prostřednictvím kopírování nebo obnovení. Další informace najdete v tématu Automatizované zálohování Hyperscale.

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

Díky technologii SQL Server zálohování a obnovení vyžaduje obnovení databáze k určitému bodu v čase nepřerušovaný řetěz zálohování. Tento řetězec se skládá z jedné úplné zálohy, volitelně jedné rozdílové zálohy a jedné nebo více záloh transakčních protokolů.

Azure SQL Database plánuje jednu úplnou zálohu každý týden. Aby bylo možné zajistit obnovení k bodu v čase během celé doby uchovávání, musí systém uchovávat další úplné, rozdílové a transakční zálohy protokolů po dobu až týdne delší, než je nakonfigurovaná doba uchovávání.

Jinými slovy, pro jakýkoli bod v čase během doby uchovávání musí existovat úplná záloha, která je starší než nejstarší čas doby uchovávání. Musí také existovat nepřerušený řetězec rozdílových záloh a záloh transakčních protokolů od této úplné zálohy až do další úplné zálohy.

Databáze hyperškálování používají jiný mechanismus plánování zálohování. Další informace najdete v tématu Plánování zálohování Hyperscale.

Zálohy, které už nejsou potřeba k zajištění funkce OBNOVENÍ k určitému bodu v čase, se automaticky odstraní. Vzhledem k tomu, že rozdílové zálohy a zálohování protokolů vyžadují, aby bylo možné obnovit dřívější úplné zálohování, vymazávají se všechny tři typy záloh společně v týdenních sadách.

Pro všechny databáze, včetně databází šifrovaných transparentním šifrováním dat, se zálohy komprimují, aby se snížila spotřeba úložiště zálohování a snížily se náklady. Průměrný kompresní poměr záloh je 3 až 4krát. V závislosti na povaze dat a na tom, jestli se v databázi používá komprese dat, ale může být výrazně nižší nebo vyšší.

Azure SQL Database vypočítá celkové využité úložiště zálohování jako kumulativní hodnotu. Tato hodnota se každou hodinu hlásí do fakturačního kanálu Azure. Kanál zodpovídá za agregaci tohoto hodinového využití za účelem výpočtu vaší spotřeby na konci každého měsíce. Po odstranění databáze se spotřeba snižuje, protože zálohy stárnou a odstraní se. Po odstranění všech záloh a obnovení k určitému bodu v čase se zastaví fakturace.

Důležité

Zálohy databáze se uchovávají, aby bylo možné zajistit obnovení k určitému bodu v čase, i když byla databáze odstraněna. Odstranění a opětovné vytvoření databáze sice může ušetřit náklady na úložiště a výpočetní prostředky, ale náklady na úložiště zálohování se můžou zvýšit. Důvodem je to, že služba uchovává zálohy pro každou odstraněnou databázi pokaždé, když se odstraní.

Monitorování využití úložiště

V případě databází s virtuálními jádry ve službě Azure SQL Database se úložiště, které jednotlivé typy zálohování (úplné, rozdílové a protokolové) spotřebovávají, hlásí v podokně monitorování databáze jako samostatná metrika. Následující snímek obrazovky ukazuje, jak monitorovat využití úložiště zálohování pro jednoúčelovou databázi.

Snímek obrazovky znázorňující výběry pro monitorování využití zálohování databází v Azure Portal

Pokyny k monitorování spotřeby v hyperškálování najdete v tématu Monitorování využití zálohování Hyperscale.

Optimalizace využití úložiště zálohování

Za využití úložiště zálohování až do maximální velikosti dat v databázi se neúčtují žádné poplatky. Nadměrné využití úložiště zálohování závisí na zatížení a maximální velikosti jednotlivých databází. Pokud chcete snížit spotřebu úložiště zálohování, zvažte některé z následujících technik ladění:

  • Zkraťte dobu uchovávání záloh na minimum pro vaše potřeby.
  • Vyhněte se provádění rozsáhlých operací zápisu, jako je opětovné sestavení indexů, častěji, než je nutné.
  • V případě operací načítání velkých objemů dat zvažte použití clusterovaných indexů columnstore a dodržování souvisejících osvědčených postupů. Zvažte také snížení počtu nes clusterovaných indexů.
  • Na úrovni služby Pro obecné účely je zřízené úložiště dat levnější než cena úložiště zálohování. Pokud máte neustále vysoké nadměrné náklady na úložiště zálohování, můžete zvážit zvětšení úložiště dat, abyste ušetřili úložiště zálohování.
  • K ukládání dočasných výsledků nebo přechodných dat použijte tempdb v aplikační logice místo trvalých tabulek.
  • Kdykoli je to možné, používejte místně redundantní úložiště zálohování (například vývojová a testovací prostředí).

Uchování záloh

Azure SQL Database poskytuje krátkodobé i dlouhodobé uchovávání záloh. Krátkodobé uchovávání umožňuje obnovení k určitému bodu v čase během doby uchovávání databáze. Dlouhodobé uchovávání poskytuje zálohy pro různé požadavky na dodržování předpisů.

Krátkodobé uchovávání

Pro všechny nové, obnovené a zkopírované databáze uchovává Azure SQL Database ve výchozím nastavení dostatečné zálohy, které umožňují obnovení k určitému bodu v čase během posledních 7 dnů. Služba provádí pravidelné úplné, rozdílové a protokolové zálohy, aby se zajistilo, že databáze budou obnovitelné k libovolnému bodu v čase v rámci doby uchovávání definované pro databázi.

Krátkodobé uchovávání záloh 1 až 35 dnů pro databáze Hyperscale je teď ve verzi Preview. Další informace najdete v tématu Správa uchovávání záloh v Hyperscale.

Rozdílové zálohování je možné nakonfigurovat tak, aby probíhalo jednou za 12 hodin nebo jednou za 24 hodin. 24hodinová frekvence rozdílového zálohování může v porovnání s 12hodinovou frekvencí prodloužit dobu potřebnou k obnovení databáze. V modelu virtuálních jader je výchozí frekvence rozdílového zálohování jednou za 12 hodin. V modelu DTU je výchozí frekvence jednou za 24 hodin.

Můžete zadat možnost redundance úložiště zálohování pro STR při vytváření databáze a později ji změnit. Pokud po vytvoření databáze změníte možnost redundance zálohování, budou nové zálohy používat novou možnost redundance. Záložní kopie vytvořené pomocí předchozí možnosti redundance STR se nepřesouvají ani nekopírují. Zůstanou v původním účtu úložiště, dokud nevyprší období uchovávání, což může být 1 až 35 dnů.

S výjimkou databází úrovně Basic můžete změnit dobu uchovávání záloh pro každou aktivní databázi v rozsahu 1 až 35 dnů. Jak je popsáno v tématu Využití úložiště zálohování, zálohy uložené pro povolení obnovení k určitému bodu v čase můžou být starší než doba uchovávání. Pokud potřebujete uchovávat zálohy po dobu delší, než je maximální doba krátkodobého uchovávání 35 dnů, můžete povolit dlouhodobé uchovávání.

Pokud odstraníte databázi, systém bude uchovávat zálohy stejným způsobem jako u online databáze s konkrétní dobou uchovávání. U odstraněné databáze není možné změnit dobu uchovávání záloh.

Důležité

Pokud odstraníte server, odstraní se také všechny databáze na daném serveru a nebude možné je obnovit. Odstraněný server nejde obnovit. Pokud jste ale pro databázi nakonfigurovali dlouhodobé uchovávání, zálohy LTR se neodstraní. Tyto zálohy pak můžete použít k obnovení databází na jiném serveru ve stejném předplatném k bodu v čase, kdy byla pořízena záloha LTR. Další informace najdete v tématu Obnovení dlouhodobé zálohy.

Dlouhodobé uchovávání

Pro SQL Database můžete v Azure Blob Storage nakonfigurovat úplné zálohy LTR až na 10 let. Po nakonfigurování zásad LTR se úplné zálohy automaticky každý týden zkopírují do jiného kontejneru úložiště.

Pokud chcete splnit různé požadavky na dodržování předpisů, můžete pro týdenní, měsíční nebo roční úplné zálohy vybrat různé doby uchovávání. Četnost závisí na zásadách. Nastavení W=0, M=1 by například vytvořilo kopii LTR měsíčně. Další informace o LTR najdete v tématu Dlouhodobé uchovávání.

Při aktualizaci redundance úložiště zálohování pro existující databázi se změna projeví pouze u následných záloh pořízených v budoucnu, a ne u existujících záloh. Všechny existující zálohy LTR databáze se budou dál nacházet v existujícím objektu blob úložiště. Nové zálohy se budou replikovat na základě nakonfigurované redundance úložiště zálohování.

Spotřeba úložiště závisí na vybrané frekvenci a době uchovávání záloh LTR. K odhadu nákladů na úložiště LTR můžete použít cenovou kalkulačku LTR.

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

Cena za úložiště zálohování se liší a závisí na vašem nákupním modelu (DTU nebo virtuální jádro), zvolené možnosti redundance úložiště zálohování a oblasti. Úložiště zálohování se účtuje na základě gigabajtů spotřebovaných měsíčně za všechny zálohy stejnou sazbou.

Redundance úložiště zálohování ovlivňuje náklady na zálohování následujícím způsobem:

  • Locally redundant price = published price
  • Zone-redundant price = published price x 1.25
  • Geo-redundant price = published price x 2

Informace o cenách najdete na stránce s cenami služby Azure SQL Database.

Poznámka

Na faktuře Za Azure se zobrazuje pouze nadměrná spotřeba úložiště zálohování, nikoli celá spotřeba úložiště zálohování. Pokud jste například v hypotetické situaci zřídili 4 TB datového úložiště, získáte 4 TB volného místa v úložišti zálohování. Pokud využijete celkem 5,8 TB prostoru úložiště zálohování, na faktuře Azure se zobrazí pouze 1,8 TB, protože se vám bude účtovat jenom využité nadbytečné úložiště zálohování.

Model DTU

V modelu DTU se za úložiště zálohování databází a elastických fondů neúčtují žádné další poplatky. Cena úložiště zálohování je součástí ceny databáze nebo fondu.

Model virtuálních jader

Azure SQL Database vypočítá celkové úložiště fakturovatelného zálohování jako kumulativní hodnotu pro všechny záložní soubory. Tato hodnota se každou hodinu hlásí do fakturačního kanálu Azure. Kanál agreguje toto hodinové využití, aby získal využití úložiště zálohování na konci každého měsíce.

Pokud dojde k odstranění databáze, spotřeba úložiště zálohování bude postupně klesat, protože starší zálohy stárnou a odstraní se. Vzhledem k tomu, že rozdílové zálohy a zálohování protokolů vyžadují, aby bylo možné obnovit dřívější úplné zálohování, vymazávají se všechny tři typy záloh společně v týdenních sadách. Po odstranění všech záloh se fakturace zastaví.

Náklady na úložiště zálohování se pro databáze Hyperscale počítají jinak. Další informace najdete v tématu Náklady na úložiště zálohování hyperškálování.

U jednoúčelových databází je velikost úložiště zálohování rovnající se 100 procentům maximální velikosti úložiště dat databáze poskytována bez dalších poplatků. K výpočtu celkového fakturovatelného úložiště zálohování se používá následující rovnice:

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

Pro elastické fondy je velikost úložiště zálohování, která se rovná 100 procentům maximálního úložiště dat pro velikost úložiště fondu, k dispozici bez dalších poplatků. U databází ve fondu se celková velikost fakturovatelného úložiště zálohování agreguje na úrovni fondu a vypočítá se takto:

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

Celkové úložiště zálohování, pokud existuje, se účtuje v gigabajtech za měsíc podle míry využité redundance úložiště zálohování. Tato spotřeba úložiště zálohování závisí na zatížení a velikosti jednotlivých databází, elastických fondů a spravovaných instancí. Silně upravené databáze mají větší rozdílové zálohy a zálohy protokolů, protože velikost těchto záloh je úměrná množství změněných dat. U takových databází se proto budou účtovat vyšší poplatky za zálohování.

Zjednodušeně předpokládejme, že databáze nashromáždila 744 GB úložiště záloh a že toto množství zůstává konstantní po celý měsíc, protože databáze je zcela nečinná. Pokud chcete tuto kumulativní spotřebu úložiště převést na hodinové využití, vydělte ji 744,0 (31 dní za měsíc krát 24 hodin za den). SQL Database bude do fakturačního kanálu Azure hlásit, že databáze spotřebovala 1 GB zálohy k určitému bodu v čase každou hodinu a konstantní rychlostí. Fakturace Azure tuto spotřebu agreguje a zobrazí využití 744 GB za celý měsíc. Náklady budou založeny na sazbě za gigabajty za měsíc ve vaší oblasti.

Tady je další příklad. Předpokládejme, že se doba uchovávání stejné nečinné databáze v polovině měsíce zvýšila ze 7 na 14 dnů. Toto zvýšení má za následek zdvojnásobení celkového úložiště zálohování na 1 488 GB. SQL Database by hlásilo využití 1 GB za hodiny 1 až 372 (první polovina měsíce). Za hodiny 373 až 744 (druhá polovina měsíce) by hlásil využití jako 2 GB. Toto využití by se agregovalo do konečné faktury ve výši 1116 GB za měsíc.

Skutečné scénáře fakturace zálohování jsou složitější. Vzhledem k tomu, že četnost změn v databázi závisí na zatížení a v průběhu času se mění, bude se lišit i velikost jednotlivých rozdílových záloh a zálohování protokolů. Hodinová spotřeba úložiště zálohování bude odpovídajícím způsobem kolísat.

Každá rozdílová záloha obsahuje také všechny změny provedené v databázi od posledního úplného zálohování. Celková velikost všech rozdílových záloh se tedy v průběhu týdne postupně zvyšuje. Poté, co starší sada úplných, rozdílových záloh a záloh protokolů zastaralá, prudce klesne.

Předpokládejme například, že aktivita náročného zápisu, jako je opětovné sestavení indexu, se spustí těsně po dokončení úplného zálohování. Změny, které provede opětovné sestavení indexu, pak budou zahrnuty:

  • V transakčním protokolu zálohy převzaté za dobu trvání opětovného sestavení.
  • V další rozdílové záloze.
  • V každé rozdílové záloze, dokud nedojde k dalšímu úplnému zálohování.

U posledního scénáře ve větších databázích se při optimalizaci ve službě vytvoří úplná záloha místo rozdílové zálohy, pokud by jinak bylo rozdílové zálohování nadměrně velké. Tím se zmenší velikost všech rozdílových záloh až do následujícího úplného zálohování.

Celkovou spotřebu úložiště zálohování můžete monitorovat pro každý typ zálohování (úplný, rozdílový, transakční protokol) v průběhu času, jak je popsáno v tématu Monitorování spotřeby.

Monitorování nákladů

Informace o nákladech na úložiště zálohování najdete v části Správa nákladů a fakturace v Azure Portal. Vyberte Cost Management a pak vyberte Analýza nákladů. Vyberte požadované předplatné pro Obor a pak následujícím způsobem vyfiltrujte časové období a službu, které vás zajímají:

  1. Přidejte filtr Název služby.

  2. V rozevíracím seznamu vyberte sql Database pro jednoúčelovou databázi nebo fond elastické databáze.

  3. Přidejte další filtr pro podkategorii Měřič.

  4. Pokud chcete monitorovat náklady na zálohování k určitému bodu v čase, vyberte v rozevíracím seznamu úložiště zálohování pitr jednoho nebo elastického fondu pro jednoúčelovou databázi nebo fond elastické databáze. Měřiče se zobrazí pouze v případě, že existuje využití úložiště zálohování.

    Pokud chcete monitorovat náklady na zálohování LTR, vyberte v rozevíracím seznamu úložiště zálohování pro jednoúčelovou databázi nebo fond elastické databáze. Měřiče se zobrazí pouze v případě, že existuje využití úložiště zálohování.

Můžou vás také zajímat podkategorie Úložiště a výpočetní prostředky , ale nesouvisí s náklady na úložiště zálohování.

Snímek obrazovky znázorňující analýzu nákladů na úložiště zálohování

Důležité

Měřiče jsou viditelné pouze pro čítače, které se aktuálně používají. Pokud čítač není k dispozici, je pravděpodobné, že se kategorie právě nepoužívá. Například čítače úložiště nebudou viditelné pro prostředky, které nevyuužijí úložiště. Pokud nedochází k žádnému využití úložiště zálohování k určitému bodu v čase nebo úložišti LTR, nebudou tyto měřiče viditelné.

Další informace najdete v tématu správa nákladů Azure SQL Database.

Šifrované zálohy

Pokud je vaše databáze šifrovaná pomocí transparentního šifrování dat, zálohy se automaticky šifrují v neaktivním uloženém stavu, a to včetně záloh LTR. Všechny nové databáze v Azure SQL mají ve výchozí konfiguraci povolené transparentní šifrování dat. Další informace o transparentním šifrování dat najdete v tématu Transparentní šifrování dat pomocí SQL Database.

Integrita zálohování

Technický tým Azure SQL průběžně automaticky testuje obnovení z automatizovaných záloh databází. Při obnovení k určitému bodu v čase databáze také obdrží kontroly integrity DBCC CHECKDB.

Všechny problémy zjištěné během kontroly integrity budou mít za následek upozornění technickému týmu. Další informace najdete v tématu Integrita dat v SQL Database.

Všechny zálohy databáze se účtují pomocí možnosti CHECKSUM, která zajišťuje další integritu zálohování.

Dodržování předpisů

Při migraci databáze z úrovně služby založené na jednotkách DTU na úroveň služby založenou na virtuálních jádrech se zachová uchovávání PITR, aby se zajistilo, že nedojde k ohrožení zásad obnovení dat vaší aplikace. Pokud výchozí uchovávání nesplňuje vaše požadavky na dodržování předpisů, můžete změnit dobu uchovávání k určitému bodu v čase. Další informace najdete v tématu Změna doby uchovávání záloh k určitému bodu v čase.

Poznámka

Článek Změna nastavení automatizovaného zálohování obsahuje postup odstranění osobních údajů ze zařízení nebo služby a je možné ho použít k podpoře vašich povinností vyplývajících z GDPR. Obecné informace o GDPR najdete v části GDPR v centru zabezpečení Microsoft a v části GDPR portálu Service Trust Portal.

Použití Azure Policy k vynucení redundance úložiště zálohování

Pokud máte požadavky na rezidenci dat, které vyžadují, abyste měli všechna data v jedné oblasti Azure, možná budete chtít vynutit zónově redundantní nebo místně redundantní zálohování databáze SQL pomocí Azure Policy.

Azure Policy je služba, kterou můžete použít k vytváření, přiřazování a správě zásad, které aplikují pravidla na prostředky Azure. Azure Policy pomáhá udržovat tyto prostředky v souladu s vašimi firemními standardy a smlouvami o úrovni služeb. Další informace najdete v tématu Přehled Azure Policy.

Integrované zásady redundance úložiště zálohování

Pokud chcete vynutit požadavky na rezidenci dat na úrovni organizace, můžete k předplatnému přiřadit zásady pomocí Azure Portal nebo Azure PowerShell. Pokud například přiřadíte následující předdefinované zásady, uživatelé v předplatném nebudou moct vytvořit databázi s geograficky redundantním úložištěm zálohování prostřednictvím Azure Portal nebo Azure PowerShell: SQL Database by se měli vyhnout použití redundance zálohování GRS.

Úplný seznam předdefinovaných definic zásad pro SQL Database najdete v referenčních informacích k zásadám.

Důležité

Zásady Azure se nevynucují při vytváření databáze prostřednictvím T-SQL. Pokud chcete určit rezidenci dat při vytváření databáze pomocí jazyka T-SQL, jako vstup pro BACKUP_STORAGE_REDUNDANCY parametr v příkazu CREATE DATABASE použijte LOCAL nebo ZONE.

Další kroky