了解如何使用NetApp Snapshot 技術保護 SAP HANA 數據
建議變更
PDF
了解NetApp Snapshot 技術如何保護 SAP HANA 資料庫，無論資料庫大小，都能在幾分鐘內完成備份。了解如何使用快照副本、 SnapRestore進行快速復原以及使用SnapVault或Azure NetApp Files備份進行複製以實現二次保護的備份和復原策略。
如今，企業需要其 SAP 應用程式持續、不間斷地可用。他們期望系統效能保持穩定，並且面對不斷增長的資料量和例行維護任務（例如係統備份）的需求，他們需要自動化的日常操作。對 SAP 資料庫進行備份是一項關鍵任務，可能會對生產 SAP 系統的效能產生重大影響。
備份視窗期越來越短，而需要備份的資料量卻不斷增加。因此，很難找到一個既能執行備份又能最大限度減少對業務流程影響的時間。恢復 SAP 系統所需的時間是一個令人擔憂的問題，因為必須最大限度地減少 SAP 生產和非生產系統的停機時間，以降低企業的成本。
使用快照備份進行備份和還原
您可以使用NetApp快照技術在幾分鐘內建立資料庫備份。建立快照副本所需的時間與資料庫的大小無關，因為快照副本不會移動儲存平台上的任何實體資料區塊。此外，由於所有操作都在儲存系統中執行，因此使用快照技術不會對即時 SAP 系統的效能產生影響。因此，您可以安排建立快照副本，而無需考慮對話高峰期或批次活動期。SAP on NetApp客戶通常會在一天內安排多次線上快照備份；例如，每六小時備份一次很常見。這些快照備份通常會在主儲存系統上保留三到五天，然後被刪除或分層儲存到更便宜的儲存系統中以進行長期保留。
快照副本也為復原操作提供了關鍵優勢。復原作業會根據備份狀態將檔案系統中的資料還原為原狀。復原作業是利用資料庫日誌備份將資料庫狀態回滾到某個時間點。
NetApp SnapRestore技術能夠根據目前可用的快照備份還原整個資料庫，或只恢復資料庫的一部分。無論資料庫大小如何，復原過程都會在幾秒鐘內完成。由於一天內可以建立多個線上快照備份，因此與傳統的每天一次準備方法相比，復原過程所需的時間大大減少。因為可以使用最多只有幾個小時（而不是最多 24 小時）的快照副本執行還原，所以在向前恢復期間需要應用的交易日誌更少。與傳統串流備份相比，復原和還原所需的時間顯著減少。
由於快照備份與活動線上資料儲存在同一磁碟系統上， NetApp建議將快照副本備份作為補充，而不是替代備份到輔助位置。大多數的恢復操作都是透過在主儲存系統上使用SnapRestore來管理。只有當包含快照副本的主儲存系統不可用時，才需要從輔助位置進行復原。如果需要恢復主儲存裝置上不再可用的備份，也可以使用輔助備份。
備份到輔助位置是基於在主儲存體上建立的快照副本。因此，資料直接從主儲存系統讀取，不會對 SAP 資料庫伺服器及其網路造成負載。主儲存直接與輔助儲存通信，並使用SnapVault或 ANF 備份功能將備份資料複製到目標位置。
與傳統備份相比， SnapVault和 ANF 備份具有顯著優勢。在初始資料傳輸（即所有資料從來源傳輸到目標）之後，所有後續備份僅將變更的資料區塊複製到輔助儲存。因此，主儲存系統的負載和完整備份所需的時間都顯著減少。由於目標位置只儲存已變更的資料區塊，因此任何額外的完整資料庫備份都會佔用較少的磁碟空間。
Snapshot備份與還原作業的執行時間
下圖顯示了客戶的 HANA Studio 使用快照備份作業的情況。影像顯示，使用快照備份技術備份 HANA 資料庫（大小約 4TB）僅需 1 分 20 秒，而使用基於檔案的備份作業則需要 4 個多小時。
在整個備份工作流程執行時間中，執行 HANA 資料庫快照作業所需的時間佔比最大。儲存快照備份本身只需幾秒鐘即可完成，與 HANA 資料庫的大小無關。
恢復時間目標比較
本節對基於檔案的快照備份和基於儲存的快照備份的復原時間目標 (RTO) 進行了比較。RTO 定義為恢復資料庫、重新啟動資料庫以及啟動資料庫所需的時間總和。
還原資料庫所需的時間
使用檔案型備份時、還原時間取決於資料庫和備份基礎架構的大小、而備份基礎架構會以每秒MB為單位來定義還原速度。例如、如果基礎架構支援以250Mbps速度還原作業、則還原持續性資料庫時、大約需要4.5小時的時間、以4TB為單位。
使用NetApp快照備份，復原時間與資料庫大小無關，始終在幾秒鐘的範圍內。
恢復資料庫所需的時間
恢復時間取決於還原後必須套用的記錄數目。此數字取決於資料備份的頻率。
使用檔案型資料備份時、備份排程通常每天一次。備份頻率通常無法提高、因為備份會降低正式作業效能。因此、在最糟的情況下、一天內寫入的所有記錄都必須在轉送恢復期間套用。
快照備份通常會安排更高的頻率，因為它們不會對 SAP HANA 資料庫的效能產生任何影響。例如，如果快照備份每六小時進行一次，最壞情況下，如果故障發生在建立下一個快照之前，則需要套用最後六小時的日誌。最壞情況下，需要對每日文件進行備份，並保存最近 24 小時的日誌。
啟動資料庫所需的時間
資料庫開始時間取決於資料庫的大小、以及將資料載入記憶體所需的時間。在下列範例中、假設資料可以以1000Mbps載入。將4TB載入記憶體約需1小時10分鐘。檔案型與Snapshot型還原與還原作業的開始時間相同。
恢復和回收樣品計算
下圖顯示了使用每日檔案備份和不同排程的快照備份進行復原作業的比較。
前兩個長條圖顯示、即使每天使用單一Snapshot備份、由於Snapshot備份的還原作業速度加快、還原與還原作業也會減少到43%。如果每天建立多個Snapshot備份、則可進一步減少執行時間、因為在轉送還原期間需要套用的記錄較少。
下圖也顯示每天四到六個Snapshot備份最合理、因為較高的頻率對整體執行時間不再有重大影響。
加速備份與複製作業的使用案例與價值
執行備份是任何資料保護策略的關鍵部分。定期排程備份、確保您能從系統故障中恢復。這是最明顯的使用案例、但也有其他SAP生命週期管理工作、因此加速備份與還原作業至關重要。
SAP HANA 系統升級就是一個例子，升級前進行按需備份以及升級失敗時進行可能的復原操作，會對整體計畫停機時間產生重大影響。以 4TB 資料庫為例，使用基於快照的備份和復原操作，您可以將計劃停機時間減少 8 小時，或者您可以多出 8 小時來分析和修復錯誤。
另一個應用場景是典型的測試週期，其中必須使用不同的資料集或參數進行多次迭代測試。利用快速備份和復原操作，您可以在測試週期內輕鬆建立保存點，並在測試失敗或需要重複測試時將系統重置到任何先前的保存點。這樣可以提前完成測試，或同時進行更多測試，從而提高測試結果。
實作快照備份後，它們可以用於解決其他多個需要 HANA 資料庫副本的用例。您可以基於任何可用快照備份的內容建立新磁碟區。此操作的運行時間為幾秒鐘，與磁碟區的大小無關。
最常見的用例是 SAP 系統刷新，即需要將生產系統中的資料複製到測試或 QA 系統中。利用ONTAP或 ANF 克隆功能，您可以在幾秒鐘內從生產系統的任何快照副本為測試系統配置磁碟區。然後必須將新磁碟區連接到測試系統，並還原 HANA 資料庫。
第二個用例是建立修復系統，用於解決生產系統中的邏輯損壞。在這種情況下，使用生產系統的較早快照備份來啟動修復系統，該系統是生產系統的完全相同的克隆，包含損壞發生之前的資料。然後利用修復系統分析問題，並在資料損壞之前匯出所需資料。
最後一個用例是能夠在不停止複製的情況下執行災難復原故障轉移測試，因此不會影響災難復原設定的 RTO 和復原點目標 (RPO)。當使用ONTAP SnapMirror複製或 ANF 跨區域複製將資料複製到災難復原站點時，生產快照備份在災難復原站點也可用，然後可以用於建立新磁碟區以進行災難復原測試。
