商業應用程式有兩個主要指標：

這些需求是根據所使用的應用程式類型和業務資料性質而定義。如果您要在單一Azure地區防範故障、RPO和RTO可能會有所不同。如果您準備災難性災難、例如整個Azure區域的損失、也可能有所不同。評估定義RPO和RTO的業務需求非常重要、因為這些需求對可用的技術選項有重大影響。

SAP HANA的基礎架構（例如虛擬機器、網路和儲存設備）必須具備備援元件、才能確保沒有單點故障。MS Azure為不同的基礎架構元件提供備援功能。

為了在運算和應用程式方面提供高可用度、備用SAP HANA主機可透過SAP HANA多主機系統設定為內建高可用度。如果伺服器或SAP HANA服務發生故障、SAP HANA服務會容錯移轉至待命主機、導致應用程式停機。

如果伺服器或應用程式發生故障時無法接受應用程式停機、您也可以使用SAP HANA系統複寫做為高可用度解決方案、在極短的時間內實現容錯移轉。SAP客戶不僅使用HANA系統複寫來解決非計畫性故障的高可用度、也能將HANA軟體升級等計畫性作業的停機時間降至最低。

邏輯毀損可能是由軟體錯誤、人為錯誤或破壞所造成。遺憾的是、邏輯毀損問題通常無法透過標準的高可用度與災難恢復解決方案來解決。因此、視發生邏輯毀損的層級、應用程式、檔案系統或儲存設備而定、有時無法滿足RTO和RPO需求。

最糟的情況是SAP應用程式的邏輯毀損。SAP應用程式通常會在不同應用程式彼此通訊及交換資料的環境中運作。因此、還原及還原發生邏輯毀損的SAP系統並非建議的方法。將系統還原至毀損發生前的某個時間點、會導致資料遺失、因此RPO會大於零。此外、SAP環境也不再同步、需要額外的後處理。

與其還原SAP系統、更好的方法是透過在個別的修復系統中分析問題、嘗試修正系統內的邏輯錯誤。根本原因分析需要業務程序和應用程式擁有者的參與。在此案例中、您會根據邏輯毀損發生之前所儲存的資料、建立修復系統（正式作業系統的複本）。在修復系統中、所需的資料可匯出並匯入正式作業系統。使用這種方法、不需要停止生產系統、而且在最佳情況下、不會遺失任何資料或只會遺失一小部分資料。

建立備份以從不同的時間點資料集進行還原與還原。一般而言、這些備份會保留幾天至幾週。

視毀損類型而定、可在資料遺失或不遺失的情況下執行還原與還原。如果RPO必須為零、即使主儲存設備和備份儲存設備遺失、備份也必須與同步資料複寫結合使用。

還原與還原的RTO定義為所需的還原時間、還原時間（包括資料庫啟動）、以及將資料載入記憶體。對於大型資料庫和傳統備份方法而言、RTO很容易達到數小時、這可能是不可接受的。若要達到極低的RTO值、備份必須與熱待機解決方案結合使用、包括將資料預先載入記憶體。

相反地、備份解決方案必須解決邏輯毀損問題、因為資料複寫解決方案無法涵蓋所有種類的邏輯毀損。

RPO主要決定您應該使用哪種資料複寫方法。如果RPO必須為零、即使主儲存設備和備份儲存設備遺失、資料也必須同步複寫。不過、同步複寫有技術限制、例如兩個Azure區域之間的距離。在大多數情況下、由於延遲、同步複寫不適用於超過100公里的距離、因此這不適用於Azure地區之間的資料複寫。

如果可接受較大的RPO、則可在較遠距離使用非同步複寫。在此案例中、RPO是由複寫頻率所定義。

SAP HANA資料庫的啟動時間遠比傳統資料庫長、因為必須先將大量資料載入記憶體、資料庫才能提供預期的效能。因此、RTO的一大部分是啟動資料庫所需的時間。無論是任何儲存型複寫、或是HANA系統複寫（不需預先載入資料）、只要容錯移轉至災難恢復站台、就必須啟動SAP HANA資料庫。

SAP HANA系統複寫提供作業模式、可在次要主機預先載入及持續更新資料。此模式可實現極低的RTO值、但也需要專用伺服器、僅用於從來源系統接收複寫資料。