自動備份-Azure SQL Database & SQL 受控執行個體Automated backups - Azure SQL Database & SQL Managed Instance

適用於: Azure SQL Database 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 Database 和 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 Database 和 SQL 受控執行個體會將資料儲存在異地多餘的 (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 受控執行個體或 SQL Database 的本機冗余、區域冗余或異地冗余儲存體 blob 之間進行選擇。The option to configure backup storage redundancy provides the flexibility to choose between locally-redundant, zone-redundant, or geo-redundant storage blobs for a SQL Managed Instance or a SQL Database. 為了確保您的資料在部署受控實例或 SQL database 的相同區域內,您可以變更預設的異地冗余備份儲存體冗余,並設定本機冗余的 (LRS) 或區域冗余的 (ZRS) 儲存體 blob 進行備份。To ensure that your data stays within the same region where your managed instance or SQL database is deployed, you can change the default geo-redundant backup storage redundancy and configure either locally-redundant (LRS) or zone-redundant (ZRS) storage blobs for backups. 儲存體冗余機制會儲存資料的多個複本,使其受到未規劃和未規劃事件的保護,包括暫時性硬體故障、網路或電力中斷或大規模的災難。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).

若為 SQL Database 備份儲存體的複本可以在建立資料庫時設定,也可以針對現有的資料庫進行更新;對現有資料庫所做的變更僅適用于未來的備份。For a SQL Database the backup storage redundancy can be configured at the time of database creation or can be updated for an existing database; the changes made to an existing database apply to future backups only. 更新現有資料庫的備份儲存體複本之後,最多可能需要48小時才會套用變更。After the backup storage redundancy of an existing database is updated, it may take up to 48 hours for the changes to be applied. 請注意,在資料庫更新為使用本機或區域多餘的儲存體時,就會立即停用異地還原。Note that, geo restore is disabled as soon as a database is updated to use local or zone redundant storage.

重要

在受控實例建立程式期間設定備份儲存體冗余,因為布建資源之後,就無法再變更儲存體冗余。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.

重要

區域-多餘的儲存體目前僅適用于 某些區域Zone-redundant storage is currently only available in certain regions.

注意

適用于 Azure SQL Database 的可設定備份儲存體複本目前已在東南亞 Azure 區域中正式推出。Configurable Backup Storage Redundancy for Azure SQL Database is currently generally available in Southeast Asia Azure region only. 超大規模層尚無法使用這項功能。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 Database,此作業會在與原始資料庫相同的伺服器上建立新的資料庫,但會使用不同的名稱來避免覆寫原始資料庫。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 DatabaseSQL Database
SQL 受控執行個體SQL Managed Instance
SQL DatabaseSQL Database
SQL 受控執行個體SQL Managed Instance
變更長期備份保留期Change long-term backup retention SQL DatabaseSQL Database
SQL 受控執行個體-N/ASQL Managed Instance - N/A
SQL DatabaseSQL Database
SQL 受控執行個體SQL Managed Instance
從某個時間點還原資料庫Restore a database from a point in time SQL DatabaseSQL Database
SQL 受控執行個體SQL Managed Instance
SQL DatabaseSQL Database
SQL 受控執行個體SQL Managed Instance
還原已刪除的資料庫Restore a deleted database SQL DatabaseSQL Database
SQL 受控執行個體SQL Managed Instance
SQL DatabaseSQL Database
SQL 受控執行個體SQL Managed Instance
從 Azure Blob 儲存體還原資料庫Restore a database from Azure Blob storage SQL Database-N/ASQL Database - N/A
SQL 受控執行個體-N/ASQL Managed Instance - N/A
SQL Database-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 Database 或 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 Database 和 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 Database 和 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 Database 和 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.

過去1-35 天內 PITR 用途的備份保留期有時稱為短期備份保留。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 Database 和 SQL 受控執行個體,您可以在 Azure Blob 儲存體中設定完整備份長期保留 (LTR) 長達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.

重要

更新現有 Azure SQL Database 的備份儲存體複本,只會套用到針對資料庫所做的未來備份。Updating the backup storage redundancy for an existing Azure SQL Database, only applies to the future backups taken for the database. 資料庫的所有現有 LTR 備份都會繼續位於現有的儲存體 blob 中,而新的備份將會儲存在要求的儲存體 blob 類型上。All existing LTR backups for the database will continue to reside in the existing storage blob and new backups will be stored on the requested storage blob type.

如需 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 Database 定價 頁面和 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 model

針對 SQL Database 中的單一資料庫,會提供等於資料庫的最大資料儲存體大小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 Database 和 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 Database 會向 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. 這項增加會導致備份儲存體總數加倍到 1488 GB。This increase results in the total backup storage doubling to 1,488 GB. SQL Database 會回報 1 GB 的使用時間1到 372 () 的前半個月。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). 此使用方式會匯總為每月 1116 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 price = xLRS price = x
  • ZRS price = 1.25 xZRS price = 1.25x
  • RA-GRS 價格 = 2xRA-GRS price = 2x

如需有關備份儲存體定價的詳細資訊,請造訪 Azure SQL Database 定價頁面Azure SQL 受控執行個體定價頁面For more details about backup storage pricing visit Azure SQL Database pricing page and Azure SQL Managed Instance pricing page.

重要

SQL 受控實例的可設定備份儲存體複本可在所有 Azure 區域中使用,目前僅適用于 SQL Database 的東南亞 Azure 區域。Configurable backup storage redundancy for SQL Managed instance is available in all Azure regions and currently available in Southeast Asia Azure region only for SQL Database. 針對受控執行個體只能在建立受控實例進程期間指定。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.

監視成本Monitor costs

若要瞭解備份儲存體成本,請移至 Azure 入口網站中的 [ 成本管理 + 計費 ],選取 [ 成本管理 ],然後選取 [ 成本分析 ]。To understand backup storage costs, go to Cost Management + Billing in the Azure portal, select Cost Management , and then select Cost analysis . 選取所需的訂用帳戶作為 範圍 ,然後篩選您感興趣的時間週期和服務。Select the desired subscription as the Scope , and then filter for the time period and service that you're interested in.

新增 服務名稱 的篩選,然後選取下拉式清單中的 [sql database ]。Add a filter for Service name , and then select sql database in the drop-down list. 使用 [ 計量子類別 ] 篩選器來選擇您服務的帳單計數器。Use the meter subcategory filter to choose the billing counter for your service. 針對單一資料庫或彈性資料庫集區,請選取 單一/彈性集區 PITR 備份儲存體For a single database or an elastic database pool, select single/elastic pool PITR backup storage . 針對受控實例,請選取 MI PITR 備份儲存體For a managed instance, select mi PITR backup storage . 儲存體計算 子類別也可能會對您感興趣,但它們並不會與備份儲存體成本相關聯。The Storage and compute subcategories might interest you as well, but they're not associated with backup storage costs.

備份儲存體成本分析

注意

計量僅適用于目前使用中的計數器。Meters are only visible for counters that are currently in use. 如果無法使用計數器,可能是目前未使用該類別。If a counter is not available, it is likely that the category is not currently being used. 例如,未部署受控實例的客戶將不會顯示受控實例計數器。For example, managed instance counters will not be present for customers who do not have a managed instance deployed. 同樣地,不使用儲存體的資源也看不到儲存體計數器。Likewise, storage counters will not be visible for resources that are not consuming storage.

加密的備份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 Database & 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.

在完整性檢查期間找到的任何問題都會對工程小組發出警示。Any issues found during the integrity check will result in an alert to the engineering team. 如需詳細資訊,請參閱 SQL Database 中的資料完整性For more information, see Data Integrity in SQL Database.

系統會使用總和檢查碼選項來執行所有資料庫備份,以提供額外的備份完整性。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,將不會受到影響。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 Database 的 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.

重要

SQL Database 和 SQL 受控執行個體仍支援 PowerShell AzureRM 模組,但未來所有的開發都是針對 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。For 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.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

Request bodyRequest 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.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

Request bodyRequest 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 for SQL Managed Instance can only be specified during the create managed instance process. 布建資源之後,您就無法變更備份儲存體的冗余選項。Once the resource is provisioned, you can't change the backup storage redundancy option. 針對 SQL Database,這項功能的公開預覽版目前僅適用于東南亞 Azure 區域。For SQL Database, public preview of this feature is currently only available in Southeast Asia Azure region.

只有在建立實例時,才可以設定受控實例的備份儲存體冗余。A backup storage redundancy of a managed instance can be set during instance creation only. 針對 SQL Database 可以在建立資料庫時設定,也可以針對現有的資料庫進行更新。For a SQL Database it can be set when creating the database or can be updated for an existing database. 預設值是異地冗余儲存體 (GRS) 。The default value is geo-redundant storage (RA-GRS). 如需在本機冗余 (LRS) 、區域冗余 (ZRS) 和異地冗余 (RA-GRS) 備份儲存體之間的定價差異,請造訪 受控實例定價頁面For differences in pricing between locally-redundant (LRS), zone-redundant (ZRS) and geo-redundant (RA-GRS) backup storage visit managed instance pricing page.

使用 Azure 入口網站設定備份儲存體冗余Configure backup storage redundancy by using the Azure portal

在 Azure 入口網站中,您可以在 [ 建立 SQL Database ] 分頁上設定備份儲存體冗余。In Azure portal, you can configure the backup storage redundancy on the Create SQL Database blade. 選項可在 [備份儲存體冗余] 區段下取得。The option is available under the Backup Storage Redundancy section. 開啟 Create SQL Database bladeOpen Create SQL Database blade

使用 PowerShell 設定備份儲存體冗余Configure backup storage redundancy by using PowerShell

若要在建立新資料庫時設定備份儲存體冗余,您可以指定-BackupStoageRedundancy 參數。To configure backup storage redundancy when creating a new database you can specify the -BackupStoageRedundancy parameter. 可能的值為 [地區]、[區域] 和 [本機]。Possible values are Geo, Zone and Local. 根據預設,所有 SQL 資料庫都會使用異地冗余儲存體進行備份。By default, all SQL Databases use geo-redundant storage for backups. 如果是使用本機或區域多餘的備份儲存體來建立資料庫,則會停用異地還原。Geo Restore is disabled if a database is created with local or zone redundant backup storage.

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

如需詳細資訊,請造訪 新的->set-azsqldatabaseFor details visit New-AzSqlDatabase.

若要更新現有資料庫的備份儲存體冗余,您可以使用-BackupStorageRedundancy 參數。To update backup storage redundancy of an existing database, you can use the -BackupStorageRedundancy parameter. 可能的值為 [地區]、[區域] 和 [本機]。Possible values are Geo, Zone and Local. 請注意,在資料庫上套用變更最多可能需要48小時的時間。Note that, it may take up to 48 hours for the changes to be applied on the database. 從異地複寫備份存放裝置切換至本機或區域冗余儲存體時,會停用異地還原。Switching from geo-redundant backup storage to local or zone redundant storage disables geo restore.

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

如需詳細資料,請造訪 Set->set-azsqldatabaseFor details visit Set-AzSqlDatabase

注意

若要使用-BackupStorageRedundancy 參數搭配資料庫還原、資料庫複製或建立次要作業,請使用 Azure PowerShell Az. Sql 2.11.0 版版本。To use -BackupStorageRedundancy parameter with database restore, database copy or create secondary operations, use Azure PowerShell version Az.Sql 2.11.0.

使用 Azure 原則來強制執行備份儲存體冗余Use Azure Policy to enforce backup storage redundancy

如果您的資料落地需求需要您將所有資料保留在單一 Azure 區域中,您可能會想要使用 Azure 原則對 SQL Database 或受控執行個體強制執列區域冗余或本機多餘的備份。If you have data residency requirements that require you to keep all your data in a single Azure region, you may want to enforce zone-redundant or locally-redundant backups for your SQL Database or Managed Instance using Azure Policy. Azure 原則是一項服務,可讓您用來建立、指派和管理將規則套用至 Azure 資源的原則。Azure Policy is a service that you can use to create, assign, and manage policies that apply rules to Azure resources. Azure 原則可協助您讓這些資源符合公司標準和服務等級協定的規範。Azure Policy helps you to keep these resources compliant with your corporate standards and service level agreements. 如需詳細資訊,請參閱 Azure 原則概觀For more information, see Overview of Azure Policy.

內建的備份儲存體冗余原則Built-in backup storage redundancy policies

新增新的內建原則之後,您可以在訂用帳戶或資源群組層級指派這些原則,以防止建立新的資料庫 (s) 或實例 (s,) 使用異地冗余備份儲存體。Following new built-in policies are added, which can be assigned at the subscription or resource group level to block creation of new database(s) or instance(s) with geo-redundant backup storage.

SQL Database 應避免使用 GRS 備份備援SQL Database should avoid using GRS backup redundancy

SQL 受控執行個體應避免使用 GRS 備份備援SQL Managed Instances should avoid using GRS backup redundancy

您可以在 這裡找到 SQL Database 和受控執行個體內建原則定義的完整清單。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 database or a managed instance with geo-redundant backup storage via Azure portal or Azure PowerShell.

重要

透過 T-sql 建立資料庫時,不會強制執行 Azure 原則。Azure policies are not enforced when creating a database via T-SQL. 若要在使用 T-sql 建立資料庫時強制執行資料存放區,請 使用 ' LOCAL ' 或 ' ZONE ' 作為 CREATE database 語句中 BACKUP_STORAGE_REDUNDANCY 辨識的輸入To enforce data residency when creating a database using T-SQL, use 'LOCAL' or 'ZONE' as input to BACKUP_STORAGE_REDUNDANCY paramater in CREATE DATABASE statement.

瞭解如何使用Azure 入口網站Azure PowerShell指派原則Learn how to assign policies using the Azure portal or Azure PowerShell

後續步驟Next steps