Sql-Server

(Ola Hallengren) 刪除比上次完整備份更早的日誌備份

  • December 21, 2017

當我將 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 腳本的錯誤理解。

引用自:https://dba.stackexchange.com/questions/193573