自动备份 - Azure SQL 数据库和 SQL 托管实例Automated backups - Azure SQL Database & SQL Managed Instance

适用于:是 Azure SQL 数据库 是Azure SQL 托管实例 APPLIES TO: yesAzure SQL Database yesAzure SQL Managed Instance

备注

本文介绍如何删除设备或服务中的个人数据,并且可为 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. 如需关于 GDPR 的常规信息,请参阅服务信任门户的 GDPR 部分If you're looking for general info about GDPR, see the GDPR section of the Service Trust portal.

什么是数据库备份?What is a database backup?

数据库备份是任何业务连续性和灾难恢复策略的基本组成部分,因为数据库备份可以保护数据免遭损坏或删除。Database backups are an essential part of any business continuity and disaster recovery strategy, because they protect your data from corruption or deletion.

SQL 数据库和 SQL 托管实例都使用 SQL Server 技术,每周创建完整备份,每 12-24 小时创建差异备份,每 5 到 10 分钟创建事务日志备份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. 事务日志备份的频率取决于计算大小和数据库活动量。The frequency of transaction log backups is based on the compute size and the amount of database activity.

还原数据库时,服务会确定需要还原哪些完整备份、差异备份和事务日志备份。When you restore a database, the service determines which full, differential, and transaction log backups need to be restored.

这些备份可在配置的保留期内将数据库还原到某个时间点。These backups enable database restore to a point in time within the configured retention period. 会将备份存储为 RA-GRS 存储 blob,后者会复制到配对区域,用于保护主要区域中的备份存储,使其免受中断影响。The backups are stored as RA-GRS storage blobs that are replicated to a paired region for protection against outages impacting backup storage in the primary region.

如果数据保护规则要求备份在较长时间(最长 10 年)内可用,可以同时为单一数据库和共用数据库配置长期保留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.

可使用这些备份:You can use these backups to:

  • 通过使用 Azure 门户、Azure PowerShell、Azure CLI 或 REST API,将现有的数据库还原到过去的某个时间点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. 对于单一数据库和共用数据库,此操作将在与原始数据库相同的服务器上创建新的数据库,但会使用不同的名称,以避免覆盖原始数据库。For single and pooled databases, this operation will create a new database on the same server as the original database, but under a different name to avoid overwriting the original database. 还原完成后,可以删除或重命名原始数据库,并重命名还原的数据库,使其具有原始数据库的名称。Once restore completes, you can delete or rename the original database, and rename the restored database to have the original database name. 在托管实例中,此操作可以类似方式在同一订阅和同一区域中的相同或不同的托管实例上创建数据库地副本。On a managed instance, this operation can similarly create a copy of the database on the same or a different managed instance under the same subscription and in the same region.
  • 将已删除的数据库还原到删除时间或者还原到保留期内的任意时间点。Restore a deleted database to the time of deletion or to any point in time within the retention period. 仅可在创建原始数据库所在的同一服务器或托管实例上还原已删除的数据库。The deleted database can be restored only on the same server or managed instance where the original database was created. 删除数据库时,该服务会在删除前执行最终事务日志备份,以防止任何数据丢失。When deleting a database, the service takes a final transaction log backup before deletion, to prevent any data loss.
  • 将数据库还原到其他地理区域Restore a database to another geographic region. 在无法访问主要区域中的数据库和备份时,异地还原可帮助从地理位置灾难中恢复。Geo-restore allows you to recover from a geographic disaster when you cannot access your database or backups in the primary region. 它可在任何 Azure 区域中的任意现有服务器或托管实例上创建新的数据库。It creates a new database on any existing server or managed instance, in any Azure region.
  • 如果为数据库配置了长期保留策略 (LTR),可从单一数据库或共用数据库的某个特定长期备份来还原数据库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 允许使用 Azure 门户Azure PowerShell 还原旧版本的数据库,以满足合规性请求或运行旧版本的应用程序。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. 有关详细信息,请参阅 长期保留For more information, see Long-term retention.

若要执行还原,请参阅从备份还原数据库To perform a restore, see Restore database from backups.

备注

在 Azure 存储中,术语“复制”指将 blob 从一个位置复制到另一个位置。In Azure Storage, the term replication refers to copying blobs from one location to another. 在 SQL 中,“数据库复制”指用于让多个辅助数据库与主数据库保持同步的各种技术。In SQL, database replication refers to various technologies used to keep multiple secondary databases synchronized with a primary database.

可以参考下列示例尝试执行备份配置和还原操作:You can try backup configuration and restore operations using the following examples:

Azure 门户Azure portal Azure PowerShellAzure PowerShell
更改备份保留Change backup retention 单一数据库Single database
托管实例Managed instance
单一数据库Single database
托管实例Managed instance
更改长期备份保留Change long-term backup retention 单一数据库Single database
托管实例 - 不可用Managed instance - N/A
单一数据库Single database
托管实例 - 不可用Managed instance - N/A
从某个时间点还原数据库Restore a database from a point in time 单一数据库Single database 单一数据库Single database
托管实例Managed instance
还原已删除的数据库Restore a deleted database 单一数据库Single database 单一数据库Single database
托管实例Managed instance
从 Azure Blob 存储还原数据库Restore a database from Azure Blob storage 单一数据库 - 不适用Single database - N/A
托管实例 - 不可用Managed instance - N/A
单一数据库 - 不适用Single database - N/A
托管实例Managed instance

备份计划Backup scheduling

会在新的数据库创建或还原后立即计划第一次完整备份。The first full backup is scheduled immediately after a new database is created or restored. 此备份通常可在 30 分钟内完成,但如果数据库较大,花费的时间可能更长。This backup usually completes within 30 minutes, but it can take longer when the database is large. 例如,对已还原的数据库或数据库副本执行初始备份可能需要更长时间,该备份通常比新数据库还大。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. 在完成首次完整备份后,会自动计划和管理所有后续备份。After the first full backup, all further backups are scheduled and managed automatically. 在平衡整体系统工作负荷时,SQL 数据库或 SQL 托管实例服务会确定所有数据库备份的确切时间。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. 不能更改备份作业的计划或者禁用备份作业。You cannot change the schedule of backup jobs or disable them.

重要

对于新的、还原的或复制的数据库,从初始完整备份之后创建了初始事务日志备份时开始,可以使用时间点还原功能。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.

备份存储消耗量Backup storage consumption

如果使用 SQL Server 备份和还原技术,将数据库还原到某个时间点需要一个不间断的备份链,其中包括一个完整备份、可选的一个差异备份以及一个或多个事务日志备份。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. SQL 数据库和 SQL 托管实例备份计划包括每周执行一次完整备份。SQL Database and SQL Managed Instance backup schedule includes one full backup every week. 因此,要在整个保留期内启用 PITR,系统需要额外存储完整备份、差异备份和事务日志备份,且存储时间最多比配置的保留期长一周。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.

换句话说,对于保留期内的任何时间点,都需要具有早于保留期最早时间的完整备份,以及从该完整备份到下一次完整备份期前的差异备份和事务日志备份的不间断备份链。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.

备注

要启用 PITR,额外备份的存储时间最多比配置的保留期长一周。To enable PITR, additional backups are stored for up to a week longer than the configured retention period. 备份存储按与所有备份相同的费率收费。Backup storage is charged at the same rate for all backups.

将自动删除不再需要为提供 PITR 功能而保留的备份。Backups that are no longer needed to provide PITR functionality are automatically deleted. 由于差异备份和日志备份需要早期的完整备份才可恢复,因此所有这三种备份类型会在每周都一并清除一次。Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets.

对于包括 TDE 加密数据库在内的所有数据库,将压缩备份,以减少未来的备份存储压缩需要和成本。For all databases including TDE encrypted databases, backups are compressed to reduce backup storage compression and costs. 平均备份压缩率为 3-4 倍,但是,根据数据的性质以及数据库中是否启用了数据压缩,平均备份压缩率可能会显著降低或提高。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.

SQL 数据库和 SQL 托管实例按累积值形式计算使用的总备份存储量。SQL Database and SQL Managed Instance compute your total used backup storage as a cumulative value. 此值每隔一小时就会报告给 Azure 计费管道,该管道负责聚合此每小时用量,以便在每月底计算消耗量。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. 删除数据后,随着备份的过期以及删除,消耗量将减少。After the database is deleted, consumption decreases as backups age out and are deleted. 删除所有备份后,PITR 不再可用,计费会停止。Once all backups are deleted and PITR is no longer possible, billing stops.

重要

即使已删除数据库,为了使用 PITR,仍会保留数据库的备份。Backups of a database are retained to enable PITR even if the database has been deleted. 删除和重建数据库可能会节省存储和计算成本,但可能会增加备份存储成本,因为该服务在每次删除数据库都时会保留每个已删除数据库的备份。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.

监视消耗情况Monitor consumption

对于 vCore 数据库,每种类型的备份(完整备份、差异备份和日志备份)所使用的存储量采用单独的指标在数据库监视边栏选项卡上进行报告。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. 下图显示了如何监视单一数据库的备份存储消耗情况。The following diagram shows how to monitor the backup storage consumption for a single database. 此功能目前不适用于托管实例。This feature is currently not available for managed instances.

在 Azure 门户中监视数据库备份消耗量

微调备份存储消耗量Fine-tune backup storage consumption

只要备份存储消耗量不超过数据库的最大数据大小,就不会对备份收费。Backup storage consumption up to the maximum data size for a database is not charged. 额外的备份存储消耗量取决于各个数据库的工作负荷和最大大小。Excess backup storage consumption will depend on the workload and maximum size of the individual databases. 考虑实施下面一些优化技术,以减少备份存储消耗量:Consider some of the following tuning techniques to reduce your backup storage consumption:

  • 备份保留期减少到所需的最小值。Reduce the backup retention period to the minimum possible for your needs.
  • 避免以超过需要的频率执行大型写入操作,例如索引重建。Avoid doing large write operations, like index rebuilds, more frequently than you need to.
  • 对于大规模数据加载操作,请考虑使用聚集列存储索引以及下列相关最佳做法,和/或减少非聚集索引的数目。For large data load operations, consider using clustered columnstore indexes and following related best practices, and/or reduce the number of non-clustered indexes.
  • 在常规用途服务层级中,预配数据存储的价格低于备份存储的价格。In the General Purpose service tier, the provisioned data storage is less expensive than the price of the backup storage. 如果额外备份存储成本一直较高,可以考虑增大数据存储,以便节省备份存储的费用。If you have continually high excess backup storage costs, you might consider increasing data storage to save on the backup storage.
  • 在应用程序逻辑中使用 TempDB 而不是永久性表来存储临时结果和/或暂时性数据。Use TempDB instead of permanent tables in your application logic for storing temporary results and/or transient data.

备份保留Backup retention

对于所有新的、还原和复制的数据库,Azure SQL 数据库和 Azure SQL 托管实例会默认保留足以实现过去 7 天的 PITR 的备份量。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. 除了超大规模数据库之外,可以为每个数据库更改备份保持期,更改幅度可为 1-35 天。With the exception of Hyperscale databases, you can change backup retention period per database in the 1-35 day range. 备份存储消耗量中所述,为启用 PITR 而存储的备份可能早于保留期。As described in Backup storage consumption, backups stored to enable PITR may be older than the retention period.

如果删除数据库,系统会保留数据库的备份至特定的保留期,与为任何一个联机数据库的保留方式一样。If you delete a database, the system keeps backups in the same way it would for an online database with its specific retention period. 不能更改已删除的数据库的备份保留期。You cannot change backup retention period for a deleted database.

重要

如果删除服务器或托管实例,则该服务器或该托管实例上所有的数据库也会删除,且无法恢复。If you delete a server or a managed instance, all databases on that server or managed instance are also deleted and cannot be recovered. 无法还原已删除的服务器或托管实例。You cannot restore a deleted server or managed instance. 但是,如果为数据库或托管实例配置了长期保留 (LTR),则不会删除长期保留备份,并且可以使用它在同一订阅的另一个服务器或托管实例上将数据库还原到执行长期保留备份的时间点。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.

出于 PITR 目的,过去 1-35 天内的备份保留有时称为短期备份保留。Backup retention for purposes of PITR within the last 1-35 days is sometimes called short-term backup retention. 如果需要将备份保留至超过 35 天的最长短期保留期,可以启用长期保留If you need to keep backups for longer than the maximum short-term retention period of 35 days, you can enable Long-term retention.

长期保留Long-term retention

对于单一数据库和共用数据库以及托管实例,可以配置完整备份的长期保留 (LTR),使其在 Azure Blob 存储中最长保存 10 年。For single and pooled databases and managed instances, you can configure long-term retention (LTR) of full backups for up to 10 years in Azure Blob storage. 如果启用 LTR 策略,每周完整备份将自动复制到不同的 RA-GRS 存储容器。If you enable an LTR policy, the weekly full backups are automatically copied to a different RA-GRS storage container. 为了满足不同的合规性要求,可为每周、每月和/或每年完整备份选择不同的保留期。To meet various compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly full backups. 存储消耗量取决于所选的 LTR 备份频率以及保留期。The storage consumption depends on the selected frequency of LTR backups, and the retention period or periods. 可以使用 LTR 定价计算器来估算 LTR 存储成本。You can use the LTR pricing calculator to estimate the cost of LTR storage.

与 PITR 备份一样,LTR 备份通过异地冗余存储进行保护。Like PITR backups, LTR backups are protected with geo-redundant storage. 有关详细信息,请参阅 Azure 存储冗余For more information, see Azure Storage redundancy.

有关 LTR 的详细信息,请参阅长期备份保留For more information about LTR, see Long-term backup retention.

存储费用Storage costs

存储价格会根据你使用的是 DTU 模型还是 vCore 模型而有所不同。The price for storage varies depending on whether you're using the DTU model or the vCore model.

DTU 模型DTU model

在 DTU 模型中,数据库和弹性池不会产生额外的备份存储费用。In the DTU model, there's no additional charge for backup storage for databases and elastic pools. 备份存储的价格构成数据库或池价格的一部分。The price of backup storage is a part of database or pool price.

vCore 模型vCore model

对于 SQL 数据库中的单一数据库,会提供与数据库最大数据存储大小 100% 相等的备份存储量,不收取额外的费用。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. 对于弹性池和托管实例,会分别提供与池的最大数据存储量或最大实例存储大小 100% 相等的备份存储量,不收取额外的费用。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.

对于单一数据库,可使用以下公式来计算可计费的备份存储总用量: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

对于共用数据库,可计费的备份存储总大小在池级别进行聚合,计算方式如下: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

对于托管实例,可计费备份存储总大小在实例级别进行聚合,计算方式如下: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

可计费的备份存储总用量按 GB/月进行收费。Total billable backup storage, if any, will be charged in GB/month. 备份存储消耗量取决于各个数据库、弹性池以及托管实例的工作负荷和大小。This backup storage consumption will depend on the workload and size of individual databases, elastic pools, and managed instances. 经过大量修改的数据库具有相对较大的差异备份和日志备份,因为这些备份的大小与数据更改量成比例。Heavily modified databases have larger differential and log backups, because the size of these backups is proportional to the amount of data changes. 因此,此类数据库的备份费用会更高。Therefore, such databases will have higher backup charges.

SQL 数据库和 SQL 托管实例按累积值形式计算所有备份文件的总可计费备份存储量。SQL Database and SQL Managed Instance computes your total billable backup storage as a cumulative value across all backup files. 此值每隔一小时就会报告给 Azure 计费管道,该管道聚合此每小时用量,以便在每月底获取备份存储消耗量。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. 如果删除数据库,备份存储消耗量将逐渐降低,因为较早的备份会过期并被删除。If a database is deleted, backup storage consumption will gradually decrease as older backups age out and are deleted. 由于差异备份和日志备份需要早期的完整备份才可恢复,因此所有这三种备份类型会在每周都一并清除一次。Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets. 当所有备份都被删除后,计费会停止。Once all backups are deleted, billing stops.

举一个简化的示例,假设数据库累积了 744 GB 的备份存储,并且此数量因数据库完全空闲会在整个月内保持恒定。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. 若要将此累积存储消耗量转换为每小时用量,可将此数量除以 744.0(每月 31 天 * 每天 24 小时)。To convert this cumulative storage consumption to hourly usage, divide it by 744.0 (31 days per month * 24 hours per day). SQL 数据库将以固定速率向 Azure 计费管道报告数据库每小时使用了 1 GB 的 PITR 备份。SQL Database will report to Azure billing pipeline that the database consumed 1 GB of PITR backup each hour, at a constant rate. Azure 计费服务将聚合此消耗量,并显示整月用量为 744 GB。Azure billing will aggregate this consumption and show a usage of 744 GB for the entire month. 成本基于所在区域的用量/GB/月费率。The cost will be based on the amount/GB/month rate in your region.

下面是一个更复杂的示例。Now, a more complex example. 假设同一空闲数据库的保留期在当月的中途从 7 天增加到了 14 天。Suppose the same idle database has its retention increased from 7 days to 14 days in the middle of the month. 这种增长会导致总备份存储翻倍至 1,488 GB。This increase results in the total backup storage doubling to 1,488 GB. SQL 数据库将报告第 1 到 372 小时(上半月)的用量为每小时 1 GB。SQL Database would report 1 GB of usage for hours 1 through 372 (the first half of the month). 它会报告第 373 到 744 小时(下半月)的用量为每小时 2 GB。It would report the usage as 2 GB for hours 373 through 744 (the second half of the month). 此用量将聚合到每月 1,116 GB 的最终帐单中。This usage would be aggregated to a final bill of 1,116 GB/month.

实际的备份计费方案更加复杂。Actual backup billing scenarios are more complex. 由于数据库中的变化率取决于工作负荷,并且会随时间而改变,因此每个差异备份和日志备份的大小也会随之改变,从而导致每小时备份存储消耗量出现相应波动。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. 此外,每个差异备份都包含自上次完整备份后数据库中的所有更改,因此,所有差异备份的总大小会在一周过程中逐渐增加,然后在早期的完整备份、差异备份和日志备份过期后急剧减少。例如,如果在完整备份完成后立即运行量较大的写入活动(如索引重新生成),则因重新生成索引所发生的修改将包含在重建期间获取的事务日志备份、下一个差异备份以及下一次完全备份发生之前执行的每个差异备份中。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. 如果在较大数据库中发生后一种情况,如果差异备份过大,则服务中的一项优化会导致创建完整备份而不是差异备份。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. 这会减少下一次完整备份之前的所有差异备份的大小。This reduces the size of all differential backups until the following full backup.

监视消耗情况中所述,可以监视每个备份类型(完整备份、差异备份、事务日志备份)随时间推移的总备份存储消耗量。You can monitor total backup storage consumption for each backup type (full, differential, transaction log) over time as described in Monitor consumption.

加密备份Encrypted backups

如果使用 TDE 加密了数据库,则备份(包括 LTR 备份)会自动静态加密。If your database is encrypted with TDE, backups are automatically encrypted at rest, including LTR backups. 默认情况下,Azure SQL 中所有新的数据库都配置为启用 TDE。All new databases in Azure SQL are configured with TDE enabled by default. 有关 TDE 的详细信息,请参阅使用 SQL 数据库和 SQL 托管实例进行透明数据加密For more information on TDE, see Transparent Data Encryption with SQL Database & SQL Managed Instance.

备份完整性Backup integrity

Azure SQL 工程团队持续不断地自动测试自动数据库备份的还原。On an ongoing basis, the Azure SQL engineering team automatically tests the restore of automated database backups. (此测试当前不适用于 SQL 托管实例。)完成时间点还原后,数据库还会接受 DBCC CHECKDB 完整性检查。(This testing is not currently available in SQL Managed Instance.) Upon point-in-time restore, databases also receive DBCC CHECKDB integrity checks.

所有类型的数据库备份都提供 CHECKSUM 选项,以便增加备份完整度。All database backups are taken with the CHECKSUM option to provide additional backup integrity.

合规性Compliance

将数据库从基于 DTU 的服务层级迁移到基于 vCore 的服务层级时,将保留 PITR 保留期以确保不会违反应用程序的数据恢复策略。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. 如果默认保留期不满足合规性要求,可以更改 PITR 保留期。If the default retention doesn't meet your compliance requirements, you can change the PITR retention period. 有关详细信息,请参阅更改 PITR 备份保留期For more information, see Change the PITR backup retention period.

备注

本文介绍如何删除设备或服务中的个人数据,并且可为 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. 如需关于 GDPR 的常规信息,请参阅服务信任门户的 GDPR 部分If you're looking for general info about GDPR, see the GDPR section of the Service Trust portal.

更改 PITR 备份保留期Change the PITR backup retention period

可以使用 Azure 门户、PowerShell 或 REST API 更改默认 PITR 备份保留期。You can change the default PITR backup retention period by using the Azure portal, PowerShell, or the REST API. 以下示例演示如何将 PITR 保留期更改为 28 天。The following examples illustrate how to change the PITR retention to 28 days.

警告

如果缩短当前的保留期,则无法还原到早于新保留期的时间点。If you reduce the current retention period, you lose the ability to restore to points in time older than the new retention period. 会删除新保留期内不再需要为提供 PITR 而保留的备份。Backups that are no longer needed to provide PITR within the new retention period are deleted. 如果延长当前的保留期,则无法立即在新的保留期内获得恢复到旧时间点的能力。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. 随着时间推移,你将获得这一能力,因为系统开始将备份保留更长时间。You gain that ability over time, as the system starts to retain backups for longer.

备注

这些 API 只影响 PITR 保留期。These APIs will affect only the PITR retention period. 如果为数据库配置了 LTR,LTR 不会受到影响。If you configured LTR for your database, it won't be affected. 有关如何更改 LTR 保留期的信息,请参阅长期保留For information about how to change LTR retention periods, see Long-term retention.

使用 Azure 门户更改 PITR 备份保留期Change the PITR backup retention period by using the Azure portal

若要通过使用 Azure 门户更改 PITR 备份保留期,请转到具有要更改保留期的数据库的服务器或托管实例。To change the PITR backup retention period by using the Azure portal, go to the server or managed instance with the databases whose retention period you want to change.

对 SQL 数据库的 PITR 备份保留期更改是在门户中的服务器级别进行的。Changes to PITR backup retention for SQL Database are done on the server page in the portal. 若要为服务器上的数据库更改 PITR 保留期,请转到服务器概述边栏选项卡。To change PITR retention for databases on a server, go to the server overview blade. 在左侧窗格中选择“管理备份”,并选择更改范围内的数据库,然后在屏幕顶部选择“配置保留期” :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:

更改 PITR 保留期,服务器级别

使用 PowerShell 更改 PITR 备份保留期Change the PITR backup retention period by using PowerShell

备注

本文进行了更新,以便使用新的 Azure PowerShell Az 模块。This article has been updated to use the new Azure PowerShell Az module. 你仍然可以使用 AzureRM 模块,至少在 2020 年 12 月之前,它将继续接收 bug 修补程序。You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. 若要详细了解新的 Az 模块和 AzureRM 兼容性,请参阅新 Azure Powershell Az 模块简介To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. 有关 Az 模块安装说明,请参阅安装 Azure PowerShellFor Az module installation instructions, see Install Azure PowerShell.

重要

PowerShell AzureRM 模块仍受 SQL 数据库和 SQL 托管实例的支持,但所有未来的开发都是针对 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. 有关详细信息,请参阅 AzureRM.SqlFor more information, see AzureRM.Sql. Az 模块和 AzureRm 模块中的命令参数大体上是相同的。The arguments for the commands in the Az module are substantially identical to those in the AzureRm modules.

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

使用 REST API 更改 PITR 备份保留期Change the PITR backup retention period by using the REST API

示例请求Sample request

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

请求正文Request body

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

示例响应Sample response

状态代码: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
  }
}

有关详细信息,请参阅备份保持期 REST APIFor more information, see Backup Retention REST API.

后续步骤Next steps