關於數據庫日誌的 SQL 備份常式
我最近發生了一件讓我重新考慮備份計劃的事件：我們的一個 MSSQL 驅動的應用程序停止了，因為文件系統上的日誌文件變得太大（它是 50 GB 的 IIRC）。
事實證明，應用程序開發人員將數據庫恢復方法設置為“完整”，並且完整備份夜間路由不會清除和縮小該日誌文件。為了縮小它必須備份它，將恢復方法更改為“簡單”，並使用縮小進行備份。
我顯然想防止這種情況發生，所以我正在尋找選擇。
這是一個 MSSQL 2012 Express x64 實例。
應用程序開發人員完全不合作（外部承包商，與所有人合作），所以我假設他不希望我讓數據庫處於“簡單”模式。
我可以輕鬆地調整我的 sqlcmd 腳本來執行“以‘完整’備份 -> 切換到‘簡單’ -> 以‘簡單’備份 -> 恢復為‘完整’”並保留文件，但我擔心我可以冒著一些我現在沒有預見到的風險。
在我看來，我應該相對頻繁地執行此操作，因為日誌文件越大，備份和收縮所需的時間就越多，從而導致明顯的減速。
如果該常式是合理的，並且在每個循環之後我最終得到“清除日誌之前的備份”和“清除日誌後的備份”，並且假設兩個程序都沒有錯誤退出，那麼丟棄第一個程序是否明智？一？我將保留“數據”備份和“清除日誌”備份。
我應該通過執行“完整備份”而不是“正常日誌備份”來添加 AFAIK 我犧牲了恢復到“兩個完整備份之間的狀態”的可能性，但我並沒有阻礙完整備份本身，因為我已經恢復和複製了他們過去很多次都沒有問題。但如果這是錯誤的，請告訴我。
注意：為簡單起見，假設現在能夠恢復到每晚的完整備份就足夠了。
我希望我能夠解釋自己。提前致謝。
我可以輕鬆地調整我的 sqlcmd 腳本來執行“以‘完整’備份 -> 切換到‘簡單’ -> 以‘簡單’備份 -> 恢復為‘完整’”並保留文件，但我擔心我可以冒著一些我現在沒有預見到的風險。
不要這樣做。這是一個可怕的想法，因為它給其他任何查看系統的人留下了錯誤的印象，並且只是對主要開發人員撒謊的一種解決方法。這不是圍繞數據庫恢復做出技術決策的好理由。由於我們對您的公司、應用程序等一無所知，因此存在未知風險，因此只有您可以與這些人交談。
正確的路徑是在利益相關者（包括任何頑固的開發人員）之間達成共識，並就滿足業務需求的RTO/RPO達成一致。然後相應地調整恢復模式。
假設您不想根據您的文章這樣做：
如果您100% 確定您不關心比日常備份更精細的恢復，請將其保持在完全恢復模式並有一個事務日誌備份作業指向，
NUL這樣增長就不是問題。它不會將文件保存在任何地方，但仍然可以讓您控制日誌增長。另見：
- 切換到簡單恢復 - 縮小事務日誌
- expressdb.io：SQL Server Express 備份- 有關 RTO/RPO 的更多背景知識和使用Ola Hallengren 的備份解決方案的一些範例作業以及一些針對 SQL Server Express 的特定指導。
全面披露：expressdb.io 是我的網站。