问仅还原验证w/事务日志备份

EN

但是，这引发了一个问题，即在仅验证失败的还原时如何继续。

只恢复验证(根据BOL)验证备份，但不恢复备份，并检查备份集是否已完成，并且整个备份是可读的。但是，RESTORE不尝试验证备份卷中包含的数据的结构。因此，即使备份集经过verified验证干净，它也不能100%保证备份集是一致的，只有成功地恢复备份才能保证备份集是有效的。

我没有看到只有verifyonly失败但恢复成功(除非使用continue_after_error成功)的情况，只有当verifyonly失败时才会发生，因为verifyonly只检查备份一致性，因为verifyonly只检查是否有足够的空间恢复数据库。

RESTORE VERIFYONLY执行的检查包括：

备份集是完整的，所有卷都是可读的。

·数据库页的某些标头字段，如页ID (就好像它即将写入数据)。

校验和(如果出现在媒体上)。

检查目的地设备是否有足够的空间。

请给我看一下你在只有失败时收到的信息。

Verifyonly之后的

只失败了

我会在我的数据库上运行一个checkdb来检查是否有任何不一致性，但是这里要指出的是，checkdb只在使用checkdb日志文件运行快照恢复时，才不会对日志文件进行一致性检查，因此我们可以说，它也检查日志文件，但不像对数据文件那样完成。如果checkdb是干净的，我会说我的数据库是一致的。

备份跨越LSNs到Y。我不能简单地采取另一个trx日志备份来“修复”这种情况:随后的trx日志备份将跨越不同范围的LSNs (Y+1到Z)。在这一点上，日志链实际上被打破了，对吗？

是的，您是正确的，进行多个备份不会修复日志备份中的损坏，但是多个日志备份不会破坏日志链。日志文件在内部与LSN编号相关联，如果以顺序方式恢复日志备份，则多个日志备份不会中断链。

我的第一个想法是立即采取差异备份。你怎么做？

它不会以任何方式解决腐败问题。差异备份是降低RTO和执行数据库快速恢复的方法。

用户更新问题后的

编辑：

在DR情况下，我能做的最好的就是恢复完整的备份和六个随后的trx日志备份。

是的你是对的。

如果我在#7失败后不久采取了差异备份，在DR情况下，我可以：

Restore the FULL backup
Restore the DIFFERENTIAL backup
Restore transaction log backups 8, 9, and 10

是的，您可以恢复差异备份，在您清除了问题的详细信息后，我更新了答案。您可以还原差异备份，然后恢复日志备份8、9、10，因为这些备份是在diff备份之后进行的。