一、故障类型
1、硬件故障
2、数据修改故障
●用户错误
●应用程序故障
●权限过多
3、软件故障
4、局部灾难
二、制定计划
应该为高可用性、备份/恢复和灾难恢复制定计划，可以为每一项活动单独制定计划，也可以为在单个文档中包含所有计划。在小公司中，这项任务可能会直接由 DBA 负责；而在大公司中，DBA 可能作为团队中的一员参与计划的制定。不管是小公司还是大公司，都需要进行风险/收益分析。必须考虑事件发生的可能性、宕机造成的损失、其他潜在的与这些事件相关联的损失和解决方案所需的成本。DBA 需要做的第一件事情是对风险、成本和收益进行研究，并写出研究报告。然后管理层决定为哪些事件制定计划并做出风险决策。需要指出的是，DBA 不是风险决策者——那是管理层的职责。但是确保管理层理解这个问题并做出决策就是 DBA 的任务。DBA还需要知道哪些计划是必须实现的，并且定期测试这些计划。
下面介绍备份/恢复计划和灾难恢复计划的基本知识。但是数据库高可用性不会介绍，因为高可用性可以单独成书了。
1、备份/恢复计划
对于备份/恢复计划，DBA 或他所在的团队的主要责任如下：
●分析业务需求
●根据恢复标准分类数据库
●用文档记录灾难恢复计划
●验证、实现和测试计划
●建立备份失败通知策略
●维护计划
<1>、分析业务需求
首先必须为计划收集一些需求，需要回答下列问题：
● 每个应用程序或数据库的干系人/所有人是谁？ 需要决定想哪些人提问题，还必须知道谁是核准最终计划的决策者。
● 这个数据库的用途是什么？ 了解数据库的用途，如数据库是否用做数据集市、数据仓库或一般的财务记账数据库等，将帮助标识哪些内容是计划必须的。
● 当发生错误(如磁盘驱动程序错误)时，应用程序/数据库可接受的宕机时间是多少？ 这也称为恢复时间目标(Recovery Time Objective，RTO)。由于当问题发生后需要时间来还原数据库，因此弄清楚这个问题有助于设计备份/恢复计划以满足宕机时间约束的要求。
通常这个问题的第一个答案是“任何宕机都是不可接受的”。这是业务中的常见答案。标准的响应方式是让公司知道，最终实现解决方案所需的成本可能会非常高。然后就可以围绕与解决方案相关的成本进行更有意义的对话。现在已经把各种选项与成本关联起来，从而开始逐渐靠近真正的需求。与管理层和业务用户之间的沟通是迭代的过程。
根据业务周期的不同，也有可能会得到多个答案。例如，财务部门在进行月底结算时发生宕机的代价是非常大的，而在这个月的其他时间段发生宕机的代价就比较小。DBA 可以为月末结算时间制定一份计划，其中可能会包含更频繁的日志备份，然后为这个月的其他时间制定不同的计划。也可以只制定一份计划，但是这份计划必须满足最苛刻的需求。无论选择何种方式，都需要把所有内容都文档化。
也许应该把这个问题分解为两个问题：宕机造成的损失是多少？处理这项业务的合理代价是多少？
● 哪些数据会发生变化以及变化的频率是多少？ 通过这个问题的答案来决定需要使用哪种类型的备份。可能只在夜间批处理时才修改数据，在其他时间只读取数据。也有可能只有一些表会被经常改变，其他表则不会发生改变。还有可能是存在大量的更新操作，但是这些更新操作只发生在一部分数据行上，而数据库中的其他数据行都是只读的。
如果数据库已经用于生产，那么调查一下事务日志的增长幅度，这样会提供一些有用的信息。
● 多少数据量的丢失是可接受的？ 这又是个比较难回答的问题，也称为恢复点目标(Recovery Point Objective，RPO)。数据的价值是多少？如果这些数据或其中部分数据丢失，那么公司造成的损害是什么？在考虑这个主题时，还必须考虑任何潜在的调整需求。一些数据在某一时间段内保持可用，一些业务对数据丢失的忍受能力较差，而一些业务可能能够忍受大量数据丢失。这不仅取决于数据的价值，还取决于业务所能够承担的风险。当然还需要考虑非 SQL Server 的解决方案。例如，业务可能无法接受任何客户订单的丢失，但是客户订单是手动输入的，可以保留客户订单的纸质副本。如果昨天的订单已丢失，那么可以重新输入这些数据。这可能是一种比较好的解决方案——也可能不是。要注意的是，需要考虑所有的业务选项，而不仅是 SQL Server 备份/还原。
这个问题的答案可能会随着时间的流逝而改变。如果因为流程过程发生改变或业务增长，那么业务需求可能也会发生改变。因此，可能需要修改备份/还原计划。定期检查业务需求，并且把每一次检查都文档化。
● 数据的规模和增长幅度是多少？ 如果还没有实现更改数据库，那么可能无法获取更多的信息，但还是要尽力获取相关信息来回答这个问题。对于已经实现的数据库，日常的监控过程会提供这些信息。还需要和正在使用数据库开发新项目的项目团队合作，他们提供的信息可能会改变此问题和其他问题的答案。
● 数据库的维护窗口是什么？ 诸如 Database Console Commands(DBCC)、索引维护和备份等特定的维护任务必须在数据库上运行，这会影响数据库的联机响应性能。在计划中必须确保这些任务是在维护窗口中执行的。
● 数据库的预算限制是多少？ 这个问题通常是没有特定的答案。相反，评估风险和代价是与公司协商的过程。但是存在特定的预算，就必须了解该预算。
● 数据库的通知计划是什么？ 当发生错误而必须通知谁呢？如何通知他们呢？此外，如何知道何时发生数据库错误呢？
<2>、根据恢复标准分类数据库
如果有很多数据库，那么可以对数据库进行分组以简化工作，然后可以为每一组制定一份计划。可以根据下列标准对数据库进行分组：
● 关键程度：数据库时任务中不可或缺的根据部分吗？
● 规模：大型数据库比小型数据库需要更多的时间来备份/还原，但是可以使用文件组备份或其他措施减少此时间。
● 易变性：为有大量数据需要修改的数据库制定的计划与为不活跃的数据库制定的计划是不同的。
完成分组之后，为这些组取一些有意义的名称。
从下列选项中为每一组数据库进行选择：
● 恢复模式：
完整：当不允许数据丢失时使用该模式
大容量日志：当数据库正在使用大容量日志恢复模式时，就对该组使用此模式
简单：当可以在完整备份之间承受数据丢失时使用该模式
● 备份计划：所有组都需要定期进行完整数据库备份，根据组的类别和恢复模式，需要选择不同的备份模式，如文件/文件组备份、日志备份等。还需要决定是否使用压缩以及使用什么媒介来储存备份。
● 备份频率：执行每一种备份的频率是多少？
● 备份安全策略：备份安全策略将详细描述保留备份的时间以及电子和/或物理保护备份安全的方式。磁带媒介的旋转策略是什么？如何实现非现场存储？如果使用磁盘间备份(使用外部的 D2D 设备)或磁盘上的备份(将备份写入一组单独的本地磁盘)，那么如何确保对备份文件存储的安全访问？
2、灾难恢复计划
灾难恢复计划需要非常详细的计划。局部灾难可能会为组织带来非常严重的经济损失。为了减少损失，组织必须能够快速地执行灾难恢复计划(DR)计划以使系统联机。这需要有健壮的灾难恢复计划以及定期进行 DR 演习以确保所有事情都在计划之内。通常组织会有定义良好的灾难恢复计划，但是他们从来不会测试这些计划能否应付灾难。因此，当真正发生灾难时就无法很顺利地执行计划。DR计划是以特定组织的业务需求为基础的，但是其中有一些通用的部分需要在制定计划前加以考虑。
● 使用项目管理软件，如 Microsoft Project，可以向软件中输入人员、资源、硬件、软件以及任务和任务的完成时间，以让软件提供系统化的方法来管理任务、资源和关键路径。
● 为恢复的详细步骤开发检查列表。
通常会使用带 Windows 故障转移群集的灾难恢复解决方案以在数据中心站点上提供硬件的冗余性，并且可以使用地理上分散的 Windows 故障转移群集来在多个数据中心上配置灾难恢复解决方案。在 Windows Server 2008 发布之前，这需要采用昂贵的基于 SAN 的解决方案。Windows Server 2008 减少了与子集和心跳延迟相关的各种限制，从而可以更加方便地实现地理上分散的群集。然而，这仍然是相当复杂而昂贵的选项。此外，AlwaysOn 可用性组、数据库镜像、复制和日志传送都可以作为廉价的灾难恢复解决方案进行部署。
一些组织还会使用后备灾难恢复解决方案以接管所有的操作，或者至少接管任务关键的操作。其中一些组织还会定期地故障转移到灾难恢复站点以验证他们的计划在真正的灾难中能否正常工作。其他一些组织可能自己没有灾难恢复计划，但是他们与另一个提供灾难恢复服务的公司之间有服务协议。
如果要实现灾难恢复站点，需要在 DR 站点间有兼容的硬件。如果还没有可用的硬件，那么用户需要为如何获取这些能够使组织的系统更快联机的硬件制定计划，并把所需的硬件记入文档中。如果是计算机，那么需要考虑CPU的数据和类型、速度、使用Inter 还是 AMD、超线程、核心数量、磁盘驱动器容量、RAID级别以及所需物理内存数量。最好使用相同同样的硬件规格以降低发生意外的可能性。如果考虑存储子系统，那么需要考虑磁盘空间需求、所需的LUN数量、RAID级别。如果是网络，那么最好配置类似的网络基础设施以维持同样的性能。
一些需要回答的问题如下：
●要多少时间才能获取计算机？谁会提供这些硬件？
●这些计算机已经预先配置好了吗？是否需要 DR 团队来配置这些计算机？谁会提供专业技能以及这些人力资源什么时候可用？
●存储设备是预先配置好LUN和RAID级别的吗？是否需要 DR 团队来配置存储设备？谁会提供专业技能以及这些人力资源什么时候可用？
●谁会提供网络设备？谁具有安装和配置网络设备的专业技能？
●DR 站点能够访问 Internet 以下载服务包、补丁和发送电子邮件吗？
为所有需要的软件、补丁和服务包制定详细的列表，并为 DR 团队如何获取这些软件制定目录清单。确保软件满足版本需求和许可证并有效。确定谁负责提供这些软件以及相关人员的联系方式。如果入科存放在某个特定的位置，那么需要了解谁有存放地的钥匙以及他的访问权限。如果软件中需要 24/7 的访问权限，当发生灾难时，DBA 需要联系一系列的相关人员，必须确保这些相关人员的联系方式是最新的，因此需要定期更新他们的联系方式。了解谁应该负责负责维护联系人列表以及当发生灾难时在哪里能够找到该列表。还需要知道指挥链已经谁是现场和非现场人员。
此外，还需要为执行计划所需的现场角色创建详细的计划及确定谁担当这些角色。确保存在备份资源以防止某个人力资源不可用。人员如何到达 DR 站点？确定每个角色需要多少人员以及谁是整个项目的管理者或谁讲负责处理所有问题。分配和记录使系统提供业务服务所需的登录名(具有相应的密码)。
为了确保DR计划能够在真正的灾难中正常工作并降低损失，作为一项最佳实践，需要定期进行灾难演习并执行 DR 计划以发现任何没有考虑到的步骤，了解要经过多长时间才能是组织的系统再次联机以及哪些地方可以流水线化以加快整个过程。最重要的是确保计划能够按预期顺利、快速地执行。为了从模拟方案中获取最大的效果，所有人都应该把演习当成真正的灾难并且按计划执行所有操作。
3、创建灾难恢复计划
要创建灾难恢复计划，首先要收集一些重要的信息。第一项是拜访任何应用程序的业务所有者，这些应用程序使用受你控制的数据库。需要从中找出发式灾难时这些业务所有者的具体需求，借助该信息可以将受你控制的数据库分类为不同的灾难恢复选项。这种分类可以简单的分为“需要灾难恢复的数据库”和“不需要灾难恢复的数据库”。或者，如果每个人都需要灾难恢复，但是一些系统需要立即运行，而其他系统可以在灾难恢复站点中联机之前保持几个小时、几天、几个星期的宕机，这可能是另一种分类数据库的方式。
此外，需要一个文档，它应该包含下列选项：
●联系列表
●决策树
●恢复成功的标准
●密钥、备份、软件和硬件的存放位置
●基础设施文档
需要为能够声明和激活紧急呼叫的管理人员创建联系列表，其中应该包含所有可能用到的联系信息。确保紧急情况下联系到这些人员。还需要建立备用的联系点，以防意外情况下联系不到某人，需求某人的帮助，这个人并不能启动灾难恢复计划。
决策树指定了具体情况所应执行的操作，可以为灾难恢复单独制定决策树，而不是使用普通恢复的决策树。当灾难发生并且任务关键的进程无法工作时，情况就非常紧急。决策树会提示你，因此你在大多数情况下只需要遵循决策树的计划，就不会在匆忙的情况下出错。由于决策树是在非常紧急的情况下使用的，因此必须具有逻辑性、清晰、易于理解和遵循。决策树应尽量简单以便完成其计划，同时仍然要包括足够多的内容一涉及大多数情况。
决策树需要对数据库丢失情况分类、必须涉及单点丢失。还应分类普通恢复情况，应该在不影响其他系统的前提下，快速恢复丢失的数据。还需要包含一项性能或服务的丢失、需要区分恢复步骤的优先次序、标识至关重要的数据库、标识出关键的进程、还可以包含安全故障。
可以对恢复成功的标准进行分级：
恢复时间目标(RTO)：恢复时间目标是个时间量，当灾难发生后，必须在此时间内将特定系统还原到恢复运行。 8小时的 RTO 意味着受影响的系统必须在灾难发生后 8 小时内恢复运行。
恢复点目标(RPO)：恢复点目标是灾难发生后系统丢失数据量的指标。8小时的 RPO 意味着丢失前 8 小时内输入的任意数据是可以接受的。
确保理解这些标准并记录文档中，以后可能会使用这些标准来衡量恢复是否成功。
文档还应该包含基础设施文档：如命名约定、DNS和网络信息等——完成作业所需的任何信息。
根据业务需求列出恢复步骤的正确次序。不要认为在宕机时还能冷静地思路并快速做出最佳的决策。提前做出所有基本决策，这样宕机发生时就只需遵循文档中的过程了。
<1>、验证、实现和测试计划
与获取恰当的业务信息相比，该任务并没有那么难，因此不用担心。如果能够准确地获取业务需求，那么通常实现备份/还原计划是非常简单的。当然，如果该计划无法工作的话，那么这也不是一份优秀的计划，但是在测试前是无法知道该计划能否正常工作的。
需要实现这份计划的人应该先通过测试定期进行实践。你应该计划常规的测试。在一些总所周知的时间段内进行测试，可能是每隔6个月测试一次。当对系统的改动需要修改计划时，也要进行测试。确保任何新的职员都理解这些计划。理想情况下，让新的职员接受培训，培训内容至少包括讨论这些计划，最好是针对灾难场景实际地完整执行一次这些计划。从上一次计划的测试以来，只要有大量的职员变动，就应该运行另一次测试。
确保测试包括建立备用服务器、完成还原过程和使应用程序/数据可用。还需要模拟故障的情形，并测试故障的响应计划。可模拟的故障包括最近完整备份的丢失或事务日志的丢失。还需要考虑诸如还原站点处于不同的时区或数据库的规模可能比以前要大得多等情形。如果关键人员不响应或联系列表不准确，那么该怎么办呢？如果门卡失效或钥匙失效了，那么该怎么办？
<2>、备份失败时通知策略
由于计划的成功依赖成功的备份，因此需要制定计划以备份失败时收到通知。记住，直到将备份复制到独立的服务器、进行还原并检查其有效性之后，你才拥有备份，因此定期还原备份和进行验证应该是你的计划的完整备份。
还需要使用 DBCC 命令来确保备份的数据库是能够正常工作的数据库。此外，数据库备份工作应该在其他的日常维护任务完成(如数据库收缩和索引维护)之后进行。这样做的原因是当从数据库备份还原时，被还原的数据库就可以立即投入使用，而不需要额外的维护工作。
4、维护计划
要成功地维护计划，就需要遵循下面 4 个步骤：
● 传达计划：为了有效的传达计划，公司内的任何人都应该能够访问这份文档，并且需要向 IT、业务用户以及管理层告知计划的内容和位置。
● 建立策略以定期演习计划：策略应该要求定期演习计划。一些公司每两年进行一次演习，而其他公司每年进行一次演习。当然也可以每年在全公司演习一次，而在 IT 部门的测试相对频繁一些。不管是哪种情况都需要按时测试这份计划。基础设施的改变以及软件和硬件的更新都可能会使计划变得不可用。虽然到现在为止 DBA 可能非常努力地练习计划中的步骤，并且非常完美地完成了演习，但是当灾难真正发生时，能否真正地恢复数据库是考核 DBA 的唯一方式，而不会考虑 DBA 制定的计划是多么完美。演习是确保成功的唯一方式。
● 建立策略以定期验证计划：定期验证计划的策略主要是考虑到一直变化的业务环境。可能会发生变化的业务过程、吸收风险能力或意愿的变化以及其他一些因素都可能使计划无效。需要重新验证从业务中收集到的信息，并且按时重新评估计划。此外，还需要关注新项目以及它们对计划的影响。
● 根据需要修正计划：最后的要求是保持计划处于最新状态。定期查看计划，然后根据需要修正计划。提出计划后又搁置的情况是相当常见的。这通常使计划变得没有任何用处，甚至更糟糕的是使用该计划可能会相当危险。
不过感觉上述内容都是财大气粗的公司才来操作的，还是留存吧！
--以上是摘抄的笔记，书籍是宋沄剑的《SQL Server 2012 管理高级教程(第2版)》