在一个数据恢复时间目标(RTO)中要考虑什么

    在与高层IT经理主管讨论数据恢复问题时，再三重复强调的是：人们很难准确地描述组织在发生重大停机事故的情况下恢复关键应用程序和交易业务的能力。他们相信关键数据是可以恢复的，而且他们正在寻找规律来证明这种可恢复性。

　　事实是，IT基础设施已经变得足够复杂。通过抽象层来消除这种复杂性以及聚合各种不同的组件以综合决定应用程序的可恢复性，这些都是一种挑战。取而代之，我们趋向于尝试确定单个组件的良好状况，希望总体的可恢复性等于各部分可恢复性的总和。

　　然而，并不一定是这种情况。首先，一个复杂应用程序的可恢复性涉及到很多活动部分，将这些活动部分都考虑在内很难做到。更重要的是，这些元件之间的同步成为了成功恢复的重要障碍。

　　在系统层上这个协调性问题通常很好理解，但是当处理包含多个应用程序组件的跨平台业务功能时，这个问题往往被忽视。事实上，在不同的时间拷贝或备份底层数据库能够增添不同的恢复天和恢复时段，而这样可以调和它们之间的矛盾。

　　夹杂着这个问题出现的是另一个问题是，在有些情况下，相互依赖的系统之间，在重要性的优先次序方面有所不同，从而导致采用的保护机制完全的不同。例如，数据库可能被认为是高优先权的，因此采用完全复制以支持一个4小时的时间恢复目标(RTO)，但是相关联的前端基于网络的应用程序组件可能被分配给一个基于磁带的恢复等级。对于灾难恢复情况下的操作恢复(如存储一个单一的卷或服务器)来说，这可能是完全可以接受的，但它可能导致的结果是用户将无法连接到一个运行中的数据库。(4小时RTO仅止这些。)

　　尽管某些不断涌现的技术可以在某种程度上帮助我们，但是今天对这个问题的阐述大部分仍旧停留在策略和过程上。其中的一个关键挑战是关于组织的。相互依赖的鉴定需要跨功能的协作。而推动这个协作需要具有一定权威的人来担当起业务功能层恢复的总体责任。将所有精力都专注于组件恢复上，这样的人通常是不存在的。