(Ola Hallengren) 删除早于上次完整备份的日志备份

Question

当我将 Ola Hallengren 的备份脚本部署到我的服务器时，我总是将@CleanupTime日志备份的参数设置为零。这样，每次运行日志备份作业时，它都会检查早于上次完整备份的日志备份文件并将其删除。但是，对于完整COPY_ONLY备份也是如此！COPY_ONLY为了删除旧的日志备份文件，日志备份作业应该只检查最后一次非完整备份。

只是想知道我是否是唯一遇到这种情况的人，或者我的建议是否合理。如果我需要在中间进行完整副本备份以 IDK 刷新 TEST 数据库，则该仅副本备份不应影响常规的每日备份顺序。请让我知道你的想法。

Answer 1

第二部分（不得不拆分我的答案）

做得更好

考虑到您的业务定义的 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 脚本的错误理解。