Azure SQL 資料庫的業務連續性概觀
適用於：
Azure SQL 資料庫 Fabric 中的 SQL 資料庫
本文概述 Azure SQL 資料庫的商務持續性和災害復原功能，說明從可能造成資料遺失或導致資料庫和應用程式無法使用的中斷事件中復原的選項和建議。 了解當使用者或應用程式錯誤影響資料完整性、Azure 可用性區域或區域中斷，或您的應用程式需要維護時，該如何處理。
概觀
Azure SQL 資料庫中的商務持續性指透過提供可用性、高可用性和災害復原，讓您的企業在中斷時繼續運作的機制、原則和程序。
大部分情況下，SQL Database 會處理雲端環境中可能發生的中斷事件，並保持您應用程式和商務程序正常運行。 不過，有些中斷事件可能需要一些時間才能緩解，例如：
- 使用者不小心刪除或更新了資料表中的資料列。
- 惡意攻擊者成功刪除資料或刪除資料庫。
- 重大自然災害事件會撤下資料中心或者可用性區域或區域。
- 罕見的資料中心、可用性區域或全區域中斷，原因是設定變更、軟體錯誤或硬體元件故障。
可用性
Azure SQL 資料庫隨附核心復原和可靠性承諾，可防止軟體或硬體故障。 資料庫備份是自動執行的，可保護您的資料免於損毀或意外刪除。 作為平台即服務 (PaaS)，Azure SQL 資料庫服務以現成功能的形式提供可用性，其可用性 SLA 高達 99.99%，為行業領先水平。
高可用性
若要在 Azure 雲端環境中實現高可用性，請啟用區域備援，以便資料庫或彈性集區使用可用性區域，並確保資料庫或彈性集區能夠從區域性故障中復原。 許多 Azure 區域提供可用性區域，這些區域是區域內獨立的資料中心群組，具有獨立的電源、冷卻和網路基礎結構。 如果一個區域發生中斷，可用性區域的作用是在其餘區域中提供區域服務、容量和高可用性。 啟用區域備援之後，資料庫或彈性集區能夠從區域性硬體和軟體故障中復原，且復原對應用程式而言是透明的。 啟用高可用性時，Azure SQL 資料庫服務可以提供 99.995% 的更高可用性 SLA。
災害復原
若要跨區域達到更高的可用性和備援，您可以啟用災害復原功能，以從災難性的區域故障中快速復原資料庫。 Azure SQL 資料庫的災害復原選項包括：
- 作用中異地複寫功能可讓您為主要資料庫建立持續同步、可讀取的次要資料庫。
- 除了持續同步處理主要資料庫與次級資料庫之外，容錯移轉群組也可讓您管理邏輯伺服器上某些或所有資料庫，到另一個區域中的次要邏輯伺服器的複寫和容錯移轉。 容錯移轉群組群組提供保持不變的讀寫和唯讀接聽程式端點，因此無需在容錯移轉後更新應用程式連接字串。
- 當您無法透過在任何 Azure 區域中的任何現有伺服器上建立新資料庫來存取主要區域中的資料庫時，異地還原可讓您從異地複寫備份進行還原，以從區域中斷中復原。
下表比較作用中異地複寫和容錯移轉群組，這是 Azure SQL 資料庫的兩個災害復原選項：
| 作用中異地複寫 | 容錯移轉群組 | |
|---|---|---|
| 主要與次要資料庫之間的連續資料同步 | Yes | Yes |
| 同時容錯移轉多個資料庫 | 否 | Yes |
| 容錯移轉之後連接字串保持不變 | No | Yes |
| 支援讀取縮放 | 是 | Yes |
| 多個複本 | 是 | No |
| 可位於與主要複本相同的區域 | 是 | No |
提供商務持續性的功能
從資料庫的角度出發，有四個主要的可能中斷案例： 下表列出 SQL Database 商務持續性功能，可用來緩解潛在的商務中斷案例：
| 商務中斷案例 | 商務持續性功能 |
|---|---|
| 影響資料庫節點的本機硬體或軟體故障。 | 為了緩解本機硬體和軟體故障，SQL Database 包括可用性結構，可確保從這些故障中自動復原，最高達到 99.99% 的可用性 SLA。 |
| 通常由應用程式 Bug 或人為錯誤所造成的資料損毀或刪除。 這類失敗是應用程式特有的，且資料庫服務通常偵測不到。 | 為了保護您的企業免於遺失資料，SQL Database 每週會自動建立完整資料庫備份、通常每 12 或 24 小時就會進行差異資料庫備份，而且每 5 至 10 分鐘就會進行交易記錄備份。 根據預設，備份會儲存在異地備援儲存體中，供所有服務層級使用七天。 除了「基本」以外的所有服務層級均支援可設定來進行時間點還原 (PITR) 的備份保留期間，最多 35 天。 如果伺服器尚未刪除，或者您已設定長期保留 (LTR)，則可以將已刪除的資料庫還原至刪除時的狀態。 |
| 罕見的資料中心或可用性區域中斷，可能是由自然災害事件、設定變更、軟體錯誤或硬體元件故障所致。 | 若要減輕資料中心或可用性區域層級中斷，請為資料庫或彈性集區啟用區域備援，以使用 Azure 可用性區域，並在 Azure 區域內的多個實體區域提供備援。 啟用區域備援可確保資料庫或彈性集區能夠抵禦區域性故障，提供高達 99.995% 的高可用性 SLA。 |
| 影響所有可用性區域及其內的資料中心的罕見區域性中斷，可能是由災難性的自然災害事件所致。 | 若要緩解整個區域的中斷，請使用下列選項之一啟用災害復原： - 持續的資料同步處理選項，例如容錯移轉群組 (建議) 或作用中異地複寫，可讓您在次要區域中建立複本以進行容錯移轉。 - 將備份儲存體備援設定為異地備援備份儲存體以使用異地還原。 |
RTO 和 RPO
當您開發商務持續性計畫時，請了解應用程式在干擾性事件之後完全復原所需的最大可接受時間。 應用程式完全復原所需的時間稱為復原時間目標 (RTO)。 另請了解在從非計劃性干擾性事件中復原時，應用程式可以容許遺失的最近資料更新 (時間間隔) 最大期間。 潛在的資料遺失稱為復原點目標 (RPO)。
下表比較每個商務持續性選項的 RPO 和 RTO：
| 商務持續性選項 | RTO (停機時間) | RPO (資料遺失) |
|---|---|---|
| 高可用性 (使用區域備援) |
通常短於 30 秒 | 0 |
| 災害復原 (搭配使用容錯移轉群組與客戶管理的容錯移轉原則或作用中異地複寫) |
通常短於 60 秒 | 等於或大於 0 (取決於尚未復現的中斷事件發生之前的資料更改) |
| 災害復原 (使用異地還原) |
通常為分鐘或小時 | 通常為分鐘或小時 |
商務持續性檢查清單
如需將可用性最大化並最大程度提高商務持續性的規範性建議，請參閱：
為區域中斷做準備
無論您使用哪一項商務持續性功能，都必須在另一個區域中準備次要資料庫。 如果您沒有適當地準備，在容錯移轉或復原後讓應用程式上線將會多花費時間，而且可能還需要進行疑難排解，這可能會延遲 RTO。 請遵循準備次要資料庫以應對區域中斷的檢查清單。
還原同一 Azure 區域內的資料庫
您可以使用自動資料庫備份，將資料庫還原至過去的時間點。 如此一來，您就能從人為錯誤所造成的資料損毀中復原。 時間點還原 (PITR) 可讓您在同一伺服器中建立新的資料庫，以代表發生損毀事件之前的資料狀態。 對於大部分的資料庫，還原作業所需的時間少於 12 小時。 復原非常大型或非常活躍的資料庫，可能需要比較長的時間。 如需詳細資訊，請參閱資料庫復原時間。
如果支援用來進行時間點還原的最大備份保留期間不足以滿足應用程式，則可透過為資料庫設定長期保留 (LTR) 原則來延長該期間。 如需詳細資訊，請參閱長期備份保留。
在最少停機時間的情況下升級應用程式
有時，應用程式會因為維護 (例如應用程式升級) 而必須離線。 管理應用程式升級 說明如何使用「主動式異地複寫」來輪流升級雲端應用程式，以將升級時的停機時間縮到最短，並提供發生錯誤時的復原路徑。
使用待命複本以節省成本
如果您的次要複本僅用於災害復原 (DR)，而且沒有任何讀取或寫入工作負載，您可以在設定新的作用中異地複寫關聯圖時指定待命資料庫，從而節省授權成本。
更多相關資訊，請檢閱無授權待命複本。
下一步
有關應用程式設計考量，請參閱設計雲端災害復原的應用程式和彈性集區災害復原策略。