恢復時間目標(recovery time objective，RTO)是指在故障或災難發生之后，一臺電腦、系統、網絡或應用程序停止工作的最高可承受時間?；謴蜁r間目標是一項職能，用于評估災難擾亂正常運營的程度和災難在單位時間里所造成的收入損失。這些因素又取決于受影響的設備和應用程序。恢復時間目標(RTO)是以秒、分鐘、小時或天數來衡量的，它是災難恢復規劃(DRP)中的一個重要考慮因素。

　　為了確定在企業經營過程中各種應用停機所造成的損失，人們已經進行了無數的研究。這些研究表明，成本取決于長期和無形的影響以及當前的、短期的或有形的因素。一旦一個應用程序已經定義了恢復時間目標(RTO)，管理員可以決定哪些災難恢復技術最適合。例如，如果某一應用程序的恢復時間目標是一個小時，在外置硬盤上的多余數據備份可能是最好的解決辦法。如果恢復時間目標是5天，那么磁帶、可刻錄光盤(CD-R)或在遠程Web服務器上的異地存儲可能會更實用。

　　數據恢復時間目標(RTO)中要考慮什么

　　在與高層IT經理主管討論數據恢復問題時，再三重復強調的是：人們很難準確地描述組織在發生重大停機事故的情況下恢復關鍵應用程序和交易業務的能力。他們相信關鍵數據是可以恢復的，而且他們正在尋找規律來證明這種可恢復性。

　　事實是，IT基礎設施已經變得足夠復雜。通過抽象層來消除這種復雜性以及聚合各種不同的組件以綜合決定應用程序的可恢復性，這些都是一種挑戰。取而代之，我們趨向于嘗試確定單個組件的良好狀況，希望總體的可恢復性等于各部分可恢復性的總和。

　　然而，并不一定是這種情況。首先，一個復雜應用程序的可恢復性涉及到很多活動部分，將這些活動部分都考慮在內很難做到。更重要的是，這些元件之間的同步成為了成功恢復的重要障礙。

　　在系統層上這個協調性問題通常很好理解，但是當處理包含多個應用程序組件的跨平臺業務功能時，這個問題往往被忽視。事實上，在不同的時間拷貝或備份底層數據庫能夠增添不同的恢復天和恢復時段，而這樣可以調和它們之間的矛盾。

　　夾雜著這個問題出現的是另一個問題是，在有些情況下，相互依賴的系統之間，在重要性的優先次序方面有所不同，從而導致采用的保護機制完全的不同。例如，數據庫可能被認為是高優先權的，因此采用完全復制以支持一個4小時的時間恢復目標(RTO)，但是相關聯的前端基于網絡的應用程序組件可能被分配給一個基于磁帶的恢復等級。對于災難恢復情況下的操作恢復(如存儲一個單一的卷或服務器)來說，這可能是完全可以接受的，但它可能導致的結果是用戶將無法連接到一個運行中的數據庫。(4小時RTO僅止這些。)

　　盡管某些不斷涌現的技術可以在某種程度上幫助我們，但是今天對這個問題的闡述大部分仍舊停留在策略和過程上。其中的一個關鍵挑戰是關于組織的。相互依賴的鑒定需要跨功能的協作。而推動這個協作需要具有一定權威的人來擔當起業務功能層恢復的總體責任。將所有精力都專注于組件恢復上，這樣的人通常是不存在的。