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

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

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

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

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

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

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

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

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