感謝北科大劉建昌同學翻譯微軟公司 Azure 團隊主管  Khalid Mouss 於 2014 年 10 月 13 日所發表的文章 http://azure.microsoft.com/blog/2014/10/13/accessing-and-using-azure-vm-unique-id/

Azure 團隊最近新增了一項功能，讓開發人員可以取得一個代表 Azure Virtual Machine 絕對唯一的 ID。

這個唯一的 Azure VM ID 是一個 128 位元的識別碼，它可以透過 Azure IaaS 虛擬機器的系統 BIOS ( SMBIOS ) 來進行編碼與儲存，並且能夠使用虛擬機器上的 BIOS指令讀出。這個識別碼不管是在 Azure 上或是本地端 ( on-premises ) 皆可以使用，並且幫助您在 Azure IaaS  佈署上用於管理授權 ( licensing )、回報 ( reporting )、追蹤 ( tracking ) 等需求。

當許多獨立的軟體供應商與合作夥伴在 Azure 上佈署了應用程式，並且需要驗證它是否執行於某個特定虛擬機器內，會需要在虛擬機器的生命週期 ( lifecycle ) 中清楚知道這個虛擬機器是在何處執行? 透過此一唯一識別碼，我們可以得知目前虛擬機器是執行於 Microsoft Azure、本地端、或是其他雲端業者平台。這個唯一的識別碼可以用於檢測軟體是否有適當的授權 ? 或是將虛擬機器的基本資料關聯到它執行所在的平台，藉此協助在其平台上做適當的參數設定。

這個唯一的識別碼不能夠被修改，只能進行讀取查詢，雖然只有在 2014 年 9 月 18 日之後建立的虛擬機器才預設擁有這項功能，但是在 2014 年 9 月 18 日之前建立的虛擬機器可以透過將虛擬機器重新啟動來得到這項功能。

虛擬機器的唯一的識別碼  ( Azure Unique VM ID ) 在下列情況下皆不會改變 :

1. 重新啟動 ( reboot )
2. 關機 ( shutdown ) ( 計畫中或是意外 )
3. 啟動/停止取消分配 ( start/stop de-allocate )
4. 服務修復 ( service healing )
5. 地域恢復 ( restore in place )

但是，若虛擬機器是一個快照 ( snapshot )，並且用來建立一個新的執行個體 ( instance )，此時的虛擬機器的唯一的識別碼 ( Azure VM ID ) 是會改變的。

如果在這項功能發行前已經建立好虛擬機器並且運行了，您可以重新啟動 VM，藉此來得到這個唯一的 ID。而重新設定之後，您就可以使用它了。

您可以透過以下步驟的操作，在您的虛擬機器中獲得虛擬機器的唯一的識別碼 ( Azure VM ID ) :

1. 建立一個虛擬機器 ( 只有在2014年9月18日之後建立的虛擬機器才預設擁有此功能 )

• 您可以參照此文章，來透過組件庫建立虛擬機器。

2. 連線至虛擬機器

• 如何登入 Windows Server 的虛擬機器
• 如何登入 Linux 的虛擬機器

3. 查詢虛擬機器的Unique ID

• Windows 虛擬機器

上圖是利用 PowerShell 指令與查詢結果

• Linux虛擬機器 ( 本文使用 Ubuntu 進行示範 )

上圖是指令與查詢結果

由於位元組 Big Endian bit ordering 因素 ，因此上圖的唯一識別碼實際應該如下:

98 F9 D8 26 - 4E 3D - XXXX - BF B6 B5DE5F108440

不管您在 Azure 虛擬機器上放置甚麼應用程式，您皆能夠透過上述方式得到一個唯一的識別碼。

再次提醒您，若您在此項功能釋出前就已經建置好虛擬機器的話，只要透過重新啟動虛擬機器，一樣也能得到此項功能。

感謝北科大劉建昌同學翻譯微軟公司 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 各服務層的詳細資訊。

業務連續性 ( Business continuity )

在先前關於主動異地備援 ( Active Geo-Replication ) 的文章中，已經先行定義了業務連續性的挑戰目標，而在這裡我們來快速複習一下幾個重要的概念 :

• 災難回復 Disaster recovery ( DR ) : 恢復應用程式至正常運作功能的過程。
• 時間點回復 Point in time restore : 將資料庫從人為錯誤或是資料錯誤的狀態下回復至過去的某個時間點 ( 需要在備份期間內 )
• 目標恢復時間 Recovery Time Objective (RTO) : 當錯誤發生後，系統要在多少時間內回復正常
• 目標恢復點 Recovery Point Objective (RPO) : 當錯誤發生時，可忍受的資料遺失的時間長度

下表顯示了不同服務層之間的業務連續性差異 :

選擇哪一種業務連續性與災難恢復 ( 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 ) 量較少的應用情境。一般而言以下幾點考量會讓用戶決定該採用標準異地備援 :

• 目標應用程式的資料更新速率 ( update rate ) 不需要用很高之災難備援 SLA。
• 應用程式只需要簡單的恢復作業流程，而不需要太複雜的邏輯來做容錯移轉的決定。
• 這些應用程式通常有成本上的考量 ( cost sensitive )。

標準異地備援 ( Standard Geo-Replication ) 相較於主動異地備援 ( Active Geo-Replication ) 簡化如下:

1. 在 Microsoft 定義的災難備援配對資料中心 ( DR paired ) 中建立一個備援資料庫 ( secondary database )。災難備援配對資料中心的列表可以在此查閱。
2. 可以在主要 ( master ) 資料庫上可以看到備援的資料庫，但是除非容錯移轉完成，否則是不能夠直接連線使用備援的資料庫。
3. 由於備援的資料庫平時是不能夠直接讀取的，也因此收費較便宜。
4. 當 Azure 資料中心長時間停擺時才會啟用容錯移轉動作，每當 Azure 入口網站會顯示 Azure SQL Database 服務為 "degraded" 時，很可能需要花費長達一個小時的時間才會恢復正常，。
5. 在 Azure 資料中心長時間停擺的狀況下，如果微軟認為復原時間會超過 24 小時，或是 Azure SQL Database 發生問題而用戶超過 24 小時沒有主動啟動容錯移轉程序，微軟會將所有使用標準異地備援的用戶資料庫自動切換到備援的資料中心。

圖一 : 為標準異地備援的典型配置。一個資料庫可以在配對的備援資料中心 ( DR paired ) 內擁有一個離線狀態的備援資料庫

如您所見，標準異地備援的重點就是讓 Azure SQL Database 資料庫從大規模的故障區域中盡速恢復，並且維持正常的運作。但是有時候要做到這點，可能還是需要更強而有力的主動異地備援 ( Active Geo-Replication ) 來完成。以下表格總結了兩者使用的差異 :

為什麼要使用標準異地備援，而不是使用 Azure SQL Database Premium 的主動異地備援?

既然 Azure SQL Database Premium 版能夠同時支援標準異地備援和主動異地備援。那在甚麼情況下您要選擇的是標準異地備援，而不是更為強大的主動異地備援呢 ?

標準異地備援被設計為一個較為簡單且便宜的災害還原解決方案 ( DR solution )，特別適合用來處理資料更新率較低的應用程式。如果 Azure SQL Database Premium 版資料庫是被用來處理大批讀取導向 ( read-oriented ) 的工作負載時，就相當適合使用標準異地備援。

當使用標準異地備援時，您無法選擇備援資料庫的資料中心位置，也不會如同主動異地備援般擁有四個具備讀取權限的備援資料庫，也無法完全控制在何時何地進行容錯移轉。但是相對的，使用標準異地備援讓您得到一個由 Microsoft 控制，較為簡單的監測方式以及容錯移轉流程。對於 Azure SQL Database Premium 用戶而言，標準異地備援和主動異地備援是可以交互搭配使用的，例如您可以使用 Azure SQL Database Premium 版資料庫去建立一個離線的標準異地備援資料庫，同時您仍可以利用主動異地備援功能，建立多個可讀取的備援資料庫用於讀取負載平衡，以應付高密集讀取的應用情境。

資料庫容錯移轉 ( failover )

標準異地備援是專門為資料庫提供從災害停機中恢復的解決方案。除非有一個 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 )

由於資料庫的容錯移轉與資料是相互關聯並且是一個具破壞性的回復方式，因此容錯移轉的整個流程應該要定期經過測試來確保應用程式能夠應付災難發生時的突發狀況。這個測試的過程叫做災壞復原演練 ( Disaster Recovery Drills )。許多國際資訊安全相關認證也要求應用程式備妥與進行災壞復原演練。雖然平時在 Azure SQL Database 正常運行的情況下，在備援資料中心內離線 ( offline ) 的備援資料庫無法真的進行容錯移轉，但是在災害復原演練時，用戶還是可以透過停止主資料庫 ( primary database ) 的地理複寫的方式，讓被援資料中心的資料庫可以被用戶啟用。來測試整體的災害復原流程。

在經過容錯移轉之後，備援資料庫將可以完全地被存取，就像主資料庫般的讓應用程式使用。在演練的過程中，資料有可能會遺失而且在這段時間主要資料中心內的資料庫並沒有受到保護，因此我們不建議客戶在實際生產用的資料庫上進行災害復原演練。我們建議您在主資料庫所在的資料中心內建立一個資料庫副本，並且使用這個副本和它的輔助區域來測試容錯轉移流程演練。

管理工具

標準異地備援提供了在主動異地備援上啟用的REST API子集。要管理標準異地備援，您可以使用這個API並且提供PowerShell指令或是使用Azure管理網站。由於這項功能還在預覽階段，因此您需要先登入到Azure SQL Database的新服務層。啟用標準異地備援最簡單的方式就是使用Azure管理網站中的"異地備援"選項。

圖三 : 使用 Azure 管理網站建立和監控離線地理輔助區的狀態

要注意的是，您可以在任何時候選擇取消地理複製。有兩種方式可以達到此效果，您可以在主資料庫上終止地理複製或是直接刪除備援的次要資料庫。

第一種方式是當您複製到錯誤的資料庫時，可以有效的終止這個動作。若您在備援資料庫建立好之前就取消這項動作，您將不會被收取任何費用，但若在備援資料庫已經建立好之後才取消，則您需要按照您使用的額度來支付費用。使用第二種方式，將會自動停止地理資料複製並且刪除備援資料庫，並且從停止的那一刻開始停止收費。

結論

標準異地備援針對擁有適度資料更新速率的應用程式，提供了一個強大的災難恢復解決方法，雖然它不如主動異地備援來的靈活，但是我們認為它還是符合大多數應用程式的需求。請告知我們您的想法，我們會認真聽取您在新的 Azure SQL Database 服務層中使用地理複製地回覆意見，您能夠在以下文章中得到更多資訊。

感謝北科大劉建昌同學翻譯微軟公司 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 ) : 可忍受的資料遺失的時間長度

何謂異地還原 ( 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 ) 中發生大規模的故障，備份在異地資料中心的資料不會受到影響。

下圖呈現了這個過程 :

圖一 : 每週和每日的備份儲存在儲存體容器 ( 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 每日備份在異地進行還原資料庫動作

如何使用異地還原 ( Geo-Restore )

異地還原能夠從 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 ) 的因素

恢復時間會受到以下因素影響 :

1. 資料庫大小 ( Size )
2. 資料庫的性能水平 ( performance level )
3. 在目標區域內執行的還原請求數目

若有一個區域資料中心長期處在停機的狀態下時，則其他區域就有可能產生大量的異地還原要求 ( 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 )。

以下表格總結了各個異地備援方案的不同之處 :

我們鼓勵您可以藉由嘗試不同方案的異地備援來找到適合自己的業務連續性與災害復原策略。與往常一樣，我們會認真的聽取各方意見，所以請您透過網站來告訴我們任何可以改善的地方。

您可以閱讀更多關於 Azure SQL Database 備份與還原的文章。

感謝北科大劉建昌同學翻譯微軟公司 Azure SQL Database 團隊主管  Tony Petrossian 於 2014 年 10 月 1 日所發表的文章 http://azure.microsoft.com/blog/2014/10/01/azure-sql-database-point-in-time-restore/

本篇文章，將說明 Azure SQL Database 的時間點還原 ( Point in Time Restore ) 功能，這項功能在 Azure SQL Database 的 Basic、Standard、Premium 版皆有提供。在先前的文章中，Azure SQL Database 團隊已經介紹了 Azure SQL Database 多項新功能，其中也包含了時間點還原，您可以參考下列圖表。在這份圖表我們可以看到，時間點還原功能是使用最近的資料備份 ( backup ) 來還原受損或是遭到刪除的資料庫。

RTO ( Recovery Time Objective ) :  系統要在多少時間內回復正常

RPO ( Recovery Point Objective ) : 可忍受的資料遺失的時間長度

何謂時間點還原 ( Point in Time Restore ) ?

Azure SQL Database 服務中的所有資料庫，皆會受到自動備份系統 ( automated backup system ) 保護。備份的保留期限會隨著訂閱的 Azure SQL Database 層級而有所不同，Premium 版為 35 天、Standard 版為 14 天、Basic 版為 7 天。

時間點還原為一個自助式服務 ( self-service )，允許客戶利用在保留期間所做的的備份來還原資料庫。在使用時間點還原功能時，會重新建立一個新的資料庫。

Azure SQL Database 資料庫備份採取自動備份，您不需要做設定而且也不會額外針對備份來作收費，您只需要在使用時間點還原功能時負擔額外的費用。還原時所建立的新資料庫，其收費標準跟平常的資料庫收費標準一樣。

總而言之，自動備份系統和時間點還原提供了零成本和零管理的方式來保護您的資料，無論任何原因損毀了資料庫，您都可以在保留期間內任一時間點中回復。

了解何謂自動備份 ( Automatic Backups )

所有的 Azure SQL Database 資料庫的  Basic、Standard、Premium  版都提供了自動備份的功能。Azure SQL Database 會每週做一次完整備份 ( full backups )，每天做一次差異備份 ( differential backup ) 以及每五分鐘進行交易記錄備份 ( log backups )。當資料庫被建立完成後即會開始第一次完整備份，這通常要花費 30 分鐘甚至更久的時間來完成備份。若該資料庫生來規模就很大 ( born big )  (例如 : 建立的資料庫為資料庫副本或是從大型資料庫還原所產生的資料庫 )，備份所需的時間會花費更久。在第一次備份完成之後，所有後續的備份會自動的由系統做安排，並且 "默默" 地在後端進行管理。

完整備份 ( full backups ) 和差異備份 ( differential backups ) 的確切執行之時間點，是由系統依據目前以系統負載量來做決定。而備份的檔案儲存在與目前資料庫相同的資料中心內。

當您還原一個資料庫時，還原所需的備份檔案將從本地備援處 ( local redundancy ) 來獲取。而每週和每日的最新備份也會複製到 Microsoft Azure 地理備援的配對資料中心 ( paired region ) 以便進行跨資料中心之災難回復。關於異地還原 ( Geo Restore ) 的敘述，在 Azure SQL Database 團隊之前發表的文章中有更詳細的敘述。

對使用中的資料庫 ( Live Database ) 作時間點還原

進入 Azure 管理入口網站，即可透過簡單的操作將各版本之 Azure SQL Database ( Basic、Standard、Premium ) 資料庫還原到任何的時間點 ( 但必需在備份的保留期限內 )。

您可以選擇在資料庫列表中選取需要還原的資料庫，或是進入該資料庫的儀表板內，並且點擊"還原"選項。

您將會被提示要輸入一個新的資料庫名稱，並且利用滑動元件來選取想要還原的時間點 ( 必需在保留期限內 )，同時也可以手動輸入最接近的時間點。完成之後按下確認鍵，資料庫便會開始還原到您所設定的時間點。

還原資料庫所需的時間由很多因素決定，包含 : 資料庫大小、選取時間點遠近、要還原到選取時間點資料庫需要重新架構的狀態數量等，通常一個龐大的資料庫，需要數個小時來還原。

還原的資料庫將會被建立在與原始資料庫相同的伺服器上，也因此我們需要重新賦予資料庫新的名稱。而還原資料庫的服務層級則是與還原時間點時資料庫設定的服務層級相同。

您需要確認您的資料庫有足夠的資料庫傳輸單位額度 ( DTU )，同時也要注意的是，還原時所建立的新資料庫，其服務層級可能會與目前資料庫的狀態不同。

一旦完成了還原動作，還原的資料庫收費標準與一般的資料庫是相同的。

您可以將還原資料庫來替換原本的資料庫，或是利用還原資料庫作為資料檢索，再去更新原始的資料庫。

若您還原資料庫的目的是用來取代現有的資料庫，您應該要驗證服務層級與效能層級是否合適，並且在需要時進行擴充。透過更改原始資料庫名稱，再將還原資料庫的名稱利用 T-SQL 指令  ALTER DATABASE 將名稱更改為原本資料庫的名稱，這樣就可以完全取代原本的資料庫了。

若您計畫從備援資料庫內讀取資料，您將需要分別編寫和執行您所需要回復資料相關之 Script。

雖然還原資料庫需要花費相當長的時間，但是在還原的過程時，還原資料庫就會顯示在資料庫列表上。您可以在還原的過程中刪除還原資料庫，此時將會取消還原的動作，您將不需要付出任何費用。

還原最近刪除的資料庫

您能夠將在其保留期限內不小心遭到刪除的資料庫還原到被刪除的時間點，或更早的時間點。

您可以使用 Azure 管理入口網站來還原被刪除的資料庫，首先需要在 Azure SQL Database 的資料庫列表中，選取"已刪除的資料庫"選項，將可以看到還在保留期限內遭到刪除的資料庫列表。

注意 : 若您重複使用太多次相同的資料庫名稱，則需要更加注意刪除的時間，這樣才不會還原到錯誤的資料庫。

就如同先前還原步驟一樣，您需要為還原資料庫新增一個名稱，而且您還原的資料庫也只能夠還原到與原始資料庫相同的伺服器上。比較特別的是，在這種情況下的還原步驟，只能夠選取固定的時間點作還原。還有一點要注意的是，當您刪除伺服器(Server)之後，您將無法復原先前存放在該伺服器的所有資料庫。

備份 (Backup ) / 還原 ( Restore ) vs. 複製 ( Copy ) / 匯出 ( Export ) / 匯入 ( Import )

時間點還原可以將資料損毀或是被刪除的資料庫重新復原。時間點還原並非使用先前 Azure SQL Database Web/Business 版資料庫運用複製為技術基礎，所實作出的匯出 ( Export ) / 自動匯出 ( automated export ) 方式 ( 此方式較為昂貴 ) 來回復資料庫。單單這一改進就證明了新版 Azure SQL Database 的優勢。

• 新版的服務層備份和還原的費用相對的便宜 ( 就備份方面，如果沒有要增加額外的備份，是不需要收費的，而需要收取的費用則是用來確保您的資料庫副本匯出的一致性還有儲存BACPAC file )。
• 零管理 ( Zreo Admin ) : 備份是由系統自動進行的，您只需要自行管理和安排匯出的排程。
• 更好的 RPO : 您可以還原到特定的時間點，並且時間可以使用到比使用匯出匯入的方式更精細的刻度 ( 1分鐘 )。
• 更好的 RTP: 從備份復原的速度比匯入的方式還要快。

注意 : 雖然在保存期限內，利用備份方式回復資料庫是相對便宜及快速的，而使用複製/匯出/匯入方式仍適用於更長期資料庫備份策略 ( long term archival )。

使用 APIs 還原資料庫

除了透過 Azure 管理入口網站來還原資料庫之外，您也可以使用 PowerShell ( Start-AzureSqlDatabaseRestore ) 和 SQL Database management API 來還原資料庫。

總結

自動備份與時間點還原(自助式服務)功能保護您的資料庫，讓其能夠從資料損毀以及刪除的狀態下回復，這種零成本和零管理的方法，不管是在哪一種服務層Basic、Standard、Premium)的資料庫都有提供。備份和還原功能在短期回復的需求下，性能較優於使用複製/匯入/匯出的方式，因此就短期資料庫回復而言，我們鼓勵���使用這種方式來做為您的商業連續性對策，而僅在需要長期歸檔或數據轉移時才使用匯出/匯入的方式。

最近在 Microsoft Azure 的首頁上多了一個「主機庫」（Gallery）的頁面，這一頁蒐集了 Azure 各種服務所提供的開始選項，以虛擬機器來說，就是展示已經在 Azure 上獲得官方支援的各種作業系統映像檔：

而在 Web 應用程式的部份，也陳列了由 Azure 團隊驗證過可以順利並直接安裝在 Azure 上的各種開源的架站套件：

只要挑選一個架站套件就可以立即開始架設網站，比方說很多人喜愛的 WordPress 套件：

只要按下 Create Web App 的按鈕就可以開始拿 WordPress 在 Azure 網站服務上架設網站囉！

如果您發現在 Gallery 中找不到您喜愛的架站套件，歡迎您到這裡來反應，我們會盡快考慮移植上 Microsoft Azure。