(Ola Hallengren) 刪除比上次完整備份更早的日誌備份
當我將 Ola Hallengren 的備份腳本部署到我的伺服器時,我總是將
@CleanupTime
日誌備份的參數設置為零。這樣,每次執行日誌備份作業時,它都會檢查比上次完整備份更早的日誌備份文件並將其刪除。COPY_ONLY
但是,完全備份也是如此!日誌備份作業應該只檢查最後的非COPY_ONLY
完整備份,以便刪除舊的日誌備份文件。只是想知道我是否是唯一遇到此問題的人,或者我的建議是否有意義。如果我需要在中午進行完全副本備份以 IDK 刷新 TEST 數據庫,則該僅副本備份不應影響正常的每日備份順序。請讓我知道你的想法。
第二部分的第二部分(不得不拆分我的答案)
做得更好
考慮到您的業務定義的 RPO 和 RTO,您現在可能希望將 的參數更改為
@CleanupTime
高於0
. 為什麼?因為該值0
只能與內置的故障安全機制一起使用。讓我們使用以下時間線:
- 08:00 備份日誌
- 09:00 備份日誌
- 10:00 備份日誌
- …
- 20:00 備份數據庫
- 21:00 備份日誌
- …
在某個時間點,您的事務日誌備份(和完整備份?)被複製到網路驅動器並通過備份解決方案從那裡備份,可能與某種磁帶和/或磁碟儲存相結合。一旦第一個
BACKUP LOG ...
發生在最後一個之後,BACKUP DATABASE ...
您以前的BACKUP LOG ...
文件就消失了……要問自己的問題
- 如果您的網路備份失敗會怎樣?
- 此(磁帶)備份何時發生?保證?
- 何時進行完整數據庫備份?
- 您希望能夠恢復什麼?
- 你有什麼 RTO?
- 您的業務需要什麼 RPO?
查看上述問題,考慮使用不同的清理時間(例如
@CleanupTime=48
)在數據庫伺服器的磁碟上保留額外數小時的事務日誌備份。好處
您不再依賴 Ola 的故障安全機制
即使您創建了
COPY_ONLY
備份 ,您的數據仍在磁碟上您的數據仍在磁碟上,即使網路出現故障並且…
- …你創建一個
BACKUP DATABASE ...
- …
COPY_ONLY
備份建立堅實的基礎
在任何給定的時間點,某些事情都會失敗。您必須確保您可以適應任何故障,並且仍然向利益相關者保證您的解決方案將是 99,…..% 萬無一失。
我是怎麼做的
使用 Ola 的解決方案絕對是一件輕而易舉的事,如果您對如何恢復數據庫以及基於您的業務 RPO 和 RTO 提出一兩個想法。
我個人的實施是有以下時間表/保留政策:
生產系統
備份日誌
- 每小時@ xx:05(非 SAP 系統)
- 每季度 @ xx:10、xx:25、xx:40、xx:55(SAP 系統)
- 保留 : 48 小時
每日差異備份
- 週一 - 週六 @ 20:00(非 SAP 系統)
- 週一至週六 @ 22:00(SAP 系統)
- 保留時間:168 小時
每週完整備份
- 週日 @ 20:00(非 SAP 系統)
- 週日 @ 22:00(SAP 系統)
- 保留時間:336 小時
測試系統
測試系統將在生產時間進行備份。這可以是上午 10:00 或下午 14:00(完整備份)和 xx:15(事務日誌備份)。
為什麼我這樣做
…或者我在這些決定背後的想法…
通過將備份時間分配到不同的插槽,我將磁碟 I/O 均勻地分佈在儲存系統上。在全時 (FULL) 或每季度 (TLOG) 時,磁碟上沒有大量 I/O。
由於數據庫的大小,我區分了 SAP 和非 SAP。
允許測試系統在白天破壞儲存。沒有高性能影響。
DIFF 和 FULL 備份發生在磁帶備份開始之前,並且通常在磁帶備份開始之前完成。
即使(磁帶)備份解決方案停機一天,保留策略也允許我達到業務制定的 RTO 和 RPO。
即使網路(整體或僅部分)中斷一天,備份仍將正常工作並符合 RTO 和 RPO。
你的思考過程
您的
@CleanupTime
設置可能是基於對 Ola 腳本的錯誤理解。