使用 SAN 複製/快照進行 SQL Server 災難恢復？
我們有一個在單個數據庫伺服器上使用 SQL Server 2008 的 Web 應用程序。所有儲存都是本地的。在過去的一年裡，我們一直試圖讓任何形式的 SQL Server 複製與我們的配置一起工作，但它不會。原因是我們有超過 2,000 個數據庫在不斷更新（每個客戶一個），所以我們的測試表明所有形式的複制都過於佔用資源。
每次我問這個問題時，人們都會關注我們有太多數據庫這一事實。這是無法改變的（出於監管和其他原因），所以我想專注於我們如何複製數據。
有人告訴我們，一種選擇是將所有數據移動到 SAN 並讓 SAN 複製數據（或拍攝頻繁的快照）。但是，如果我們的數據庫伺服器出現故障，在這種情況下是否存在數據庫損壞的風險？是否有可能利用複製到另一個 SAN 的 SAN 來提供一個體面的 DR 解決方案（在我們的例子中，我們可能會失去大約 30 分鐘的數據，但我們不能失去一整天的價值……即我們可以’ t 去前一晚的備份）。
如其他答案所述：
- 舊式數據庫鏡像和新式 AlwaysOn 需要執行緒，您肯定會用完 2000 個數據庫的執行緒。我模糊地記得實際限制遠低於 200 個數據庫。（在某處有一份白皮書，但我現在懶得去尋找它，而且這個答案已經超長了。）當然，每個實例有 200 個數據庫。理論上，您可以啟動 20 個實例並在每個實例上執行 100 個數據庫。管理所有這些會很麻煩，而且我懷疑管理所有這些實例之間的記憶體會讓人頭疼。
- SQL Server 複製（複製表（或表的子集），而不是文件）並不是真正用於 DR。即使對於一些數據庫，也很難設置和管理。您可能需要更改您的數據模型以使其正常工作，這可能意味著您的應用程序的更改。您需要一種自動化方式將相同的複製配置應用於您的 2000 個（可能相同或幾乎相同）數據庫中的每一個。您需要用於配置複製的儲存過程很混亂。通過 GUI 管理配置為複制的 2000 個數據庫將是一場噩夢。當/如果您進行故障轉移，您可能需要進行更改以使一切恢復正常。故障轉移時間不是您想要進行任何可以避免的挑剔更改或工作的時間。您希望盡快恢復一切並執行。
- SAN 儲存單元之間的複制可能會很昂貴，尤其是當您談論來自 EMC 等公司的硬體時。一旦您從供應商開始，您就幾乎與他們結婚以進行升級、維護、額外空間等。
建議 #1： 你看過 Steeleye 的 DataKeeper 之類的東西嗎？它是一種基於軟體的複制產品，可在您的伺服器上執行，並利用 Windows 故障轉移群集。我從來沒有真正使用過它，除了觀看一些狗和小馬錶演外，我與公司沒有任何联系。它看起來非常適合您的情況。
建議2： 如果是我，我絕對沒有預算，我會考慮一些本土的原木運輸系統。我懷疑內置的日誌傳送能否很好地處理 2000 個數據庫。編寫日誌傳送系統並不難，它可以解決特定於您的環境的所有問題。（例如，您可能需要通過 sftp 將文件發送到您的 DR 站點。）
基本上，該系統分為三個部分。每個部分都需要定期執行：
- 一部分是事務日誌備份，將每個數據庫的 tlog 備份文件放到不同的文件夾中（用於文件系統擴展）。我不會為此使用維護嚮導，我已經看到它多次出現問題並開始跳過數據庫並且通常行為不端。如果您想提供 30 分鐘的保證，則可能每 15 分鐘執行一次。
- 一部分將備份文件從暫存區域複製到您的 DR 站點。如果您的 DR 有 VPN，這可能就像 robocopy CMD 文件一樣簡單。如果您需要更高級的東西（sftp 或 ssh/scp，或者如果您沒有內置備份壓縮功能，則可能是 zip/unzip），您可以編寫一個包或一個 powershell 腳本。這可以執行得更快，也許每 5 分鐘一次，以確保它得到一切。一旦某些東西被複製到異地，它就是“安全的”。
- 一部分將它在 DR 站點找到的 tlog 備份還原到您的輔助伺服器上。您需要確保辨識已恢復的 tlog，並按某個計劃將其移走或刪除，否則您最終將耗盡空間。這不需要經常執行，但您需要確保它已在所有可用的 tlog 備份上執行，然後在您遇到問題時聲明 DR 輔助“活動”。
您想要審核所有三個步驟的表，一些報告/腳本向您顯示發生了什麼（是在您的主站點或輔助站點上執行的特定數據庫？輔助站點上是否有任何數據庫在兩個小時內沒有看到 tlog 恢復？ ) 和警報方案。
最重要的是，我還希望能夠選擇一個特定的數據庫進行故障轉移，以及能夠對所有內容進行故障轉移。能夠選擇一個數據庫進行故障轉移可以輕鬆進行測試（您故障轉移一個測試數據庫，而不是客戶的數據庫），並且如果您遇到擴展問題，可能會給您一個基本的負載平衡方案。您還需要一種自動方式在主伺服器和輔助伺服器之間“重新同步”（從主伺服器獲取完整備份並將其應用到輔助伺服器，啟動 tlogs 流動等）。這些功能對於 2.0 版本可能會更好。
（大家都忘記了 MS 支持的最早的 tlog 傳送是通過一些腳本實現的，你可以下載並在 SQL 7.0 上執行。有 go GUI，UI 是一些 SQL 報告和一些儲存過程。）
除了編寫一點 tsql 程式碼之外，這裡的挑戰是：
- 更改為完整恢復模式（在我看來，您可能在簡單恢復模式下執行）以及可能用於日誌備份的儲存使用量的增加、數據庫大小的增加、您有什麼。
- 確保您的儲存系統能夠處理頻繁的 tlog 備份負載並及時將它們複製到 DR 站點。IOW，如果您有 2000 個數據庫並希望保證數據直到最後一小時，您需要能夠對這 2000 個數據庫中的每一個數據庫進行一個事務日誌備份並將其放到網路儲存中（不在您的主伺服器中的某個位置） ）。
- 確保一切正常。
在我完成所有這些工作後，我將開始研究自動故障轉移，如何告訴我的網站執行特定客戶數據庫的實時版本等。如果您沒有執行集群系統，請確保您保持所有登錄名/密碼、工作、連結伺服器等同步是 PITA。