数据库灾备系统包括：备份系统和容灾系统。两者实现原理和承担的作用是不同的。备份记录的是数据库一段时间的变化，用于恢复数据库到过去的某一个时间点时的状态，应对的场景主要是由于误删除、测试开发等原因需要把数据库恢复到某一个时间点的情况。容灾系统对应的是生产系统的实时或者准实时映像，应对的场景是在生产系统崩溃时及时把应用切换到容灾系统上，确保生产系统的持续运行。

俗话说：“养兵千日，用兵一时”，为了确保在关键时刻能够用备份系统或容灾系统快速恢复生产数据库的正常运行，平时必须做好足够的演练。所以，在进行数据库备份和容灾系统建设时，建设方都会为生产数据库系统建设一个数据库恢复测试环境。而数据库管理员日常的一个重要工作就是维护测试环境，并定期做数据库恢复测试和容灾数据库切换测试。测试系统维护工作主要有以下内容：检查灾备测试环境的存储是否足够，用于进行数据库灾备测试的环境不可能与生产环境一样，其CPU处理能力和内存可能会比生产系统要少，但其存储系统的大小一定不能低于生产数据库的数据文件的大小；检查操作系统版本是否满足要求，尽量保证测试环境的操作系统版本与生产环境一样，因为这样才能尽可能真实地模拟在真正的生产环境中做数据库恢复时可能会遇到各种问题；检查数据库软件版本是否满足要求，要保证测试环境的数据库软件版本与生产环境一样， 包括补丁程序；检查测试环境的日志中是否有报错信息，重点检查操作系统和存储系统的管理日志中是否有报错信息，如果有应该及时处理。

数据库备份恢复演练的最终目的是确保在将来的某个时刻，如果要进行数据库恢复操作时，能够快速、准确地在规定时间内恢复整个生产数据库。要不断通过针对各种数据库故障的恢复演练来完善数据库恢复方案。数据库备份恢复演练通常包括以下内容：恢复整个数据库，这个部分是用来检验整个生产数据库发生不可修复的故障后，是否能够利用数据库备份系统进行恢复；恢复部分数据文件，并且打开数据库，这个部分主要是用来应对部分数据文件受到损坏，仅仅需要在生产数据库上恢复部分数据文件的情景；将数据库恢复到过去的某个历史时刻，然后打开数据库，这个部分主要是用来应对某些人为“误操作”引起的数据丢失或修改的情景，不仅要把数据库的数据文件恢复出来，还要利用数据库日志文件将数据库修复至“误操作”之前。

在进行数据库恢复演练时，需要做如下记录：记录每个具体操作指令（包括具体的命令、参数等）；记录每个操作完成所需的时间；记录所有操作可能遇到的各种问题以及处理方法和处理时间；记录数据库恢复后的检查过程。将上述记录整理成恢复演练技术文档《数据库恢复技术方案》，供下次演练时参考。这也是今后在正式生产环境中做数据库恢复操作时的重要参考资料。

数据库恢复演练的步骤如下：为不影响容灾系统的正常工作，可以把容灾系统上的数据文件拷贝一份到测试环境中，这样，在进行切换演练时，就无须担心影响到容灾系统；在测试环境中停止数据同步操作，在打开容灾数据库前，需要停止容灾数据库的数据同步操作；在测试环境中打开数据库，将测试环境的数据库打开并假设作为生产数据库使用；将部分用于测试的应用终端连接到测试环境中，将用于测试的终端应用程序连接至测试环境的数据库上，在测试终端上测试各种关键应用；应用开发人员根据测试的切换时间，检查应用程序在这个时间点之后的业务操作是否正常；清理测试环境，将测试用的数据库从测试环境中清除；整理切换演练技术文档，将整个切换演练过程的所有操作命令、各个步骤所需时间等记录下来，并将其整理成《数据库容灾切换技术方案》。

数据库管理员的日常工作之一就是检查数据库灾备系统的运行是否正常。主要检查以下几个方面：①上次的数据库备份是否正常完成；②上次数据库备份所需时间是否正常；③备份系统的介质是否有报错信息；④容灾数据库与生产数据库之间的数据同步是否正常；⑤容灾端数据库的参数是否与生产数据库的参数匹配。

把检查灾备系统是否正常运行作为数据库管理员的日常运维工作是非常必要的。有一个非常大型的医院HIS系统出现了硬件故障，导致HIS数据库无法打开。当用户决定利用数据库备份进行恢复时，才发现备份系统早已报错，数个星期前就已经停止备份了。而且用户没有建设数据库容灾系统。虽然最终打开了HIS数据库，但是不可避免地丢失了很多数据，这些数据需要手工补录。

没有不出问题的生产数据库，数据库管理员总会遇到这样或者那样的情况，需要修复生产数据库，尽快恢复业务应用。其实，如果具备了前面提到的《数据库恢复技术方案》和《数据库容灾切换技术方案》，数据库管理员是不需要担心的。如果生产数据库真的出了非常严重的故障，数据库管理员只需按照已制订好的预案处理就行了。以下是关于数据库恢复和数据库容灾切换的实际操作流程：

1. 检查生产环境是否满足数据库恢复要求。硬件环境是否完好；存储空间是否足够；操作系统是否正常；数据库软件是否完备；备份软件是否正常。

2. 检查数据库备份情况。

3. 近期备份是否正常，确定利用哪次的数据库备份进行恢复；备份介质是否正常。

4. 开始恢复生产数据库，根据演练情况预估恢复时间；根据演练步骤进行数据库恢复操作。

5. 应用测试，测试生产数据库是否可用：检查生产数据是否可用；检查是否有数据需要手工补录。

6. 正式启动生产数据库和应用程序，通知各个科室可以正式使用业务操作；现场观察生产环境运行情况；做一次生产数据库的备份。

7. 容灾数据库切换流程  检查容灾数据库环境是否正常；重点检查容灾系统的数据库参数；检查容灾环境的存储。

8. 应用测试，将应用终端转接到容灾数据库上；检查容灾数据库的数据是否完备；检查应用的性能是否满足要求。

9. 正式切换数据库系统，将所有的医院客户端的数据库配置都转接到容灾数据库上；现场观察生产环境运行情况；对容灾数据库做一次数据库备份。

10. 修复原来的生产环境，将修复好的生产环境作为容灾端做数据同步；将修复好的生产环境作为容灾端，重新配置数据库容灾系统。

11. 将现有的生产数据库反向切换回修复好的生产环境，按照之前的步骤将数据库从容灾端切换回生产端。

PDCA循环（plan：计划；do：实施；check：检查；action：修正）是一个非常好的方法，可以用来检查灾备运维期间遇到的问题，然后调整灾备系统的策略和实施过程。需要关注以下问题：

（一）不注意检查灾备系统的运行状态

很多情况下都是灾备系统早已出现问题，用户在平时没有进行检查。结果在真正出现问题后，却发现灾备系统无法顶上。究其原因，一方面，是主观上重视不够，认为灾备系统只要建设好了就不用管它了。另一方面，医院信息化的人手不足，能够应付好平时的生产系统就很不错了。针对医院信息化的特点，建议使用专业的应用监控平台来监控生产和容灾系统的运行情况，一旦出现问题，这类监控平台会主动通知系统管理员。

（二）不进行数据库恢复测试

医院信息科的管理流程中没有关于数据库恢复测试的工作内容。甚至于在建设数据库容灾系统时也因为各种原因而没有实施数据库恢复测试，更不用说有具体的数据库恢复技术方案了。90%以上的数据库故障都可以在较短时间内恢复，前提是要有详细的数据库恢复方案。

（三）忽略容灾系统的硬件资源

因为资金限制，绝大多数医院在建设容灾系统时，仅仅考虑了数据不丢失或少丢失，并没有真正考虑到容灾系统的计算能力问题。对于三甲医院，容灾系统的计算能力至少应该是生产系统负载的110%以上。如正常的生产系统负载是50%，生产系统的CPU个数假设是10个。那么容灾系统的CPU个数应该不少于：10×50%×110%=6（个）。这样，如果容灾系统真正顶上作为生产系统使用，也有10%的资源空闲。

（四）不注意灾备系统的恢复时间和切换时间

因为平时没有做数据库恢复和切换演练，在真正出现数据库故障时，往往给不出大致的系统恢复时间。这会造成决策上的失误，没有使用正确的方法来恢复数据库，造成应用系统长时间不能恢复正常。

（五）不注意灾备系统本身为生产环境引入的风险

很多IT系统故障都是最近对系统做了改动，但是却没有注意到这些改动带来的风险而造成的。在建设容灾系统时，或多或少都会对生产系统做改动。无论这种改动多么小，都会为生产系统带来新的风险。在工程施工和日常运维中涉及现有生产系统的更改时一定要考虑风险分析和风险控制。