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

Platí pro:Azure SQL Database

• Azure SQL databáze
• 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ě úložných snímků. U tradiční technologie zálohování SQL Server mají větší databáze dlouhé zálohovací a obnovovací časy. Díky využití snapshotů poskytuje Hyperscale okamžité zálohování a rychlé obnovení bez ohledu na velikost databáze. Další informace najdete v tématu Hyperscale zálohová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álohování transakčních logů závisí na velikosti výpočetní kapacity a množství aktivity v databázi. Když obnovíte databázi, Azure SQL Database určí, které plné, diferenciální a transakční logové zálohy obnovit.

Architektura Hyperscale nevyžaduje úplné, rozdílové ani protokolové zálohy. Další informace najdete v tématu Hyperscale zálohování.

Redundance zálohovacího úložiště

Mechanismus zálohy ukládání uchovává více kopií vašich dat, takže jsou chráněna před plánovanými i 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 úložištích blob, které se replikují do párové 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. Tyto nastavení můžete přepsat. Tato možnost se vztahuje pouze na stránku portálu Vytvořit databázi SQL .

• Volba prostředí pro úlohy vývoje nastaví redundanci ú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í nastaví redundanci úložiště zálohování na geograficky redundantní úložiště, což je výchozí nastavení.
• Volba Workload environment také mění počáteční nastavení pro výpočetní výkon, i když tuto možnost můžete 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.

Aby vaše zálohy zůstaly ve stejné oblasti, kde je vaše databáze nasazena, změňte zálohovací zálohu z výchozího geo-redundantního úložiště na jiné typy úložišť, které uchovávají data v daném regionu. 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.

Zálohovací zálohu si můžete nastavit 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čuje se pro aplikace, které vyžadují odolnost vůči regionální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 na jedno fyzické místo v spárované sekundární oblasti.

  Výsledkem je:

  • Tři synchronizované 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ě.

  

• Geo-Zone redundantní úložiště (GZRS): Geograficky zónově redundantní úložiště (GZRS) kombinuje vysokou dostupnost poskytovanou redundancí napříč zónami dostupnosti (ZRS) s ochranou před regionálními výpadky poskytovanými geografickou replikací (GRS). V GZRS Azure kopíruje vaše zálohy synchronně přes tři dostupné zóny Azure v primární oblasti a asynchronně třikrát na jedno fyzické místo v spárované sekundární oblasti.

  Microsoft doporučuje používat GZRS pro aplikace vyžadující maximální konzistenci, odolnost a dostupnost, vynikající výkon a odolnost pro zotavení po havárii.

  Výsledkem je:

  • Tři synchronní kopie napříč Zóny dostupnosti v primární oblasti.

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

    Následující diagram znázorňuje, jak se vaše data replikují pomocí GZRS nebo RA-GZRS:

  

Upozornění

• 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). Některé regiony však poskytují pouze jednu dostupnostní zónu a ZRS nepodporují.
• Zálohovací zálohu pro databáze Hyperscale můžete nastavit pouze během vytváření. Jakmile je prostředek zřízen, 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 kopii databáze. Přečtěte si další informace o zálohování a redundanci úložiště Hyperscale.

Využití záloh

Používejte automaticky vytvořené zálohy v následujících situací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í. Smazanou databázi můžete obnovit pouze na stejném serveru, kde jste původní databázi vytvořili. Než smažete databázi, Azure SQL Database provede finální zálohu transakčních logů, aby zabránila ztrátě dat.

• Obnovení databáze do jiné geografické oblasti Geo-obnova vám pomůže zotavit se 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 momentálně nepoužíváte geo-replikované zálohy pro databázi, můžete toto nastavení změnit nastavením redundance úložiště záloh.

• Obnovte databázi z konkrétní dlouhodobé zálohy jedné nebo sdílené databáze, pokud je databáze nakonfigurována s LTR politikou. 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í.

Upozornění

Při obnově databáze, pokud je redundance zdrojového úložiště záloh nakonfigurovaná jako geograficky zónově redundantní úložiště (GZRS), nová databáze zdědí konfiguraci zdrojového úložiště záloh, pokud výslovně neurčíte nastavení redundance úložiště záloh. Toto dědění se vztahuje na jakoukoli operaci obnovení, například obnovení k určitému bodu v čase, kopii databáze, geoobnovení a obnovení z dlouhodobé zálohy. Během této operace, pokud cílový region Azure nepodporuje specifickou zálohovací redundanci, obnova selže s odpovídající chybovou zprávou. Tuto chybu můžete zmírnit tím, že explicitně uvedete dostupné možnosti úložiště pro daný region.

Automatické zálohování na sekundárních replikách

Úroveň služeb Business Critical přijímá automatické zálohy ze sekundární repliky. Vzhledem k tomu, že se data replikují mezi procesy SQL Serveru na každém uzlu, služba zálohování provede zálohování z nečitelných sekundárních replik. Tento návrh zajistí, že primární replika zůstane vyhrazená pro hlavní úlohu a sekundární replika pro čtení je vyhrazená pro úlohy jen pro čtení. Automatické zálohování ve služební úrovni Business Critical se většinou provádí ze sekundární repliky. Pokud automatická záloha selže na sekundární replice, zálohovací služba převezme zálohu z primární repliky.

Automatické zálohování sekundárních replik:

• Jsou ve výchozím nastavení povolené.
• Jsou zahrnuty bez dalších nákladů nad cenu dané úrovně služby.
• Přinést lepší výkon a předvídatelnost pro úroveň služby Business Critical.

Poznámka:

Vytvořte žádost o podporu Microsoftu, abyste požádali o deaktivaci funkce pro vaši instanci.

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

Informace o časech obnovení naleznete v části RTO a RPO.

Záložní vlastnost	Obnovení bodu v čase (PITR)	Geografické obnovení	LTR
Typy zálohování SQL	Úplná, diferenciální, protokol.	Nejnovější geograficky replikované kopie záloh PITR.	Pouze úplné zálohy
Uchování	Výchozí hodnota je 7 dní, lze ji konfigurovat mezi 1 a 35 dny (s výjimkou základních databází, u kterých lze nastavit hodnotu mezi 1 a 7 dny).	Ve výchozím nastavení je povoleno, stejně jako ve zdroji.2	Ve výchozím nastavení není povoleno. Uchování je možné až po dobu 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, když je redundance úložiště zálohování PITR nastavena na geograficky redundantní nebo geograficky zónově redundantní (GZRS). 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	Supported
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	Nepodporováno3	Nepodporováno3
Obnovení prostřednictvím webu Azure Portal	Ano	Ano	Ano
Obnovení přes PowerShell	Ano	Ano	Ano
Obnovení prostřednictvím Azure CLI	Ano	Ano	Ano

¹ Pro obchodně kritické aplikace, které vyžadují velké databáze a musí zajistit provozní kontinuitu, použijte skupiny převzetí služeb při selhání.
² Všechny PITR zálohy 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í umožněno.
³ Alternativním řešením je obnovit data na nový server a přesunout server do jiného předplatného pomocí přesunu prostředku, nebo použít databázovou kopii mezi předplatnými.

Obnovení databáze ze zálohy

Pro více informací o obnově databáze viz Obnova databáze ze záloh. Pro prozkoumání konfigurace záloh a obnovovacích operací použijte následující příklady.

Operace	Azure Portal	Azure CLI (příkazový řádek nástroje Azure)	Azure PowerShell
Změna uchovávání záloh	SQL databáze Spravovaná instance SQL	SQL databáze Spravovaná instance SQL	SQL databáze Spravovaná instance SQL
Změna dlouhodobého uchovávání záloh	SQL databáze Spravovaná instance SQL	SQL databáze Spravovaná instance SQL	SQL databáze Spravovaná instance SQL
Obnovení databáze z bodu v čase	SQL databáze Spravovaná instance SQL	SQL databáze Spravovaná instance SQL	SQL databáze Spravovaná instance SQL
Obnovení odstraněné databáze	SQL databáze Spravovaná instance SQL	SQL databáze Spravovaná instance SQL	SQL databáze Spravovaná instance SQL

Poznámka:

Obnovení databází mezi úrovní služby Hyperscale a dalšími úrovněmi služby Azure SQL Database se v současné době nepodporuje.

Export databáze

Nemůžete si stáhnout ani přímo přistupovat k automatickým zálohám provedeným službou Azure. Azure tyto zálohy používá pouze pro obnovovací operace.

Pro export Azure SQL Database zvažte jiné alternativy.

• Když potřebujete exportovat databázi pro archivaci nebo přesun na jinou platformu, exportujte schéma databáze a data do souboru BACPAC . Soubor BACPAC je soubor ZIP s příponou BACPAC obsahující metadata a data z databáze. Soubor BACPAC můžete uložit do úložiště Azure Blob nebo do lokálního úložiště na lokálním místě. Později ho můžete importovat zpět do Azure SQL Database, Azure SQL Managed Instance nebo instance SQL Server.
• Službu Azure SQL Database můžete také importovat nebo exportovat pomocí privátního propojení nebo importu nebo exportu služby Azure SQL Database, aniž byste umožnili službám Azure přístup k serveru.

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

První kompletní záloha je naplánována hned po vytvoření nebo obnovení nové 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.

Po první úplné zálohě Azure automaticky plánuje a spravuje všechny další zálohy. Služba SQL Database určuje přesné načasování všech záloh databáze, protože vyrovnává celkovou pracovní zátěž 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.
• Hyperscale databáze jsou chráněny okamžitě po vytvoření, na rozdíl od jiných databází, kde počáteční zálohování trvá nějakou dobu. Ochrana je okamžitá i v případě, že databáze Hyperscale byla vytvořena s velkým množstvím dat prostřednictvím kopírování nebo obnovy. Pro více informací viz Hyperscale automatizované zálohy.

Spotřeba zálohovacího úložiště

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 bylo možné zajistit PITR během celé doby uchovávání, musí Azure uchovávat další plné, diferenciální a transakční logové zálohy až o týden déle, než je nastavená 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í typu Hyperscale.

Azure automaticky maže zálohy, které již nejsou potřeba k poskytování funkcionality PITR. Protože diferenciální zálohy a zálohy protokolu vyžadují pro obnovu dřívější plnou zálohu, Azure odstraňuje všechny tři typy záloh společně po týdenních sadách.

Pro všechny databáze, včetně databází šifrovaných TDE, Azure komprimuje všechny plné i diferenciální zálohy, aby snížil kompresi a náklady na zálohování. Průměrný kompresní poměr záloh je tři až čtyři ku jedné. Může však být 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í šifrovaných TDE Azure nekomprimuje soubory zálohování logů kvůli výkonu. U databází bez TDE jsou logové zálohy komprimovány.

Azure SQL Database vypočítá celkové využité úložiště zálohování jako kumulativní hodnotu. Každou hodinu Azure tuto hodnotu hlásí do fakturačního řetězce. Datový tok je zodpovědný za agregaci tohoto hodinového využití za účelem výpočtu vaší spotřeby na konci každého měsíce. Po smazání databáze spotřeba klesá, protože zálohy se vyčerpávají a jsou mazány. Po odstranění všech záloh a po té, co není možné obnovení k určitému bodu v čase, se fakturace zastaví.

Důležité

Azure uchovává zálohy databáze, aby poskytl PITR i v případě, že databázi smažete. 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 Azure uchovává zálohy pro každou smazanou databázi pokaždé, když ji smažete.

Monitorování spotřeby

U vCore databází v Azure SQL Database panel monitorování databáze hlásí úložiště, které každý typ zálohy (plná, diferenciální a log) spotřebovává 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.

Doladění spotřeby úložiště záloh

Za spotřebu zálohovacího úložiště do maximální velikosti dat v databázi neplatíte. Pro snížení spotřeby zálohovacího úložiště zvažte některé z následujících technik ladě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 zálohovací úložiště, zvažte zvýšení datového úložiště, abyste ušetřili zálohovací úložiště.
• 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í databáze umožňuje obnovení databáze pomocí PITR v rámci doby uchovávání. 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 ve výchozím nastavení uchovává dostatek záloh, aby umožnila PITR v posledních sedmi dnech. Azure SQL Database provádí pravidelné plné, diferenciální a logové zálohy, aby zajistila, že databáze jsou obnovitelné v libovolném okamžiku během doby uchovávání databáze.

Můžete nastavit diferenciální zálohy 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 vCore 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 záložního úložiště pro STR a později ji změnit. Pokud změníte možnost zálohování v existující databázi, nové zálohy použijí novou možnost redundance. Azure nepřesouvá ani nekopíruje záložní kopie vytvořené s předchozí možností krátkodobé redundance. Azure je ponechá v původním úložném účtu až do vypršení doby uchovávání, která může být od 1 do 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ě zálohování, zálohy uložené pro umožnění bodového obnovení v čase (PITR) 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 smažete databázi, Azure uchovává zálohy stejným způsobem pro online databázi s její specifickou dobu uchovávání. Dobu uchovávání záloh odstraněné databáze nemůžete změnit.

Důležité

Pokud smažete logický Azure SQL server, smažete také všechny databáze na tomto logickém serveru. Nemůžete obnovit smazané databáze. Nemůžete obnovit smazaný logický server. Ale pokud jste pro databázi nastavili dlouhodobé uchovávání, zálohy pro dlouhodobé uchovávání se neodstraní. Tyto zálohy pak můžete použít k obnovení databází na jiném logickém serveru ve stejném předplatném, až do okamžiku, kdy byla provedena záloha LTR. Pro více informací viz Obnova 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 Azure automaticky každý týden kopíruje úplné zálohy do jiného úložného kontejneru.

Pro splnění různých požadavků na dodržování předpisů zvolte různé doby uchovávání pro týdenní, měsíční a roční plné zálohy. Frekvence závisí na zásadách. Například nastavení W=0, M=1 vytvoří měsíční kopii LTR. Další informace o LTR naleznete v tématu Dlouhodobé uchovávání.

Aktualizace redundance úložiště záloh u existující databáze se projeví pouze u budoucích záloh, nikoli u existujících záloh. 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. Pomocí cenové kalkulačky LTR odhadnete náklady na úložiště 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ílový úkol úrovně služby.

Můžete povolit dlouhodobé uchovávání databází Hyperscale vytvořených nebo migrovaných z jiných služebních úrovní. 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. Prosím, obraťte se na podporu Microsoft, abyste umožnili dlouhodobé uchovávání záloh." V takovém případě kontaktujte podporu Microsoft a vytvořte tiket na podporu k vyřešení problému.

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

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. Za zálohovací úložiště platíte podle gigabajtů spotřebovaných měsíčně, stejně jako u všech záloh.

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

Poznámka:

Na faktuře Azure se zobrazuje pouze překročená spotřeba úložiště zálohování, ne celá spotřeba úložiště zálohování. Například v hypotetickém scénáři, pokud zpřístupníte 4 TB datového úložiště, získáte 4 TB volného zálohovacího místa. Pokud používáte celkem 5,8 TB zálohovacího úložiště, faktura Azure ukazuje pouze 1,8 TB, protože platíte pouze za přebytečné zálohovací úložiště, které používáte.

Model DTU

V modelu DTU se u databází a elastických fondů neúčtují žádné další poplatky za úložiště záloh PITR při výchozí době uchovávání sedm dní i delší. Cena PITR zálohovacího úložiště je součástí ceny databáze nebo poolu.

V DTU modelu platíte za zálohovací úložiště LTR pro databáze a elastické pooly 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ává celkové fakturovatelné zálohovací úložiště jako kumulativní hodnotu napříč všemi zálohami. Každou hodinu Azure posílá tuto hodnotu do fakturačního řetězce. Pipeline agreguje tuto hodinovou spotřebu, aby určil vaši spotřebu zálohovacího úložiště na konci každého měsíce.

Pokud smažete databázi, spotřeba zálohovacího úložiště postupně klesá, jak starší zálohy zastarávají a jsou mazány. Protože diferenciální zálohy a zálohy protokolu vyžadují pro obnovu dřívější plnou zálohu, Azure odstraňuje všechny tři typy záloh společně po týdenních sadách. Po odstranění všech záloh se fakturace zastaví.

Hyperscale databáze používají odlišnou metodu výpočtu nákladů na zálohovací úložiště. Další informace najdete v tématu Náklady na úložiště zálohování Hyperscale.

U jednotlivých databází získáte zálohovací úložiště odpovídající maximální velikosti datového úložiště pro danou databázi bez dalších poplatků. Následující rovnice vypočítává celkové využití fakturovatelného zálohovacího úložiště:

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

U elastických poolů získáte zálohovací úložiště odpovídající maximálnímu datovému úložišti pro velikost poolu 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

Za celkové fakturovatelné zálohovací úložiště, pokud existuje, platíte za gigabajt za měsíc podle redundance zálohovacího úložiště. Tato spotřeba úložiště zálohování závisí na pracovní zátěži a velikosti jednotlivých databází, elastických skupin 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í.

Jako zjednodušený příklad předpokládejme, že databáze hromadí 744 GB zálohovacího úložiště a toto množství zůstává konstantní po celý měsíc, protože databáze je zcela nevyužitá. 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 hlásí do Azure fakturačního systému, že databáze každou hodinu konstantně spotřebovává 1 GB zálohy PITR. Fakturace Azure agreguje tuto spotřebu a ukazuje 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 u stejné nečinné databáze se v polovině měsíce zvýší doba uchovávání ze 7 dnů na 14 dnů. Výsledkem tohoto zvýšení je, že celkové úložiště zálohy se zdvojnásobilo na 1 488 GB. SQL Database hlásí 1 GB využití pro hodiny 1 až 372 (první polovina měsíce). Ukazuje spotřebu 2 GB pro hodiny od 373 do 744 (druhá polovina měsíce). Tato spotřeba dohromady činí konečný účet 1 116 GB měsíčně.

Skutečné scénáře zálohování fakturace jsou složitější. Protože rychlost změn v databázi závisí na zátěži a je v čase proměnlivá, liší se i velikost každého diferenciálu a zálohování logů. 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 vyřazení starší sady úplných, rozdílových a protokolových záloh.

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í. Úpravy, které indexová přestavba přináší, jsou zahrnuty:

• V zálohách transakčního protokolu provedených během doby 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ém až do provedení dalšího úplného zálohování.

V posledním případě u větších databází optimalizace v Azure vytvoří plnou zálohu místo diferenciální zálohy, pokud by jinak byla diferenciální záloha příliš rozsáhlá. Tato optimalizace snižuje velikost všech diferenciálních záloh až do následné úplné zálohy.

Můžete sledovat celkovou spotřebu úložného prostoru pro zálohy pro každý typ zálohování (plné, rozdílové, transakční logy) v průběhu času, jak je popsáno v 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. Chcete-li monitorovat náklady na PITR zálohování, v rozevíracím seznamu vyberte úložiště pro zálohování jednotlivé databáze nebo elastického fondu pitr. Měřidla se zobrazují jen v případě, že existuje spotřeba záložního úložiště.

   Pokud chcete monitorovat náklady na zálohování LTR, v rozevíracím seznamu vyberte úložiště zálohování LTR pro jednotlivou databázi nebo pružný fond databáze. Měřidla se zobrazují jen v případě, že existuje spotřeba záložního úložiště.

Podkategorie úložiště a výpočty vás také můžou zajímat, ale nejsou spojené s náklady na úložiště pro zálohování.

Důležité

Měřiče jsou viditelné pouze pro čítače, které se aktuálně používají. Pokud není čítač dostupný, je pravděpodobné, že se kategorie aktuálně nepoužívá. Například počítadla skladů nejsou viditelná pro zdroje, které nevyužívají úložiště. Pokud nedochází ke spotřebě úložiště záloh PITR ani LTR, tyto ukazatele nejsou viditelné.

Další informace najdete v tématu Správa nákladů služby Azure SQL Database.

Šifrované zálohy

Pokud šifrujete databázi pomocí TDE, zálohy jsou automaticky šifrovány v klidu, včetně záloh LTR. Všechny nové databáze v Azure SQL mají ve výchozí konfiguraci povolené TDE (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í

Azure SQL Database automaticky řeší určité typy poškození dat pomocí vestavěných technik, když je to potřeba, bez ztráty dat. V Azure SQL Database provádí SQL Database Engine ověřování stránek během záloh spravovaných službou a při každé obnovovací operaci. Všechny problémy zjištěné během kontroly integrity způsobí upozornění technickému týmu.

Jako další vrstvu ochrany můžete testovat obnovu záloh a provádět kontroly integrity. Pro více informací viz Data integrity in Azure SQL Database.

Všechny databázové zálohy využívají CHECKSUM tuto možnost pro zvýšení integrity záloh.

Ochrana záloh

Předplatné Azure vlastněné Microsoft spravuje zálohy Azure SQL Database pomocí bezpečných, interních účtů Azure Storage. K takovým zálohám nemáte přístup zvenčí, takže poskytují silnou izolaci a ochranu dat. V rámci Microsoftu mohou k těmto zálohám přistupovat, vytvářet, kopírovat nebo obnovovat pouze backendové služby. Technici Microsoftu, včetně vývojářů, nemají stálý přístup. Aby se minimalizovalo vystavení a maximalizovalo zabezpečení, může Microsoft získat přístup just-In-Time (JIT) pod přísnými kontrolními mechanismy auditu, pokud je to naprosto nezbytné k řešení konkrétních problémů zákazníků.

Zálohy jsou automaticky mazány po uplynutí doby uchovávání.

Dodržování předpisů prostřednictvím uchovávání záloh

Pokud výchozí doba uchovávání nesplňuje vaše požadavky na soulad s předpisy, změňte dobu uchovávání pro PITR. Pro více informací si přečtěte Změna doby uchovávání záloh PITR.

Když migrujete databázi z DTU založené služby na vCore, migrace zachová PITR retention, aby nebyla ohrožena politika obnovy dat vaší aplikace.

Poznámka:

Pro kroky k odstranění osobních údajů v zálohách Azure SQL Database na podporu vašich povinností podle GDPR viz Změna nastavení automatického zálohování. Obecné informace o GDPR naleznete v části GDPR Centra zabezpečení společnosti Microsoft a části GDPR Service Trust Portal.

Použijte Azure Policy k prosazení redundance při ukládání záloh

Pokud máte požadavky na datovou rezidenci, které vyžadují, abyste všechna data uchovávali v jednom Azure regionu, můžete vynutit zónově redundantní nebo lokálně redundantní zálohy pro vaši SQL databázi 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é se vztahují na prostředky Azure. Azure Policy vám pomáhají udržet tyto zdroje v souladu s vašimi firemními standardy a dohodami 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í

Pro vynucení požadavků na rezidentnost dat na organizační úrovni přiřaďte politiky k předplatnému pomocí portálu Azure nebo Azure PowerShell.

Například pokud povolíte politiku "Azure SQL DB by se měla vyhnout použití GRS zálohování", uživatelé nemohou vytvářet databáze s výchozím úložištěm jako globálně redundantním úložištěm. Politika zabraňuje uživatelům používat GRS a vrací chybovou zprávu "Konfigurace typu záložního úložiště na 'Standard_RAGRS' selhala během vytváření nebo aktualizace databáze."

Pro úplný seznam vestavěných definic politik pro SQL Database viz odkaz na politiku.

Důležité

Politiky Azure nejsou vynucovány při vytváření databáze přes T-SQL. Pro určení datové rezidentity při vytváření databáze pomocí T-SQL použijte LOCAL nebo ZONE jako vstup do parametru BACKUP_STORAGE_REDUNDANCY v příkazu CREATE DATABASE.

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.
• Referenční informace o upravitelných konfiguracích pro Azure SQL Database