恢复时间目标(recovery time objective，RTO)是指在故障或灾难发生之后，一台电脑、系统、网络或应用程序停止工作的最高可承受时间。恢复时间目标是一项职能，用于评估灾难扰乱正常运营的程度和灾难在单位时间里所造成的收入损失。这些因素又取决于受影响的设备和应用程序。恢复时间目标(RTO)是以秒、分钟、小时或天数来衡量的，它是灾难恢复规划(DRP)中的一个重要考虑因素。

　　为了确定在企业经营过程中各种应用停机所造成的损失，人们已经进行了无数的研究。这些研究表明，成本取决于长期和无形的影响以及当前的、短期的或有形的因素。一旦一个应用程序已经定义了恢复时间目标(RTO)，管理员可以决定哪些灾难恢复技术最适合。例如，如果某一应用程序的恢复时间目标是一个小时，在外置硬盘上的多余数据备份可能是最好的解决办法。如果恢复时间目标是5天，那么磁带、可刻录光盘(CD-R)或在远程Web服务器上的异地存储可能会更实用。

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

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

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

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

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

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

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