了解关闭“验证备份完整性”对SQL备份的影响/风险


12

当前,我们在环境中的SQL Server 2005/2008 / 2008R2 / 2012服务器上使用标准维护计划进行备份,并且始终选中“验证备份完整性”框。

一些备份运行时间很长,因此我建议关闭该选项,但是管理层需要我记录此更改的影响和风险。

我了解此选项的用法和历史,对我来说似乎没有必要将备份作业的时间加倍,因为(我认为)可能备份步骤中而不是在验证过程中发生的任何错误。

我错了吗?如果我要备份到磁盘而不是流式磁带或其他东西,将其关闭的风险很小吗?(如果需要的话,我们会通过网络备份到EMC DD-800备份设备。)

是否有什么正式的MS建议可以安全关闭此功能?

您是否在环境中的每个备份上运行“验证”?你会抽查他们吗?

编辑:为澄清起见,当您在维护计划中选中“验证备份完整性”时,SQL将在每次备份后立即对每个数据库执行完整的RESTORE VERIFYONLY。就像原始备份一样,数据/ IO占用大量资源,并且(基本上)使备份作业的总时间增加了一倍。这是一样的使备份的“校验”选项(不能在向导中进行,因为据我所知)。


感谢大家。再增加一个链接,我自己参考,有关使用跟踪标志启用备份校验和,甚至可以通过SQL维护计划时:nebraskasql.blogspot.com/2014/03/...
BradC

Answers:


5

我错了吗?如果我要备份到磁盘而不是流式磁带或其他东西,将其关闭的风险很小吗?

不,你是对的:-)

RESTORE VERIFYONLY仅不能确保发生损坏时能够恢复数据库。从本质上讲,它将不执行任何完整性检查。

更好的方法是定期获取备份并在其他服务器上进行有效还原,然后在该服务器上执行DBCC CHECKDB。

这是一个原因,为什么我不是维护计划的忠实拥护者,因为GUI没有公开很多backup .. with CHECKSUMT-SQL可以实现的选择。

保罗·兰德尔的神话博客

24p)使用RESTORE…WITH VERIFYONLY验证整个备份

否。使用VERIFYONLY仅可验证备份头看起来像备份头。仅当您使用WITH CHECKSUM进行备份并执行RESTORE…WITH VERIFYONLY 使用WITH CHECKSUM 进行备份时 ,还原才会进行更广泛的检查,包括整个备份的校验和。

您是否在环境中的每个备份上运行“验证”?你会抽查他们吗?

我不运行VERIFYONLY。相反,我使用CHECKSUM进行备份,然后将它们还原+ CHECKDB在另一台服务器上。如果您想发挥创造力,可以按照 统计抽样来验证数据库备份的方法。

这与在备份上启用“校验和”选项不同(据我所知,这不能在向导中完成)。

您可以启用跟踪标志3023,以便CHECKSUM自动为BACKUP命令启用该选项。与往常一样,测试您环境中任何跟踪标志的行为!

最重要的是-放弃维护计划,并使用更明智的备份解决方案 (提示:Ola的备份解决方案),该解决方案将使您可以根据需要自定义它。

(如果需要的话,我们会通过网络备份到EMC DD-800备份设备。)

在本地备份到磁盘,然后执行PowerShell传输作业,该作业会将备份从服务器本地复制到网络共享(备份服务器)。这将比直接复制到网络共享更快。

另外,启用即时文件初始化,这将有助于数据文件的自动增长,并有助于缩短还原时间(以防万一,如果您必须还原数据库)。拥有方便的选择总是好事。

一本好书将是:备份:规划恢复策略


感谢您的详细回答。我想我可能建议您在备份上启用校验和,这样可以在备份步骤中捕获更高百分比的错误,并有望抵消(略微)跳过BACKUP VERIFYONLY的更高风险。我了解您针对在不同服务器上进行定期还原的建议,但是由于我们环境的规模,这似乎不太合理,除非是基于抽样。
BradC 2015年

@BradC很高兴我的回答对您有用。我回答的要点是使用TSQL(而不是GUI维护计划),以便您可以灵活利用并灵活使用。正如FYI ..维护计划已在SQL Server 2016中得到了增强CTP 2.4,MS称其为SQL Server智能维护计划 -集成了最佳实践,并且可以即时确定最佳策略。仍然没有GUI可以击败TSQL :-)
Kin Shah

谢谢@Kin。我熟悉其他环境中的全定制脚本方法,显然这可能会带来错误和脚本维护方面的问题。我们正在评估一些第三方压缩代理,因此最终可能需要自定义脚本。
BradC 2015年

2

底线是,除非您在某处进行数据库还原,否则您将无法完全确定给定的备份文件是否良好。

验证备份的理想测试是建立一个环境,在该环境中,数据库备份和数据库日志备份在日常过程中始终被还原。这是使用日志传送的优势之一...

如果您仍然希望仅使用verifyonly,则可以专门为此设置环境。这将减轻您(可能是)生产服务器的工作负担,并减少作业时间。

最后,您是否考虑过放弃维护计划?像Ola的脚本这样的脚本除了备份和维护之外:https : //ola.hallengren.com/


由于我们正在评估一些第三方备份代理(这些备份代理可与我们的特定备份设备配合使用),因此将来我们可能会放弃维护计划。我假设这些将需要自定义脚本,类似于Ola开发的脚本。
BradC 2015年

1

从技术上讲,还原verfyonly就像执行还原一样,但是没有更好的方法检查实际还原数据库以检查其有效备份。我们有一个实例,其中仅通过verifyonly通过,但是由于损坏而无法恢复数据库,我的意思是不要指望此作为备份可以的验证。现在,我们已经开发出了一个系统,可以在一个单独的实例上还原所有数据库以检查其有效性,显然这并非总是可能的,因此请尝试每周对某些数据库进行采样。多头和空头不信任仅验证100%。


是的,但是我不确定这是否真的回答了我的问题,因为我建议在我们的环境中关闭 “ RESTORE VERIFYONLY”。除非您的观点是:“因为只有进行实际的完全还原才能证明备份是可行的,所以关闭此选项不会明显增加风险”。
BradC 2015年

正确的,唯一真正检查IMO是实际执行真正的恢复
盖德
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.