描述復原時間目標和復原點目標

已完成

了解復原時間和復原點目標對您的高可用性和災害復原 (HADR) 方案來說很重要,因為這兩者是任何可用性解決方案的基礎。

復原時間目標

復原時間目標 (RTO) 是在發生中斷或問題之後,可讓資源恢復的時間上限。 如果該程序所花費的時間超過 RTO,則可能會導致罰款和無法完成工作等等的後果。 您可以針對整個解決方案指定 RTO,包括所有資源及個別元件 (例如 SQL Server 執行個體和資料庫)。

復原點目標

復原點目標 (RPO) 是資料庫應該復原的時間點,也等於企業可接受的最大資料遺失量。 例如,假設包含 SQL Server 的 IaaS VM 在上午 10:00 發生中斷,而 SQL Server 執行個體內的資料庫具有 15 分鐘的 RPO。 無論使用哪一種功能或技術來復原該執行個體及其資料庫,我們皆預期最多會有 15 分鐘的資料遺失。 這表示資料庫可以還原至上午 9:45 或更晚的時間,以確保符合所制定 RPO 的最少或零資料遺失。 有幾個因素可判定該 RPO 是否可達成。

定義復原時間和復原點目標

RTO 和 RPO 的驅動因素是商務需求,但也會以各種技術和其他因素為基礎,例如管理員 (不只是 DBA) 的技能和能力。 雖然企業想要零停機時間或零資料遺失,但基於各種原因,這可能並不實際或難以達成。 解決方案的 RTO 和 RPO 應在所有相關人員經過開放且誠實的討論後決定。

RTO 和 RPO 的其中一個重要層面是瞭解停機的成本。 如果您定義該數字,以及停機或停用時對企業的整體影響為何,則定義解決方案就會比較容易。 例如,如果企業無法處理某項目,每小時可能會損失 $10,000 美元或遭到政府機關罰款,如此可測量的方式可協助您定義 RTO 和 RPO。 解決方案上的支出應與停機的數量或成本成比例。 如果您的 HADR 解決方案成本為 $X,但發生問題時,您只受到幾秒鐘的影響,而不是數小時或數天的影響,這表示您已回本。

從非商務的觀點來看,RTO 應定義在元件層級 (例如 SQL Server),並且針對整個應用程式結構定義。 只有顧好最弱的環節,才能提高從中斷情況復原的能力。 例如,如果 SQL Server 及其資料庫可在 5 分鐘內恢復運作,但應用程式伺服器需要 20 分鐘的時間才能達到相同程度,則整體 RTO 將會是 20 分鐘,而不是 5 分鐘。 SQL Server 環境的 RTO 仍是 5 分鐘,但仍不會變更整體的復原時間。

RPO 專門針對資料而設定,並且會直接影響任何 HADR 解決方案的設計,以及系統管理的原則和程序。 使用的功能必須同時支援所定義的 RTO 和 RPO。 例如,如果交易記錄備份的排程為每隔 30 分鐘一次,但 PRO 為 15 分鐘,則資料庫只能復原到最後一個可用的交易記錄備份,在最壞的情況下將是 30 分鐘前。 此時間假設的前提是沒有其他問題,且備份已經過測試且已知狀況良好。 當您難以測試環境中每個資料庫所產生的每個備份時,備份就只是檔案系統上的檔案。 如果沒有至少執行定期的還原作業,則無法保證這些檔案的狀況良好。 在備份過程中執行檢查,可為您提供一定程度的信心。

所使用的特定功能,例如 Always On 可用性群組 (AG) 或 Always On 容錯移轉叢集執行個體 (FCI),也會影響您的 RTO 和 RPO。 由於功能的設定方式不同,IaaS 或 PaaS 解決方案可能會或不會自動容錯移轉到另一個位置,而這可能會導致更長的停機時間。 藉由定義 RTO 和 RPO,支援該需求的技術解決方案可以設計成知曉時間和資料遺失的容許範圍。 如果這些要求並不實際,則必須據以調整 RTO 和 RPO。 例如,如果預期的 RTO 是兩小時,但備份需要三小時才能複製到目的地伺服器以進行還原,那麼您就會錯過 RTO。 在決定 RTO 和 RPO 時,您必須考慮這些類型的因素。

HA 和災害復原都應該定義 RTO 和 RPO。 HA 被視為區域化較高的事件,可讓您更輕鬆地從中進行復原。 高可用性的其中一個範例是,在 Azure 區域內,AG 會從一個複本中自動容錯移轉至另一個複本。 這可能需要幾秒鐘的時間,因此在這段時間中,您必須確保應用程式可以在容錯移轉之後進行連線。 SQL Server 的停機時間會縮減到最低。 本機 RTO 或 RPO 可能會以分鐘為單位來測量,這取決於解決方案或系統的重要本質。

災害復原類似於啟動全新的資料中心。 解決困境需要很多要件,SQL Server 只是其中一個元件。 讓一切恢復運作可能需要數小時或更久的時間。 這就是為何將 RTO 和 RPO 分開的原因。 即使許多用於 HA 和災害復原的技術和功能都相同,但所需的時間與投入程度可能不盡相同。

所有 RTO 和 RPO 都應定期或視需要來正式記錄及修訂。 記錄之後,您就可以考慮要在結構中使用哪些技術和功能。