目前，我们在我们环境中的 SQL Server 2005/2008/2008R2/2012 服务器上使用标准维护计划进行备份，并且始终选中“验证备份完整性”框。
一些备份运行时间很长，因此我建议关闭该选项，但管理层需要我记录此更改的影响和风险。
我了解此选项的使用和历史，我似乎没有必要将备份工作的时间加倍（在我看来），任何可能发生的错误都将在备份步骤期间发生，而不是在验证期间发生。
我错了吗？如果我要备份到磁盘而不是流式磁带或其他东西，关闭它的风险是否最小？（如果相关，我们通过网络备份到 EMC DD-800 备份设备。）
是否有任何官方的 MS 建议何时可以安全地关闭此功能？
您是否对环境中的每个备份都运行“验证”？你抽查他们吗？
编辑：为了澄清，当您在维护计划中检查“验证备份完整性”时，SQL 将在每次备份后立即对每个数据库执行完整的RESTORE VERIFYONLY 。这与原始备份一样密集的数据/IO，并且（基本上）使备份作业的总时间加倍。这与在备份中启用“校验和”选项不同（据我所知，这不能在向导中完成）。
不，你是对的:-)
RESTORE VERIFYONLYonly 不能确保在发生损坏时能够恢复数据库。从本质上讲，它不会执行任何完整性检查。更好的方法是定期进行备份并在不同的服务器上进行有效恢复并在其上执行 DBCC CHECKDB。
这就是为什么我不是维护计划的忠实拥护者的原因之一，因为 GUI 没有提供很多
backup .. with CHECKSUM可以通过 T-SQL 实现的选项。来自Paul Randal 的神话博客
我不运行 VERIFYONLY。相反，我使用 CHECKSUM 进行备份，然后在另一台服务器上恢复 + CHECKDB。如果您想发挥创意，您可以遵循 Statistical Sampling for Verifying Database Backups方法。
您可以启用跟踪标志 3023，以便
CHECKSUM为 BACKUP 命令自动启用该选项。与往常一样，在您的环境中测试任何跟踪标志的行为！底线是 - 放弃维护计划并使用更明智的备份解决方案 （提示：Ola 的备份解决方案），这将允许您根据需要对其进行自定义。
在本地备份到磁盘，然后执行 PowerShell 传输作业，将备份从服务器本地复制到网络共享（备份服务器）。这将比直接复制到网络共享更快。
此外，启用即时文件初始化，这将有助于数据文件的自动增长以及有助于减少恢复时间（以防万一您必须恢复数据库）。有方便的选择总是好的。
不错的读物是：备份：规划恢复策略
底线是，除非您在某处进行数据库恢复，否则您不能完全确信给定的备份文件是好的。
验证备份的理想测试是设置一个环境，在该环境中，数据库备份和数据库日志备份始终作为日常流程的一部分进行恢复。这是使用日志传送的优点之一......
如果您仍然想坚持使用 verifyonly，您可以专门设置一个环境来执行此操作。这将从您的（大概）生产服务器上卸载工作，并减少工作时间。
最后，您是否考虑过放弃维护计划？像 Ola 的脚本之类的脚本，除了备份和维护之外： https ://ola.hallengren.com/
从技术上讲，verfyonly 还原就像执行还原一样，但是没有更好的检查来实际还原数据库以检查其有效备份。我们有一个实例，verifyonly 通过了但是数据库由于损坏而无法恢复，我的观点是不要指望这个作为验证备份是好的。我们现在开发了一个系统，可以在一个单独的实例上恢复我们所有的数据库以检查它们的有效性，显然这并不总是可行的，因此请尝试每周对某个数据库进行采样。多头和空头不信任verifyonly 100%。