automatizované zálohování – Azure SQL Database & spravované Instance Azure SQL

PLATÍ PRO: Azure SQL Database Azure SQL Managed Instance

Co je zálohování databáze?

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

Frekvence zálohování

SQL Database i SQL spravované Instance používají SQL Server technologie k vytváření úplných záloh každý týden, rozdílové zálohování každých 12-24 hodin a zálohování protokolů transakcí každých 5 až 10 minut. Frekvence zálohování transakčních protokolů závisí na velikosti výpočetních prostředků a množství aktivit databáze.

Když provedete obnovení databáze, služba určí, které úplné zálohy, rozdílové zálohy a zálohy transakčních protokolů je potřeba obnovit.

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

ve výchozím nastavení SQL Database a SQL spravované Instance ukládají data 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é mají vliv na úložiště zálohování v primární oblasti, a umožňuje obnovit server do jiné oblasti v případě havárie.

Možnost konfigurace redundance úložiště zálohování nabízí flexibilitu při výběru mezi místně redundantními, redundantními nebo geograficky redundantními objekty blob úložiště. aby se zajistilo, že vaše data zůstanou ve stejné oblasti, ve které je nasazená vaše spravovaná instance nebo databáze SQL, můžete změnit výchozí geograficky redundantní záložní úložiště záloh a nakonfigurovat místně redundantní úložiště nebo objekty blob redundantní pro zóny pro zálohování. Storage mechanismy redundance ukládají více kopií vašich dat, aby byly chráněné před plánovanými i neplánovanými událostmi, včetně přechodného selhání hardwaru, sítě nebo výpadků napájení nebo obrovského přirozeného katastrofy. Nakonfigurovaná redundance záložního úložiště se používá pro nastavení krátkodobého uchovávání záloh, která se používají pro obnovení v časovém intervalu (PITR) a dlouhodobé zálohy uchovávání dat, které se používají k dlouhodobému zálohování (LTR).

v případě SQL Database lze redundanci úložiště zálohování nakonfigurovat v době vytváření databáze nebo může být aktualizována pro existující databázi. změny provedené v existující databázi platí pouze pro budoucí zálohy. Po aktualizaci redundance záložního úložiště existující databáze může trvat až 48 hodin, než se změny použijí. Geografické obnovení je zakázané, jakmile se databáze aktualizuje tak, aby používala místní nebo zóny redundantního úložiště.

Využití zálohy

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

• Obnovení existující databáze - v daném časovém okamžiku obnovte stávající databázi k určitému bodu v čase v minulosti v době uchování pomocí Azure Portal, Azure PowerShell, Azure CLI nebo REST API. v případě SQL Database tato operace vytvoří novou databázi na stejném serveru jako původní databázi, ale používá jiný název, aby nedošlo k přepsání původní databáze. Po dokončení obnovení můžete původní databázi odstranit. Alternativně můžete Přejmenovat původní databázi a pak znovu přejmenovat obnovenou databázi na původní název databáze. podobně pro SQL spravované instance tato operace vytvoří kopii databáze na stejné nebo jiné spravované instanci ve stejném předplatném a stejné oblasti.
• Obnovení odstraněné databáze - v okamžiku v čase Obnovení odstraněné databáze do doby odstranění nebo do libovolného bodu v čase v rámci doby uchování. Odstraněnou databázi lze obnovit pouze na stejném serveru nebo ve spravované instanci, kde byla vytvořena původní databáze. Při odstraňování databáze služba před odstraněním zabere v konečném zálohování protokolu transakcí, aby nedošlo ke ztrátě dat.
• Geografické obnovení - Obnovte databázi do jiné geografické oblasti. Geografické obnovení umožňuje obnovení z geografické havárie, když nemůžete získat přístup k databázi nebo zálohám v primární oblasti. Vytvoří novou databázi na jakémkoli existujícím serveru nebo spravované instanci v libovolné oblasti Azure.

  Důležité

  geografické obnovení je dostupné jenom pro SQL databáze nebo spravované instance nakonfigurované s geograficky redundantním úložištěm záloh.

• Obnovení z dlouhodobého zálohování - Obnovte databázi z určité dlouhodobé zálohy izolované databáze nebo databáze ve fondu, pokud je databáze nakonfigurovaná s použitím dlouhodobých zásad uchovávání informací (LTR). LTR umožňuje obnovit starou verzi databáze pomocí Azure Portal, rozhraní příkazového řádku Azure nebo Azure PowerShell vyhovět žádosti o dodržování předpisů nebo spustit starou verzi aplikace. Další informace najdete v tématu Dlouhodobé uchovávání.

možnosti obnovení a funkce Azure SQL Database a Azure SQL Managed Instance

Tato tabulka shrnuje možnosti a funkce Obnovení bodu v čase (PITR), geografického obnovenía záloh dlouhodobého uchovávání.

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

** Ve výchozím nastavení se všechny zálohy obnovení k obnovení ukládají do geograficky redundantního úložiště. Proto je geografické obnovení ve výchozím nastavení povolené.

*** Alternativním řešením je obnovení na nový server a přesunutí serveru do jiného předplatného pomocí přesunu prostředků.

Obnovení databáze ze zálohy

Pokud chcete provést obnovení, podívejte se na obnovení databáze ze zálohy. Operace konfigurace zálohování a obnovení můžete vyzkoušet pomocí následujících příkladů:

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

První úplné zálohování se naplánuje okamžitě po vytvoření nebo obnovení nové databáze. Tato záloha se obvykle dokončí během 30 minut, ale pokud je databáze velká, může to trvat déle. Například prvotní zálohování může u obnovené databáze nebo kopie databáze trvat déle, což by obvykle bylo větší než u nové databáze. Po prvním úplném zálohování se všechny další zálohy naplánují a spravují automaticky. Přesné načasování všech záloh databáze určuje služba spravované instance SQL Database SQL, protože vyvažuje celkové zatížení systému. Nemůžete změnit plán úloh zálohování ani je zakázat.

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

Při SQL Server zálohování a obnovení vyžaduje obnovení databáze k bodu v čase nepřerušovaný řetěz zálohování, který se skládá z jedné úplné zálohy, volitelně jedné rozdílové zálohy a jednoho nebo více záloh transakčních protokolů. SQL Database a SQL zálohování spravované instance zahrnuje každý týden jednu úplnou zálohu. Aby tedy systém poskytoval obnovení k obnovení v rámci celé doby uchovávání, musí uchovávat další úplné zálohy, rozdílové zálohy a zálohy transakčních protokolů po dobu až jednoho týdne delší, než je nakonfigurovaná doba uchovávání.

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

Zálohy, které už nejsou potřeba k zajištění funkce obnovení k obnovení k více než 10, se automaticky odstraní. Vzhledem k tomu, že rozdílové zálohování a zálohování protokolů vyžadují, aby dřívější úplné zálohování bylo možné obnovit, všechny tři typy záloh se v týdenních sadách vyprázdní společně.

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

SQL Database a SQL Managed Instance vypočítají celkové využité úložiště zálohování jako kumulativní hodnotu. Každou hodinu se tato hodnota hlásí fakturačnímu kanálu Azure, který 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 vypadne stáří záloh a odstraní se. Jakmile se odstraní všechny zálohy a obnovení k obnovení k obnovení už není možné, účtování se zastaví.

Monitorování spotřeby

U databází virtuálních jader se úložiště spotřebované jednotlivými typy zálohování (úplné, rozdílové a protokolové) hlásí v podokně monitorování databáze jako samostatná metrika. Následující diagram ukazuje, jak monitorovat spotřebu úložiště zálohování pro jednu databázi. Tato funkce momentálně není dostupná pro spravované instance.

Vyladění spotřeby úložiště zálohování

Využití ú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áloh bude záviset na zatížení 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í:

• Zkrátit dobu uchovávání záloh na minimální možnou velikost vašich potřeb.
• Vyhněte se provádění velkých operací zápisu, jako jsou opětovné sestavení indexu, častěji, než potřebujete.
• U operací načítání velkých objemů dat zvažte použití clusterovaných indexů columnstore a využití souvisejících osvědčených postupů nebo snížení počtu nes clusterovaných indexů.
• Na Pro obecné účely služby je zřízené úložiště dat levnější než cena za úložiště zálohování. Pokud máte neustále vysoké náklady na úložiště záloh, můžete zvážit zvýšení úložiště dat, abyste ušetřit na úložišti záloh.
• K ukládání dočasných výsledků nebo přechodných dat použijte databázi tempdb místo trvalých tabulek v aplikační logice.
• Kdykoli je to možné, používejte místně redundantní úložiště záloh (například vývojové/testovací prostředí).

Uchování záloh

Azure SQL Database a Azure SQL Managed Instance poskytují krátkodobé i dlouhodobé uchovávání záloh. Krátkodobé zálohy umožňují obnovení k bodu v čase (PITR) s obdobím uchovávání pro databázi, zatímco 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 si Azure SQL Database a spravovaná instance Azure SQL uchovávají dostatek záloh, aby ve výchozím nastavení umožnily obnovení k obnovení k obnovení během posledních sedmi dnů. Pravidelné úplné rozdílové zálohování a zálohování protokolů zajišťuje, aby databáze bylo možné obnovit do libovolného bodu v čase v rámci doby uchovávání definované pro databázi nebo spravovanou instanci. Pro Azure SQL Databases je navíc možné rozdílové zálohování nakonfigurovat na 12hodinovou nebo 24hodinovou frekvenci.

S výjimkou databází úrovně Hyperscale a Basic můžete změnit dobu uchovávání záloh pro každou aktivní databázi v rozmezí 1 až 35 dnů. Jak je popsáno v části Spotřeba úložiště zálohování,zálohy uložené pro povolení obnovení k obnovení k více než delším obdobím uchovávání dat mohou být starší. Pouze pro Azure SQL Managed Instance je možné nastavit míru uchovávání záloh pitr po odstranění databáze v rozsahu 0 až 35 dnů.

Pokud odstraníte databázi, systém zachová zálohy stejným způsobem jako pro online databázi s určitou dobu uchovávání. Dobu uchovávání záloh odstraněné databáze nemůžete změnit.

Uchovávání záloh pro účely PITR během posledních 1-35 dnů se někdy označuje jako krátkodobé uchovávání záloh. Pokud potřebujete uchovat zálohy po dobu delší, než je maximální doba pro krátkodobé uchovávání 35 dní, můžete povolit dlouhodobé uchovávání.

Dlouhodobé uchovávání

u SQL Database i SQL spravované Instance můžete v úložišti objektů Blob v Azure nakonfigurovat dlouhodobou dobu úplného zálohování (LTR) po dobu až 10 let. Po nakonfigurování zásad LTR se všechny zálohy automaticky zkopírují do jiného kontejneru úložiště. Pro splnění různých požadavků na dodržování předpisů můžete pro týdenní, měsíční nebo roční úplné zálohování vybrat jiné doby uchování. Storage spotřeba závisí na zvolené četnosti a období uchovávání záloh LTR. Pomocí cenové kalkulačky ltr můžete odhadnout náklady na úložiště ltr.

Další informace o LTR najdete v tématu dlouhodobé uchovávání záloh.

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

Cena za úložiště zálohování se liší a závisí na vašem nákupním modelu (DTU nebo vCore), zvolené možnosti redundance úložiště zálohování a také ve vaší oblasti. úložiště zálohování se účtuje za GB za měsíc spotřebovaný. ceny najdete na stránce s cenami za Azure SQL Database a na stránce s cenami Azure SQL Managed Instance .

Další informace o nákupech modelů najdete v tématu Volba mezi nákupními modely Vcore a DTU.

Model DTU

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

Model virtuálních jader

u izolovaných databází v SQL Database se hodnota úložiště zálohy rovnající 100% maximální velikosti úložiště dat pro databázi poskytuje bez dalších poplatků. V případě elastických fondů a spravovaných instancí se hodnota úložiště zálohy rovná 100% maximálního úložiště dat pro fond nebo maximální velikost úložiště instance se poskytuje bez dalších poplatků.

V případě izolovaných databází se tato rovnice používá k výpočtu celkového využití fakturovatelných ú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ě databází ve fondu je celková fakturovatelná velikost úložiště záloh agregovaná na úrovni fondu a vypočte 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

V případě spravovaných instancí je celková fakturovatelná velikost úložiště záloh agregovaná na úrovni instance a vypočte 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álohování, pokud je nějaké, se bude účtovat za GB za měsíc podle sazby využité redundance úložiště zálohy. Tato spotřeba úložiště záloh bude záviset na zatížení a velikosti jednotlivých databází, elastických fondů a spravovaných instancí. Vysoce upravované databáze mají větší rozdílové a zaprotokolované zálohy, 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í.

služba SQL Database a SQL Managed Instance počítá vaše celkové fakturovatelné úložiště záloh jako kumulativní hodnotu ve všech zálohovaných souborech. Každou hodinu se tato hodnota oznamuje fakturačnímu kanálu Azure, který agreguje Toto hodinové použití, aby se na konci každého měsíce využívala spotřeba úložiště záloh. Pokud dojde k odstranění databáze, spotřeba úložiště zálohování se postupně sníží, protože staré stáří záloh vyprší a odstraní se. Vzhledem k tomu, že rozdílové zálohy a zálohy protokolů vyžadují, aby se obnovitelné dřívější úplné zálohování, všechny tři typy zálohování se v týdenních sadách vyprázdní. Po odstranění všech záloh se ukončí fakturace.

Jako zjednodušený příklad předpokládáme, že databáze nashromáždila 744 GB úložiště zálohování a tato částka zůstane v celém měsíci konstantní, protože databáze je zcela nečinná. Pokud chcete tuto kumulativní spotřebu úložiště převést na hodinové použití, rozdělte ji o 744,0 (31 dnů za měsíc × 24 hodin denně). SQL Database bude hlásit fakturačnímu kanálu Azure, který databáze využila 1 GB PITR zálohování každou hodinu, a to za ustálenou sazbou. Fakturace Azure agreguje tuto spotřebu a za celý měsíc ukáže využití 744 GB. Náklady budou založené na sazbách za GB za GB a měsíc ve vaší oblasti.

Teď je to složitější příklad. Předpokládejme, že stejná nečinná databáze má za následek zvýšení jejich uchování ze sedmi dnů na 14 dní uprostřed měsíce. Výsledkem tohoto zvýšení je celková velikost úložiště zálohování od zdvojnásobení až 1 488 GB. SQL Database by nahlásil 1 GB využití v hodinách 1 až 372 (první polovina měsíce). Vykazovat využití jako 2 GB po dobu 373 až 744 (druhá polovina měsíce). Toto použití by bylo agregované do konečné faktury 1 116 GB/měsíc.

Skutečné scénáře fakturace ze zálohy jsou složitější. Vzhledem k tomu, že frekvence změn v databázi závisí na zatížení a je v průběhu času proměnná, velikost jednotlivých rozdílů a zálohování protokolů se budou lišit, což způsobí, že se odpovídajícím způsobem mění hodinová spotřeba úložiště zálohování. Kromě toho každá rozdílová záloha obsahuje všechny změny provedené v databázi od posledního úplného zálohování, takže celková velikost všech rozdílných záloh se postupně zvyšuje v průběhu týdne a pak se prudce rozrůstá, jakmile se uvolní starší sada úplných, rozdílových a záložních záloh protokolu. Například pokud je po dokončení úplného zálohování spuštěná operace silného zápisu, jako je třeba opětovné sestavení indexu, pak se změny provedené při opětovném sestavení indexu budou zahrnovat do záloh protokolu transakcí pořízených po dobu trvání opětovného sestavení, v další rozdílové záloze a v každé rozdílové záloze, dokud nedojde k dalšímu úplnému zálohování. Pro druhý scénář ve větších databázích vytvoří optimalizace ve službě úplnou zálohu 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ích úplných záloh.

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

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

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

• místně redundantní cena = x
• zóna – redundantní cena = 1,25 ×
• geograficky redundantní cena = 2x

další podrobnosti o cenách úložiště zálohování najdete na stránce s cenami Azure SQL Database a na stránce Azure SQL Managed Instance.

Sledovat náklady

Pokud chcete pochopit náklady na úložiště zálohování, v Azure Portal klikněte na cost management + fakturace , vyberte cost management a pak vyberte Analýza nákladů. Vyberte požadované předplatné jako obor a potom vyfiltrujte časový interval a službu, které vás zajímají.

Přidejte filtr pro název služby a potom v rozevíracím seznamu vyberte SQL Database . Filtr podkategorie měřiče použijte k výběru čítače fakturace pro vaši službu. Pro izolovanou databázi nebo fond elastické databáze vyberte Single/elastický fond PITR úložiště zálohování. V případě spravované instance vyberte mi PITR úložiště zálohování. podkategorie Storage a compute by vás mohly zajímat, ale nejsou spojené s náklady na úložiště zálohování.

další informace najdete v tématu Azure SQL Database cost management.

Šifrovaná zálohování

Pokud je databáze zašifrovaná pomocí TDE, zálohy se automaticky zašifrují v klidovém stavu, včetně záloh LTR. všechny nové databáze ve službě Azure SQL jsou ve výchozím nastavení nakonfigurované s povoleným TDE. další informace o TDE najdete v tématu transparentní šifrování dat SQL Database & SQL Managed Instance.

Integrita zálohy

na průběžném základě tým Azure SQL engineering automaticky testuje obnovení automatizovaných záloh databáze. (toto testování není aktuálně k dispozici ve SQL Managed Instance. měli byste naplánovat příkaz DBCC CHECKDB ve vašich databázích v SQL Managed Instance, která je naplánovaná na vaše zatížení.)

Při obnovení k bodu v čase získají databáze také kontroly integrity DBCC CHECKDB.

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

Všechny zálohy databáze jsou pořízeny s možností KONTROLNÍho SOUČTu, která poskytuje další integritu zálohování.

Dodržování předpisů

Při migraci databáze z úrovně služby založené na DTU na úroveň služby založené na vCore se uchování PITR zachová, aby se zajistilo ohrožení zásad obnovení dat vaší aplikace. Pokud výchozí doba uchovávání nevyhovuje vašim požadavkům na dodržování předpisů, můžete změnit dobu uchování PITR. Další informace najdete v tématu Změna doby uchování zálohy PITR.

Změna krátkodobé zásady uchovávání informací

Můžete změnit výchozí dobu uchovávání záloh PITR a rozdílovou četnost záloh pomocí Azure Portal, PowerShellu nebo REST API. Následující příklady ukazují, jak změnit PITR uchování na 28 dní a rozdílové zálohy na interval 24 hodin.

Změna zásad krátkodobého uchovávání pomocí Azure Portal

Pokud chcete změnit dobu uchovávání zálohy obnovení k obnovení nebo frekvenci rozdílového zálohování pro aktivní databáze pomocí Azure Portal, přejděte na server nebo spravovanou instanci s databázemi, jejichž dobu uchovávání chcete změnit. V levém podokně vyberte Zálohy a pak vyberte kartu Zásady uchovávání informací. Vyberte databáze, pro které chcete změnit uchovávání záloh pitr. Pak na panelu akcí vyberte Konfigurovat uchovávání.

Změna zásad krátkodobého uchovávání pomocí Azure CLI

Připravte si prostředí pro Azure CLI.

• V nástroji použijte prostředí Bash Azure Cloud Shell.

  

• Pokud tomu dáváte přednost, můžete nainstalovat Azure CLI a spouštět referenční příkazy CLI.

  • Pokud používáte místní instalaci, přihlaste se k Azure CLI pomocí příkazu az login. Pokud chcete dokončit proces ověřování, postupujte podle kroků zobrazených na terminálu. Další možnosti přihlášení jsou popsané v tématu Přihlášení pomocí Azure CLI.

  • Po zobrazení výzvy nainstalujte rozšíření Azure CLI při prvním použití. Další informace o rozšířeních najdete v tématu Využití rozšíření v Azure CLI.

  • Spuštěním příkazu az version zjistěte verzi a závislé knihovny, které jsou nainstalované. Pokud chcete upgradovat na nejnovější verzi, spusťte az upgrade.

# Set new PITR differential backup frequency on an active individual database
# Valid backup retention must be between 1 and 35 days
# Valid differential backup frequency must be ether 12 or 24
az sql db str-policy set \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --retention-days 28 \
    --diffbackup-hours 24

# Set new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
az sql midb short-term-retention-policy set \
    --resource-group myresourcegroup \
    --managed-instance myinstance \
    --name mymanageddb \
    --retention-days 1 \

# Set new PITR backup retention period for ALL active databases
# Valid backup retention must be between 1 and 35 days
az sql midb short-term-retention-policy set \
    --resource-group myresourcegroup \
    --managed-instance myinstance \
    --retention-days 1 \

Změna zásad krátkodobého uchovávání pomocí PowerShellu

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28

# SET new PITR differential backup frequency on an active individual database
# Valid differential backup frequency must be ether 12 or 24. 
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28 -DiffBackupIntervalInHours 24

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -InstanceName testserver -DatabaseName testDatabase -RetentionDays 1

# SET new PITR backup retention period for ALL active databases
# Valid backup retention must be between 1 and 35 days
Get-AzSqlInstanceDatabase -ResourceGroupName resourceGroup -InstanceName testserver | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 1

# SET new PITR backup retention on an individual deleted database
# Valid backup retention must be between 0 (no retention) and 35 days. Valid retention rate can only be lower than the period of the retention period when database was active, or remaining backup days of a deleted database.
Get-AzSqlDeletedInstanceDatabaseBackup -ResourceGroupName resourceGroup -InstanceName testserver -DatabaseName testDatabase | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 0

# SET new PITR backup retention for ALL deleted databases
# Valid backup retention must be between 0 (no retention) and 35 days. Valid retention rate can only be lower than the period of the retention period when database was active, or remaining backup days of a deleted database
Get-AzSqlDeletedInstanceDatabaseBackup -ResourceGroupName resourceGroup -InstanceName testserver | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 0

Změna zásad krátkodobého uchovávání pomocí REST API

Následující požadavek aktualizuje dobu uchovávání na 28 dnů a také nastaví frekvenci rozdílového zálohování na 24 hodin.

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2021-02-01-preview

{ 
    "properties":{
        "retentionDays":28
        "diffBackupIntervalInHours":24
  }
}

{ 
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
    "diffBackupIntervalInHours":24
  }
}

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2017-10-01-preview

{
  "properties":{
    "retentionDays":28
  }
}

{
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
  }
}

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

Konfigurovatelná redundance úložiště pro SQL Databases je možné nakonfigurovat při vytváření databáze nebo aktualizovat pro existující databázi. Změny provedené v existující databázi se vztahují pouze na budoucí zálohy. Pro SQL spravovanou instanci a redundanci úložiště záloh HyperScale je možné zadat pouze během procesu vytváření. Po zřízení prostředku nemůžete změnit možnost redundance úložiště zálohování. Výchozí hodnota je geograficky redundantní úložiště. Rozdíly v cenách mezi místně redundantním, zónově redundantním a geograficky redundantním úložištěm zálohování najdete na stránce s cenami spravovaných instancí.

Konfigurace redundance úložiště zálohování pomocí Azure Portal

Konfigurace redundance úložiště zálohování pomocí Azure CLI

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier GeneralPurpose \
    --backup-storage-redundancy Local

az sql db update \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --backup-storage-redundancy Local

Konfigurace redundance úložiště zálohování pomocí PowerShellu

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Geo

# Change the backup storage redundancy for Database01 to zone-redundant. 
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Zone

New-AzSqlInstance -Name managedInstance2 -ResourceGroupName ResourceGroup01 -Location westcentralus -AdministratorCredential (Get-Credential) -SubnetId "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/resourcegroup01/providers/Microsoft.Network/virtualNetworks/vnet_name/subnets/subnet_name" -LicenseType LicenseIncluded -StorageSizeInGB 1024 -VCore 16 -Edition "GeneralPurpose" -ComputeGeneration Gen4 -BackupStorageRedundancy Geo

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 uchováte v jedné oblasti Azure, můžete pro svou službu SQL Database nebo spravovanou instanci vynutit zónově redundantní nebo místně redundantní zálohování 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é používají pravidla pro prostředky Azure. Azure Policy pomáhá zajistit, aby tyto prostředky byly v souladu s vašimi firemními standardy a smlouvami o úrovni služeb. Další informace najdete v tématu Přehled Azure Policy.

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

Přidávají se následující nové integrované zásady, které je možné přiřadit na úrovni předplatného nebo skupiny prostředků a blokovat tak vytváření nových databází nebo instancí s geograficky redundantním úložištěm zálohování.

SQL Database byste se měli vyhnout použití redundance záloh GRS.

SQL spravované instance by se neměly používat redundanci záloh GRS

Úplný seznam předdefinových definic zásad pro SQL Database a spravovanou instanci najdete tady.

Pokud chcete vynutit požadavky na rezidenci dat na úrovni organizace, můžete tyto zásady přiřadit k předplatnému. Po přiřazení těchto zásad na úrovni předplatného uživatelé v daném předplatném nebudou moct vytvořit databázi nebo spravovanou instanci s geograficky redundantním úložištěm zálohování prostřednictvím Azure Portal nebo Azure PowerShell.

Naučte se přiřazovat zásady pomocí Azure Portal nebo Azure PowerShell

Další kroky

• Zálohy databází jsou důležitou součástí jakékoli strategie pro provozní kontinuitu a zotavení po havárii, protože chrání vaše data před náhodným poškozením nebo odstraněním. další informace o dalších SQL Database řešení pro provozní kontinuitu najdete v tématu přehled provozní kontinuity.
• Informace o tom, jak nakonfigurovat, spravovat a obnovit dlouhodobé uchovávání automatizovaných záloh v úložišti objektů BLOB v Azure pomocí Azure Portal, najdete v tématu Správa dlouhodobého uchovávání záloh pomocí Azure Portal.
• Informace o tom, jak nakonfigurovat, spravovat a obnovit dlouhodobé uchovávání automatizovaných záloh v úložišti objektů BLOB v Azure pomocí PowerShellu, najdete v tématu Správa dlouhodobého uchovávání záloh pomocí PowerShellu.
• Získejte další informace o tom, jak obnovit databázi k určitému bodu v čase pomocí Azure Portal.
• Získejte další informace o tom, jak obnovit databázi k určitému bodu v čase pomocí prostředí PowerShell.
• další informace o spotřebě úložiště zálohování na spravované instanci Azure SQL najdete v tématu o spotřebě úložiště zálohování na spravované instanci.
• další informace o tom, jak vyladit uchovávání a náklady úložiště záloh pro Azure SQL Managed instance, najdete v tématu jemné vyladění nákladů na úložiště zálohování ve spravované instanci.