使用 Azure SQL Database & Azure SQL 受控執行個體的商務持續性概觀
適用於：
Azure SQL Database Azure SQL 受控執行個體
Azure SQL Database 和 SQL 受控執行個體中的商務持續性是指讓您的企業在面臨中斷時可持續運作的機制、原則和程序 (特別是其運算基礎結構)。 在大部分情況下，SQL Database 和 SQL 受控執行個體將會處理雲端環境中可能發生的干擾性事件，並讓您的應用程式和商務程序能夠持續執行。 不過，SQL Database 有一些無法自動處理的干擾性事件，例如：
- 使用者不小心刪除或更新了資料表中的資料列。
- 惡意攻擊者接著刪除資料或刪除資料庫。
- 地震導致電源中斷並讓資料中心暫時停用。
此概觀描述 SQL Database 和 SQL 受控執行個體針對商務持續性和災害復原所提供的功能。 了解選項、建議和教學課程，以從可能導致資料遺失或造成資料庫和應用程式無法使用的干擾性事件中復原。 了解當使用者或應用程式錯誤影響資料完整性、Azure 區域中斷，或您的應用程式需要維護時該如何處理。
您可用來提供商務持續性的 SQL Database 功能
就資料庫的觀點而言，有四個主要可能中斷案例：
- 影響資料庫節點的本機硬體或軟體失敗，例如磁碟機失敗。
- 通常由應用程式 Bug 或人為錯誤所造成的資料損毀或刪除。 這類失敗是應用程式特有，而且資料庫服務通常偵測不到。
- 可能由天然災害所造成的資料中心中斷。 此案例需要某種程度的異地備援，讓應用程式能容錯移轉到替代資料中心。
- 升級或維護錯誤，在計劃性基礎結構維護升級期間發生的非預期問題，可能需要快速復原到先前的資料庫狀態。
為了減緩本機硬體和軟體失敗，SQL Database 包括高可用性架構，確保可會從這些失敗中自動復原、最高可達 99.995% 的可用性 SLA。
為了保護您的企業免於遺失資料，SQL Database 和 SQL 受控執行個體每週均會自動建立完整資料庫備份、通常每 12 小時就會進行差異資料庫備份，而且每 5 - 10 分鐘就會進行交易記錄備份。 所有服務層級的備份都會在 RA-GRS 儲存體中至少儲存七天的時間。 除了「基本」以外的所有服務層級均支援可設定來進行時間點還原的備份保留期間，最多 35 天。
SQL Database 和 SQL 受控執行個體也提供數種商務持續性功能，可讓您用來減輕各種非計劃性案例。
- 時態表可讓您從任何時間點還原資料列版本。
- 內建自動備份和時間點還原可讓您將整個資料庫還原至已設定保留期間 (最多 35 天) 內的某個時間點。
- 如果尚未刪除伺服器，您可以將已刪除的資料庫還原到當初加以刪除的時間點。
- 長期備份保留可讓您最多保留備份 10 年。
- 作用中異地複寫可讓您建立可讀取的複本，並在資料中心中斷或應用程式升級時，手動容錯移轉至任何複本。
- 自動容錯移轉群組可在資料中心中斷時，讓應用程式能夠自動復原。
復原相同 Azure 區域內的資料庫
您可以使用自動資料庫備份，將資料庫還原至過去的時間點。 如此一來，您就能從人為錯誤所造成的資料損毀中復原。 時間點還原可讓您在相同伺服器中建立新的資料庫，以代表發生損毀事件之前的資料狀態。 對於大部分的資料庫，還原作業所需的時間少於 12 小時。 復原非常大型或非常活躍的資料庫，可能需要比較長的時間。 如需復原時間的詳細資訊，請參閱資料庫復原時間。
如果支援用來進行時間點還原 (PITR) 的最大備份保留期間不足以滿足應用程式，則可透過為資料庫設定長期保留 (LTR) 原則來延長該期間。 如需詳細資訊，請參閱長期備份保留。
比較異地複寫和容錯移轉群組
自動容錯移轉群組會簡化異地複寫的部署和使用方式，並新增其他功能，如下表所述：
| 異地複寫 | 容錯移轉群組 | |
|---|---|---|
| Automatic failover | 否 | 是 |
| 同時容錯移轉多個資料庫 | 否 | 是 |
| 使用者必須在容錯移轉之後更新連接字串 | 是 | 否 |
| SQL 受控執行個體支援 | 否 | 是 |
| 可位於與主要複本相同的區域 | 是 | 否 |
| 多個複本 | 是 | 否 |
| 支援讀取縮放 | 是 | 是 |
將資料庫復原到現有的伺服器
雖然很罕見，但 Azure 資料中心也可能會中斷。 發生中斷時，可能只會讓業務中斷幾分鐘，也可能會持續幾小時。
- 其中一個選項是等待您的資料庫在資料中心中斷結束之後重新上線。 這適用於可以容忍資料庫離線的應用程式。 例如，您不需要不斷處理的開發專案或免費試用版。 當資料中心中斷時，您不會知道中斷可能持續多久，因此，這個選項只有在您暫時不需要資料庫時才可行。
- 另一個選項是使用異地備援資料庫備份 (異地還原)，在任何 Azure 區域中的任何伺服器上還原資料庫。 異地還原使用異地備援備份做為其來源，即使因為中斷而無法存取資料庫或資料中心，也能用來復原資料庫。
- 最後，如果您已使用作用中異地複寫或自動容錯移轉群組來為資料庫設定異地次要資料庫，便可迅速地從中斷復原。 根據您選擇的這些技術，您可以使用手動或自動容錯移轉。 雖然容錯移轉本身只需要幾秒鐘的時間就能完成，服務將需要至少 1 小時才能啟動。 這是依據中斷的規模來確保容錯移轉之正當性的必要作法。 此外，基於非同步複寫的本質，容錯移轉可能會造成小規模的資料遺失。
當您開發商務持續性計劃時，您必須了解應用程式在干擾性事件之後完全復原所需的最大可接受時間。 完全復原應用程式所需的時間稱為復原時間目標 (RTO)。 您也必須了解在從非計劃性干擾性事件中復原時，應用程式可以容許遺失的最近資料更新 (時間間隔) 最大期間。 潛在的資料遺失稱為復原點目標 (RPO)。
不同的復原方法會提供不同層級的 RPO 和 RTO。 您可以選擇特定的復原方法，或使用方法組合來實現完整的應用程式復原。 下表比較每個復原選項的 RPO 和 RTO。 自動容錯移轉群組會簡化異地複寫的部署和使用方式，並新增其他功能，如下表所述：
| 復原方法 | 復原時間目標 (RTO) | 復原點目標 (RPO) |
|---|---|---|
| 從異地複寫備份進行異地還原 | 12 h | 1 小時 |
| 自動容錯移轉群組 | 1 小時 | 5 秒 |
| 手動資料庫容錯移轉 | 30 秒 | 5 秒 |
注意
手動資料庫容錯移轉是指使用非計劃性模式，將單一資料庫容錯移轉到其異地複寫的次要資料庫。 請參閱此文章稍早的表格，以取得自動容錯移轉 RTO 和 RPO 的詳細資料。
如果您的應用程式符合下列任何準則，請使用自動容錯移轉群組：
- 是關鍵性應用程式。
- 具有不允許 12 小時或以上之停機時間的服務等級協定 (SLA)。
- 停機可能會衍生財務責任。
- 具有很高的資料變更率，且無法接受為時 1 小時的資料遺失。
- 與潛在的財務責任和相關企業損失相較下，使用主動式異地複寫的額外成本較低。
您可以根據應用程式需求，選擇使用資料庫備份和作用中異地複寫的組合。 若要探討使用這些商務持續性功能，針對獨立資料庫和彈性集區進行的設計考量，請參閱設計雲端災害復原的應用程式和彈性集區災害復原策略。
下列各節概述使用資料庫備份或主動式異地複寫來進行復原的步驟。 如需包括規劃需求的詳細步驟、復原後步驟，以及如何模擬中斷以執行災害復原演練的相關資訊，請參閱從中斷復原 SQL Database 中的資料庫。
準備中斷
無論您要使用何種商務持續性功能，您都必須︰
- 識別並準備目標伺服器，包括伺服器層級的 IP 防火牆規則、登入和
master資料庫層級權限。 - 決定如何將用戶端和用戶端應用程式重新導向到新的伺服器
- 記錄其他相依性，例如稽核設定和警示
如果您沒有適當地準備，在容錯移轉或資料庫復原後讓應用程式上線將會多花費時間，而且也可能需要在有壓力的情況下進行疑難排解 - 這是不良的情況組合。
容錯移轉至異地複寫的次要資料庫
若您使用作用中異地複寫或自動容錯移轉群組作為復原機制，則可設定自動容錯移轉原則或使用手動的非計劃性容錯移轉。 啟動容錯移轉後，次要資料庫就會成為新的主要資料庫，並準備好記錄新的交易以及回應查詢 - 只會遺失尚未複寫的資料。 如需關於設計容錯移轉程序的資訊，請參閱設計雲端災害復原應用程式。
注意
當資料中心重新上線時，舊的主要資料庫就會自動重新連線至新的主要資料庫，並成為次要資料庫。 若您需要將主要複本重新定位至原始區域，可手動啟動規劃的容錯移轉 (容錯回復)。
執行異地還原
如果您使用自動備份搭配異地備援儲存體 (預設為啟用)，您可以使用異地還原來復原資料庫。 復原通常會在 12 小時內進行，且可能遺失最多 1 小時的資料 (視最後一次記錄備份的建立並複寫時間而定)。 在復原完成之前，資料庫無法記錄任何交易或回應任何查詢。 請注意，異地還原只會將資料庫還原至最後一個可用的時間點。
注意
如果資料中心在您的應用程式切換到復原的資料庫之前就重新上線，則您可以取消復原。
執行容錯移轉後/復原後工作
從其中任何一種復原機制復原之後，您都必須執行下列額外的工作，您的使用者和應用程式才能回復正常執行狀態︰
- 將用戶端與用戶端應用程式重新導向新的伺服器與還原的資料庫。
- 確定有適當的伺服器層級 IP 防火牆規則供使用者連線或使用資料庫層級防火牆，才能啟用適當的規則。
- 確定有適當的登入和 master 資料庫層級權限 (或使用自主使用者)。
- 視情況設定稽核。
- 視情況設定警示。
注意
如果您使用容錯移轉群組，並使用 R/W 接聽程式來連線至資料庫，即會針對應用程式以自動且明確的方式進行容錯移轉後的重新導向。
在最少停機時間的情況下升級應用程式
有時，應用程式會因為計劃性維護 (例如應用程式升級) 而必須離線。 管理應用程式升級 說明如何使用「主動式異地複寫」來輪流升級雲端應用程式，以將升級時的停機時間縮到最短，並提供發生錯誤時的復原路徑。
後續步驟
若要探討單一資料庫和彈性集區的應用程式設計考量，請參閱設計雲端災害復原的應用程式和彈性集區災害復原策略。