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

适用于: Azure SQL 数据库 Azure SQL 托管实例

备注

本文介绍如何删除设备或服务中的个人数据,并且可为 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. 这些备份可在配置的保留期内将数据库还原到某个时间点。These backups enable database restore to a point in time within the configured retention period. 如果数据保护规则要求备份在较长时间(最长 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.

备份频率Backup frequency

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.

备份存储冗余Backup storage redundancy

默认情况下,SQL 数据库和 SQL 托管实例将数据存储在复制到配对区域的异地冗余 (RA-GRS) 存储 Blob 中。By default, SQL Database and SQL Managed Instance store data in geo-redundant (RA-GRS) storage blobs that are replicated to a paired region. 这有助于防止影响主区域备份存储的中断,并且你可在发生灾难时将服务器还原到其他区域。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.

配置备份存储冗余的选项提供了在 SQL 托管实例的本地冗余或异地冗余存储 blob 之间进行选择的灵活性。The option to configure backup storage redundancy provides the flexibility to choose between locally-redundant, or geo-redundant storage blobs for a SQL Managed Instance. 若要确保数据位于部署托管实例的同一区域中,可以更改默认的异地冗余备份存储冗余,并为备份配置本地冗余 (LRS) 存储 blob。To ensure that your data stays within the same region where your managed instance is deployed, you can change the default geo-redundant backup storage redundancy and configure either locally-redundant (LRS) storage blobs for backups. Azure 存储冗余机制会存储数据的多个副本,以防范各种计划内和计划外的事件,包括暂时性的硬件故障、网络中断或断电、大范围自然灾害等。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. 配置的备份存储冗余同时应用于短期备份保留设置和长期保留备份,前者用于时间点还原 (PITR),后者用于长期备份 (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).

重要

请在托管实例创建过程中配置备份存储冗余,因为预配资源后无法再更改存储冗余。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.

备注

适用于 Azure SQL 数据库的可配置备份存储冗余目前不可用。Configurable Backup Storage Redundancy for Azure SQL Database is currently not available. 此功能在超大规模层中尚不可用。This feature is not yet available for Hyperscale tier.

备份使用情况Backup usage

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

  • 现有数据库的时间点还原 - 通过使用 Azure 门户、Azure PowerShell、Azure CLI 或 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. 对于 SQL 数据库,此操作会在与原始数据库相同的服务器上创建新的数据库,但会使用不同的名称,以避免覆盖原始数据库。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. 还原完成后,可删除原始数据库。After restore completes, you can delete the original database. 另外,可以重命名还原的数据库,然后使其具有原始数据库的名称。Alternatively, you can rename both the original database, and then rename the restored database to the original database name. 同样,对于 SQL 托管实例,此操作可以在同一订阅和同一区域中的相同或不同的托管实例上创建数据库地副本。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.
  • 删除的数据库的时间点还原 - 将已删除的数据库还原到删除时间或者还原到保留期内的任意时间点。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. 仅可在创建原始数据库所在的同一服务器或托管实例上还原已删除的数据库。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.
  • 异地还原 - 将数据库还原到其他地理区域Geo-restore - 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.

    重要

    异地还原仅适用于配置了异地冗余备份存储的 SQL 数据库或托管实例。Geo-restore is available only for SQL databases or managed instances configured with geo-redundant backup storage.

  • 从长期备份保留 - 如果为数据库配置了长期保留策略 (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 允许使用 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:

操作Operation Azure 门户Azure portal Azure PowerShellAzure PowerShell
更改备份保留Change backup retention SQL 数据库SQL Database
SQL 托管实例SQL Managed Instance
SQL 数据库SQL Database
SQL 托管实例SQL Managed Instance
更改长期备份保留Change long-term backup retention SQL 数据库SQL Database
SQL 托管实例 - N/ASQL Managed Instance - N/A
SQL 数据库SQL Database
SQL 托管实例SQL Managed Instance
从某个时间点还原数据库Restore a database from a point in time SQL 数据库SQL Database
SQL 托管实例SQL Managed Instance
SQL 数据库SQL Database
SQL 托管实例SQL Managed Instance
还原已删除的数据库Restore a deleted database SQL 数据库SQL Database
SQL 托管实例SQL Managed Instance
SQL 数据库SQL Database
SQL 托管实例SQL Managed Instance
从 Azure Blob 存储还原数据库Restore a database from Azure Blob storage SQL 数据库 - N/ASQL Database - N/A
SQL 托管实例 - N/ASQL Managed Instance - N/A
SQL 数据库 - N/ASQL Database - N/A
SQL 托管实例SQL 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.
  • 尽可能使用本地冗余备份存储(例如开发/测试环境)Use locally-redundant backup storage whenever possible (for example dev/test environments)

备份保留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 each active 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. 仅对于 Azure SQL 托管实例,在 0-35 天范围内删除了数据库后,可以设置 PITR 备份保留率。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.

如果删除数据库,系统会保留数据库的备份至特定的保留期,与为任何一个联机数据库的保留方式一样。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

对于 SQL 数据库 SQL 托管实例,可以配置完整备份的长期保留 (LTR),使其在 Azure Blob 存储中最长保存 10 年。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. 配置启用 LTR 策略后,每周完整备份将自动复制到不同的存储容器。After the LTR policy is configured, full backups are automatically copied to a different storage container weekly. 为了满足不同的合规性要求,可为每周、每月和/或每年完整备份选择不同的保留期。To meet various compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly full backups. 存储消耗量取决于所选的频率和 LTR 备份的保留期。Storage consumption depends on the selected frequency and retention periods of LTR backups. 可以使用 LTR 定价计算器来估算 LTR 存储成本。You can use the LTR pricing calculator to estimate the cost of LTR storage.

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

存储费用Storage costs

备份存储的价格取决于购买模型(DTU 或 vCore)、选择的备份存储冗余选项以及区域。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. 备份存储按每月使用的 GB 数计费,有关定价的信息,请参阅 Azure SQL 数据库定价页和 Azure SQL 托管实例定价页。The backup storage is charged per GB/month consumed, for pricing see Azure SQL Database pricing page and Azure SQL Managed Instance pricing page.

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 as per the rate of the backup storage redundancy used. 备份存储消耗量取决于各个数据库、弹性池以及托管实例的工作负荷和大小。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.

备份存储冗余Backup storage redundancy

备份存储冗余按以下方式影响备份成本:Backup storage redundancy impacts backup costs in the following way:

  • LRS 价格 = xLRS price = x
  • RA-GRS 价格 = 2xRA-GRS price = 2x

有关备份存储定价的详细信息,请访问 Azure SQL 数据库定价页Azure SQL 托管实例定价页For more details about backup storage pricing visit Azure SQL Database pricing page and Azure SQL Managed Instance pricing page.

重要

可配置的备份存储冗余目前不适用于 SQL 数据库。Configurable backup storage redundancy is currently not available for SQL Database. 对于托管实例,只能在创建托管实例的过程中指定。For Managed Instance it can only be specified during the create managed instance process. 预配资源后,不能更改备份存储冗余选项。Once the resource is provisioned, you cannot change the backup storage redundancy option.

加密备份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 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.

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

若要更改活动 Azure SQL 数据库的 PITR 备份保留,请使用以下 PowerShell 示例。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

使用 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.

示例请求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.

配置备份存储冗余Configure backup storage redundancy

备注

备份的可配置存储冗余当前仅适用于 SQL 托管实例,并且只能在创建托管实例过程中指定。Configurable storage redundancy for backups is currently only available for SQL Managed Instance, and can only be specified during the create managed instance process. 预配资源以后,不能更改备份存储冗余选项。Once the resource is provisioned, you can't change the backup storage redundancy option.

只能在创建实例期间设置托管实例的备份存储冗余。A backup storage redundancy of a managed instance can be set during instance creation only. 默认值为异地冗余存储 (RA-GRS)。The default value is geo-redundant storage (RA-GRS). 有关本地冗余 (LRS) 和异地冗余 (RA-GRS) 备份存储的定价差异,请访问托管实例定价页For differences in pricing between locally-redundant (LRS), and geo-redundant (RA-GRS) backup storage visit managed instance pricing page.

使用 Azure 门户配置备份存储冗余Configure backup storage redundancy by using the Azure portal

在 Azure 门户中,用于更改备份存储冗余的选项位于“计算 + 存储”边栏选项卡上,在创建 SQL 托管实例时,可以从“基本信息”选项卡上的“配置托管实例”选项访问该边栏选项卡 。In the Azure portal, the option to change backup storage redundancy is located on the Compute + storage blade accessible from the Configure Managed Instance option on the Basics tab when you are creating your SQL Managed Instance. 打开“计算 + 存储”配置边栏选项卡Open Compute+Storage configuration-blade

在“计算 + 存储”边栏选项卡上找到选择备份存储冗余的选项。Find the option to select backup storage redundancy on the Compute + storage blade. 配置备份存储冗余Configure backup storage redundancy

使用 PowerShell 配置备份存储冗余Configure backup storage redundancy by using PowerShell

若要在创建托管实例的过程中配置备份存储冗余,可以指定 -BackupStoageRedundancy 参数。For configuring backup storage redundancy during managed instance creation you can specify -BackupStoageRedundancy parameter. 可能的值为异地、区域和本地。Possible values are Geo, Zone and Local.

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

有关更多详细信息,请访问 New-AzSqlInstanceFor more details visit New-AzSqlInstance.

使用 Azure Policy 强制实施备份存储冗余Use Azure Policy to enforce backup storage redundancy

如果根据数据驻留要求,你需要将所有数据保留在单个 Azure 区域中,你可能希望使用 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 locally-redundant backups for your Managed Instance using Azure Policy. Azure Policy 是一项服务,可用于创建、分配和管理将规则应用于 Azure 资源的策略。Azure Policy is a service that you can use to create, assign, and manage policies that apply rules to Azure resources. Azure Policy 可帮助你确保这些资源始终符合公司标准和服务级别协议。Azure Policy helps you to keep these resources compliant with your corporate standards and service level agreements. 有关详细信息,请参阅 Azure Policy 概述For more information, see Overview of Azure Policy.

内置备份存储冗余策略Built-in backup storage redundancy policies

添加了以下新的内置策略,你可以在订阅或资源组级别分配这些策略,以阻止创建具有异地冗余备份存储的新实例。Following new built-in policies are added, which can be assigned at the subscription or resource group level to block creation of new instance(s) with geo-redundant backup storage.

SQL 托管实例应避免使用 GRS 备份冗余SQL Managed Instances should avoid using GRS backup redundancy

此处提供了 SQL 数据库和托管实例内置策略定义的完整列表。A full list of built-in policy definitions for SQL Database and Managed Instance can be found here.

若要在组织级别强制实施数据驻留要求,可以将这些策略分配到订阅。To enforce data residency requirements at an organizational level, these policies can be assigned to a subscription. 在订阅级别分配这些策略后,指定订阅中的用户将无法通过 Azure 门户或 Azure PowerShell 创建具有异地冗余备份存储的托管实例。After these are assigned at a subscription level, users in the given subscription will not be able to create a managed instance with geo-redundant backup storage via Azure portal or Azure PowerShell.

了解如何使用 Azure 门户 Azure PowerShell 分配策略Learn how to assign policies using the Azure portal or Azure PowerShell

后续步骤Next steps