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

Platí pro:Azure SQL Database

• Azure SQL Database
• Spravovaná instance Azure SQL

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í pomocí automatizovaných záloh databáze.

Co je záloha databáze?

Zálohy databází jsou důležitou 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 nakonfigurované době 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 jednoúčelové databáze i databáze ve fondu.

Pro jiné úrovně služeb než Hyperscale používá Azure SQL Database technologii stroje SQL Serveru k zálohování a obnovení dat. Databáze Hyperscale používají zálohování a obnovení na základě snímků úložiště. U tradiční technologie zálohování SQL Serveru mají větší databáze dlouhou dobu zálohování a obnovení. Při 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ří:

• Úplné zálohování každý týden.
• Rozdílové zálohování každých 12 nebo 24 hodin.
• Zálohy transakčních protokolů se zálohují přibližně každých 10 minut.

Přesná frekvence záloh transakčních protokolů je založená na velikosti výpočetních prostředků a množství databázové aktivity. 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é ani protokolové zálohy. Další informace najdete v tématu Zálohování hyperškálování.

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

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

Ve výchozím nastavení nové databáze ve službě Azure SQL Database ukládají zálohy v geograficky redundantních objektech blob úložiště, které se replikují do spárované oblasti. Geografická redundance pomáhá chránit před výpadky, které ovlivňují úložiště záloh v primární oblasti. Umožňuje také obnovit databáze v jiné oblasti v případě výpadku oblasti.

Azure Portal nabízí možnost prostředí úloh, které pomáhá předdefinovat některá nastavení konfigurace. Tato nastavení je možné přepsat. Tato možnost se vztahuje pouze na stránku portálu Vytvořit databázi SQL .

• Volba vývojového prostředí úloh nastaví možnost redundance úložiště zálohování tak, aby používala místně redundantní úložiště. Místně redundantní úložiště je méně nákladné a je vhodné pro předprodukční prostředí, která nevyžadují redundanci zónového nebo geograficky replikovaného úložiště.
• Volba produkčního prostředí úlohy nastaví redundanci úložiště zálohování na geograficky redundantní úložiště, výchozí nastavení.
• Možnost Prostředí úloh také změní počáteční nastavení výpočetních prostředků, i když se dá přepsat. V opačném případě nemá možnost Prostředí úloh žádný vliv na licencování ani jiné nastavení konfigurace databáze.

Pokud chcete zajistit, aby vaše 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é vaše data udržují v dané oblasti. Nakonfigurovaná redundance úložiště zálohování se použije pro krátkodobé uchovávání záloh (STR) i 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 můžete aktualizovat. Změny, které provedete v existující databázi, se vztahují pouze na 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 použijí.

Pro zálohování 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.

  

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

  

• 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ýsledkem je:

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

  

Upozorňující

• Geografické obnovení je zakázané, jakmile se databáze aktualizuje tak, aby používala místně redundantní nebo zónově redundantní úložiště.
• Diagramy redundance úložiště zobrazují všechny oblasti s více zónami dostupnosti (multi-az). Existují však některé oblasti, které poskytují pouze jednu zónu dostupnosti a nepodporují zónu ZRS.
• 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. Případně můžete použít kopírování databáze. Přečtěte si další informace o zálohování a redundanci úložiště Hyperscale.

Využití záloh

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

• Pomocí webu Azure Portal, Azure PowerShellu, Azure CLI nebo rozhraní REST API obnovte existující databázi k určitému bodu v čase . Tato operace vytvoří novou databázi na stejném serveru jako původní databázi, 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 místo odstranění původní databáze přejmenovat databázi a potom ji přejmenovat na původní název databáze.

• Obnovte odstraněnou databázi k určitému bodu v čase v období uchovávání, včetně času odstranění. Odstraněnou databázi lze 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 zotavení z regionálního výpadku, když nemáte přístup k databázi nebo zálohám v primární oblasti. Vytvoří novou databázi na jakémkoli existujícím serveru v libovolné oblasti Azure.

  Důležité

  Geografické obnovení je dostupné jenom 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 databáze nakonfigurována pomocí zásad LTR. LTR umožňuje obnovit starší verzi databáze pomocí webu Azure Portal, Azure CLI nebo Azure PowerShellu, abyste vyhověli žádosti o dodržování předpisů nebo ke spuštění starší verze aplikace. Další informace najdete v tématu Dlouhodobé uchovávání.

Možnosti a funkce obnovení

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

Vlastnost Backup	PITR	Geografické obnovení	Dlouhodobé uchovávání
Typy zálohování SQL	Full, differential, log.	Nejnovější geograficky replikované kopie záloh obnovení k určitému bodu v čase.	Pouze úplné zálohy
Cíl bodu obnovení (RPO)	10 minut na základě velikosti výpočetních prostředků a množství databázové aktivity.	Až 1 hodinu na základě geografické replikace.*	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 možné nakonfigurovat 7 dní mezi 1 a 35 dny (s výjimkou základních databází, které se dají konfigurovat mezi 1 a 7 dny).	Ve výchozím nastavení povoleno; stejně jako u zdroje.**	Ve výchozím nastavení není povoleno. 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í. Zónově redundantní nebo místně redundantní úložiště můžete nakonfigurovat.
Konfigurace záloh jako neměnných	Nepodporováno	Nepodporováno	Nepodporováno
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 webu Azure Portal	Ano	Ano	Yes
Obnovení přes PowerShell	Ano	Ano	Yes
Obnovení prostřednictvím Azure CLI	Ano	Ano	Yes

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

** Všechny zálohy obnovení k určitému bodu v čase jsou ve výchozím nastavení uložené v geograficky redundantním úložišti, takže geografické obnovení je ve výchozím nastavení povolené.

Alternativním řešením je obnovit nový server a pomocí přesunu prostředku 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. Operace konfigurace zálohování a obnovení můžete prozkoumat pomocí následujících příkladů.

Operace	Azure Portal	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 bodu v čase	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. Tato záloha se obvykle dokončí do 30 minut, ale může trvat déle, když je databáze velká. Například počáteční záloha může trvat déle u obnovené databáze nebo kopie databáze, která by obvykle byla 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 se funkce obnovení k určitému bodu v čase zpřístupní, když se vytvoří počáteční záloha transakčního protokolu, která následuje po vytvoření počáteční úplné zálohy.
• 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 v případě, že se databáze Hyperscale vytvořila 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.

Spotřeba úložiště zálohování

Díky technologii zálohování a obnovení SQL Serveru 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 jednoho úplného zálohování, volitelně jednoho rozdílového zálohování a jednoho nebo více záloh transakčních protokolů.

Azure SQL Database plánuje každou týden jednu úplnou zálohu. Aby systém zajistil obnovení k určitému bodu v průběhu celého období uchovávání, musí uchovávat další úplné, rozdílové a transakční zálohy protokolů po dobu až týdne, než je nakonfigurovaná doba uchovávání.

Jinými slovy, pro každý 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í existovat také nepřerušovaný řetězec rozdílových záloh a záloh transakčních protokolů z tohoto úplného zálohování až do dalšího úplného zálohování.

Databáze Hyperscale 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 poskytování funkcí obnovení k určitému bodu v čase, se automaticky odstraní. Vzhledem k tomu, že rozdílové zálohy a zálohy protokolů vyžadují, aby bylo možné obnovit dřívější úplné zálohování, všechny tři typy zálohování se vyprázdní společně v týdenních sadách.

U všech databází, včetně databází zašifrovaných transparentním šifrováním dat, se komprimují všechny úplné a rozdílové zálohy, aby se snížily náklady na kompresi a náklady na úložiště zálohování. Průměrný poměr komprese záloh je 3 až 4krát. Může však být výrazně nižší nebo vyšší v závislosti na povaze dat a na tom, jestli se v databázi používá komprese dat.

Důležité

U databází zašifrovaných transparentním šifrováním dat nejsou soubory záloh protokolů komprimovány z důvodů výkonu. Zálohy protokolů pro databáze, které nejsou šifrované transparentním šifrováním dat, jsou komprimované.

Azure SQL Database vypočítá celkové využité úložiště zálohování jako kumulativní hodnotu. Každou hodinu se tato hodnota 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 spotřeby na konci každého měsíce. Po odstranění databáze se spotřeba sníží, jakmile se zálohování zmenší a odstraní se. Po odstranění všech záloh a obnovení k určitému bodu v čase už není možné, fakturace se zastaví.

Důležité

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

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

U databází virtuálních jader ve službě Azure SQL Database se úložiště, které každý typ zálohování (úplné, rozdílové a protokoly) využívá, hlásí v podokně monitorování databáze jako samostatnou metriku. Následující snímek obrazovky ukazuje, jak monitorovat spotřebu úložiště zálohování pro jednu databázi.

Pokyny k monitorování spotřeby v Hyperscale najdete v tématu Monitorování spotřeby zálohování Hyperscale.

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

Spotřeba úložiště zálohování až do maximální velikosti dat pro databázi se neúčtuje. Nadbytečná spotřeba úložiště zálohování závisí na úloze a maximální velikosti jednotlivých databází. Zvažte některé z následujících technik ladění, které snižují spotřebu úložiště zálohování:

• Snižte dobu uchovávání záloh na minimum pro vaše potřeby.
• Vyhněte se velkým operacím zápisu, jako jsou opětovné sestavení indexu, častěji, než potřebujete.
• U velkých operací načítání 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 neclusterovaných indexů.
• Ve vrstvě 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é náklady na nadbytečné úložiště zálohování, můžete zvážit zvýšení úložiště dat, abyste ušetřili úložiště záloh.
• Místo trvalých tabulek v logice aplikace používejte tempdb dočasné výsledky nebo přechodná data.
• Pokud je to možné, používejte místně redundantní úložiště zálohování (například vývojové/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 uchová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 azure SQL Database uchovává dostatečné zálohy, které ve výchozím nastavení umožňují obnovení k určitému bodu v čase za posledních 7 dnů. Služba přijímá pravidelné úplné, rozdílové zálohy a zálohy protokolů, aby se zajistilo, že databáze se dají obnovit k libovolnému bodu v čase v době uchovávání, která je definovaná pro databázi.

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

Při vytváření databáze můžete zadat možnost redundance úložiště zálohování pro STR 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é s předchozí možností redundance STR se nepřesouvají ani nekopírují. Zůstanou v původním účtu úložiště, dokud nevyprší doba uchovávání, což může být 1 až 35 dnů.

Dobu uchovávání záloh pro každou aktivní databázi můžete změnit v rozsahu 1 až 35 dnů, s výjimkou základních databází, které lze konfigurovat od 1 do 7 dnů. Jak je popsáno ve spotřebě úložiště služby Backup, 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 déle, než je maximální doba krátkodobého uchovávání 35 dnů, můžete povolit dlouhodobé uchovávání.

Pokud databázi odstraníte, systém uchovává zálohy stejným způsobem jako u online databáze s konkrétní dobou uchovávání. Dobu uchovávání záloh odstraněné databáze nemůžete změnit.

Důležité

Pokud odstraníte server, odstraní se také všechny databáze na daném serveru a nejde 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 určitému bodu v čase při vytvoření zálohy LTR. Další informace najdete v tématu Obnovení dlouhodobé zálohy.

Dlouhodobé uchovávání

Pro SLUŽBU SQL Database můžete nakonfigurovat úplné dlouhodobé uchovávání záloh (LTR) po dobu až 10 let ve službě Azure Blob Storage. Po nakonfigurování zásad LTR se úplné zálohy 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 vybrat různá období uchovávání týdenních, měsíčních nebo ročních úplných záloh. Frekvence závisí na zásadách. Například nastavení W=0, M=1 by vytvořilo kopii LTR měsíčně. Další informace o LTR naleznete v tématu Dlouhodobé uchovávání.

Aktualizace redundance úložiště zálohování pro existující databázi použije změnu pouze na následné zálohy pořízené v budoucnu, a ne pro existující zálohy. Všechny existující zálohy LTR pro databázi se nadále nacházejí v existujícím objektu blob úložiště. Nové zálohy se replikují 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.

Při obnovování databáze Hyperscale ze zálohy LTR je vlastnost škálování čtení zakázaná. Pokud chcete povolit škálování čtení na obnovené databázi, aktualizujte databázi po jejím vytvoření. Při obnovování ze zálohy LTR je potřeba zadat cíl na úrovni služby.

Dlouhodobé uchovávání je možné povolit pro databáze Hyperscale vytvořené nebo migrované z jiných úrovní služby. Pokud se pokusíte povolit LTR pro databázi Hyperscale, která ještě není podporovaná, zobrazí se následující chyba: Došlo k chybě při povolování dlouhodobého uchovávání záloh pro tuto databázi. Pokud chcete povolit dlouhodobé uchovávání záloh, obraťte se prosím na podporu Microsoftu." V takovém případě se obraťte na podporu Microsoftu a vytvořte lístek podpory pro vyřešení tohoto problému.

Ceny úložišť zálohování

Cena úložiště zálohování se liší a závisí na 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 za měsíc, a to stejnou rychlostí pro všechny zálohy.

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

Ceny najdete na stránce s cenami služby Azure SQL Database.

Poznámka:

Na faktuře Za Azure se zobrazuje pouze nadbytečná spotřeba úložiště zálohování, ne 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 úložiště zálohování. Pokud používáte celkem 5,8 TB prostoru úložiště záloh, faktura Azure zobrazuje jenom 1,8 TB, protože se vám účtuje jenom nadbytečné úložiště záloh, které jste použili.

Model DTU

V modelu DTU se pro databáze a elastické fondy neúčtují žádné další poplatky za úložiště zálohování PITR za výchozí uchovávání 7 dní a déle. Cena úložiště zálohování k určitému bodu v čase je součástí ceny databáze nebo fondu.

Důležité

V modelu DTU se databáze a elastické fondy účtují za úložiště zálohování LTR na základě skutečného úložiště spotřebovaného zálohami LTR.

Model virtuálních jader

Azure SQL Database vypočítá celkové fakturovatelné úložiště záloh jako kumulativní hodnotu ve všech záložních souborech. Každou hodinu se tato hodnota hlásí do fakturačního kanálu Azure. Kanál agreguje toto hodinové využití, aby získal spotřebu úložiště záloh na konci každého měsíce.

Pokud dojde k odstranění databáze, spotřeba úložiště záloh se postupně sníží, protože starší zálohy stárnou a odstraní se. Vzhledem k tomu, že rozdílové zálohy a zálohy protokolů vyžadují, aby bylo možné obnovit dřívější úplné zálohování, všechny tři typy zálohování se vyprázdní 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í Hyperscale.

U jednoúčelových databází se za příplatek poskytuje velikost úložiště zálohy rovnající se 100 procentům maximální velikosti úložiště dat pro databázi. Následující rovnice se používá k výpočtu celkového fakturovatelného využití úložiště záloh:

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

V případě elastických fondů se velikost úložiště zálohování rovná 100 procentu maximálního úložiště dat pro velikost úložiště fondu bez dalších poplatků. U databází ve fondu se celková velikost fakturovatelného úložiště záloh 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é fakturovatelné úložiště záloh ( pokud existuje) se účtuje v gigabajtech za měsíc podle míry redundance úložiště zálohování, kterou jste použili. Tato spotřeba úložiště zálohování závisí na úloze 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. Proto mají tyto databáze vyšší poplatky za zálohování.

Ve zjednodušeném příkladu předpokládejme, že databáze nashromáždila 744 GB úložiště záloh a že tato částka zůstává po celý měsíc konstantní, 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 denně). SQL Database každou hodinu hlásí fakturační kanál Azure, který databáze spotřebovala 1 GB zálohy pitR za každou hodinu. Fakturace Azure agreguje tuto spotřebu a zobrazuje využití 744 GB za celý měsíc. Náklady vycházejí z sazby za gigabajty za měsíc ve vaší oblasti.

Tady je další příklad. Předpokládejme, že stejná nečinná databáze se během měsíce zvýší o 7 dní na 14 dnů. Výsledkem tohoto zvýšení je celková velikost úložiště zálohování na dvojnásobek až 1 488 GB. SQL Database hlásí 1 GB využití po dobu hodin 1 až 372 (první polovina měsíce). Nahlásí využití jako 2 GB pro hodiny 373 až 744 (druhá polovina měsíce). Toto využití by se agregovalo na konečnou fakturu 1 116 GB za měsíc.

Scénáře fakturace skutečných záloh jsou složitější. Vzhledem k tomu, že rychlost změn v databázi závisí na úloze a je v průběhu času proměnlivá, velikost jednotlivých rozdílových záloh a zálohování protokolů se také bude lišit. Hodinová spotřeba úložiště záloh odpovídajícím způsobem kolísá.

Každé rozdílové zálohování 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 postupně zvyšuje v průběhu týdne. Pak se výrazně sníží po starší sadě úplných, rozdílových a protokolových záloh se stáčí.

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

• V zálohách transakčního protokolu převzala dobu trvání opětovného sestavení.
• V dalším rozdílovém zálohování.
• V každém rozdílovém zálohování pořízené až do dalšího úplného zálohování.

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

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

Monitorování nákladů

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

1. Přidejte filtr pro název služby.

2. V rozevíracím seznamu vyberte databázi SQL pro jednu databázi nebo fond elastické databáze.

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

4. Pokud chcete monitorovat náklady na zálohování obnovení k určitému bodu v čase, vyberte v rozevíracím seznamu úložiště zálohování s jedním nebo elastickým fondem fondů pitr pro jednu databázi nebo fond elastické databáze. Měřiče se zobrazují jenom v případě, že existuje spotřeba ú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í ltr pro jednu databázi nebo fond elastické databáze. Měřiče se zobrazují jenom v případě, že existuje spotřeba úložiště zálohování.

Podkategorie úložiště a výpočetních prostředků vás také můžou zajímat, ale nejsou spojené s náklady 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í dostupný, je pravděpodobné, že se kategorie aktuálně nepoužívá. Například čítače úložiště nebudou viditelné pro prostředky, které spotřebovávají úložiště. Pokud není k dispozici žádná spotřeba úložiště záloh pitR nebo LTR, tyto měřiče se nezobrazí.

Další informace najdete v tématu Správa nákladů služby 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í služby 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 obdrží databáze také kontroly integrity DBCC CHECKDB.

Všechny problémy zjištěné během kontroly integrity způsobí upozornění technickému týmu. Další informace naleznete v tématu Integrita dat ve službě SQL Database.

Všechny zálohy databáze se provádějí s možností CHECKSUM, aby se zajistila další integrita zálohování.

Splně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í bodu obnovení k určitému bodu v čase. Další informace najdete v tématu Změna doby uchovávání záloh obnovení k určitému bodu v čase.

Poznámka:

Článek o nastavení automatického zálohování změn obsahuje postup odstranění osobních údajů ze zařízení nebo služby a lze je použít k podpoře vašich povinností v rámci GDPR. Obecné informace o GDPR naleznete v části GDPR Centra zabezpečení společnosti Microsoft a části GDPR 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 všechna data zachovali v jedné oblasti Azure, můžete pomocí služby Azure Policy vynutit zónově redundantní nebo místně redundantní zálohy pro vaši databázi SQL.

Azure Policy je služba, kterou můžete použít k vytváření, přiřazování a správě zásad, které se vztahují 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 služby Azure Policy.

Předdefinované 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í webu Azure Portal nebo Azure PowerShellu. 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 webu Azure Portal nebo Azure PowerShellu: SQL Database by se nemělo používat redundanci zálohování GRS.

Úplný seznam předdefinovaných definic zásad pro SLUŽBU 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í T-SQL, použijte jako vstup pro parametr BACKUP_STORAGE_REDUNDANCY v příkazu CREATE DATABASE hodnotu LOCAL nebo ZONE.

Související obsah

• Další informace o dalších řešeních provozní kontinuity služby SQL Database najdete v přehledu provozní kontinuity.
• 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í pomocí záloh nebo obnovení databáze k určitému bodu v čase pomocí PowerShellu.
• Informace o konfiguraci, správě a obnovení z dlouhodobého uchovávání automatizovaných záloh ve službě Azure Blob Storage najdete v tématu Správa dlouhodobého uchovávání záloh.
• Informace o službě Azure SQL Managed Instance najdete v tématu Automatizované zálohy pro službu SQL Managed Instance.