问关于备份和恢复策略

EN

你的后备计划似乎不错。当然，一切都取决于：

恢复点目标(RPO)，换句话说-你能承受多少数据损失？

和

恢复时间目标(RTO)如果发生数据库灾难，您能够花费多少时间将数据库恢复到其工作状态？

注意，如果要在简单恢复模型下运行数据库，则无法进行事务日志备份。

这种做法正确吗？如果没有，请提出更好的选择？

看起来不错，您的备份应该依赖于您的RPO和RTO，而RPO和RTO应该由业务设置。通常，当没有备份时，备份将设置如下：

• 每周备份一次
• 每天备份一次
• 每15分钟记录一次备份

哪种恢复模式最适合？(简单、完整、大容量记录)

当您不想管理事务日志时，应该使用Simple +您不需要时间点恢复。(没有日志备份)

当您需要时间点恢复时，应该使用Full。

我个人从未使用过大容量日志

如果任何备份文件(完整备份文件、差异备份文件或日志备份)已损坏，那么有哪些选项可以快速恢复数据库，同时最大限度地减少数据丢失？

尝试在没有损坏的情况下找到最后一个备份，并恢复该备份。预防腐败比解决腐败容易得多。

这就是为什么定期在数据库上执行DBCC很重要(例如使用Ola Hallengren脚本)。

就我个人而言，我做了一个完整的备份，然后我将做一个checkdb，这样，我确信我拥有的备份是正确的，没有任何损坏。

我想要备份和恢复..。Server上的关键数据库。

让我们从故事的结尾开始.

当数据库在火球中爆炸时：

1. 您需要多长时间才能恢复并运行(恢复时间目标)，以及
2. 在您这样做的过程中，您的企业准备丢失多少数据(恢复点目标)。

这两项都需要在您和您的业务之间协作定义的术语(您不能单独完成)，并在您的公司的恢复策略中固定下来。

问:在上述所有内容中，哪个词明显地缺失了？

回答：“支援”。

能够恢复数据库才是重要的。

你怎么做到这一点并不是。

尽管如此，99.9%的用户可能会使用与数据库相关的备份工具来实现您的恢复策略。

这方法正确吗？

我们不能告诉你。

只有你的生意才能做到这一点。

以防任何备份文件..。堕落了..。

这就是为什么你定期进行康复彩排

1. 你理解并练习执行恢复过程(你不想在凌晨2点试图解决这个问题，而高级管理人员却在你的脖子上呼吸！)，
2. 您可以度量执行恢复所需的时间(当然，这可能会随着时间的推移而改变)，以及
3. 您可以确保备份文件实际上是可用的(在备份文件成为工作威胁之前)。