使用Amazon FSX for ONTAP Sfor Sf.進行備份與還原
建議變更
PDF
您可以使用NetApp Snapshot技術在幾分鐘內建立資料庫備份。
建立Snapshot複本所需的時間與資料庫大小無關、因為Snapshot複本不會在儲存平台上移動任何實體資料區塊。此外、使用Snapshot技術也不會影響即時SAP系統的效能。因此、您可以排程建立Snapshot複本、而不需考慮尖峰對話或批次活動期間。SAP與NetApp客戶通常會在一天內排程多個線上Snapshot備份、例如、每六小時一次就很常見。這些Snapshot備份通常會在一線儲存系統上保留三到五天、然後再移除或分層至較便宜的儲存設備、以供長期保留。
Snapshot複本也為還原與還原作業提供重要優勢。NetApp SnapRestore 支援還原整個資料庫、或是根據目前可用的Snapshot複本、將資料庫的一部分還原到任何時間點。這類還原程序只需幾秒鐘就能完成、不受資料庫大小限制。由於每天可以建立數個線上Snapshot備份、因此相較於傳統的每日一次備份方法、恢復程序所需的時間會大幅縮短。由於您可以使用Snapshot複本執行還原、而且快照複本最少只有幾小時的時間（而非24小時）、因此在轉送恢復期間必須套用較少的交易記錄。因此、RTO縮短至數分鐘、而非傳統串流備份所需的數小時。
Snapshot複本備份與作用中的線上資料儲存在相同的磁碟系統上。因此、NetApp建議使用Snapshot複本備份做為補充、而非取代次要位置的備份。大部分的還原和還原動作都是使用SnapRestore 主儲存系統上的功能進行管理。只有當包含Snapshot複本的主要儲存系統毀損時、才需要從次要位置進行還原。如果需要還原主要位置不再提供的備份、您也可以使用次要位置。
備份到次要位置的基礎是在主要儲存設備上建立的Snapshot複本。因此、資料會直接從主要儲存系統讀取、而不會在SAP資料庫伺服器上產生負載。主儲存設備會直接與二線儲存設備通訊、並使用NetApp SnapVault 功能將備份資料複寫到目的地。
與傳統備份相比、此技術提供顯著優勢。SnapVault在初始資料傳輸（所有資料都已從來源傳輸至目的地）之後、所有後續備份複本只會將變更的區塊移至次要儲存設備。因此、主儲存系統的負載和完整備份所需的時間會大幅減少。由於僅將變更的區塊儲存在目的地、因此任何額外的完整資料庫備份所耗用的磁碟空間都會大幅減少。SnapVault
Snapshot備份與還原作業的執行時間
下圖顯示客戶使用Snapshot備份作業的HANA Studio。映像顯示HANA資料庫（大小約4TB）使用Snapshot備份技術、在1分鐘20秒內備份、而使用檔案型備份作業則需4小時以上。
整體備份工作流程執行時間最大的一部分是執行HANA備份儲存點作業所需的時間、而此步驟取決於HANA資料庫的負載。儲存Snapshot備份本身一律會在幾秒鐘內完成。
恢復時間目標比較
本節提供檔案型與儲存型Snapshot備份的還原時間目標（RTO）比較。RTO是根據還原、還原及啟動資料庫所需的時間總和來定義。
還原資料庫所需的時間
使用檔案型備份時、還原時間取決於資料庫和備份基礎架構的大小、而備份基礎架構會以每秒MB為單位來定義還原速度。例如、如果基礎架構支援以250Mbps速度還原作業、則還原持續性資料庫時、大約需要4.5小時的時間、以4TB為單位。
有了儲存Snapshot複本備份、還原時間不受資料庫大小限制、而且一律在數秒內完成。
啟動資料庫所需的時間
資料庫開始時間取決於資料庫的大小、以及將資料載入記憶體所需的時間。在下列範例中、假設資料可以以1000Mbps載入。將4TB載入記憶體約需1小時10分鐘。檔案型與Snapshot型還原與還原作業的開始時間相同。
恢復資料庫所需的時間
恢復時間取決於還原後必須套用的記錄數目。此數字取決於資料備份的頻率。
使用檔案型資料備份時、備份排程通常每天一次。備份頻率通常無法提高、因為備份會降低正式作業效能。因此、在最糟的情況下、一天內寫入的所有記錄都必須在轉送恢復期間套用。
Snapshot備份通常會以較高的頻率排程、因為它們不會影響SAP HANA資料庫的效能。例如、如果每六小時排程一次Snapshot備份、則在最糟的情況下、還原時間是檔案型備份的恢復時間（6小時/ 24小時=.25）的四分之一。
下圖顯示每日檔案型備份與Snapshot備份的還原與還原作業與不同排程的比較。
前兩個長條圖顯示、即使每天使用單一Snapshot備份、由於Snapshot備份的還原作業速度加快、還原與還原作業也會減少到43%。如果每天建立多個Snapshot備份、則可進一步減少執行時間、因為在轉送還原期間需要套用的記錄較少。
下圖也顯示每天四到六個Snapshot備份最合理、因為較高的頻率對整體執行時間不再有重大影響。
加速備份與複製作業的使用案例與價值
執行備份是任何資料保護策略的關鍵部分。定期排程備份、確保您能從系統故障中恢復。這是最明顯的使用案例、但也有其他SAP生命週期管理工作、因此加速備份與還原作業至關重要。
SAP HANA系統升級是一個範例、說明升級前的隨需備份、以及升級失敗時的可能還原作業、對整體計畫性停機時間有重大影響。以4TB資料庫為例、您可以使用Snapshot型備份與還原作業、將計畫性停機時間縮短8小時。
另一個使用案例是典型的測試週期、測試必須在多個迭代上使用不同的資料集或參數。使用快速備份與還原作業時、您可以在測試週期內輕鬆建立儲存點、並在測試失敗或需要重複時、將系統重設為先前的任何儲存點。如此可讓測試提早完成、或同時進行更多測試、並改善測試結果。
實作Snapshot備份後、即可用於處理其他多種需要HANA資料庫複本的使用案例。有了FSXfor ONTAP Sf2、您就能根據任何可用Snapshot備份的內容來建立新的Volume。此作業的執行時間僅需數秒、與磁碟區大小無關。
最受歡迎的使用案例是SAP系統重新整理、其中需要將正式作業系統的資料複製到測試或QA系統。藉由運用FSXfor ONTAP S還原 複製功能、您可以在數秒內從正式作業系統的任何Snapshot複本中、為測試系統配置磁碟區。然後、新的Volume必須附加至測試系統、並還原HANA資料庫。
第二個使用案例是建立修復系統、用於解決正式作業系統中的邏輯毀損問題。在這種情況下、會使用正式作業系統的舊Snapshot備份來啟動修復系統、這是正式作業系統的相同實體複本、以及毀損發生之前的資料。然後使用修復系統來分析問題、並在必要的資料毀損之前匯出。
最後一個使用案例是能夠在不停止複寫的情況下執行災難恢復容錯移轉測試、因此不會影響災難恢復設定的RTO和恢復點目標（RPO）。當使用FSX for ONTAP the Sfor NetApp SnapMirror複寫將資料複寫到災難恢復站台時、正式作業Snapshot備份也可在災難恢復站台上使用、然後再用來建立新的磁碟區以進行災難恢復測試。
