Sdílet prostřednictvím

Automatizované zálohy ve službě Azure SQL Managed Instance

  • Článek

Platí pro: Azure SQL Managed Instance

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

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 jsou automatizované zálohy databází?

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. Se službou Azure SQL Managed Instance se zálohy databázového stroje SQL Serveru automaticky spravují microsoftem a ukládají se do účtů úložiště Azure spravovaných Microsoftem.

Pomocí těchto záloh obnovte databázi k určitému bodu v čase v nakonfigurované době uchovávání až do 35 dnů. Pokud ale vaše pravidla ochrany dat vyžadují, aby vaše zálohy byly k dispozici po delší dobu (až 10 let), můžete pro každou databázi nakonfigurovat zásady dlouhodobého uchovávání (LTR ).

Frekvence zálohování

Spravovaná instance Azure SQL vytvoří:

Frekvence záloh transakčních protokolů závisí na velikosti výpočetních prostředků a množství databázové aktivity. Transakční protokoly se zabíjí přibližně každých 10 minut, ale můžou se lišit. Při obnovování databáze služba určuje, které úplné, rozdílové a transakční zálohy protokolů je potřeba obnovit v příslušném pořadí.

Upozornění

Automatické úplné zálohování se spouští jednou týdně na základě plánu určeného Microsoftem. Zálohy iniciované uživatelem mají prioritu oproti automatickým úplným zálohám, takže dlouhotrvající zálohování jen pro kopírování může ovlivnit načasování dalšího automatického úplného zálohování.

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

Azure SQL Managed Instance ve výchozím nastavení 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é ovlivňují úložiště záloh v primární oblasti. V případě havárie také umožňuje obnovit instanci do jiné oblasti.

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, výpadky sítě nebo napájení nebo masivní přírodní katastrofy.

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. 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í instance a později ji můžete aktualizovat na úrovni instance. Změny, které provedete v existující instanci, se vztahují pouze na budoucí zálohy. Po aktualizaci redundance úložiště zálohování existující instance může trvat až 24 hodin, než se změny použijí. Změny provedené v redundanci úložiště zálohování se vztahují pouze na krátkodobé zálohy. Zásady dlouhodobého uchovávání zdědí možnost redundance krátkodobých záloh při vytváření zásad. Možnost redundance přetrvává u dlouhodobých záloh, i když se možnost redundance pro krátkodobé zálohy následně změní.

Poznámka:

Změna redundance zálohování je operace správy aktualizací, která iniciuje převzetí služeb při selhání.

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 replikace, ale nedoporučujeme ji pro aplikace, které vyžadují vysokou dostupnost nebo odolnost.

    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. Je aktuálně k dispozici 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ýsledkem je:

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

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

  • Geograficky zónově redundantní úložiště (GZRS):: Kombinuje vysokou dostupnost poskytovanou redundancí napříč zónami dostupnosti s ochranou před regionálními výpadky poskytovanými geografickou replikací. Data v účtu GZRS se zkopírují do tří zón dostupnosti Azure v primární oblasti. Data se také replikují do sekundární geografické oblasti pro ochranu před regionálními katastrofami. V této oblasti máte také tři synchronní kopie v jedné zóně dostupnosti, které byly zkopírovány z primární oblasti do sekundární oblasti asynchronně.

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

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 ani GZRS.

Využití záloh

Tyto zálohy rovněž umožňují:

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

Vlastnosti zálohování Obnovení k určitému bodu v čase Geografické obnovení Dlouhodobé uchovávání
Typy zálohování SQL Úplné, rozdílové a transakční zálohy protokolů. Replikované kopie záloh PITR Pouze úplné zálohy.
Cíl bodu obnovení (RPO) Přibližně 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. 1 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í 1 až 35 dní. Ve výchozím nastavení povoleno; stejně jako u zdroje. 2 Ve výchozím nastavení není povoleno. Uchování je až 10 let.
Úložiště Azure 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
Aktualizace zásad3 Musí se shodovat nebo upgradovat Musí se shodovat nebo upgradovat Musí se shodovat nebo upgradovat
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 Podporováno Nepodporováno 4 Nepodporováno 4
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

1 Pro důležité obchodní aplikace, které vyžadují velké databáze a musí zajistit provozní kontinuitu, viz skupiny převzetí služeb při selhání.
2 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, což znamená, že geografické obnovení je ve výchozím nastavení povolené.
3 Zálohy databáze převzaté z instancí nakonfigurovaných pomocí zásad aktualizace SQL Serveru 2022 je možné obnovit do instancí nakonfigurovaných pomocí sql Serveru 2022 nebo vždy aktuálních zásad aktualizace. Zálohy databáze převzaté z instancí nakonfigurovaných pomocí zásad aktualizace Always-up-to-date je možné obnovit pouze do instancí nakonfigurovaných pomocí zásad aktualizace Always-up-to-date.
4 Alternativním řešením je obnovení na nový server a přesun serveru do jiného předplatného pomocí přesunu prostředku.

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 vyzkoušet 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
Obnovení databáze ze služby Azure Blob Storage Spravovaná instance SQL

Plán automatických záloh

Spravovaná instance Azure SQL automaticky spravuje zálohy vytvořením úplných, rozdílových a transakčních záloh protokolů. Tento proces se řídí interním plánem.

Prvotní zálohování

  • Nové databáze: Okamžitě po vytvoření, obnovení databáze nebo provedení změn redundance zálohování se zahájí první úplná záloha. Tato záloha se obvykle dokončí během 30 minut, ale u větších databází může trvat déle.

  • Obnovené databáze: Doba trvání počáteční zálohy obnovených databází se liší a závisí na velikosti databáze. Obnovené databáze nebo kopie databáze, které jsou často větší, mohou vyžadovat více času pro počáteční zálohování.

Důležité

První úplné zálohování nové databáze má přednost před jinými zálohami databáze, takže se jedná o první zálohu pořízenou během prvního úplného okna zálohování. Pokud je okno úplného zálohování již aktivní a další databáze se zálohují, první úplné zálohování nové databáze se provede okamžitě po dokončení úplné zálohy jiné databáze.

Naplánované úplné zálohování

  • Týdenní plán: Systém nastaví týdenní úplné okno zálohování pro celou instanci.
  • Okno úplného zálohování: Toto je určené období při provedení úplného zálohování. I když je cílem systému dokončit úplné zálohování v tomto okně, v případě potřeby může zálohování pokračovat až po naplánovaný čas, dokud se dokončí.
  • Adaptivní plánování: Algoritmus zálohování vyhodnocuje dopad okna zálohování na úlohu přibližně jednou týdně pomocí využití procesoru a vstupně-výstupní propustnosti jako indikátorů. V závislosti na úloze předchozího týdne se může upravit okno úplného zálohování.
  • Konfigurace uživatele: Je důležité si uvědomit, že uživatelé nemůžou změnit ani zakázat plán zálohování.

Důležité

U nové, obnovené nebo zkopírované databáze se funkce obnovení k určitému bodu v čase (PITR) zpřístupní po dokončení počáteční zálohy transakčního protokolu po počáteční úplné zálohování.

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

Plány zálohování spravované instance Azure SQL zahrnují 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í.

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 Managed Instance 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 odstraněné databáze se uchovávají pro obnovení k určitému bodu v čase(PITR), což může zvýšit náklady na úložiště, protože zálohy se uchovávají, i když je databáze odstraněná. Pokud chcete snížit náklady, můžete nastavit dobu uchovávání záloh na 0 dnů, ale jenom pro odstraněné databáze. U běžných databází je minimální doba uchovávání 1 den.

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 databáze na minimum pro vaše potřeby.
  • Vyhněte se provádění velkých operací 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

Spravovaná instance Azure SQL 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í

U všech nových, obnovených a zkopírovaných databází uchovává spravovaná instance Azure SQL dostatek záloh, které ve výchozím nastavení umožňují obnovení k určitému bodu v čase během posledních 7 dnů. Tuto konfiguraci je možné změnit v rozsahu od 1 do 35 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 nebo spravovanou instanci.

Při vytváření instance můžete zadat možnost redundance úložiště zálohování pro STR a později ji změnit. Pokud po vytvoření instance 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í. Jak je popsáno ve spotřebě ú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í, aby se zajistilo přesné obnovení dat.

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í. U odstraněné databáze se však doba uchovávání aktualizuje od 1 do 35 dnů na 0–35 dnů, takže je možné zálohy odstranit ruč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í.

Důležité

Pokud odstraníte spravovanou instanci, odstraní se také všechny databáze v této spravované instanci a nebude možné je obnovit. Odstraněnou spravovanou instanci není možné obnovit. Pokud jste ale nakonfigurovali dlouhodobé uchovávání pro spravovanou instanci, zálohy LTR se neodstraní. Tyto zálohy pak můžete použít k obnovení databází do jiné spravované instance ve stejném předplatném k určitému bodu v čase, kdy byla provedena záloha LTR. Další informace najdete v tématu Obnovení dlouhodobé zálohy.

Dlouhodobé uchovávání

Pomocí služby SQL Managed Instance můžete nakonfigurovat ukládání úplných záloh LTR po dobu až 10 let ve službě Azure Blob Storage. Po nakonfigurování zásad LTR se úplné zálohy automaticky 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. Nastavení W=0, M=1, Y=0 by například vytvořilo měsíční kopii LTR. Další informace o LTR naleznete v tématu Dlouhodobé uchovávání.

Redundance úložiště zálohování LTR ve službě Azure SQL Managed Instance se dědí z redundance úložiště zálohování používané str v době, kdy je definována zásada LTR. Nemůžete ho změnit, i když se v budoucnu změní redundance úložiště zálohování STR.

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.

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

Azure SQL Managed Instance 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í.

Cena úložiště zálohování se liší. Závisí na zvolené možnosti redundance úložiště zálohování a vaší 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
  • Geo-zone-redundant price = published price x 3.4

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

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.

U spravovaných instancí se celková velikost fakturovatelného úložiště záloh agreguje na úrovni instance a vypočítá se takto:

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

Celkové fakturovatelné úložiště záloh ( pokud existuje) se účtuje v gigabajtech za měsíc pro každou oblast podle míry redundance úložiště zálohování, kterou jste použili. Spotřeba úložiště zálohování závisí na úloze a velikosti jednotlivých databází 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 budou mít 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 Managed Instance každou hodinu hlásí fakturační kanál Azure, který databáze spotřebovala 1 GB zálohy pitR 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 Managed Instance 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. Náklady na uchovávání se okamžitě nezvyšuje. Postupně se zvyšují každý den, protože zálohy rostou, dokud nedosáhne maximální doby uchovávání 14 dnů.

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

Aby se snížila velikost všech rozdílových záloh, příliš velké rozdílové zálohy, které překračují 750 GB a jsou rovny 75 % velikosti databáze, se upřednostní na úplné zálohování, pokud bylo poslední úplné zálohování pořízeno před více než 24 hodinami.

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 spravovanou instanci SQL pro spravovanou instanci.

  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í spravované instance pitr. 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 spravovanou instanci SQL – ltr úložiště zálohování. 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í.

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í dostupný, je pravděpodobné, že se kategorie aktuálně nepoužívá. Například čítače spravovaných instancí nebudou k dispozici pro zákazníky, kteří nemají nasazenou spravovanou instanci. Stejně tak nebudou čítače úložiště 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í.

Š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 Managed Instance.

Microsoft je plně zodpovědný za udržování a obměně klíčů pro databáze pomocí klíčů spravovaných službou (SMK). Zálohy, ať už PITR nebo LTR, převzaté z instancí s povoleným transparentním šifrováním dat s povoleným SMK, může microsoft obnovit.

Automatické zálohování uložené v účtech úložiště spravovaných v Azure se automaticky šifruje službou Azure Storage. Přečtěte si další informace o šifrování neaktivních uložených dat ve službě Azure Storage.

Integrita zálohování

Všechny zálohy databáze se provádějí s možností CHECKSUM, aby se zajistila další integrita zálohování. Automatické testování automatizovaných záloh databází technickým týmem Azure SQL není v současné době k dispozici pro azure SQL Managed Instance. Naplánujte testovací obnovení zálohování a databázi DBCC CHECKDB v databázích ve službě SQL Managed Instance kolem vaší úlohy.

I když systém neověřuje integritu záloh, stále existuje integrovaná ochrana záloh, která upozorní Microsoft, pokud dojde k problému se službou zálohování. Kromě toho vás Microsoft podporuje, pokud dojde k problému se zálohováním, jako je například úplné zálohování, služba zálohování se zablokuje, zálohování protokolů je mimo smlouvu SLA nebo pokud je poškozený hardware nebo software zálohování.

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

Pokud máte požadavky na rezidenci dat, které vyžadují zachování všech dat v jedné oblasti Azure, můžete pomocí Azure Policy vynutit zónově redundantní nebo místně redundantní zálohy pro spravovanou instanci 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 na úrovni předplatného nebo skupiny prostředků, nebudou uživatelé v předplatném moct vytvořit spravovanou instanci s geograficky redundantním úložištěm zálohování prostřednictvím webu Azure Portal nebo Azure PowerShellu: Spravované instance SQL by se neměly používat redundanci zálohování GRS.

Úplný seznam předdefinovaných definic zásad pro službu SQL Managed Instance 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 vynutit 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 místní nebo ZÓNu.

Kompatibilita

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.

Další kroky