HANA System 的備份與還原
System & DB backup and recovery
Persistence Layer
為了讓HANA 在重新起動服務或因為任何不正常的因素重開機時回復到最後一筆成功的資料交易狀態。我們需要 persistence layer;也就是 storage layer來完成這件事。
通常HANA system的DB會被分為兩部分(Data and log)分別儲存在不會互相影響I/O performance 的storage中以便能達到高效能的要求。
如上圖，其中 Data 區域儲存的大部分是System Data/Application data/Undo log等資訊而且都是在Memory上運作，透過"Async非同步"模式將資料寫入DISK. 而Log 部分則是資料在Memory上有任何異動時該筆交易資料的Log則會"同步"寫入DISK。為了維持這種高效要求，DISK通常都是SSD之類的HD。
而SavePoint則可以視為一段時間的整體完整資料寫入DISK中(預設是每五分鐘寫入一次，這個時間點是可以調整的)
HANA System透過定期的savepoint 資料加上 transaction log回復到最後一筆成功交易資料的方式就跟其他所有的DB是一樣的。
哪為什麼要做備份呢?大概有以下幾點
1. 硬體損壞，你的storage可能完全損毀。連RAID都掛了。
2. DB有邏輯上的問題，可能是資料庫檔案壞了。
3. 人為錯誤，可能是交易資料寫錯了需要回復。
為了避免這些問題所以需要將DB做備份，而備份的範圍就包含了上面所講的， Data and Log的部分。而通常裡面包含如下的資料
- User Data
- System topology
- Data models
- Secure Store (SSFS)
每一個HANA System的Service 都有自己的 Data and Log需要備份
備份的時間順序可參考下圖
HANA支援下列的備份模式
●Full backup
●Delta backup
●Redo log backups
●Backup and recovery using third party tools
●Integrity checks for backups
●Backup lifecycle management
●Recovery to the most recent state
●Recovery to a specific point in time
●Recovery to a specific data backup
●Database copy using backup and recovery
備份可以用以下工具
-SAP HANA cockpit
-SAP HANA studio
-DBA Cockpit
-SQL commands
這邊要另外提及Log的backup，我們在其他篇提及log的模式有normal and overwrite。在Overwrite模式下是無法做log backup的，另外若你在該DB執行第一次的full backup, HANA會把log 模式自動轉到normal mode.
另外備份時有一些地方需要特別注意
1.備份工作執行時， DB是online的。
2. 確認所有的HANA服務都是啟動中的。
3.備份的過程中對系統的效能影響是很小的
4. 只有正在使用中的資料會有備份，意思是未使用中的資料或是 data block是空值的話是沒有備分的。
5. 若前一個備份工作沒有完成，若再繼續第二個備份工作則第二個工作會被系統終止並繼續執行前一個備份工作。
6. HANA的備份是 full的DB，是無法備份個別的object的。
7. 可以用SQL Command 做 DATA的snapshot(可利用 Cockpit or HANA studio還原)
8. SAP 在備份功能有開放經過SAP驗證的第三方備份軟體(在設定HANA的備份tasks時可以選擇 Backint的介面)。
備份與還原的權限，參考下圖
基本上, 要backup只要有 backup operator的權限即可，但需要還原的話就需要有<sid>admin或是 DB admin權限。
另外有幾個SAP Notes可以參考
1. Nots 1730932 — 使用backint介面備份
2. Notes 2444090 — 備份加密
還原的注意事項
1. 資料還原時無法還原在原來系統的更低階的軟體版本。
2. 還原時 DB需要offline。
3. System DB的還原。
3.1 system DB需要先還原後才可以還原tenant DB。
3.2 system DB只有在損毀時才需要還原。
3.3 如果只有tenant DB損毀，哪system DB是不需要還原的。
3.4 還原system DB在特定的時間點(point-in-time)只能用SQL command的方式
最後是還原system DB時，tenant DB一定是無法運作的。但還原特定的某一個tenant DB(雖然它offline)但system DB是online的。也就是說其他的tenant DB還是online可用的。
4. 使用cockpit還原 tenant DB只能有point-in-time的還原，而system DB則是最後一筆成功的交易。若要還原system DB到point-in-time則需要使用recoverSys.py 這個tool.
備份的策略
Multitenant DB
System and tenant DB可以獨立各別備份,而tenant DB可透過system DB來備分。備份的資料有這三個部分，如下圖
備份的資料型式有幾種
1. Full 完整備份
2. Delta
2.1 Differential 差異備份
2.2 Incremental 增量備份
3. Redo log
這些備份的方式跟其他的DB是一樣的在此不多做解釋。特別說說明Differential / Incremental backup 是無法用在snapshot的還原作業的。
另外資料還原的狀況可能有
1. 回到最後一筆成功的資料交易
2. 回到特定的時間點(point-in-time)
3. 來自特定的備份檔案
4. DB copy
使用cockpit 執行備份作業(示意圖如下)
使用 SQL command 備份
語法: BACKUP DATA USING FILE <path><prefix>
範例
Full Backup Tenant DB
> BACKUP DATA USING FILE(‘/usr/sap/HD01/HDB01/backup/data/DB_HD1/’,’2020_11_217_14_20_39' ) ASYNCHRONOUS
Differential Backup Tenant DB
> BACKUP DATA DIFFERENTIAL USING FILE (‘/usr/sap/HD01/HDB01/backup/data/DB_HD1/’,’2020_11_217_14_20_39')ASYNCHRONOUS
Incremental Backup Tenant DB
> BACKUP DATA INCREMENTAL USING FILE (‘/usr/sap/HD01/HDB01/backup/data/DB_HD1/’,’2020_11_217_14_20_39')ASYNCHRONOUS
使用Data Snapshot的注意事項
對storage 的DATAy在特定時間點做snapshot，因為這樣的關係所以對整個系統的影響非常小(因為只有sotrage layer會影響到)所以回復資料也非常快。
1. 可以恢復system DB 及一個以上的Tenant DB
2. system DB and Tenant DB一次只能一個DB回復，且要先回復 System DB.意思是你無法使用一次性的恢復工作作業完成所有DB的恢復。一次一個的來。
3. 只用snapshot的資料也可以搭配 delta and log 檔案來恢復到特定的時間點或到最後一筆成功交易的時間點。
4. 若原來的架構是 single-container 無法恢復到 multitenant 的架構。
Log 的備份
之前提到log的寫入有 normal and overwrite mode, normal mode如下圖的運作方式
我們可以看到這樣的模式是一群log file的循環，哪與overwrite mode的比對是這樣
所以在overwrite的狀況下我們只能使用data做還原而沒有辦法加上log file。也就是還原的時間點只能看這一個data 的savepoint是何時發生的。
假設正常的狀況下我們要怎麼備份呢?通常會是full/Delta/log交互使用以達到資料不遺失發生
哪還原時呢?
1. 若回到最後一筆成功的交易時間點，我們需要的備份資料會有
Full backup + + last differential backup + + subsequent incremental backups + + subsequent log backups + + redo log from log area
2. 特定時間點
如上，不一樣的是redo log的時間點
還原時的注意重點
1. DB要是shutdown
2. 要有DATABASE_ADMIN的權限
3. 來源與目的端要有相同的軟體版本/設定
4. 若還原地的SID and Hardware ID跟原來backup的不一樣，哪license key會失效(系統會立即被鎖住不能用或是備份檔備份到的license key是無效的恢復倒也會被馬上鎖住)
備份檔案的檢查
SAP提供了兩個tool(在OS layer)執行備份出來的檔案
1. hdbbackupcheck <backup_name>
這主要是檢查備份檔有沒有毀損
2. hdbbackdiag
這個是在檢查在做回復時所需的所有檔案是不是可用的與完好的。防止我們在做還原時有某個檔案損壞造成還原作業失敗.通常若還原失敗HANA會再重新再嘗試一次還原作業。
為防止還原時因某一個備份檔損壞重來一次備份而造成時間的浪費，我們還可以設定fallback,也就是在執行一連串的備份檔案還原中每次一個相關的備份被還原成功後，我們就可以設定fallback讓之前沒問題的還原檔案不用重跑一次，直接從失敗的還原檔案開始。
提及哪麼多，我們就可以依情況所需來挑選要怎樣的備份，可參考以下比較表
可以看到的是，我們若要backup/recovery的資料精細度越細所耗費的資源就會越多。
