Automatizované zálohyAutomated backups

SQL Database automaticky vytvoří zálohy databáze uchovávané po dobu trvání nakonfigurované doby uchování a pomocí geograficky redundantního úložiště Azure s přístupem pro čtení (RA-GRS) zajistí, že jsou zachovány i v případě, že datové centrum není k dispozici.SQL Database automatically creates the database backups that are kept for the duration of the configured retention period, and uses Azure read-access geo-redundant storage (RA-GRS) to ensure that they are preserved even if the data center is unavailable. Tyto zálohy jsou vytvořeny automaticky.These backups are created automatically. 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.Database backups are an essential part of any business continuity and disaster recovery strategy because they protect your data from accidental corruption or deletion. Pokud vaše pravidla zabezpečení vyžadují, aby byly zálohy dostupné po delší dobu (až 10 let), můžete nakonfigurovat dlouhodobé uchovávání pro databáze typu Singleton a elastické fondy.If your security rules require that your backups are available for an extended period of time (up to 10 years), you can configure a long-term retention on Singleton databases and Elastic pools.

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í SQL DatabaseWhat is a SQL Database backup

SQL Database používá technologii SQL Server k vytváření úplných záloh každý týden, rozdílové zálohování každých 12 hodin a zálohování protokolů transakcí každých 5-10 minut.SQL Database uses SQL Server technology to create full backups every week, differential backups every 12 hours, and transaction log backups every 5-10 minutes. Zálohy se ukládají v objektech BLOB úložiště RA-GRS , které se replikují do spárovaného datového centra kvůli ochraně před výpadkem datového centra.The backups are stored in RA-GRS storage blobs that are replicated to a paired data center for protection against a data center outage. Při obnovení databáze vyřadí služba vyčíslení úplného, rozdílového a zálohy protokolu transakcí, které je třeba obnovit.When you restore a database, the service figures out which full, differential, and transaction log backups need to be restored.

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

  • Obnovte stávající databázi k určitému bodu v čase v minulosti v rámci doby uchování pomocí Azure Portal, Azure PowerShell, rozhraní příkazového řádku Azure nebo REST API.Restore an existing database to a point-in-time in the past within the retention period using the Azure portal, Azure PowerShell, Azure CLI, or REST API. V izolovaných databázích a elastických fondech Tato operace vytvoří novou databázi na stejném serveru jako původní databázi.In Single database and Elastic pools, this operation will create a new database in the same server as the original database. V rámci spravované instance Tato operace může vytvořit kopii databáze nebo stejné nebo jiné spravované instance v rámci stejného předplatného.In Managed Instance, this operation can create a copy of the database or same or different Managed Instance under the same subscription.
  • Obnovení odstraněné databáze na čas, kdy byla odstraněna nebo kdykoli v rámci doby uchování.Restore a deleted database to the time it was deleted or anytime within the retention period. Odstraněnou databázi lze obnovit pouze na stejném logickém serveru nebo ve spravované instanci, kde byla vytvořena původní databáze.The deleted database can only be restored in the same logical server or Managed Instance where the original database was created.
  • Obnovte databázi do jiné geografické oblasti.Restore a database to another geographical region. Geografické obnovení umožňuje obnovení z geografické havárie, když nemůžete získat přístup k serveru a databázi.Geo-restore allows you to recover from a geographic disaster when you cannot access your server and database. Vytvoří novou databázi na jakémkoli existujícím serveru kdekoli na světě.It creates a new database in any existing server anywhere in the world.
  • Obnovte databázi z určité dlouhodobé zálohy na Izolovaná databáze nebo elastický fond, pokud byla databáze nakonfigurovaná s použitím dlouhodobých zásad uchovávání informací (LTR).Restore a database from a specific long-term backup on Single Database or Elastic Pool 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 spustila starou verzi aplikace.LTR allows you to restore an old version of the database 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

Termín replikace ve službě Azure Storage označuje kopírování souborů z jednoho umístění do druhého.In Azure storage, the term replication refers to copying files from one location to another. Replikace databáze SQL odkazuje na udržování více sekundárních databází synchronizovaných s primární databází.SQL's database replication refers to keeping multiple secondary databases synchronized with a primary database.

Některé z těchto operací můžete vyzkoušet v následujících příkladech:You can try some of these operations using the following examples:

Azure PortalThe Azure portal Azure PowerShellAzure PowerShell
Změna uchovávání zálohChange backup retention Izolovaná databázeSingle Database
Spravovaná instanceManaged Instance
Izolovaná databázeSingle Database
Spravovaná instanceManaged Instance
Změna dlouhodobého uchovávání zálohChange Long-term backup retention Samostatná databázeSingle database
Spravovaná instance – není k dispoziciManaged Instance - N/A
Izolovaná databázeSingle Database
Spravovaná instance – není k dispoziciManaged Instance - N/A
Obnovit databázi z bodu v časeRestore database from point-in-time Samostatná databázeSingle database Samostatná databázeSingle database
Spravovaná instanceManaged Instance
Obnovení odstraněné databázeRestore deleted database Samostatná databázeSingle database Samostatná databázeSingle database
Spravovaná instanceManaged Instance
Obnovení databáze z Azure Blob StorageRestore database from Azure Blob Storage Izolovaná databáze – není k dispoziciSingle database - N/A
Spravovaná instance – není k dispoziciManaged Instance - N/A
Izolovaná databáze – není k dispoziciSingle database - N/A
Spravovaná instanceManaged Instance

Frekvence zálohováníBackup frequency

Obnovení k určitému časovému okamžikuPoint-in-time restore

SQL Database podporuje samoobslužné obnovení (PITR) pomocí automatického vytváření úplných záloh, rozdílových záloh a záloh protokolů transakcí.SQL Database supports self-service for point-in-time restore (PITR) by automatically creating full backup, differential backups, and transaction log backups. Úplné zálohy databáze jsou vytvářeny týdně, rozdílové zálohy databáze jsou obvykle vytvářeny každých 12 hodin a zálohy protokolu transakcí jsou obvykle vytvářeny každých 5-10 minut, přičemž četnost je založena na výpočetní velikosti a množství aktivity databáze.Full database backups are created weekly, differential database backups are generally created every 12 hours, and transaction log backups are generally created every 5 - 10 minutes, with the frequency based on the compute size and amount of database activity. První úplné zálohování je naplánováno ihned po vytvoření databáze.The first full backup is scheduled immediately after a database is created. Obvykle se dokončí do 30 minut, ale může trvat déle, než databáze bude mít značnou velikost.It usually completes within 30 minutes, but it can take longer when the database is of a significant size. Například počáteční záloha může trvat déle na obnovenou databázi nebo kopii databáze.For example, the initial backup can take longer on a restored database or a database copy. Po první úplné záloze se všechny další zálohy naplánují automaticky a budou se bezobslužně spravovat na pozadí.After the first full backup, all further backups are scheduled automatically and managed silently in the background. Přesné načasování všech záloh databáze určuje služba SQL Database, protože musí vyrovnat celkové zatížení systému.The exact timing of all database backups is determined by the SQL Database service as it balances the overall system workload. Úlohy zálohování nemůžete změnit ani zakázat.You cannot change or disable the backup jobs.

Zálohy PITR jsou geograficky redundantní a chráněné Azure Storage replikace mezi různými oblastmi .The PITR backups are geo-redundant and protected by Azure Storage cross-regional replication

Další informace najdete v tématu obnovení k bodu v čase .For more information, see Point-in-time restore

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

Databáze typu Single a Pool nabízí možnost konfigurace dlouhodobého uchovávání (LTR) úplných záloh po dobu až 10 let v úložišti objektů BLOB v Azure.Single and pooled databases offer the option of configuring long-term retention (LTR) of full backups for up to 10 years in Azure Blob storage. Pokud je povolená zásada LTR, týdenní úplné zálohy se automaticky zkopírují do jiného kontejneru úložiště RA-GRS.If LTR policy is enabled, the weekly full backups are automatically copied to a different RA-GRS storage container. Pokud chcete splnit jiný požadavek na dodržování předpisů, můžete pro týdenní, měsíční nebo roční zálohy vybrat jinou dobu uchování.To meet different compliance requirement, you can select different retention periods for weekly, monthly and/or yearly backups. Spotřeba úložiště závisí na zvolené četnosti zálohování a na dobu uchování (e).The storage consumption depends on the selected frequency of backups and the retention period(s). 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.

Podobně jako PITR, zálohy LTR jsou geograficky redundantní a chráněné Azure Storage replikace mezi různými oblastmi.Like PITR, the LTR backups are geo-redundant and protected by Azure Storage cross-regional replication.

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

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

U izolovaných databází se celkové využití úložiště záloh počítá takto:For single databases, the total backup storage usage is calculated as follows:
Total backup storage size = (size of full backups + size of differential backups + size of log backups) – database size.Total backup storage size = (size of full backups + size of differential backups + size of log backups) – database size.

U elastických fondů je celková velikost úložiště zálohování agregovaná na úrovni fondu a počítá se takto:For elastic pools, the total backup storage size is aggregated at the pool level and is calculated as follows:
Total backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - allocated pool data storage.Total backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - allocated pool data storage.

Zálohy, které jsou starší než doba uchovávání, se automaticky vyprázdní podle jejich časového razítka.Backups that are older than the retention period are automatically purged based on their timestamp. Vzhledem k tomu, že rozdílové zálohy a zálohy protokolů vyžadují, aby bylo předchozí úplné zálohování užitečné, vyčistí se společně v týdenních blocích.Because the differential backups and log backups require an earlier full backup to be useful, they are purged together in weekly chunks.

Azure SQL Database vypočítá celkové úložiště záloh v rámci uchování jako kumulativní hodnotu.Azure SQL Database will compute your total in-retention 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 vyřazení databáze se spotřeba sníží jako stáří zálohování.After the database is dropped, consumption decreases as backups age. Jakmile budou zálohy starší než doba uchovávání, fakturace se zastaví.Once the backups become older than the retention period, the billing stops.

Monitorování spotřebyMonitoring consumption

Každý typ zálohy (úplný, rozdíl a protokol) je hlášen v okně monitorování databáze jako samostatná metrika.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áloh.The following diagram shows how to monitor the backups storage consumption.

Monitorovat spotřebu zálohy databáze v okně monitorování databáze Azure Portal

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

Nadměrná spotřeba úložiště záloh bude záviset na zatížení a velikosti jednotlivých databází.The excess backup storage consumption will depend on the workload and size of the individual databases. Můžete zvážit implementaci některých z následujících postupů optimalizace pro další snížení spotřeby úložiště záloh:You can consider implementing some of the following tuning techniques to further 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 častěji, než je potřeba, jako je například opětovné sestavení indexu.Avoid performing large write operations more frequently than needed, such as index rebuilds.
  • Při operacích s velkým objemem dat zvažte použití clusterovaných indexů columnstore, snižte počet neclusterovaných indexů a zvažte také operace hromadného načítání s počtem řádků přibližně 1 000 000.For large data load operations consider using clustered columnstore indexes, reduce number of non-clustered indexes, and also consider bulk load operations with row count around one million.
  • V Pro obecné účely úrovni služby je zřízené úložiště dat levnější než cena za nadměrné úložiště záloh, protože zákazníci s průběžnými vysokými náklady na úložiště záloh můžou zvážit zvýšení úložiště dat, aby se uložily na úložiště zálohování.In General Purpose service tier, the provisioned data storage is less expensive than the price of the excess backup storage due to which customers with continuously high excess backup storage costs may consider increasing the data storage in order to save on the backup storage.
  • Použijte databázi TempDB v logice ETL k ukládání dočasných výsledků místo trvalých tabulek (platí pouze pro spravovanou instanci).Use TempDB in your ETL logic for storing temporary results, instead of permanent tables (applicable to managed instance only).
  • Zvažte vypnutí šifrování TDE pro databáze, které neobsahují citlivá data (např. vývojové nebo testovací databáze).Consider turning off TDE encryption for databases that do not contain sensitive data (development or test databases, for instance). Zálohy pro nešifrované databáze jsou obvykle komprimovány s vyšším kompresním poměrem.Backups for non-encrypted databases are typically compressed with a higher compression ratio.

Důležité

Pro analytická Datová tržiště \ úlohy datového skladu se důrazně doporučuje použít clusterované indexy columnstore, snížit počet neclusterovaných indexů a také zvážit operace hromadného načítání s počtem řádků přibližně 1 000 000, abyste snížili nadměrné využití úložiště záloh.For analytical, data mart \ data warehouse workloads it is strongly recommended to use clustered columnstore indexes, reduce the number of non-clustered indexes, and also consider bulk load operations with row count around one million to reduce the excess backup storage consumption.

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

Model DTUDTU Model

Pro úložiště zálohování databází a elastických fondů pomocí modelu DTU se neúčtují žádné další poplatky.There is no additional charge for backup storage for databases and elastic pools using the DTU model.

Model virtuálních jadervCore model

U izolovaných databází se minimální hodnota záložního úložiště rovná 100% velikosti databáze je k dispozici bez dalších poplatků.For single databases, a minimum backup storage amount equal to 100% of database size is provided at no extra charge. U elastických fondů a spravovaných instancí se minimální hodnota úložiště zálohy rovná 100% přiděleného úložiště dat pro fond nebo velikost instance, v uvedeném pořadí, je k dispozici bez dalších poplatků.For elastic pools and managed instances, a minimum backup storage amount equal to 100% of the allocated data storage for the pool or instance size, respectively, is provided at no extra charge. Využití úložiště zálohování nad tuto mez bude zpoplatněno v jednotkách GB/měsíc.Additional consumption of backup storage will be charged in GB/month. Tato další spotřeba bude záviset na zatížení a velikosti jednotlivých databází.This additional consumption will depend on the workload and size of the individual databases.

Azure SQL DB bude počítat celkové úložiště záloh v rámci uchovávání jako kumulativní hodnotu.Azure SQL DB will compute your total in-retention 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 získání 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 get your consumption at the end of each month. Po vyřazení databáze snížíme spotřebu jako stáří zálohy.After the database is dropped, we decrease the consumption as the backups age. Jakmile budou starší než doba uchovávání, fakturace se zastaví.Once they become older than the retention period, the billing stops. Vzhledem k tomu, že se všechny zálohy protokolů a rozdílové zálohy uchovávají pro celou dobu uchovávání dat, budou vysoce upravované databáze mít vyšší poplatky za zálohování.Because all the log backups and differential backups are retained for the full retention period, databases that are heavily modified will have higher backup charges.

Předpokládejme, že databáze shromáždila 744 GB úložiště zálohování a tato částka zůstane v celém měsíci konstantní.Let's assume the database has accumulated 744 GB of backup storage and this amount stays constant throughout an entire month. Pokud chcete tuto kumulativní spotřebu úložiště převést na hodinové použití, rozdělíme ji na 744,0 (31 dnů měsíčně * 24 hodin za den).To convert this cumulative storage consumption to an hourly usage, we divide it by 744.0 (31 days per month * 24 hours per day). Proto databáze SQL DB každou hodinu využívala 1 GB PITR zálohování.Thus, SQL DB will report the database consumed 1 GB of PITR backup each hour. Faktura za Azure agreguje toto a ukáže využití 744 GB po celý měsíc a náklady na základě sazby $/GB/mo ve vaší oblasti.Azure billing will aggregate this and show a usage of 744 GB for the entire month and the cost based on the $/GB/mo rate in your region.

Teď je to složitější příklad.Now, a more complex example. Předpokládejme, že se v databázi zakázalo zvýšení na 14 dní uprostřed měsíce a tato (hypoteticky) má za následek celkové úložiště zálohování od zdvojnásobení až 1488 GB.Suppose the database has its retention increased to 14 days in the middle of the month and this (hypothetically) results in the total backup storage doubling to 1488 GB. SQL DB by nahlásilo 1 GB využití v hodinách 1-372 a pak vykazovat využití jako 2 GB po dobu 373-744.SQL DB would report 1 GB of usage for hours 1-372, and then report the usage as 2 GB for hours 373-744. Tato částka se agreguje jako finální faktura za 1116 GB/měsíc.This would be aggregated to be a final bill of 1116 GB/mo.

Pomocí analýzy nákladů na předplatné Azure můžete zjistit aktuální výdaje na úložiště záloh.You can use Azure subscription cost analysis to determine your current spending on backup storage.

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

Pokud chcete například porozumět nákladům na úložiště zálohování pro spravovanou instanci, přejděte prosím do svého předplatného v Azure Portal a otevřete okno Analýza nákladů.For example, to understand the backup storage costs for managed instance, please go to your subscription in Azure portal and open the Cost Analysis blade. Vyberte podkategorii měřičů Pitr Backup , abyste viděli aktuální náklady na zálohování a prognózu nákladů.Select the meter subcategory mi pitr backup storage to see your current backup cost and charge forecast. Můžete také zahrnout další podkategorie měřičů, jako je například Managed instance pro obecné účely – úložiště nebo spravovaná instance pro obecné účely – COMPUTE Gen5 pro porovnání nákladů na úložiště zálohování s jinými kategoriemi nákladů.You can also include other meter subcategories such as managed instance general purpose - storage or managed instance general purpose - compute gen5 to compare backup storage cost with other cost categories.

Uchování zálohBackup retention

Všechny databáze Azure SQL (jedna, sdružená a databáze spravované instance) mají výchozí dobu uchovávání záloh po dobu sedmi dnů.All Azure SQL databases (single, pooled, and managed instance databases) have a default backup retention period of seven days. Dobu uchování zálohy můžete změnit až na 35 dnů.You can change backup retention period up to 35 days.

Pokud databázi odstraníte, SQL Database zachová zálohy stejným způsobem jako u online databáze.If you delete a database, SQL Database will keep the backups in the same way it would for an online database. Pokud například odstraníte databázi Basic, která má dobu uchovávání 7 dní, záloha, která je starší než 4 dny, se uloží na tři dny.For example, if you delete a Basic database that has a retention period of seven days, a backup that is four days old is saved for three more days.

Pokud potřebujete uchovat zálohy po dobu delší, než je maximální doba uchovávání, můžete upravit vlastnosti zálohy a přidat jednu nebo více dlouhodobých dob uchovávání do databáze.If you need to keep the backups for longer than the maximum retention period, you can modify the backup properties to add one or more long-term retention periods to your database. Další informace najdete v tématu Dlouhodobé uchovávání.For more information, see Long-term retention.

Důležité

Pokud odstraníte server SQL Azure hostující databáze SQL, odstraní se také všechny elastické fondy a databáze patřící do serveru a nelze je obnovit.If you delete the Azure SQL server that hosts SQL databases, all elastic pools and databases that belong to the server are also deleted and cannot be recovered. Odstraněný Server nelze obnovit.You cannot restore a deleted server. Pokud jste ale nakonfigurovali dlouhodobé uchovávání, zálohy pro databáze s LTR nebudou odstraněny a tyto databáze je možné obnovit.But if you configured long-term retention, the backups for the databases with LTR will not be deleted and these databases can be restored.

Šifrovaná zálohováníEncrypted backups

Pokud je vaše 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, the backups are automatically encrypted at rest, including LTR backups. Když je u databáze SQL Azure povolené TDE, zálohují se taky zálohy.When TDE is enabled for an Azure SQL database, backups are also encrypted. Ve výchozím nastavení jsou všechny nové databáze SQL Azure nakonfigurované s povoleným TDE.All new Azure SQL databases are configured with TDE enabled by default. Další informace o TDE naleznete v tématu transparentní šifrování dat with Azure SQL Database.For more information on TDE, see Transparent Data Encryption with Azure SQL Database.

Integrita zálohyBackup integrity

V nepřetržitém případě Azure SQL Database technický tým automaticky testuje obnovení automatizovaných záloh databáze databází umístěných na logických serverech a elastických fondech (není k dispozici ve spravované instanci).On an ongoing basis, the Azure SQL Database engineering team automatically tests the restore of automated database backups of databases placed in Logical servers and Elastic pools (this is not available in Managed Instance). Při obnovení k bodu v čase získávají databáze také kontroly integrity pomocí příkazu DBCC CHECKDB.Upon point-in-time restore, databases also receive integrity checks using DBCC CHECKDB.

Spravovaná instance provádí automatické počáteční zálohování s CHECKSUM databází obnovených pomocí nativního příkazu RESTORE nebo služby migrace dat po dokončení migrace.Managed Instance takes automatic initial backup with CHECKSUM of the databases restored using native RESTORE command or Data Migration Service once the migration is completed.

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 o integritě dat v Azure SQL Database najdete v tématu Integrita dat v Azure SQL Database.For more information about data integrity in Azure SQL Database, see Data Integrity in Azure SQL Database.

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 is not compromised. Pokud výchozí doba uchovávání nesplňuje požadavky na dodržování předpisů, můžete změnit dobu uchování PITR pomocí PowerShellu nebo REST API.If the default retention doesn't meet your compliance requirements, you can change the PITR retention period using PowerShell or REST API. Další informace najdete v tématu Změna doby uchování zálohy.For more information, see Change 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ěnit dobu uchování zálohy PITRChange PITR backup retention period

Výchozí dobu uchovávání záloh PITR můžete změnit pomocí Azure Portal, PowerShellu nebo REST API.You can change the default PITR backup retention period 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 PITR retention to 28 days.

Varování

Pokud zmenšíte aktuální dobu uchovávání, nebudou už všechny existující zálohy starší než nová doba uchování k dispozici.If you reduce the current retention period, all existing backups older than the new retention period are no longer available. Pokud zvýšíte aktuální dobu uchovávání, SQL Database zachová stávající zálohy, dokud nedosáhnete delší doby uchovávání.If you increase the current retention period, SQL Database will keep the existing backups until the longer retention period is reached.

Poznámka

Tato rozhraní API budou mít vliv jenom na dobu uchovávání PITR.These APIs will only impact 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 will not be impacted. Další informace o tom, jak změnit dobu uchování LTR, najdete v tématu dlouhodobé uchovávání.For more information about how to change the LTR retention period(s), see Long-term retention.

Změna doby uchovávání záloh PITR pomocí Azure PortalChange PITR backup retention period using Azure portal

Pokud chcete změnit dobu uchovávání záloh PITR pomocí Azure Portal, přejděte na objekt serveru, jehož doba uchovávání dat chcete změnit na portálu, a pak vyberte vhodnou možnost podle toho, který objekt serveru upravujete.To change the PITR backup retention period using the Azure portal, navigate to the server object whose retention period you wish to change within the portal and then select the appropriate option based on which server object you're modifying.

Změna uchovávání PITR zálohování pro jednu databázi Azure SQL se provádí na úrovni serveru.Change of PITR backup retention for single Azure SQL Databases is performed at the server level. Změny provedené na úrovni serveru se vztahují na databáze na tomto serveru.Change made at the server level applies to databases on that server. Chcete-li změnit PITR pro Azure SQL Database Server z Azure Portal, přejděte na okno Přehled serveru, klikněte na možnost spravovat zálohy v navigační nabídce a pak na navigačním panelu klikněte na možnost konfigurace uchovávání.To change PITR for Azure SQL Database server from Azure portal, navigate to the server overview blade, click on Manage Backups on the navigation menu, and then click on Configure retention at the navigation bar.

Změnit Azure Portal PITR

Změna doby uchovávání záloh PITR pomocí PowerShelluChange PITR backup retention period 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 Azure Resource Manager je stále podporován Azure SQL Database, ale všechny budoucí vývojové prostředí jsou pro modul AZ. SQL.The PowerShell Azure Resource Manager module is still supported by Azure SQL Database, but all future development is for the Az.Sql module. Tyto rutiny naleznete v tématu AzureRM. SQL.For these cmdlets, see AzureRM.Sql. Argumenty pro příkazy v modulech AZ a v modulech AzureRm jsou v podstatě identické.The arguments for the commands in the Az module and in the AzureRm modules are substantially identical.

Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28

Změna doby uchování PITR pomocí REST APIChange PITR retention period using 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 žádostiRequest Body

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

Ukázková odezvaSample 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.

Další krokyNext steps