Automatizované zálohování – Azure SQL Database & spravované instance SQLAutomated backups - Azure SQL Database & SQL Managed Instance

platí pro: Azure SQL Database spravované instance Azure SQL

Poznámka

Tento článek obsahuje postup pro odstranění osobních údajů ze zařízení nebo služby a je možné ho využít jako podporu vašich závazků v rámci GDPR.This article provides steps for how to delete personal data from the device or service and can be used to support your obligations under the GDPR. Pokud hledáte obecné informace o GDPR, přečtěte si část věnovanou GDPR na portálu Service Trust.If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.

Co je zálohování databáze?What is a database backup?

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 poškozením nebo odstraněním.Database backups are an essential part of any business continuity and disaster recovery strategy, because they protect your data from corruption or deletion. Tyto zálohy umožňují obnovení databáze k určitému bodu v čase v rámci nakonfigurované doby uchování.These backups enable database restore to a point in time within the configured retention period. Pokud vaše pravidla ochrany dat vyžadují, aby vaše zálohy byly dostupné po delší dobu (až 10 let), můžete nakonfigurovat dlouhodobé uchovávání pro databáze s jednou i ve fondu.If your data protection rules require that your backups are available for an extended time (up to 10 years), you can configure long-term retention for both single and pooled databases.

Frekvence zálohováníBackup frequency

SQL Database i spravované instance SQL 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.Both SQL Database and SQL Managed Instance use SQL Server technology to create full backups every week, differential backups every 12-24 hours, and transaction log backups every 5 to 10 minutes. Frekvence zálohování protokolu transakcí je založena na výpočetní velikosti a množství aktivity databáze.The frequency of transaction log backups is based on the compute size and the amount of database activity.

Při obnovení databáze služba Určuje, které zálohy úplného, rozdílového a transakčního protokolu se musí obnovit.When you restore a database, the service determines which full, differential, and transaction log backups need to be restored.

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

Ve výchozím nastavení SQL Database a SQL Managed instance ukládají data v geograficky redundantních objektech BLOB úložiště (RA-GRS), které se replikují do spárované oblasti.By default, SQL Database and SQL Managed Instance store data in geo-redundant (RA-GRS) storage blobs that are replicated to a paired region. To pomáhá chránit před výpadky, které mají vliv na úložiště zálohování v primární oblasti a umožňují obnovit server do jiné oblasti v případě havárie.This helps to protect against outages impacting backup storage in the primary region and allow you to restore your server to a different region in the event of a disaster.

Možnost konfigurace redundance záložního úložiště poskytuje flexibilitu pro výběr mezi místně redundantními, redundantními a geograficky redundantními objekty blob úložiště pro spravovanou instanci SQL nebo SQL Database.The option to configure backup storage redundancy provides the flexibility to choose between locally-redundant, zone-redundant, or geo-redundant storage blobs for a SQL Managed Instance or a SQL Database. 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í (LRS) nebo ZRS (Storage-redundantní) objekty blob úložiště pro zálohy.To ensure that your data stays within the same region where your managed instance or SQL database is deployed, you can change the default geo-redundant backup storage redundancy and configure either locally-redundant (LRS) or zone-redundant (ZRS) storage blobs for backups. Mechanismy redundance úložiště 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.Storage redundancy mechanisms store multiple copies of your data so that it is protected from planned and unplanned events, including transient hardware failure, network or power outages, or massive natural disasters. 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).The configured backup storage redundancy is applied to both short-term backup retention settings that are used for point in time restore (PITR) and long-term retention backups used for long-term backups (LTR).

Pro SQL Database lze redundanci úložiště zálohování nakonfigurovat v době vytváření databáze nebo aktualizovat pro existující databázi. změny provedené v existující databázi platí pouze pro budoucí zálohy.For a SQL Database the backup storage redundancy can be configured at the time of database creation or can be updated for an existing database; the changes made to an existing database apply to future backups only. 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í.After the backup storage redundancy of an existing database is updated, it may take up to 48 hours for the changes to be applied. Všimněte si, že je geografická obnova zakázaná, jakmile se databáze aktualizuje tak, aby používala místní nebo zóny redundantní úložiště.Note that, geo restore is disabled as soon as a database is updated to use local or zone redundant storage.

Důležité

Konfigurace redundance úložiště zálohování během procesu vytváření spravované instance, když je prostředek zřízený, už není možné změnit redundanci úložiště.Configure backup storage redundancy during the managed instance creation process as once the resource is provisioned, it is no longer possible to change the storage redundancy.

Důležité

Redundantní úložiště v zóně je aktuálně dostupné jenom v určitých oblastech.Zone-redundant storage is currently only available in certain regions.

Poznámka

Konfigurovatelná redundance záložního úložiště pro Azure SQL Database je v současnosti všeobecně dostupná jenom v oblasti Azure jihovýchodní Asie.Configurable Backup Storage Redundancy for Azure SQL Database is currently generally available in Southeast Asia Azure region only. Tato funkce ještě není k dispozici pro úroveň škálování.This feature is not yet available for Hyperscale tier.

Využití zálohyBackup usage

Tyto zálohy rovněž umožňují:You can use these backups to:

  • 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.Point-in-time restore of existing database - Restore an existing database to a point in time in the past within the retention period by using Azure portal, Azure PowerShell, Azure CLI, or 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.For SQL Database, this operation creates a new database on the same server as the original database, but uses a different name to avoid overwriting the original database. Po dokončení obnovení můžete původní databázi odstranit.After restore completes, you can delete the original database. Alternativně můžete Přejmenovat původní databázi a pak znovu přejmenovat obnovenou databázi na původní název databáze.Alternatively, you can rename both the original database, and then rename the restored database to the original database name. Podobně pro spravovanou instanci SQL Tato operace vytvoří kopii databáze na stejné nebo jiné spravované instanci v rámci stejného předplatného a stejné oblasti.Similarly, for SQL Managed Instance, this operation creates a copy of the database on the same or different managed instance in the same subscription and same region.
  • 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í.Point-in-time restore of deleted database - Restore a deleted database to the time of deletion or to any point in time within the retention period. Odstraněnou databázi lze obnovit pouze na stejném serveru nebo ve spravované instanci, kde byla vytvořena původní databáze.The deleted database can be restored only on the same server or managed instance where the original database was created. 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.When deleting a database, the service takes a final transaction log backup before deletion, to prevent any data loss.
  • Geografické obnovení - Obnovte databázi do jiné geografické oblasti.Geo-restore - Restore a database to another geographic region. 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.Geo-restore allows you to recover from a geographic disaster when you cannot access your database or backups in the primary region. Vytvoří novou databázi na jakémkoli existujícím serveru nebo spravované instanci v libovolné oblasti Azure.It creates a new database on any existing server or managed instance, in any Azure region.

    Důležité

    Geografické obnovení je dostupné jenom pro databáze SQL nebo spravované instance nakonfigurované s geograficky redundantním úložištěm záloh.Geo-restore is available only for SQL databases or managed instances configured with geo-redundant backup storage.

  • 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).Restore from long-term backup - Restore a database from a specific long-term backup of a single database or pooled database, if the database has been configured with a long-term retention policy (LTR). LTR umožňuje obnovit starou verzi databáze pomocí Azure Portal nebo Azure PowerShell , aby splňovala požadavek na dodržování předpisů nebo spustil starou verzi aplikace.LTR allows you to restore an old version of the database by using the Azure portal or Azure PowerShell to satisfy a compliance request or to run an old version of the application. Další informace najdete v tématu Dlouhodobé uchovávání.For more information, see Long-term retention.

Chcete-li provést obnovení, přečtěte si téma obnovení databáze ze zálohy.To perform a restore, see Restore database from backups.

Poznámka

V Azure Storage pojem replikace označuje kopírování objektů BLOB z jednoho umístění do druhého.In Azure Storage, the term replication refers to copying blobs from one location to another. V jazyce SQL replikace databáze odkazuje na různé technologie, které se používají k synchronizaci více sekundárních databází s primární databází.In SQL, database replication refers to various technologies used to keep multiple secondary databases synchronized with a primary database.

Operaci konfigurace zálohování a obnovení můžete vyzkoušet v následujících příkladech:You can try backup configuration and restore operations using the following examples:

OperaceOperation portál AzureAzure portal Azure PowerShellAzure PowerShell
Změna uchovávání zálohChange backup retention SQL DatabaseSQL Database
Spravovaná instance SQLSQL Managed Instance
SQL DatabaseSQL Database
Spravovaná instance SQLSQL Managed Instance
Změna dlouhodobého uchovávání zálohChange long-term backup retention SQL DatabaseSQL Database
Spravovaná instance SQL – N/ASQL Managed Instance - N/A
SQL DatabaseSQL Database
Spravovaná instance SQLSQL Managed Instance
Obnovení databáze z určitého bodu v časeRestore a database from a point in time SQL DatabaseSQL Database
Spravovaná instance SQLSQL Managed Instance
SQL DatabaseSQL Database
Spravovaná instance SQLSQL Managed Instance
Obnovení odstraněné databázeRestore a deleted database SQL DatabaseSQL Database
Spravovaná instance SQLSQL Managed Instance
SQL DatabaseSQL Database
Spravovaná instance SQLSQL Managed Instance
Obnovení databáze ze služby Azure Blob StorageRestore a database from Azure Blob storage SQL Database – N/ASQL Database - N/A
Spravovaná instance SQL – N/ASQL Managed Instance - N/A
SQL Database – N/ASQL Database - N/A
Spravovaná instance SQLSQL Managed Instance

Plánování zálohováníBackup scheduling

První úplná záloha je naplánována ihned po vytvoření nebo obnovení nové databáze.The first full backup is scheduled immediately after a new database is created or restored. Tato záloha se obvykle dokončí do 30 minut, ale pokud je databáze velká, může trvat déle.This backup usually completes within 30 minutes, but it can take longer when the database is large. Například počáteční záloha může trvat déle na obnovenou databázi nebo kopii databáze, která by obvykle byla větší než nová databáze.For example, the initial backup can take longer on a restored database or a database copy, which would typically be larger than a new database. Po prvním úplném zálohování se naplánují a spravují všechny další zálohy automaticky.After the first full backup, all further backups are scheduled and managed automatically. Přesné časování všech záloh databáze určuje služba SQL Database nebo služba SQL Managed instance, protože vyrovnává celkovou úlohu systému.The exact timing of all database backups is determined by the SQL Database or SQL Managed Instance service as it balances the overall system workload. Nemůžete změnit plán úloh zálohování ani je zakázat.You cannot change the schedule of backup jobs or disable them.

Důležité

V případě nové, obnovené nebo zkopírované databáze bude možnost obnovení k určitému bodu v čase dostupná z doby, kdy se vytvoří počáteční záloha protokolu transakcí, která následuje po počátečním úplném zálohování.For a new, restored, or copied database, point-in-time restore capability becomes available from the time when the initial transaction log backup that follows the initial full backup is created.

Spotřeba úložiště zálohBackup storage consumption

Díky SQL Server technologie zálohování a obnovení vyžaduje obnovení databáze k určitému bodu v čase nepřerušený řetězec zálohy sestávající z jedné úplné zálohy, volitelně jednu rozdílovou zálohu a jednu nebo více záloh protokolu transakcí.With SQL Server backup and restore technology, restoring a database to a point in time requires an uninterrupted backup chain consisting of one full backup, optionally one differential backup, and one or more transaction log backups. Plán zálohování pro SQL Database a SQL Managed instance zahrnuje jednu úplnou zálohu každý týden.SQL Database and SQL Managed Instance backup schedule includes one full backup every week. Proto aby bylo možné povolit PITR v rámci celé doby uchovávání, systém musí ukládat další zálohy úplného, rozdílového a transakčního protokolu až do týden delšího, než je nastavená doba uchování.Therefore, to enable PITR within the entire retention period, the system must store additional full, differential, and transaction log backups for up to a week longer than the configured retention period.

Jinými slovy, pro libovolný bod v čase během doby uchování, musí existovat úplná záloha, která je starší než nejstarší čas doby uchování, a také nepřerušený řetězec rozdílového a záložního zálohování protokolu z tohoto úplného zálohování do dalšího úplného zálohování.In other words, for any point in time during the retention period, there must be a full backup that is older than the oldest time of the retention period, as well as an uninterrupted chain of differential and transaction log backups from that full backup until the next full backup.

Poznámka

Pokud chcete povolit PITR, ukládají se další zálohy až do týden delšího, než je nastavená doba uchování.To enable PITR, additional backups are stored for up to a week longer than the configured retention period. Úložiště zálohování se účtuje stejnou sazbou za všechny zálohy.Backup storage is charged at the same rate for all backups.

Zálohy, které už nejsou potřeba k poskytování funkcí PITR, se automaticky odstraní.Backups that are no longer needed to provide PITR functionality are automatically deleted. 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í.Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets.

Pro všechny databáze, včetně TDE šifrovaných databází, jsou zálohy komprimovány, aby se snížila komprese a náklady úložiště zálohování.For all databases including TDE encrypted databases, backups are compressed to reduce backup storage compression and costs. Průměrná kompresní kompresní poměr je 3-4 časů, ale může 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.Average backup compression ratio is 3-4 times, however it can be significantly lower or higher depending on the nature of the data and whether data compression is used in the database.

Služba SQL Database a SQL Managed instance COMPUTE celkově používala úložiště zálohování jako kumulativní hodnotu.SQL Database and SQL Managed Instance compute your total used backup storage as a cumulative value. Každou hodinu se tato hodnota oznamuje 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.Every hour, this value is reported to the Azure billing pipeline, which is responsible for aggregating this hourly usage to calculate your consumption at the end of each month. Po odstranění databáze se spotřeba sníží, protože stáří záloh vyprší a odstraní se.After the database is deleted, consumption decreases as backups age out and are deleted. Jakmile se všechny zálohy odstraní a PITR už není možné, fakturace se zastaví.Once all backups are deleted and PITR is no longer possible, billing stops.

Důležité

Zálohy databáze jsou zachovány a umožňují PITR i v případě, že byla databáze odstraněna.Backups of a database are retained to enable PITR even if the database has been deleted. Při odstraňování a opětovném vytváření databáze může dojít k úspory nákladů na úložiště a výpočetní prostředky, protože služba uchovává zálohy pro každou odstraněnou databázi, pokaždé, když se odstraní.While deleting and re-creating a database may save storage and compute costs, it may increase backup storage costs, because the service retains backups for each deleted database, every time it is deleted.

Monitorovat spotřebuMonitor consumption

Pro databáze vCore se úložiště spotřebované jednotlivými typy zálohování (úplné, rozdílové a protokolu) hlásí v okně monitorování databáze jako samostatná metrika.For vCore databases, the storage consumed by each type of backup (full, differential, and log) is reported on the database monitoring blade as a separate metric. Následující diagram ukazuje, jak monitorovat spotřebu úložiště zálohování pro jednu databázi.The following diagram shows how to monitor the backup storage consumption for a single database. Tato funkce není pro spravované instance aktuálně k dispozici.This feature is currently not available for managed instances.

Monitorovat spotřebu zálohy databáze v Azure Portal

Doladit spotřebu úložiště zálohováníFine-tune backup storage consumption

Využití úložiště zálohování až do maximální velikosti dat pro databázi se neúčtují.Backup storage consumption up to the maximum data size for a database is not charged. Nadlimitní využití úložiště záloh bude záviset na zatížení a maximální velikosti jednotlivých databází.Excess backup storage consumption will depend on the workload and maximum size of the individual databases. Vezměte v úvahu některé z následujících technik optimalizace, abyste snížili spotřebu úložiště záloh:Consider some of the following tuning techniques to reduce your backup storage consumption:

  • Snižte dobu uchovávání záloh na minimum, co potřebujete.Reduce the backup retention period to the minimum possible for your needs.
  • Vyhněte se provádění rozsáhlých operací zápisu, jako je například opětovné sestavení indexu, častěji než potřebujete.Avoid doing large write operations, like index rebuilds, more frequently than you need to.
  • V případě operací s velkým objemem dat zvažte použití clusterovaných indexů columnstore a následující související osvědčené postupya nebo snižte počet neclusterovaných indexů.For large data load operations, consider using clustered columnstore indexes and following related best practices, and/or reduce the number of non-clustered indexes.
  • Ve vrstvě služby Pro obecné účely zřízené úložiště dat je levnější než cena úložiště zálohování.In the General Purpose service tier, the provisioned data storage is less expensive than the price of the backup storage. Pokud máte průběžné vysoké náklady na úložiště záloh, můžete zvážit zvýšení úložiště dat pro uložení do úložiště zálohování.If you have continually high excess backup storage costs, you might consider increasing data storage to save on the backup storage.
  • Použijte databázi TempDB místo trvalých tabulek v aplikační logice pro ukládání dočasných výsledků nebo přechodných dat.Use TempDB instead of permanent tables in your application logic for storing temporary results and/or transient data.
  • Pokud je to možné, používejte místně redundantní úložiště zálohování (například vývojové a testovací prostředí).Use locally-redundant backup storage whenever possible (for example dev/test environments)

Uchování zálohBackup retention

U všech nových, obnovených a kopírovaných databází jsou Azure SQL Database a Azure SQL Managed instance zachovány dostatečné zálohy, aby ve výchozím nastavení povolovaly PITR během posledních 7 dnů.For all new, restored, and copied databases, Azure SQL Database and Azure SQL Managed Instance retain sufficient backups to allow PITR within the last 7 days by default. S výjimkou databází v rámci škálování můžete změnit dobu uchovávání záloh na každou aktivní databázi v rozsahu 1-35 dne.With the exception of Hyperscale databases, you can change backup retention period per each active database in the 1-35 day range. Jak je popsáno v části spotřeba úložiště zálohy, zálohy uložené do povolit PITR můžou být starší než doba uchování.As described in Backup storage consumption, backups stored to enable PITR may be older than the retention period. Jenom pro Azure SQL Managed instance je možné nastavit míru uchovávání záloh PITR, jakmile se databáze odstraní v rozsahu 0-35 dnů.For Azure SQL Managed Instance only, it is possible to set the PITR backup retention rate once a database has been deleted in the 0-35 days range.

Pokud databázi odstraníte, systém bude uchovávat zálohy stejným způsobem jako online databáze s určitou dobou uchování.If you delete a database, the system keeps backups in the same way it would for an online database with its specific retention period. Nemůžete změnit dobu uchování zálohy pro odstraněnou databázi.You cannot change backup retention period for a deleted database.

Důležité

Odstraníte-li server nebo spravovanou instanci, jsou odstraněny také všechny databáze na tomto serveru nebo spravované instance a nelze je obnovit.If you delete a server or a managed instance, all databases on that server or managed instance are also deleted and cannot be recovered. Odstraněné servery nebo spravované instance se nedají obnovit.You cannot restore a deleted server or managed instance. Pokud jste ale u databáze nebo spravované instance nakonfigurovali dlouhodobé uchovávání dat (LTR), zálohy dlouhodobého uchovávání se neodstraní a dají se použít k obnovení databází na jiném serveru nebo spravované instanci ve stejném předplatném, k určitému bodu v čase, kdy se vytvořila dlouhodobá záloha uchovávání.But if you had configured long-term retention (LTR) for a database or managed instance, long-term retention backups are not deleted, and can be used to restore databases on a different server or managed instance in the same subscription, to a point in time when a long-term retention backup was taken.

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.Backup retention for purposes of PITR within the last 1-35 days is sometimes called short-term backup retention. 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í.If you need to keep backups for longer than the maximum short-term retention period of 35 days, you can enable Long-term retention.

Dlouhodobé uchováváníLong-term retention

V případě SQL Database i SQL spravované instance můžete v úložišti objektů BLOB v Azure nakonfigurovat dlouhodobé uchovávání po dobu až 10 let (LTR).For both SQL Database and SQL Managed Instance, you can configure full backup long-term retention (LTR) for up to 10 years in Azure Blob storage. Po nakonfigurování zásad LTR se všechny zálohy automaticky zkopírují do jiného kontejneru úložiště.After the LTR policy is configured, full backups are automatically copied to a different storage container weekly. 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í.To meet various compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly full backups. Spotřeba úložiště závisí na zvolené četnosti a období uchovávání záloh LTR.Storage consumption depends on the selected frequency and retention periods of LTR backups. Pomocí cenové kalkulačky ltr můžete odhadnout náklady na úložiště ltr.You can use the LTR pricing calculator to estimate the cost of LTR storage.

Důležité

Aktualizace redundance záložního úložiště pro existující Azure SQL Database se týká pouze budoucích záloh provedených pro databázi.Updating the backup storage redundancy for an existing Azure SQL Database, only applies to the future backups taken for the database. Všechny existující zálohy LTR pro databázi budou nadále umístěny v existujícím objektu BLOB úložiště a nové zálohy budou uloženy v požadovaném typu objektu BLOB úložiště.All existing LTR backups for the database will continue to reside in the existing storage blob and new backups will be stored on the requested storage blob type.

Další informace o LTR najdete v tématu dlouhodobé uchovávání záloh.For more information about LTR, see Long-term backup retention.

Náklady na úložištěStorage costs

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.The price for backup storage varies and depends on your purchasing model (DTU or vCore), chosen backup storage redundancy option, and also on your region. Úložiště zálohování se účtuje za GB za měsíc spotřebovaný. ceny najdete na stránce s cenami Azure SQL Database a na stránce s cenami Azure SQL Managed instance .The backup storage is charged per GB/month consumed, for pricing see Azure SQL Database pricing page and Azure SQL Managed Instance pricing page.

Model DTUDTU model

V modelu DTU se za úložiště zálohování pro databáze a elastické fondy neúčtují žádné další poplatky.In the DTU model, there's no additional charge for backup storage for databases and elastic pools. Cena za úložiště záloh je součástí ceny databáze nebo fondu.The price of backup storage is a part of database or pool price.

Model virtuálních jadervCore model

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ů.For single databases in SQL Database, a backup storage amount equal to 100 percent of the maximum data storage size for the database is provided at no extra charge. 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ů.For elastic pools and managed instances, a backup storage amount equal to 100 percent of the maximum data storage for the pool or the maximum instance storage size, respectively, is provided at no extra charge.

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:For single databases, this equation is used to calculate the total billable backup storage usage:

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:For pooled databases, the total billable backup storage size is aggregated at the pool level and is calculated as follows:

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:For managed instances, the total billable backup storage size is aggregated at the instance level and is calculated as follows:

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.Total billable backup storage, if any, will be charged in GB/month as per the rate of the backup storage redundancy used. 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í.This backup storage consumption will depend on the workload and size of individual databases, elastic pools, and managed instances. 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 dat.Heavily modified databases have larger differential and log backups, because the size of these backups is proportional to the amount of data changes. Proto budou mít tyto databáze vyšší poplatky za zálohování.Therefore, such databases will have higher backup charges.

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.SQL Database and SQL Managed Instance computes your total billable backup storage as a cumulative value across all backup files. 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.Every hour, this value is reported to the Azure billing pipeline, which aggregates this hourly usage to get your backup storage consumption at the end of each month. 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.If a database is deleted, backup storage consumption will gradually decrease as older backups age out and are deleted. 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í.Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets. Po odstranění všech záloh se ukončí fakturace.Once all backups are deleted, billing stops.

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á.As a simplified example, assume a database has accumulated 744 GB of backup storage and that this amount stays constant throughout an entire month because the database is completely idle. 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ě).To convert this cumulative storage consumption to hourly usage, divide it by 744.0 (31 days per month * 24 hours per day). 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.SQL Database will report to Azure billing pipeline that the database consumed 1 GB of PITR backup each hour, at a constant rate. Fakturace Azure agreguje tuto spotřebu a za celý měsíc ukáže využití 744 GB.Azure billing will aggregate this consumption and show a usage of 744 GB for the entire month. Náklady budou založené na sazbách za GB za GB a měsíc ve vaší oblasti.The cost will be based on the amount/GB/month rate in your region.

Teď je to složitější příklad.Now, a more complex example. Předpokládejme, že stejná databáze s nečinným se zvýšila z 7 dnů na 14 dní uprostřed měsíce.Suppose the same idle database has its retention increased from 7 days to 14 days in the middle of the month. Výsledkem tohoto zvýšení je celková velikost úložiště zálohování od zdvojnásobení až 1 488 GB.This increase results in the total backup storage doubling to 1,488 GB. SQL Database by nahlásil 1 GB využití v hodinách 1 až 372 (první polovina měsíce).SQL Database would report 1 GB of usage for hours 1 through 372 (the first half of the month). Vykazovat využití jako 2 GB po dobu 373 až 744 (druhá polovina měsíce).It would report the usage as 2 GB for hours 373 through 744 (the second half of the month). Toto použití by bylo agregované do konečné faktury 1 116 GB/měsíc.This usage would be aggregated to a final bill of 1,116 GB/month.

Skutečné scénáře fakturace ze zálohy jsou složitější.Actual backup billing scenarios are more complex. 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í.Because the rate of changes in the database depends on the workload and is variable over time, the size of each differential and log backup will vary as well, causing the hourly backup storage consumption to fluctuate accordingly. 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í.Furthermore, each differential backup contains all changes made in the database since the last full backup, thus the total size of all differential backups gradually increases over the course of a week, and then drops sharply once an older set of full, differential, and log backups ages out. For example, if a heavy write activity such as index rebuild has been run just after a full backup completed, then the modifications made by the index rebuild will be included in the transaction log backups taken over the duration of rebuild, in the next differential backup, and in every differential backup taken until the next full backup occurs. 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.For the latter scenario in larger databases, an optimization in the service creates a full backup instead of a differential backup if a differential backup would be excessively large otherwise. Tím se zmenší velikost všech rozdílových záloh až do následujících úplných záloh.This reduces the size of all differential backups until the following full backup.

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.You can monitor total backup storage consumption for each backup type (full, differential, transaction log) over time as described in Monitor consumption.

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

Redundance záložního úložiště ovlivňuje náklady na zálohování následujícím způsobem:Backup storage redundancy impacts backup costs in the following way:

  • LRS Price = xLRS price = x
  • ZRS Price = 1,25 ×ZRS price = 1.25x
  • RA-GRS Price = 2xRA-GRS price = 2x

Další podrobnosti o cenách za úložiště zálohování najdete na stránce s cenami Azure SQL Database a na stránce s cenami Azure SQL Managed instance.For more details about backup storage pricing visit Azure SQL Database pricing page and Azure SQL Managed Instance pricing page.

Důležité

Konfigurovatelná redundance úložiště zálohování pro spravovanou instanci SQL je dostupná ve všech oblastech Azure a aktuálně dostupná v oblasti jihovýchodní Asie – Azure jenom pro SQL Database.Configurable backup storage redundancy for SQL Managed instance is available in all Azure regions and currently available in Southeast Asia Azure region only for SQL Database. U spravované instance se dá zadat jenom během procesu vytváření spravované instance.For Managed Instance it can only be specified during the create managed instance process. Po zřízení prostředku nemůžete změnit možnost redundance úložiště zálohování.Once the resource is provisioned, you cannot change the backup storage redundancy option.

Sledovat nákladyMonitor costs

Pokud chcete pochopit náklady na úložiště zálohování, v Azure Portal klikněte na cost management + fakturace , vyberte cost managementa pak vyberte Analýza nákladů.To understand backup storage costs, go to Cost Management + Billing in the Azure portal, select Cost Management, and then select Cost analysis. Vyberte požadované předplatné jako obora potom vyfiltrujte časový interval a službu, které vás zajímají.Select the desired subscription as the Scope, and then filter for the time period and service that you're interested in.

Přidejte filtr pro název službya potom v rozevíracím seznamu vyberte SQL Database .Add a filter for Service name, and then select sql database in the drop-down list. Filtr podkategorie měřiče použijte k výběru čítače fakturace pro vaši službu.Use the meter subcategory filter to choose the billing counter for your service. Pro izolovanou databázi nebo fond elastické databáze vyberte Single/elastický fond PITR úložiště zálohování.For a single database or an elastic database pool, select single/elastic pool PITR backup storage. V případě spravované instance vyberte mi PITR úložiště zálohování.For a managed instance, select mi PITR backup storage. Podkategorie úložišť a výpočtů vám můžou zajímat i to, že nejsou spojené s náklady na úložiště zálohování.The Storage and compute subcategories might interest you as well, but they're not associated with backup storage costs.

Analýza nákladů na úložiště zálohování

Poznámka

Měřiče jsou viditelné pouze pro čítače, které jsou právě používány.Meters are only visible for counters that are currently in use. Pokud není čítač k dispozici, je pravděpodobná kategorie aktuálně nepoužitá.If a counter is not available, it is likely that the category is not currently being used. Například čítače spravované instance nebudou k dispozici pro zákazníky, kteří nemají nasazenou spravovanou instanci.For example, managed instance counters will not be present for customers who do not have a managed instance deployed. Podobně se nebudou zobrazovat čítače úložiště pro prostředky, které nespotřebovávají úložiště.Likewise, storage counters will not be visible for resources that are not consuming storage.

Šifrovaná zálohováníEncrypted backups

Pokud je databáze zašifrovaná pomocí TDE, zálohy se automaticky zašifrují v klidovém stavu, včetně záloh LTR.If your database is encrypted with TDE, backups are automatically encrypted at rest, including LTR backups. Všechny nové databáze v Azure SQL jsou ve výchozím nastavení nakonfigurované s povoleným TDE.All new databases in Azure SQL are configured with TDE enabled by default. Další informace o TDE najdete v tématu transparentní šifrování dat s SQL Database & spravované instance SQL.For more information on TDE, see Transparent Data Encryption with SQL Database & SQL Managed Instance.

Integrita zálohyBackup integrity

Na průběžném základě technický tým Azure SQL automaticky testuje obnovení automatizovaných záloh databáze.On an ongoing basis, the Azure SQL engineering team automatically tests the restore of automated database backups. (Toto testování není aktuálně k dispozici ve spravované instanci SQL.) Při obnovení k bodu v čase získají databáze také kontroly integrity DBCC CHECKDB.(This testing is not currently available in SQL Managed Instance.) Upon point-in-time restore, databases also receive DBCC CHECKDB integrity checks.

Všechny problémy zjištěné během kontroly integrity budou mít za následek upozornění technickému týmu.Any issues found during the integrity check will result in an alert to the engineering team. Další informace najdete v tématu Integrita dat v SQL Database.For more information, see Data Integrity in 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í.All database backups are taken with the CHECKSUM option to provide additional backup integrity.

Dodržování předpisůCompliance

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.When you migrate your database from a DTU-based service tier to a vCore-based service tier, the PITR retention is preserved to ensure that your application's data recovery policy isn't compromised. 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.If the default retention doesn't meet your compliance requirements, you can change the PITR retention period. Další informace najdete v tématu Změna doby uchování zálohy PITR.For more information, see Change the PITR backup retention period.

Poznámka

Tento článek obsahuje postup pro odstranění osobních údajů ze zařízení nebo služby a je možné ho využít jako podporu vašich závazků v rámci GDPR.This article provides steps for how to delete personal data from the device or service and can be used to support your obligations under the GDPR. Pokud hledáte obecné informace o GDPR, přečtěte si část věnovanou GDPR na portálu Service Trust.If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.

Změna doby uchování zálohy PITRChange the PITR backup retention period

Výchozí dobu uchování zálohy PITR můžete změnit pomocí Azure Portal, PowerShellu nebo REST API.You can change the default PITR backup retention period by using the Azure portal, PowerShell, or the REST API. Následující příklady ukazují, jak změnit PITR uchování na 28 dní.The following examples illustrate how to change the PITR retention to 28 days.

Upozornění

Pokud omezíte dobu uchování, ztratíte možnost obnovení do bodů v čase, který je starší než nová doba uchování.If you reduce the current retention period, you lose the ability to restore to points in time older than the new retention period. Zálohy, které už nejsou potřeba k poskytování PITR v rámci nové doby uchování, se odstraní.Backups that are no longer needed to provide PITR within the new retention period are deleted. Pokud zvýšíte aktuální dobu uchovávání, okamžitě nezískáte možnost obnovení do starších bodů v čase v rámci nové doby uchování.If you increase the current retention period, you do not immediately gain the ability to restore to older points in time within the new retention period. Tuto možnost získáte v průběhu času, protože systém začne uchovávat zálohy déle.You gain that ability over time, as the system starts to retain backups for longer.

Poznámka

Tato rozhraní API budou mít vliv jenom na dobu uchovávání PITR.These APIs will affect only the PITR retention period. Pokud jste nakonfigurovali LTR pro vaši databázi, nebude to mít vliv na.If you configured LTR for your database, it won't be affected. Informace o tom, jak změnit dobu uchování LTR, najdete v tématu dlouhodobé uchovávání.For information about how to change LTR retention periods, see Long-term retention.

Změňte dobu uchování zálohy PITR pomocí Azure PortalChange the PITR backup retention period by using the Azure portal

Pokud chcete změnit dobu uchovávání záloh PITR pro aktivní databáze pomocí Azure Portal, přejděte na server nebo na spravovanou instanci s databázemi, jejichž doba uchovávání se má změnit.To change the PITR backup retention period for active databases by using the Azure portal, go to the server or managed instance with the databases whose retention period you want to change.

Změny uchovávání PITR zálohování pro SQL Database se provádí na stránce serveru na portálu.Changes to PITR backup retention for SQL Database are done on the server page in the portal. Pokud chcete změnit uchovávání PITR pro databáze na serveru, přejděte na okno Přehled serveru.To change PITR retention for databases on a server, go to the server overview blade. V levém podokně vyberte Spravovat zálohy , vyberte databáze v rozsahu změny a pak v horní části obrazovky vyberte Konfigurovat uchování :Select Manage Backups in the left pane, select the databases in scope of your change, and then select Configure retention at the top of the screen:

Změna uchovávání PITR, úrovně serveru

Změna doby uchovávání záloh PITR pomocí prostředí PowerShellChange the PITR backup retention period by using PowerShell

Poznámka

Tento článek je aktualizovaný a využívá nový modul Az Azure PowerShellu.This article has been updated to use the new Azure PowerShell Az module. Můžete dál využívat modul AzureRM, který bude dostávat opravy chyb nejméně do prosince 2020.You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Další informace o kompatibilitě nového modulu Az a modulu AzureRM najdete v tématu Seznámení s novým modulem Az Azure PowerShellu.To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Pokyny k instalaci modulu Az najdete v tématu věnovaném instalaci Azure PowerShellu.For Az module installation instructions, see Install Azure PowerShell.

Důležité

Modul PowerShell AzureRM je stále podporován SQL Database a SQL Managed instance, ale všechny budoucí vývojové prostředí jsou pro modul AZ. SQL.The PowerShell AzureRM module is still supported by SQL Database and SQL Managed Instance, but all future development is for the Az.Sql module. Další informace naleznete v tématu AzureRM. SQL.For more information, see AzureRM.Sql. Argumenty příkazů v modulu AZ jsou v podstatě stejné jako v modulech AzureRm.The arguments for the commands in the Az module are substantially identical to those in the AzureRm modules.

Pro změnu uchovávání záloh PITR pro aktivní databáze SQL Azure použijte následující příklad PowerShellu.To change the PITR backup retention for active Azure SQL Databases, use the following PowerShell example.

# 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

Změňte dobu uchování zálohy PITR pomocí REST APIChange the PITR backup retention period by using the REST API

Ukázková žádostSample request

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

Text požadavkuRequest body

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

Ukázková odpověďSample response

Stavový kód: 200Status code: 200

{
  "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
  }
}

Další informace najdete v tématu REST API uchovávání záloh.For more information, see Backup Retention REST API.

Ukázková žádostSample request

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

Text požadavkuRequest body

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

Ukázková odpověďSample response

Stavový kód: 200Status code: 200

{
  "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
  }
}

Další informace najdete v tématu REST API uchovávání záloh.For more information, see Backup Retention REST API.

Konfigurace redundance úložiště zálohováníConfigure backup storage redundancy

Poznámka

Nastavitelná redundance úložiště pro zálohování pro spravovanou instanci SQL se dá zadat jenom během procesu vytváření spravované instance.Configurable storage redundancy for backups for SQL Managed Instance can only be specified during the create managed instance process. Po zřízení prostředku nemůžete změnit možnost redundance úložiště zálohování.Once the resource is provisioned, you can't change the backup storage redundancy option. Pro SQL Database je verze Public Preview této funkce aktuálně dostupná jenom v oblasti jihovýchodní Asie – Azure.For SQL Database, public preview of this feature is currently only available in Southeast Asia Azure region.

Redundanci úložiště zálohy spravované instance lze nastavit pouze během vytváření instance.A backup storage redundancy of a managed instance can be set during instance creation only. Pro SQL Database může být nastavená při vytváření databáze nebo může být aktualizována pro existující databázi.For a SQL Database it can be set when creating the database or can be updated for an existing database. Výchozí hodnota je geograficky redundantní úložiště (RA-GRS).The default value is geo-redundant storage (RA-GRS). Pro rozdíly v cenách mezi místně redundantními (LRS), ZRS a geograficky redundantním úložištěm zálohování navštivte stránku s cenami spravované instance.For differences in pricing between locally-redundant (LRS), zone-redundant (ZRS) and geo-redundant (RA-GRS) backup storage visit managed instance pricing page.

Konfigurace redundance úložiště zálohování pomocí Azure PortalConfigure backup storage redundancy by using the Azure portal

V Azure Portal můžete v okně vytvořit SQL Database nakonfigurovat redundanci úložiště zálohování.In Azure portal, you can configure the backup storage redundancy on the Create SQL Database blade. Tato možnost je k dispozici v části redundance záložního úložiště.The option is available under the Backup Storage Redundancy section. Otevřít okno pro vytvoření SQL DatabaseOpen Create SQL Database blade

Konfigurace redundance úložiště zálohování pomocí PowerShelluConfigure backup storage redundancy by using PowerShell

Při konfiguraci redundance záložního úložiště při vytváření nové databáze můžete zadat parametr-BackupStoageRedundancy.To configure backup storage redundancy when creating a new database you can specify the -BackupStoageRedundancy parameter. Možné hodnoty jsou geografické, zóna a místní.Possible values are Geo, Zone and Local. Ve výchozím nastavení používají všechny databáze SQL geograficky redundantní úložiště k zálohování.By default, all SQL Databases use geo-redundant storage for backups. Geografická Obnova je zakázaná, pokud je databáze vytvořená s místním nebo záložním úložištěm zálohování zóny.Geo Restore is disabled if a database is created with local or zone redundant backup storage.

# 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

Podrobnosti najdete v New-AzSqlDatabase.For details visit New-AzSqlDatabase.

Pokud chcete aktualizovat redundanci záložního úložiště existující databáze, můžete použít parametr-BackupStorageRedundancy.To update backup storage redundancy of an existing database, you can use the -BackupStorageRedundancy parameter. Možné hodnoty jsou geografické, zóna a místní.Possible values are Geo, Zone and Local. Všimněte si, že může trvat až 48 hodin, než se změny použijí v databázi.Note that, it may take up to 48 hours for the changes to be applied on the database. Přepnutí z geograficky redundantního úložiště zálohování na místní nebo do redundantního úložiště zóny zakáže geografické obnovení.Switching from geo-redundant backup storage to local or zone redundant storage disables geo restore.

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

Podrobnosti najdete v sadě set-AzSqlDatabase .For details visit Set-AzSqlDatabase

Poznámka

Pokud chcete použít parametr-BackupStorageRedundancy s obnovením databáze, kopírováním databáze nebo vytvořením sekundárních operací, použijte Azure PowerShell verze AZ. SQL 2.11.0.To use -BackupStorageRedundancy parameter with database restore, database copy or create secondary operations, use Azure PowerShell version Az.Sql 2.11.0.

Použití Azure Policy k vymáhání redundance úložiště zálohováníUse Azure Policy to enforce backup storage redundancy

Pokud máte požadavky na data, které vyžadují, abyste zachovali všechna vaše data v jedné oblasti Azure, můžete pro SQL Database nebo spravovanou instanci vynutit zálohy na základě zóny nebo místně redundantního zálohování pomocí Azure Policy.If you have data residency requirements that require you to keep all your data in a single Azure region, you may want to enforce zone-redundant or locally-redundant backups for your SQL Database or Managed Instance using 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 is a service that you can use to create, assign, and manage policies that apply rules to Azure resources. Azure Policy vám pomůže zajistit, aby tyto prostředky vyhovovaly vašim firemním standardům a smlouvám o úrovni služeb.Azure Policy helps you to keep these resources compliant with your corporate standards and service level agreements. Další informace najdete v tématu přehled Azure Policy.For more information, see Overview of Azure Policy.

Integrované zásady redundance záložního úložištěBuilt-in backup storage redundancy policies

Přidají se nové předdefinované zásady, které se dají přiřadit na úrovni předplatného nebo skupiny prostředků, aby se blokovaly vytváření nových databází nebo instancí s geograficky redundantním úložištěm záloh.Following new built-in policies are added, which can be assigned at the subscription or resource group level to block creation of new database(s) or instance(s) with geo-redundant backup storage.

SQL Database by se nemělo používat redundanci zálohování GRSSQL Database should avoid using GRS backup redundancy

Spravované instance SQL by se neměly používat redundanci GRS BackupSQL Managed Instances should avoid using GRS backup redundancy

Úplný seznam předdefinovaných definic zásad pro SQL Database a spravovanou instanci najdete tady.A full list of built-in policy definitions for SQL Database and Managed Instance can be found here.

K vykonání požadavků na uspořádání dat na úrovni organizace je možné tyto zásady přiřadit k předplatnému.To enforce data residency requirements at an organizational level, these policies can be assigned to a subscription. Po přiřazení na úrovni předplatného nebudou uživatelé v daném předplatném 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.After these are assigned at a subscription level, users in the given subscription will not be able to create a database or a managed instance with geo-redundant backup storage via Azure portal or Azure PowerShell.

Důležité

Při vytváření databáze prostřednictvím T-SQL se neuplatňují zásady Azure.Azure policies are not enforced when creating a database via T-SQL. Pokud chcete vyhodnotit zajistění dat při vytváření databáze pomocí T-SQL, použijte v příkazu CREATE DATABASE možnost Local nebo Zone jako vstup BACKUP_STORAGE_REDUNDANCY parametr.To enforce data residency when creating a database using T-SQL, use 'LOCAL' or 'ZONE' as input to BACKUP_STORAGE_REDUNDANCY paramater in CREATE DATABASE statement.

Naučte se přiřazovat zásady pomocí Azure Portal nebo Azure PowerShellLearn how to assign policies using the Azure portal or Azure PowerShell

Další krokyNext steps