VM快照是否足以备份SQL？

Question

我在Azure VM上运行了一个Microsoft SQL DB。

我每天都有VM的快照，这是我目前唯一的备份机制。

这被认为是最佳做法吗？我是不是在冒什么险？

Answer 1

在我告诉您您是否遵循最佳实践之前，我建议您了解以下几个条款，这些术语决定了什么样的备份计划适合您。这也将使你能够决定你是在冒险还是不冒险。

恢复模型

有三种恢复模型:完全恢复模型(默认和最常用的)--在执行事务日志备份之前，完全日志记录的日志将不会清除--一些修改(如索引重新构建或大容量加载)可以最小限度地记录下来，这将减少在执行事务日志备份之前日志生成的日志记录量，就像完全恢复模型--简单的恢复模型--一些修改可以最低限度地记录下来，就像大容量日志恢复模型一样，日志直到检查点出现时才会清除(通常是自动的)，并且事务日志备份是不可能的。

备份类型

Server中有三种常用的备份类型:完全数据库备份、事务日志备份、差异数据库备份

RTO表示恢复时间目标.

简单地说，您可以将RTO看作是一种衡量多少停机时间是可接受的，或者数据必须多久才能再次被访问。RTO通常是从数据/数据库/系统的理想启动时间或可访问性的9个方面来讨论的。例如，5-9意味着99.999%的正常运行时间，如果这是一天24小时，一年365天，那么这就意味着每年允许的停机时间超过5分钟。这真的很难实现。它更容易满足4-九(每年52.5分钟的停机时间)或3-九(8.75小时每年的停机时间)。在讨论所需的启动时间时，您必须决定它是在24×365，还是在工作日的上午9:00到下午5:00，还是其他时间。您还需要确定所测量的停机时间是否包括用于维护/修补的预定停机时间，因为如果允许定期维护，则更容易满足大量的九次故障。

RPO代表恢复点目标.

简单地说，您可以将RPO看作是衡量损失了多少数据或工作是可以接受的。使用备份实现非常小甚至零的数据/工作损失相对容易，但取决于灾难发生时数据库遭受的损坏程度，恢复可能需要很长时间。例如，如果整个数据库被销毁，取决于数据库的体系结构和存在的备份，则可能需要大量时间才能恢复到灾难的程度。大多数RPO被定义为可能丢失工作的时间。例如，RPO可能是数据库应该在灾难发生后30分钟内恢复到一个点，这意味着可能会损失多达30分钟的工作。

一旦理解了上述概念，就需要制定备份策略。确保您的业务计数器与您的策略一致，特别是关于您可能丢失多少数据。请阅读我在参考文献中列出的关于规划复苏策略的文章。

参考资料：

1. 意外DBA (30天第7天)：备份:恢复模型和备份类型)，保罗·兰德尔
2. 数据库维护最佳实践第三部分-事务日志维护 (金伯利·特里普)
3. 意外DBA (30天第8天)：备份:规划恢复策略)，保罗·兰德尔
4. 意外DBA (30天)：备份:理解RTO和RPO)，保罗·兰德尔