主页 / dba / 问题 / 193573
Accepted
Guillermo Garcia
Asked: 2017-12-20 15:39:15 +0800 CST

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

  • 772

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

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

sql-server sql-server-2012

3 个回答

  1. Best Answer

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

    做得更好

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

    • 5

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

    这里有一两件事需要考虑。在我看来，你可能在思考过程中走捷径。我会在做这个假设时解释......

    您可能想快速查看我在此处接受的答案，该答案是在参考问题需要关于备份策略的建议 [关闭]时发布的，以便为您提供有关 RTO 和 RPO 的一些想法。

    为什么？因为设置@CleanupTime=0可能是个坏主意...

    首先回答你的问题。

    这是 Ola 脚本中的错误吗？-不。Ola 设计了他的脚本来检查最后一次BACKUP DATABASE...（完整备份），然后删除BACKUP LOG ...在该备份之前发生的事务日志备份 ( )，并且仅当备份@CleanupTime低于发生完整备份时。

    这是一种故障安全机制，并不打算用作一般功能。

    按设计工作，因为 aBACKUP DATABASE ... WITH COPY_ONLY...仍然是Full Backup。

    安全第一

    使用该选项创建备份BACKUP DATABASE ... COPY_ONLY...然后创建BACKUP LOG...仍将允许您使用 FULLCOPY_ONLY备份和可用的事务日志备份将数据库恢复到一致状态。

    我使用我的 StackExchange 数据库对此进行了测试：

    • 手动创建COPY_ONLY备份
    • 修改一些数据
    • BACKUP LOG ...使用 Ola 的脚本 执行
    • 恢复数据库

    手动备份COPY_ONLY

    --------------------------------------------------
备份数据库 [StackExchange] 到磁盘 = 'C:\adhoc\StackExchange_Full_CopyOnly_20171221_082242.bak'
                WITH COPY_ONLY, COMPRESSION, RETAINDAYS = 3, NOFORMAT, NOINIT, NAME = N'StackExchange-Full Backup Sichern', SKIP, NOREWIND,
                     NOUNLOAD，STATS = 10，校验和
-------------------------------------------------
10% 已处理。
21% 已处理。
31% 已处理。
40% 已处理。
50% 已处理。
61% 已处理。
70% 已处理。
80% 已处理。
91% 已处理。
为数据库“StackExchange”处理了 376 页，文件 1 上的文件“StackExchange”。
100% 处理。
为数据库“StackExchange”处理了 2 页，文件 1 上的文件“StackExchange_log”。
BACKUP DATABASE 在 0.027 秒（109.103 MB/秒）内成功处理了 378 个页面。
-------------------------------------------------
完成的

    使用 Ola 的脚本备份事务日志

    日期 21.12.2017 08:29:06
记录作业历史记录 (OLA DatabaseBackup - USER_DATABASES - LOG)

步骤 ID 1
服务器 MYNOTEBOOK
作业名称 OLA DatabaseBackup - USER_DATABASES - LOG
步骤名称 OLA DatabaseBackup - USER_DATABASES - LOG
持续时间 00:00:01
Sql 严重性 0
Sql 消息 ID 0
操作员通过电子邮件发送    
运营商网发送   
操作员分页  
重试次数 0

信息
以用户身份执行：NT Service\SQLSERVERAGENT。...557.0 版：开发版（64 位） 过程：[msdb].[dbo].[DatabaseBackup] 参数：@Databases = 'USER_DATABASES'，@Directory = 'C:\SQL\Backup'，@BackupType = 'LOG'，@Verify = 'Y'，@CleanupTime = 48，@CleanupMode = 'AFTER_BACKUP'，@Compress = NULL，@CopyOnly = 'N'，@ChangeBackupType = 'N'，@BackupSoftware = NULL，@CheckSum = 'Y'，@BlockSize = NULL，@BufferCount = NULL，@MaxTransferSize = NULL，@NumberOfFiles = NULL，@CompressionLevel = NULL，@Description = NULL，@Threads = NULL，@Throttle = NULL，@Encrypt = 'N' ，@EncryptionAlgorithm = NULL，@ServerCertificate = NULL，@ServerAsymmetricKey = NULL，@EncryptionKey = NULL，@ReadWriteFileGroups = 'N'，@OverrideBackupPreference = 'N'，@NoRecovery = '

[缩短]

  ... 处理退出代码 0。该步骤成功。

    恢复

    USE [master]
-- Restore the COPY_ONLY Backup 
RESTORE DATABASE [StackExchange] FROM  DISK = N'C:\adhoc\StackExchange_Full_CopyOnly_20171221_082242.bak' 
WITH  REPLACE, FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5
-- Restore an OLA Transaction Log backup
RESTORE LOG [StackExchange] FROM  DISK = N'C:\SQL\Backup\MYNOTEBOOK\StackExchange\LOG\NB31710_StackExchange_LOG_20171221_082906.trn' 
WITH  FILE = 1,  NOUNLOAD,  STATS = 5

    你可能不会在时间戳的差异是大约。7 分钟。

    结果

    6% 已处理。
10% 已处理。
16% 已处理。
21% 已处理。
25% 已处理。
31% 已处理。
36% 已处理。
40% 已处理。
46% 已处理。
50% 已处理。
55% 已处理。
61% 已处理。
65% 已处理。
70% 已处理。
76% 已处理。
80% 已处理。
86% 已处理。
91% 已处理。
95% 已处理。
100% 处理。
为数据库“StackExchange”处理了 376 页，文件 1 上的文件“StackExchange”。
为数据库“StackExchange”处理了 2 页，文件 1 上的文件“StackExchange_log”。
RESTORE DATABASE 在 0.021 秒（140.276 MB/秒）内成功处理了 378 个页面。
100% 处理。
为数据库“StackExchange”处理了 0 页，文件 1 上的文件“StackExchange”。
为数据库“StackExchange”处理了 2 页，文件 1 上的文件“StackExchange_log”。
RESTORE LOG 在 0.005 秒 (2.441 MB/秒) 内成功处理了 2 个页面。

    概括

    Ola 的脚本按设计工作。我们已经验证了 aBACKUP DATABASE ... WITH COPY_ONLY...和 an AdditionalBACKUP LOG ...将一起工作。故障安全功能确保您可以使用最后一次完整备份（无论是否为 COPY_ONLY）和可用的事务日志备份来恢复数据库。

    （更多答案请阅读第二部分第二部分）

    • 3

  3. 你说的对！我认为这是一个错误或设计。我能够回购这个场景。

    所以基本上当你用这个运行 Ola 的脚本时：

    EXECUTE [master].[dbo].[DatabaseBackup] 
@Databases = 'UserShrinkSizeTest', 
@Directory = N'C:\Backup', 
@BackupType = 'FULL', 
@Verify = 'Y', 
@CleanupTime = NULL, 
@CheckSum = 'Y', 
@LogToTable = 'Y',
@CopyOnly = 'Y' --copy_only param

    或本地：

    -- native copy_only
BACKUP DATABASE [UserShrinkSizeTest] 
TO  DISK = N'C:\Backup\machine$SQLSERVER16\UserShrinkSizeTest\COPY_ONLY\UserShrinkSizeTest_21122017_COPYONLY.bak'
 WITH  COPY_ONLY, INIT, STATS = 1
GO

    当您执行新的完整备份或完整copy_only备份甚至差异备份时，您之前的所有日志备份都将在您运行另一个日志备份后被删除（Ola 的带@CleanupTime = 0参数的日志备份脚本）。

    使用 Ola 的脚本版本进行测试：2016 年 10 月 7 日。

    基于Ola 的网站：

    清理时间

    指定删除备份文件的时间（以小时为单位）。如果没有指定时间，则不会删除备份文件。

    DatabaseBackup 会检查以确认比最新的完整备份或差异备份更新的事务日志备份不会被删除。

    它没有提到COPY_ONLY备份。

    同时，您可以将日志备份参数更改@CleanupTime = NULL为作为解决方法。或者考虑迁移到其他备份工具（例如Minion Backup或dbatools）或滚动您自己的自定义代码，因为 Ola 维护计划的最后一次更新是在 2016 年 10 月 7 日。如果您想提出问题/增强，这里有一个github 。

    • 1

相关问题