SQL Server 2008 中的 RSync 數據庫文件增量
好吧，我覺得這是一個糟糕的主意，但我需要一些幫助來理解為什麼這很糟糕：
我仍在為我們的數據中心實施災難恢復/業務連續性解決方案。我們正在執行 MSSQL 2008 Enterprise，併計劃在雲中執行被動實例。目前我建議使用 Log Shipping，但有人要求我探索使用 RSync（或類似的東西）將 MDF/LDF 文件增量推送到雲端，而不是使用內部工具。
目標是減少我們的佔用空間，並且由於許可問題，大部分時間都不執行雲 SQL 實例（我們目前的數據中心已經在使用我們的 Passive/DR 許可證，但如果該中心出現故障，則許可證可用） .
我找到了一個使用 VSS 創建和推送增量的解決方案，即使文件被鎖定，但我想知道會出現什麼樣的問題。我能得到一些見解嗎？我們將每 15 分鐘推送一次增量，所討論的數據庫大約為 2GB，在 15 分鐘的視窗中可能會生成 10 MB 的 T-Logs。
我不相信 rsync 會為使用者或系統數據庫複製 ldf 和 mdf 文件，我也不相信我在生產環境中一起破解的任何東西（VSS 或其他）。SQL Server 對何時（以及是否）將內容寫入 ldf 和 mdf 文件非常挑剔。設計時未考慮到這一點的軟體 (rsync) 可能無法正確處理，尤其是如果它不了解需要將 ldf 文件和 mdf 文件視為相互關聯的文件系統時。如果該軟體無法正確處理，則在您進行故障轉移之前可能不會注意到任何事情，嘗試上線並將您的數據庫標記為可疑，因為 SQL Server 將其視為數據損壞。更糟糕的是，“正確處理”可能取決於系統上的負載量，而您可能在輕負載的測試環境中找不到問題。
我已經看到足夠多的人認為他們正在複製他們的文件，但實際上並沒有。他們在恢復站點上留下了損壞的文件，在主站點上留下了無法訪問的備份文件。所以，這意味著他們沒有數據庫。
簡而言之，你是在為麻煩預約。
如果您擁有某種塊級複製技術，例如 EMC 的 SRDF，或者正在研究無共享集群，那可能會有所不同。這些技術與 SQL Server 和 Windows 提供的群集服務介面，以確保您的寫入安全並且您的文件將/應該是一致的。
如果我唯一的災難恢復選項是一個正常停機的遠端站點，我會使用日誌傳送並確保我擁有所有元件來恢復遠端站點上的數據庫。如果您不能使內置的日誌傳送做到這一點，那麼編寫自己的日誌並不難。在過去的 14 年裡，我可能已經從零開始編寫了三四個（簡單的）日誌傳送系統。
至少，您需要的關鍵是： 需要進行完整備份並將其複製到遠端站點。您的 tlog 備份需要進行並複製到遠端站點。您需要一種自動化方法來恢復該完整備份和任何相關的 tlog 備份。理想情況下，這應該足夠簡單，其他人可以做和/或足夠簡單，您可以在凌晨 3 點找出主伺服器發生故障並且您半睡半醒的情況。
當您有活動時，啟動另一台伺服器將花費更長的時間，因為您需要做很多手動工作。這意味著這不如簡單地實施正常日誌傳送。您還需要定期對此進行測試。
（當然，你還需要擔心其他事情，比如作業、包、登錄和使用者同步、在發生故障時更改 Web 伺服器上的 DSN 等等。如果你有一個大環境和嚴重的災難，比如失去您的主要數據中心，當 IIS 人員、文件伺服器人員、網路人員和其他任何人都試圖將他們的東西也拿出來時，您將嘗試這樣做。）
如果是我，我會急於在遠端站點安裝一個熱備用伺服器。這將使（標準的、開箱即用的）日誌傳送更容易並使數據庫鏡像成為可能。聽起來你已經嘗試過了。