Azure SQL Database 異地還原 (Geo-Restore) 功能
感謝北科大劉建昌同學翻譯微軟公司 Azure SQL Database 團隊主管 Tony Petrossian 於 2014 年 9 月 13 日所發表的文章 https://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-restore）是一種利用地理容錯備份 ( geo-redundant backup ) 來還原並建立新資料庫的一種技術，此功能適用於任何 Azure SQL Database 所在之資料中心。由於它使用了一個地理容錯備份來還原資料庫，因此即使資料庫因為不明原因停擺，還是能夠在異地進行還原的動作。異地還原功能內建在所有的 Azure SQL Database 服務層中 ( Basic、Standard、Premium )，此功能無須額外設定即會自動的運作，並且不會增加任何額外的花費。
異地還原 ( Geo-Restore ) 的技術細節
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 ) 中發生大規模的故障，備份在異地資料中心的資料不會受到影響。
下圖呈現了這個過程 :
![clip_image002[4]](https://msdntnarchive.z22.web.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/81/31/metablogapi/0488.clip_image0024_226EB770.gif "clip_image002[4]")
圖一 : 每週和每日的備份儲存在儲存體容器 ( 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 小時。
下圖呈現了這個過程 :
![clip_image004[4]](https://msdntnarchive.z22.web.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/81/31/metablogapi/7762.clip_image0044_64507B5C.gif "clip_image004[4]")
圖二: 利用 Azure SQL Database 每日備份在異地進行還原資料庫動作
如何使用異地還原 ( Geo-Restore )
異地還原能夠從 Azure 管理網站上使用。在 Azure SQL Database 列表中選取要備援的伺服器，並且選擇"備份"的選項。
在備份的選項中，提供了該伺服器中所有可以使用的備份清單，其中也包含了上次備份的時間以及備份的服務層版本。
當您選擇了一個備份進行還原，您需要為新建立的還原資料庫提供一個名稱，並且指定目標伺服器，一旦按下確認之後，還原動作將會把還原資料庫放置到指定的伺服器上。
![clip_image006[4]](https://msdntnarchive.z22.web.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/81/31/metablogapi/5037.clip_image0064_4C27EF9F.jpg "clip_image006[4]")
圖三 : 在 SQL資 料庫中選取 "伺服器"選項
![clip_image008[4]](https://msdntnarchive.z22.web.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/81/31/metablogapi/0576.clip_image0084_0273F64D.jpg "clip_image008[4]")
圖四 : 選擇您要還原的資料庫，並且選取"備份"選項
![clip_image010[4]](https://msdntnarchive.z22.web.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/81/31/metablogapi/4760.clip_image0104_1A754604.jpg "clip_image010[4]")
圖五 : 在異地備份列表上選擇要還原的資料庫
![clip_image012[4]](https://msdntnarchive.z22.web.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/81/31/metablogapi/4503.clip_image0124_3680E38D.jpg "clip_image012[4]")
圖六 : 設定還原資料庫的名稱以及目標伺服器
![clip_image014[4]](https://msdntnarchive.z22.web.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/81/31/metablogapi/6567.clip_image0144_156B5642.jpg "clip_image014[4]")
圖七 : SQL資料庫列表會顯示出資料庫正在還原
如同 Microsoft Azure 其他各項管理功能，用戶同樣地也可以透過 REST API 或 PowerShell 來進行上述的還原步驟。
透過 Azure 管理入口網站來進行還原資料庫的動作，較適合特別且小量的資料庫還原。而使用 REST API 或 Powershell 則適用於多個資料庫還原或是自訂管理腳本 ( Script ) 和應用程式。您可以參考 Azure SQL Database REST API 和 Azure SQL Database Recovery PowerShell API。
若啟動了一個錯誤的還原操作，您不需要等待還原的動作結束才進行取消，可以透過將還原資料庫刪除的方式，來取消此操作取消，這樣就可以避免有任何費用的產生。
影響恢復時間 ( recovery time ) 的因素
恢復時間會受到以下因素影響 :
- 資料庫大小 ( Size )
- 資料庫的性能水平 ( performance level )
- 在目標區域內執行的還原請求數目
若有一個區域資料中心長期處在停機的狀態下時，則其他區域就有可能產生大量的異地還原要求 ( 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。
災害復原演練 ( DR Drills )
透過災害復原演練，可以展示出一個生產用的資料庫在災難停機的狀態下受到保護的效果。由於異地還原可以在任何時間點進行，因此可以透過定期的災害復原演練來證實這些還原功能是可以正常運作的。
結論
透過異地還原 ( 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 備份與還原的文章。