Azure SQL數據庫最快的備份/還原策略？

Question

備份/還原Azure SQL數據庫的最快方法是什么？

背景：我們擁有大小約為40 GB的數據庫，並且Azure SQL數據庫導入/導出服務以本機方式從.bacbac文件（~4GB壓縮數據）恢復它需要長達6-8小時。 創建.bacpac也很長，需要大約2個小時。

UPD：

UPD。 使用CREATE DATABASE [DBBackup] AS COPY OF [DB]創建數據庫（通過事務一致的方式）復制CREATE DATABASE [DBBackup] AS COPY OF [DB]只需15分鍾，40 GB數據庫，並且還原是簡單的數據庫重命名。

UPD。 2014年12月。讓我與您分享我們最終獲得的數據庫遷移模式最快方式的經驗。

首先，數據層應用程序（.bacpac）的方法在DB變得稍微大一點后對我們來說是不可行的，如果你有至少一個總體大小的非聚集索引，它對你也不適用> 2 GB，直到您在導出之前禁用非聚集索引 - 這是由於Azure SQL事務日志限制。

我們堅持使用Azure遷移向導 ，對於數據傳輸，只需為每個表運行BCP（BCP的參數是可配置的），並且比使用.bacpac的方法快20％。

以下是我們在遷移向導中遇到的一些陷阱：

1. 我們遇到了非Unicode字符串的編碼問題。 確保BCP導入和導出以相同的排序規則運行。 它是-C ...配置開關，您可以在MW應用程序中找到BCP調用.config文件的參數。
2. 考慮到MW（至少是本文撰寫時的實際版本）運行BCP，其參數將使約束處於不可信狀態，因此不要忘記在BCP導入后檢查所有不受信任的約束 。

Answer 1

如果您的數據庫是40GB，那么很久以后就會考慮使用冗余的數據庫服務器，一旦主服務器發生故障就可以立即服務。

您應該在主數據庫服務器旁邊運行第二個服務器，該服務器沒有實際例程，除非每小時/每天與主服務器同步（取決於數據更改的頻率以及運行此過程所需的時間）。 您還可以考慮從此數據庫服務器而不是主數據庫服務器創建備份。

如果您的主數據庫服務器出現故障 - 無論出於何種原因 - 您可以將應用程序中的主機地址更改為備份數據庫，並花8小時調試您的其他服務器，而不是讓您的拇指在等待Azure門戶執行其操作而你的客戶抱怨。

您的數據庫不應該花費6-8小時從備份恢復。 如果您在此估算中包含上載/下載時間，則應考慮將數據存儲在Azure數據中心以及本地。

有關詳細信息，請參閱MSDN上有關業務連續性的這篇文章： http ： //msdn.microsoft.com/en-us/library/windowsazure/hh852669.aspx

您將需要專門查看“數據庫副本”部分，但如果您的數據庫太大，那么本文值得全文閱讀。

Answer 2

Azure現在支持即時恢復/地理還原和GeoDR功能。 您可以使用這些組合進行快速備份/還原。 PiTR和Geo恢復無需額外費用，而您需要支付Geo副本

Answer 3

有多種方法可以在Azure上執行備份，還原和復制作業。

1. 及時恢復。

Azure Service每5分鍾進行一次完整備份，多個差異備份和t-log備份。

2. 地理還原

與時間點恢復相同。 唯一的區別是它從存儲在不同區域的不同blob存儲中獲取冗余副本。

3. 地域復制

與SQL可用性組相同。 4副本與讀取功能異步。 選擇要成為熱備用的區域。

更多關於Microsoft網站的信息 。 博客在這里 。

Answer 4

Azure SQL數據庫已經擁有Liam所指的這些本地副本。 您可以在http://social.technet.microsoft.com/wiki/contents/articles/1695.inside-windows-azure-sql-database.aspx#High_Availability_with_SQL_Azure找到有關這三個本地副本的更多詳細信息。

此外，SQL數據庫最近引入了新的服務層，其中包括新的時間點恢復。 有關詳細信息，請訪問http://msdn.microsoft.com/en-us/library/azure/hh852669.aspx

Answer 5

關鍵是要使用正確的數據管理策略，這有助於解決您的目標。 將所有內容放在雲上的錯誤架構和方法可能會帶來災難性的......這里有更多內容可供閱讀 - http://archdipesh.blogspot.com/2014/03/windows-azure-data-strategies-and.html