備份和恢復的SQL服務器上的數據庫的大型數據庫或採集的過程是用於災難恢復&而言非常重要。但是，我還沒有找到一個可靠的解決方案，可以保證整個過程儘可能高效，100％可靠，易於維護，並且可以跨多臺服務器進行配置。數據庫備份/恢復過程
Microsft的維護計劃似乎不夠。我使用的最佳解決方案是我使用許多作業手動創建的，每個數據庫在源服務器（備份）和目標服務器（恢復）上運行時都有許多步驟。作業使用存儲過程來執行備份，複製&恢復。每天運行一次（完全備份/恢復），每5分鐘運行一次（事務日誌傳送）。
儘管我目前的流程通過電子郵件工作並報告任何工作失敗，但我知道整個流程不是非常可靠，並且無法在非DBA的所有服務器上輕鬆維護/配置，該過程。
我想知道如果其他人有此相同的備份/恢復過程以及其他人如何解決這個問題。
我做着完全相同的事情，即使在這個過程中也經常發生各種問題。
你如何處理在從服務器A上的文件複製到服務器B和恢復服務器上的事務備份B.
每隔一段時間之間的間距，而事務備份大於正常，並需要較長的時間複製。然後，還原作業將獲取該文件正在使用的操作系統錯誤。
這不是什麼大不了的，因爲該文件在下一次自動應用圍繞但它會更好有一般一個更優雅的解決方案，一個專門解決這個問題。
我已經使用了類似的步驟，以保持開發/測試/ QA數據庫開發人員和QA人使用夜間的基礎上「零階梯」。
文檔是關鍵 - 如果你想刪除的內容斯科特Hanselman的所謂的「巴士因子」（即危險，該系統的創建者將被車撞到，一切都開始吸）。
也就是說，對於正常的數據庫備份和災難恢復計劃，我發現SQL Server維護計劃工作得非常好。只要你包括： 1）體面的文件 2）例行測試。
我列出了一些的方式去這樣做（的人吸引到這個問題，在尋找如何去創建一個災難恢復計劃爲例）：
SQL Server Backup Best Practices (Free Tutorial/Video)
的關鍵部分您的問題是備份解決方案由非DBA管理的能力。像備份腳本這樣的任何本地SQL Server應答都不能滿足這種需求，因爲備份腳本需要T-SQL知識。
正因爲如此，您希望看起來像米奇小麥提到的第三方解決方案。我爲Quest（LiteSpeed的製作人）工作，所以我當然偏向那個 - 很容易向非DBA展示。在我離開我的最後一家公司之前，我有十分鐘的時間向系統管理員和開發人員展示了LiteSpeed控制檯的工作方式，就是這樣。自那以後他們就沒有叫過。
另一種方法是使用與您店鋪其他人使用的相同的備份軟件。 TSM，Veritas，Backup Exec和Microsoft DPM都具有SQL Server代理，可讓您的Windows管理員以不同程度的易用性管理備份過程。如果你真的想要一個非DBA來管理它，這可能是最簡單的方法，儘管你犧牲了SQL專用備份工具給你的很多性能。