您如何正確地為文件伺服器進行災難恢復？
我們目前正在為 Windows 文件伺服器實施 DR 策略。我們已經排除了儲存複製，因為它是一個預覽功能，並且故障轉移集群旨在實現高可用性，而不是災難恢復。DFSR 在複製打開/鎖定文件方面也存在缺陷，因此不適合該任務。
文件伺服器 VM 的 SAN 到 SAN 複製對我來說似乎是最好的方法，儘管我已經被警告不要這樣做，因為複制是未在更高級別合併的原始副本，可能導致不一致文件系統或損壞的文件。但是，對於以這種方法複製的任何伺服器，這一事實都是正確的，這也是我們 DR 計劃中用於其他伺服器的方法。VSS/以前的版本也總是可以用來恢復任何損壞的文件。
進行 SAN 複製的好處是否大於文件損壞的風險？或者有沒有更好的方法對文件伺服器進行 DR？也許有一種產品可以執行更高級別的複制/快照，從而最大限度地減少數據中的邏輯不一致？
注意：集群執行 vSphere 5.5
SAN 到 SAN 複製是您在宣布災難後儘快使文件伺服器恢復聯機並儘可能減少損失的最佳選擇。請注意，這種類型的 DR 保護不能保護與本地備份相同的東西——例如，您不能使用複制的 SAN 卷來取消刪除上個月的文件。
損壞的文件不是 SAN 到 SAN 複製的危險，除非是主站點上的文件伺服器損壞了它們。每個提供基於塊的儲存 (LUN) 複製的 SAN 都有一些機制來防止損壞和保證一致性。這是一個比大多數人知道的更棘手的問題，因為出於優化原因，即使沒有複製，寫入也經常無序地應用於磁碟。這就是為什麼大多數儲存的寫入記憶體具有某種電源故障安全網（如電池或 UPS）：如果沒有僅保存在記憶體中的寫入，則底層磁碟可能已損壞。通常這是可以的，但是如果您斷電，您需要確保儲存確認的最後一次寫入已保存到磁碟，以使磁碟在啟動時保持一致。
複製根據您的複制方式以不同方式處理此問題：
- 同步複製保證了一致性，因為它不會向本地伺服器返回寫入確認，直到確認寫入已安全地到達輔助站點。這大大減慢了寫入速度，並且沒有供應商支持在距離相對較短的恆星連接不到的任何東西上執行此操作。事實上，支持的距離通常很短，以至於你很容易受到同樣的颶風的影響。它很少見，而且通常不是唯一的。
- 非同步檢查點複製是迄今為止最常見的算法，被絕大多數開放系統儲存使用。該盒子會定期複製一個一致的檢查點，這意味著它將確保在遠端系統上找到的可恢復副本沒有失去的寫入。如果它在檢查點的中間被中斷，它會丟棄它並轉到最後一個已知的一致點。我見過的系統，只要您的 WAN 支持它，就可以使用這種方法讓您獲得 15 秒的恢復點。
- 非同步按順序傳遞複製比檢查點更稀有且更難實現，但在我看來是非同步算法中最好的。它的作用是按照完成的順序通過 WAN 發送寫入。問題是，與檢查點複製不同，如果這落後了，則用於保存未發送寫入的儲存無法在不需要完全重新同步（重新發送所有數據）的情況下被刷新。通常，如果連結跟不上寫入速度，它會退回到檢查點模式，並在獲得足夠近的檢查點後再次開始按順序傳遞。EMC 的恢復點和日立的 HUR 都這樣做，但是我還沒有看到任何其他供應商這樣設置。
所有這些機制都為您提供“崩潰一致性”。磁碟處於與突然關閉伺服器電源時相同的狀態。從崩潰一致性副本中執行文件系統和數據庫需要一些工作，但它總是可行的。如果您想要更多的東西（您在問題中提到的“更高級別”），您需要將您的複制與您的應用程序集成。這通常意味著暫停應用程序的寫入，等到所有內容都被轉移到儲存中，然後啟動複製的一致性點。這稱為“應用程序一致性”。它通常會提供稍早的恢復點，但恢復時間比崩潰一致性略短。