最近在 Microsoft Azure 的首頁上多了一個「主機庫」（Gallery）的頁面，這一頁蒐集了 Azure 各種服務所提供的開始選項，以虛擬機器來說，就是展示已經在 Azure 上獲得官方支援的各種作業系統映像檔：
而在 Web 應用程式的部份，也陳列了由 Azure 團隊驗證過可以順利並直接安裝在 Azure 上的各種開源的架站套件：
只要挑選一個架站套件就可以立即開始架設網站，比方說很多人喜愛的 WordPress 套件：
只要按下 Create Web App 的按鈕就可以開始拿 WordPress 在 Azure 網站服務上架設網站囉！
如果您發現在 Gallery 中找不到您喜愛的架站套件，歡迎您到這裡來反應，我們會盡快考慮移植上 Microsoft Azure。
相信大家對資料的備份還原一定不陌生，這中間的過程一定也困擾著許多人，難道備份還原一定要這麼麻煩嗎?就不能再簡單一點嗎?
大家的心聲微軟聽到了，所以微軟為大家提供了更簡單、快速，也更安全的方法，就是利用Microsoft Azure所提供的服務，顛覆大家對備份還原的看法。
以下連結為備份還原詳細步驟 :
SQL Server 2014: https://onedrive.live.com/redir?resid=7D20775E3D8E95A2!1239&authkey=!AMYrvJJ-luP9lDc&ithint=file%2cpptx
Windows Server 2012 R2: https://onedrive.live.com/redir?resid=7D20775E3D8E95A2!1240&authkey=!AIRWbeZAlbDklPk&ithint=file%2cpptx
感謝北科大劉建昌同學翻譯微軟公司主管 Tobias Ternstrom 於 2014 年 7 月 12 日所發表的文章 http://azure.microsoft.com/blog/2014/07/12/spotlight-on-sql-database-active-geo-replication/
在本篇文章中，我們將繼續針對 Azure SQL Database 各種業務連續性 ( Business Continuity ) 方案作介紹，以及討論最近 Azure SQL Database Premium 版所提供的主動異地備援 ( Active Geo-Replication ) 功能。除了本篇文章的介紹之外，您也可以透過 Channel 9 觀看由 Sasha Nosov 和 Scott Klein 所主講的關於主動異地備援如何運作以及如何確保業務連續性的介紹影片。
所謂業務連續性 ( Business continuity ) 意指當企業在面臨資訊基礎建設或系統發生中斷時，能夠讓資訊服務持續不間斷之機制、策略或是程序。依照資料庫的角度來看，最主要有四種造成服務中斷的狀況 :
1. 本地端硬體或軟體故障時會影響資料庫節點 ( node ) 之運作。( 例如 : 磁碟機故障 )
2. 資料庫內的資料損毀或是遭到刪除 : 此種錯誤通常是因為應用程式的 bug 或人為因素所造成，因此無法透過基礎建設 ( infrastructure ) 方式來偵測問題或排除問題。
3. 資料中心停止運作 : 發生這種原因可能是由自然災害所引起，在這種情況下，需要使用容錯轉移 ( failover ) 的異地備援 ( geo-redundancy )，將現有服務移轉到備用的資料中心。
4. 升級或維護時所發生的錯誤 : 當在進行更新或是維護時，發生了出乎意料的錯誤，此時需要將資料庫還原到更新前的原始狀態。
從 Azure SQL Database 建立的那一刻起，Azure 系統一直維持每個資料庫都有三個甚至是更多的副本來保護資料庫，資料異動確認 ( updates committed ) 回應前至少已經有兩份資料副本，在高可用性 ( HA ) 措施的保護下，要是發生上述第一點服務中斷的情況，也就是本地端的硬體或軟體發生故障時，仍可以有效的保護資料庫持續提供服務。
而在最新發布的 Azure SQL Database 服務層 ( Basic,、Standard、Premium ) 中，也為了因應上述其他三種資料庫服務中斷情況，提供了確保用戶業務連續性方案。
以下將個別來介紹Azure SQL Database如何在中斷發生的狀況下維持商業連續性 :
資料庫內的資料損毀或是遭到刪除
所有的 Azure SQL Database 資料庫版本 ( Basic、Standard、Premium ) 服務層都提供了自動備份的功能。這項功能專門可以解決因資料損毀或被刪除所造成的錯誤。Azure SQL Database 會每週做一次完整備份 ( full backups )，每天做一次差異備份 ( differential backup ) 以及每五分鐘進行交易記錄備份 ( log backups )。而備份的保存期限會依照使用者所使用服務層而有所不同，Premium 版為 35 天、Standard 版為 14 天、Basic 版為 7 天。您可以利用在保存期限內的任何一個備份來還原資料庫，甚至可以還原最近遭到刪除的資料庫，此一自由還原資料至任意時間點的功能可參閱此篇內容。
資料中心停止運作
而針對 Azure 資料中心因為某些原因造成的長時間停擺，Azure SQL Database 各版本提供多種將資料庫備份到另外一個地區資料中心的功能，目前有三種跨資料中心的備援方式可供選擇 :
1. 異地還原功能 ( Geo-restore ) ，無論 Azure SQL Database 的 Basic、Standard 和 Premium 版都能夠透過異地還原功能，在配對的資料中心運用 Azure Storage 內的地理備援複本將資料還原，相關資訊可參閱此篇內容。
2. 標準異地備援 ( Standard geo-replication ) Azure SQL Database 在 Standard 和 Premium 版上擴展了本地端高可用性系統 ( Local HA system ) 能力，用戶可在 Azure 配對之資料中心 ( paired region ) 上建立和維護一個次要資料庫，在平時這個次要資料庫是離線並且是無法讀取的，一旦遇到主資料中心發生停止運作的情況，���戶可以決定是否進行容錯轉移，此時在配對資料中心備援用的次要資料庫方可使用，相關資訊可參閱此篇內容。
3. 主動異地備援 ( Active geo-replication ) Azure SQL Database Premium 版用戶可以選擇此異地備援方式，降低資料遺失風險、並能在最短時間恢復在異地恢復運作的一項災難備援解決方案。主動準異地備援功能可讓用戶選擇多達 4 個地理備援的次要資料庫，而這些次要資料庫可以在任何時候進行讀取，並且也可以用於負載平衡 ( Load Balance ) 快速讀取這些副本資料。主動異地備援目前已經進入技術預覽階段，用戶可以公開測試。
升級或維護時所發生的錯誤
使用主動異地備援，您可以建立一個連續的資料庫副本，透過它能夠立即的凍結先前更新或是維護的資料庫和應用程式，而在這個過程之中若是偵測到的錯誤，也能夠快速地回復到這個連續的資料庫副本。
不同的 Azure SQL Database 服務層提供了不同的災難備援解決方案。我們想要強調的是，在不同 Azure SQL Database 服務層之間用戶可以輕易地進行 ”降級” 或是 ”升級”，因此，當資料庫需要進行一些很重要的更新時，您可以先將資料庫從 Standard 版 ”升級” 到 Premium 版，這樣就能夠使用最保險的主動異地備援方式進行系統更新。等到更新完成之後，再將資料庫 ”降級” 回 Standard 版。這樣的好處一方面可以減少成本，另外一方面又能夠提升資料庫在更新時的可靠度。
接下來我們將仔細的描述主動異地備援如何使用於確保業務連續性，並且透過下面的圖示來說明它是如何運作的。
 |
圖一 一個 Azure SQL Database Premium 版的資料庫可以同時在同個區域或是不同的區域上建立最多四個可讀取的次要資料庫
主動異地備援關係 ( Active geo-replication relationships ) 可以透過 Azure 入口管理網站、PowerShell、REST API 來進行管理和建立。在入口網站中，您可以從主要或是輔助的資料庫中管理其備援關係，並且從主資料庫中監控每一個次要資料庫複製的狀況。
圖二 可以使用 Azure 管理入口網站建立和監控多達四個不同資料中心上的次要資料庫
每個資料庫可以建立多達四個可讀取的次要資料庫，每一個都與主資料庫擁有相同的名稱，但是分別建立於不同的伺服器上(伺服器所在的資料中心區域可以相同，也可以不同 )。當次要資料庫第一次被建立時，其狀態為主資料庫當前的狀況，一旦當次要資料庫建立完畢之後，它將會從主資料庫那裡進行連續性的資料複製。
次要資料庫就如同一般的資料庫，在本地端同樣地擁有高可用性系統 ( HA system ) 架構的保護。
圖三 次要資料庫的名稱與主資料庫相同，但是位於不同的伺服器上
不同於 Azure SQL Database 本地端高可用性架構下採用即時的資料複製方式，主動異地備援從主資料庫將資料複製到次要資料庫的資料複製方式是屬於非同步的，當主資料庫正在等待與次要資料庫完成資料交易時，主資料庫不會產生封鎖 ( blocked ) 的狀況。當複製資料到較遙遠的資料中心時，這項改變將可以解決資料複製時發生連線問題 (connection problems) 或網路高延遲 ( high-latency )。
為了確保次要資料庫進行資料交易時，不會造成主資料庫發生瓶頸 ( bottleneck )，因此次要資料庫需要擁有與主資料庫相同 ( 甚至更高 ) 的服務水準等級。
在使用主動異地備援時，次要資料庫是可以讀取的，所以可以支援唯讀 (read-only) 負載之應用情境。當使用者要跨越多個資料庫進行複雜的查詢動作或是需要低延遲時間讀取資料時，這項功能就能夠派上用場。
圖四 : 當某地資料中心發生停擺，可以終止備援關係，並且應用程式將進行容錯轉移到次要位置上。
每個主資料庫的備援關係 ( Replication relationships ) 是可以手動進行調整的，它允許您可以在任何時間點終止複寫。如果您決定終止主區域的複寫，您可以選擇立即終止 ( 這樣會遺失所有尚未執行的交易 )，也可以選擇在所有交易結束之後再終止。如果是資料中心停止運作，連帶影響到主資料庫停止服務，此時仍然可以手動使用容錯移轉。
圖五 : 您可以選擇立即停止或是等待所有數據交易處理完之後再停止
注意 : 只有主資料庫才有提供上述兩種停止作業方式。
若是從次要資料庫終止備援關係的話，備援關係將立即終止，並且您將會失去尚未被複製的資料交易。而會失去多少將取決於主資料庫在故障的時間點所做的備份以及在連線中緩衝多少資料交易。當您決定是否要終止備援關係時，您需要考慮到資料遺失的問題以及是否資料庫是否需要再進行備份。
圖六 : 若是從次要資料庫上進行停止異地備援的動作，就只能夠選擇立即停止
一旦您終止了主資料庫與次要資料庫間的備援關係，此時次要資料庫將成為一個可以正常讀寫的資料庫，同時您也擁有這個資料庫完整的存取權限。由於次要資料庫與主資料庫擁有相同的名稱 ( 但是在不同的伺服器上 )，因此您需要在應用程式上重新配置連接字串 ( Connection String )。若您進行了容錯移轉，這將需要在新的資料庫上重新建立與先前主資料庫相同的地理備援關係，以確保在容錯轉移之後，仍繼續擁有地理備援或負載平衡的能力，滿足業務連續性上的需求。
圖七 : 在終止次要資料庫的備援關係之後，新的主資料庫也需要建立地理備援關係來保護資料庫，並且也支援負載平衡
主動異地備援可以被整合進任何應用程式架構中，但是在某些應用架構中使用它是有風險存在的。更多關於此主題的資訊請參照本文。
主動異地備援不僅提供了強大的地理備援功能來保護資料庫不受到資料中心停擺所影響，更能夠使用在不同的商業連續性方案。主動異地備援目前已進入技術預覽階段，只有 Azure SQL Database Premium 版方有提供。
您可以透過此文章了解更多關於 Azure SQL Database 使用主動異地備援來維持業務連續性，或是觀看在Channel 9上由 Sasha 和Scott 主講關於主動異地備援如何支援實際業務的影片。我們將認真聽取您的意見，請您放心使用它，並且告知我們您的想法。
感謝北科大劉建昌同學翻譯微軟公司 Azure SQL Database 團隊主管 Tony Petrossian 於 2014 年 9 月 13 日所發表的文章 http://azure.microsoft.com/blog/2014/09/13/azure-sql-database-geo-restore/
本篇文章將會繼續介紹有關於 Azure SQL Database 中針對業務連續性 ( Business Continuity ) 以及災害復原 (
BCDR, Business Continuity and Disaster Recovery ) 相關功能中的異地還原 (Geo-Restore) 功能。在先前介紹標準異地備援 ( Standard Geo-replication ) 文章中，我討論了 Azure SQL Database 不同服務層 ( Service Tier ) 中對於處理災難復原的各項選擇，以下的表格可以讓我們快速的複習。
RTO ( Recovery Time Objective ) : 系統要在多少時間內回復正常
RPO ( Recovery Point Objective ) : 可忍受的資料遺失的時間長度
| 業務連續性與災害復原 ( BCDR, Business Continuity and Disaster Recovery ) 相關功能 | Basic 版 | Standard 版 | Premium 版 |
| 即時還原 ( Point in Time Restore ) | 還原至過去 7 天內的某時間點 | 還原過去 14 天內的某時間點 | 還原過去 35 天內的某時間點 |
| 異地還原 ( Geo-Restore ) | RTO<24小時 RPO<24小時 | RTO<24小時 RPO<24小時 | RTO<24小時 RPO<24小時 |
| 標準異地備援 ( Standard Geo-Replication ) | 不支援 | RTO<2小時 RPO<30分鐘 | RTO<2小時 RPO<30分鐘 |
| 主動異地備援 ( Active Geo-Replication ) | 不支援 | 不支援 | RTO<1小時 RPO<5分鐘 |
異地還原（Geo-restore）是一種利用地理容錯備份 ( geo-redundant backup ) 來還原並建立新資料庫的一種技術，此功能適用於任何 Azure SQL Database 所在之資料中心。由於它使用了一個地理容錯備份來還原資料庫，因此即使資料庫因為不明原因停擺，還是能夠在異地進行還原的動作。異地還原功能內建在所有的 Azure SQL Database 服務層中 ( Basic、Standard、Premium )，此功能無須額外設定即會自動的運作，並且不會增加任何額外的花費。
Azure SQL Database 異地還原使用了與時間點還原 ( point in time restore ) 相同的技術，只有一個主要的差別，那就是它使用了 Azure Storage BLOB 讀取權限異地備援儲存體 ( RA-GRS ) 的特性，讓資料庫的備份資料儲存於 BLOB 內，並透過 Azure Storage BLOB 異地備援功能備份到另一配對之資料中心，再將時間點最近的異地資料庫副本來還原資料庫。
每一個主要的 Azure SQL Database 資料庫皆會維護一個備份鏈 (backup chain) ，所謂備份鍊包含了每週一次完整備份 ( full backups )、每天一次差異備份 ( differential backup ) 以及每五分鐘進行交易記錄備份 ( log backups )，透過這個備份鏈，所有最新的完整備份和差異備份皆會儲存到 Azure Storage BLOB ( RA-GRS ) 儲存體中。由於這些 BLOB 具備地理複製 ( geo-replicated ) 能力，因此即使在資料庫的主要區域 ( Primary region ) 中發生大規模的故障，備份在異地資料中心的資料不會受到影響。
下圖呈現了這個過程 :
圖一 : 每週和每日的備份儲存在儲存體容器 ( storage container )中，透過 Azure Storage BLOB RA-GRS 地理複寫功能，將資料庫自動備份副本複寫到配對資料中心 Azure Storage BLOB 內。
如果發生大規模的故障事件造成 Azure SQL Database 資料庫所在之資料中心停擺，用戶就可以利用異地還原的功能來將資料庫還原到配對區域的資料中心內的 Azure SQL Database，以便盡速繼續提供服務，但由於 Azure Storage BLOB 儲存體內儲存的是 Azure SQL Database 每日差異備份的內容，因此 RPO ( Recovery Point Objective 可忍受的資料遺失的時間長度 ) 最長可能會達 24 小時。
下圖呈現了這個過程 :
圖二: 利用 Azure SQL Database 每日備份在異地進行還原資料庫動作
異地還原能夠從 Azure 管理網站上使用。在 Azure SQL Database 列表中選取要備援的伺服器，並且選擇"備份"的選項。
在備份的選項中，提供了該伺服器中所有可以使用的備份清單，其中也包含了上次備份的時間以及備份的服務層版本。
當您選擇了一個備份進行還原，您需要為新建立的還原資料庫提供一個名稱，並且指定目標伺服器，一旦按下確認之後，還原動作將會把還原資料庫放置到指定的伺服器上。
圖三 : 在 SQL資 料庫中選取 "伺服器"選項
圖四 : 選擇您要還原的資料庫，並且選取"備份"選項
圖五 : 在異地備份列表上選擇要還原的資料庫
圖六 : 設定還原資料庫的名稱以及目標伺服器
圖七 : SQL資料庫列表會顯示出資料庫正在還原
如同 Microsoft Azure 其他各項管理功能，用戶同樣地也可以透過 REST API 或 PowerShell 來進行上述的還原步驟。
透過 Azure 管理入口網站來進行還原資料庫的動作，較適合特別且小量的資料庫還原。而使用 REST API 或 Powershell 則適用於多個資料庫還原或是自訂管理腳本 ( Script ) 和應用程式。您可以參考 Azure SQL Database REST API 和 Azure SQL Database Recovery PowerShell API。
若啟動了一個錯誤的還原操作，您不需要等待還原的動作結束才進行取消，可以透過將還原資料庫刪除的方式，來取消此操作取消，這樣就可以避免有任何費用的產生。
影響恢復時間 ( recovery time ) 的因素
恢復時間會受到以下因素影響 :
若有一個區域資料中心長期處在停機的狀態下時，則其他區域就有可能產生大量的異地還原要求 ( geo-restore requests )。此時系統會適時限定還原資源的分配，以確保原本在該區域的工作附載 ( workloads ) 不會受到影響。因此若有大量的請求湧入，勢必會增加該區域恢復資料庫的時間。
雖然異地還原適用於所有 Azure SQL Database 服務層 ( Basic、Standard、Premium)，但這只是最基本的資料庫災害復原解決方式( Disaster Recovery solution )，因此 PRO 和 RTO 會比其他進階的災害復原解決方式 ；例如 : 標準異地備援 ( Standard Geo-Replication ), 主動異地備援 ( Active Geo-Replication ) 花費的時間來的長。
一個 Azure SQL Database Basic 層級擁有最大的 2GB 異地還原，異地還原提供了一個合理的災害復原解決方式 ( RTO 為24小時 )。而對於 Standard 和 Premium 層級的資料庫而言，若是想要讓恢復時間縮短或是減少資料量的遺失，您可以考慮使用標準異地備援 ( Standard Geo-Replication ), 主動異地備援 ( Active Geo-Replication ) 。這兩個異地備援機制提供了較短的 PRO 和 RTO。
透過災害復原演練，可以展示出一個生產用的資料庫在災難停機的狀態下受到保護的效果。由於異地還原可以在任何時間點進行，因此可以透過定期的災害復原演練來證實這些還原功能是可以正常運作的。
透過異地還原 ( Geo-Restore )、標準異地備援 ( Standard Geo-Replication )、主動異地備援 ( Active Geo-Replication ) 的結合，提供了多種選擇來符合您業務需求的商業連續性解決方案 ( business continuity solution )。
以下表格總結了各個異地備援方案的不同之處 :
| 方案 | 異地還原 (Geo-Restore) | 標準異地備援 (Standard Geo-Replication) | 主動異地備援 (Active Geo-Replication) |
| 處理區域災害 ( Regional disaster ) | Yes | Yes | Yes |
| 災害復原演練 (DR Drills) | Yes | Yes | Yes |
| 線上應用程式更新 ( upgrade ) | No | No | Yes |
| 線上應用程式移轉 ( relocation ) | No | No | Yes |
| 讀取負載平衡 ( Read load balancing ) | No | No | Yes |
我們鼓勵您可以藉由嘗試不同方案的異地備援來找到適合自己的業務連續性與災害復原策略。與往常一樣，我們會認真的聽取各方意見，所以請您透過網站來告訴我們任何可以改善的地方。
您可以閱讀更多關於 Azure SQL Database 備份與還原的文章。
感謝北科大劉建昌同學翻譯微軟公司 Azure SQL Database 團隊主管 Tony Petrossian 於 2014 年 9 月 3 日所發表的文章 http://azure.microsoft.com/blog/2014/09/03/azure-sql-database-standard-geo-replication/
在這篇文章中，我們將繼續針對 Azure SQL Database 各種業務連續性 ( Business Continuity ) 方案作介紹，以及討論最近 Azure SQL Database 新釋出的標準異地備援 ( Standard Geo-Replication ) 功能。標準異地備援功能允許您從主要資料庫以非同步 ( asynchronously ) 的方式將已認可的交易 ( committed transactions ) 複製到預先設定妥的備援資料中心 ( Azure Regions )。
在深入討論之前，我們先整理 Azure SQL Database 所有確保業務連續性之解決方案，並且討論它們在各 Azure SQL Database 服務層級下的狀況。您可以在此篇文章中找到所有關於 Azure SQL Database 各服務層的詳細資訊。
在先前關於主動異地備援 ( Active Geo-Replication ) 的文章中，已經先行定義了業務連續性的挑戰目標，而在這裡我們來快速複習一下幾個重要的概念 :
下表顯示了不同服務層之間的業務連續性差異 :
| 業務連續性與災害復原 ( BCDR, Business Continuity and Disaster Recovery ) 相關功能 | Basic | Standard | Premium |
| 即時還原 ( Point in Time Restore ) | 過去 7 天內的時間點 | 過去 14 天內的時間點 | 過去 35 天內的時間點 |
| 異地還原 ( Geo-Restore ) | RTO<24小時 RPO<24小時 | RTO<24小時 RPO<24小時 | RTO<24小時 RPO<24小時 |
| 標準異地備援 ( Standard Geo-Replication ) | 不支援 | RTO<2小時 RPO<30分鐘 | RTO<2小時 RPO<30分鐘 |
| 主動異地備援 ( Active Geo-Replication ) | 不支援 | 不支援 | RTO<1小時 RPO<5分鐘 |
選擇哪一種業務連續性與災難恢復 ( Business Continuity/Disaster Recovery ，BCDR ) 解決方案的關鍵因素往往與應用程式效能有關，如果您的應用程式的資料更新率 ( rate of updates ) 較低，處理的資料量也較少時，Azure SQL Database 所提供最基本異理還原 ( Geo-Restore ) 將是適合您的方案。若應用程式需要處理較大的資料量，並且對於 RPO 以及應用程式效能要求較高時，就需要使用標準異地備援 ( Standard Geo-Replication ) 來符合您的需求。至於最高階的主動異地備援 ( Active Geo-Replication ) 則是針對需要最低 RPO 以及處理大量資料異動量之需求所提供的解決方案。
當您從 Azure SQL Database Basic 服務層升級到 Premium 服務層時，您能夠選擇的業務連續性與災難恢復 ( BCDR ) 解決方案也就越多。Azure SQL Database 高階版本包含了所有入門版本服務層級的全部 BCDR 功能。
現在讓我們進一步了解標準異地備援的用戶驗經驗，以及它不同於主動異地備援之處。
首先，標準異地備援與主動異地備援是建立在相同的技術上，但是標準異地備援較適合資料密集寫入 ( write-intensive ) 量較少的應用情境。一般而言以下幾點考量會讓用戶決定該採用標準異地備援 :
標準異地備援 ( Standard Geo-Replication ) 相較於主動異地備援 ( Active Geo-Replication ) 簡化如下:
圖一 : 為標準異地備援的典型配置。一個資料庫可以在配對的備援資料中心 ( DR paired ) 內擁有一個離線狀態的備援資料庫
如您所見，標準異地備援的重點就是讓 Azure SQL Database 資料庫從大規模的故障區域中盡速恢復，並且維持正常的運作。但是有時候要做到這點，可能還是需要更強而有力的主動異地備援 ( Active Geo-Replication ) 來完成。以下表格總結了兩者使用的差異 :
| 方案 | 標準異地備援 (Standard Geo-Replication) | 主動異地備援 (Active Geo-Replication) |
| 處理區域災害 ( Regional disaster ) | Yes | Yes |
| 災害復原演練 (DR Drills) | Yes | Yes |
| 線上應用程式更新 | No | Yes |
| 線上應用程式搬移 ( relocation ) | No | Yes |
| 讀取負載平衡 ( Read load balancing ) | No | Yes |
既然 Azure SQL Database Premium 版能夠同時支援標準異地備援和主動異地備援。那在甚麼情況下您要選擇的是標準異地備援，而不是更為強大的主動異地備援呢 ?
標準異地備援被設計為一個較為簡單且便宜的災害還原解決方案 ( DR solution )，特別適合用來處理資料更新率較低的應用程式。如果 Azure SQL Database Premium 版資料庫是被用來處理大批讀取導向 ( read-oriented ) 的工作負載時，就相當適合使用標準異地備援。
當使用標準異地備援時，您無法選擇備援資料庫的資料中心位置，也不會如同主動異地備援般擁有四個具備讀取權限的備援資料庫，也無法完全控制在何時何地進行容錯移轉。但是相對的，使用標準異地備援讓您得到一個由 Microsoft 控制，較為簡單的監測方式以及容錯移轉流程。對於 Azure SQL Database Premium 用戶而言，標準異地備援和主動異地備援是可以交互搭配使用的，例如您可以使用 Azure SQL Database Premium 版資料庫去建立一個離線的標準異地備援資料庫，同時您仍可以利用主動異地備援功能，建立多個可讀取的備援資料庫用於讀取負載平衡，以應付高密集讀取的應用情境。
標準異地備援是專門為資料庫提供從災害停機中恢復的解決方案。除非有一個 Azure SQL Database 在主要的託管區域停止運作，否則您將無法啟動容錯移轉到配對資料中心內的備援 ( secondary ) 資料庫。也就是說若您使用標準異地備援，倘若發生用戶應用層級的資料庫停止運作，用戶是無法自行手動進行的容錯移轉，若有這類需求，用戶應該選擇使用主動異地備援。
若有一個 Azure 資料中心發生長時間停機的狀況時，微軟會針對使用 Azure SQL Database 標準異地備援的資料庫進行容錯轉移。這項措施的目標，就是要在 Azure SQL Database 停機發生後的一小時之內啟動容錯移轉，一旦啟動這項措施，用戶您開始進行容錯轉移動作，將資料庫移轉至備援資料中心的資料庫，並停止主要資料庫與備援資料庫之間的資料複製動作。
這種方法使得容錯移轉變得相當簡單，應用程式只需要判斷是否啟用容錯移轉的旗標 ( flag )，再來決定要進行容錯移轉還是等待目前資料庫復原。這兩種選擇會依據應用程式需求而有所不同。若您的應用程式比較注重不停機的高可用性 ( higher availability ) 並能容忍漏失過去一個小時已經儲存於主要資料庫內的資料，當為微軟啟用允許容錯轉移後，用戶應盡速啟用容錯移轉。倘若您的應用程式比較注重資料的完整性，已經儲的資料遺失是非常敏感 ( sensitive ) 的，雖然微軟已經允許標準異地備援用戶開始進行容錯轉移，用戶能可能願意繼續等待 Azure SQL Database 恢復正常，以避免資料庫內的資料漏失。然而，若是主要資料庫所在之 Azure 資料中心若是在發生停機後 24 小時之內都沒法復原，則標準異地備援的資料庫都會自動執行容錯移轉動作。在這種最壞狀況下，應用程式將會有 24 小時的停機時間並且會有部分資料遺失。無論是用戶自己啟動容錯移轉或是等待 24 小時讓它自行發生，用戶都需重新配置與設定您的應用程式的資料庫連線，連接到容錯轉移後的備援資料庫。
完成容錯轉移之後，您也會想要確定新的主要資料中心 ( Primary region ) 是否也受到相同的保護，因此在進行容錯移轉的過程中，Azure 會更新它的災難恢復配對資料中心 ( DR pair )，這將允許您從新的主要資料中心 ( Primary region ) 來啟動新的地理資料複製來保護它自己。由於建立新的備援區域需要花費一些時間 ( 取決於資料庫資料量大小 )，您必須承擔在建立新的備援區域的這段期間，Azure SQL Database 暫時無高可用性備援能力，並且接受在沒有保護狀態下執行應用程式的風險。最妥當的辦法就是等待容錯移轉資料庫已經有完整備援資料中心保護之後，再啟動應用程式。
建立完備原資料中心後，新的災害復原 ( DR ) 的配置如下圖所示 :
圖二 : 在容錯移轉更新完新的災難備援配對資中心之後，應用程式可以建立一個新的備援資料庫並開始資料複製動作
由於資料庫的容錯移轉與資料是相互關聯並且是一個具破壞性的回復方式，因此容錯移轉的整個流程應該要定期經過測試來確保應用程式能夠應付災難發生時的突發狀況。這個測試的過程叫做災壞復原演練 ( Disaster Recovery Drills )。許多國際資訊安全相關認證也要求應用程式備妥與進行災壞復原演練。雖然平時在 Azure SQL Database 正常運行的情況下，在備援資料中心內離線 ( offline ) 的備援資料庫無法真的進行容錯移轉，但是在災害復原演練時，用戶還是可以透過停止主資料庫 ( primary database ) 的地理複寫的方式，讓被援資料中心的資料庫可以被用戶啟用。來測試整體的災害復原流程。
在經過容錯移轉之後，備援資料庫將可以完全地被存取，就像主資料庫般的讓應用程式使用。在演練的過程中，資料有可能會遺失而且在這段時間主要資料中心內的資料庫並沒有受到保護，因此我們不建議客戶在實際生產用的資料庫上進行災害復原演練。我們建議您在主資料庫所在的資料中心內建立一個資料庫副本，並且使用這個副本和它的輔助區域來測試容錯轉移流程演練。
標準異地備援提供了在主動異地備援上啟用的REST API子集。要管理標準異地備援，您可以使用這個API並且提供PowerShell指令或是使用Azure管理網站。由於這項功能還在預覽階段，因此您需要先登入到Azure SQL Database的新服務層。啟用標準異地備援最簡單的方式就是使用Azure管理網站中的"異地備援"選項。
圖三 : 使用 Azure 管理網站建立和監控離線地理輔助區的狀態
要注意的是，您可以在任何時候選擇取消地理複製。有兩種方式可以達到此效果，您可以在主資料庫上終止地理複製或是直接刪除備援的次要資料庫。
第一種方式是當您複製到錯誤的資料庫時，可以有效的終止這個動作。若您在備援資料庫建立好之前就取消這項動作，您將不會被收取任何費用，但若在備援資料庫已經建立好之後才取消，則您需要按照您使用的額度來支付費用。使用第二種方式，將會自動停止地理資料複製並且刪除備援資料庫，並且從停止的那一刻開始停止收費。
標準異地備援針對擁有適度資料更新速率的應用程式，提供了一個強大的災難恢復解決方法，雖然它不如主動異地備援來的靈活，但是我們認為它還是符合大多數應用程式的需求。請告知我們您的想法，我們會認真聽取您在新的 Azure SQL Database 服務層中使用地理複製地回覆意見，您能夠在以下文章中得到更多資訊。