適用於資料庫一致性快照集的增強型前置-後置指令碼
Azure 備份服務已提供前置-後置指令碼架構，以便使用 Azure 備份在的 Linux VM 中達成應用程式一致性。 這包括了在取得磁碟快照集之前先叫用備份前置指令碼 (用以讓應用程式靜止)，並於手照完成後再呼叫備份後置指令碼 (用以解除應用程式靜止狀態的命令)，以便將應用程式回覆至正常模式。
製作、偵錯以及維護前置/後置指令碼的工作可能深具挑戰性。 為了要消除此一複雜性，Azure 備份已為常用的資料庫提供了簡化版的前置/後置指令碼體驗，方便使用者以最少的負擔取得應用程式一致性快照集。
新的增強型前置-後置指令碼架構具有以下主要優點：
- 這些前置-後置指令碼已直接與備份延伸模組安裝於 Azure VM 之中。 這種安排有助於省去在外部位置製作後再行下載的動作。
- 您可以在 GitHub 中查看前置-後置指令碼的定義和內容，甚至提交建議與變更。 您可以透過 GitHub 來提交建議和變更，而所提的建議和變更在經過分級和新增後，就能讓更多社群成員受益。
- 您甚至可以透過 GitHub 為其他資料庫新增前置-後置指令碼，這些指令碼在經過分級和整理後，就能讓更多社群成員受益。
- 強固的架構可以有效率地處理各種案例，例如，前置指令碼執行失敗或損毀。 不論如何，後置指令碼都會自動執行，以復原前置指令碼所完成的變更。
- 該架構同時也提供了外部工具擷取更新所需的傳訊通道，並已對任何訊息/事件準備了其專屬的行動計劃。
方案流程
支援矩陣
以下是增強型架構中所涵蓋的資料庫清單：
- Oracle (正式推出) - 支援矩陣的連結
- MySQL (預覽)
必要條件
您只需要修改 /etc/azure 中的組態檔 (workload.conf)，即可提供連線詳細資料。 這可讓 Azure 備份連線至相關的應用程式，並執行前置和後置指令碼。 組態檔有以下參數。
[workload]
# valid values are mysql, oracle
workload_name =
command_path =
linux_user =
credString =
ipc_folder =
timeout =
下表描述參數：
| 參數 | 必要 | 說明 |
|---|---|---|
| workload_name | Yes | 此參數中會含有您要進行應用程式一致性備份的資料庫名稱。 目前支援的值包括 oracle 或 mysql。 |
| command_path/configuration_path | 這會包含前往工作負載二進位檔案的路徑。 如果已將工作負載二進位檔案設定為 path 變數，則這個欄位並非強制性欄位。 | |
| linux_user | Yes | 這會包含具備資料庫使用者登入存取權之 Linux 使用者的使用者名稱。 如果未設定此值，則會將根視為預設使用者。 |
| credString | 這代表用於連線至資料庫的認證字串。 這個值將會含有完整的登入字串。 | |
| ipc_folder | 工作負載只能寫入特定的檔案系統路徑。 您必須在此處提供此資料夾路徑，以便前置指令碼可將狀態寫入這個資料夾路徑中。 | |
| timeout | Yes | 這是資料庫處於「靜止」狀態的時間上限。 預設值為 90 秒。 不建議將值設定為小於 60 秒。 |
注意
JSON 定義是一個範本，您可以視 Azure 備份服務所要處理的特定資料庫加以修改。 若要了解每一個資料庫的組態檔，請參考各資料庫的手冊。
以下是使用增強型前置-後置指令碼架構的整體體驗：
- 準備資料庫環境
- 編輯設定檔
- 觸發 VM 備份
- 視需要從應用程式一致性復原點還原 VM 或磁碟/檔案。
建立資料庫備份策略
使用快照集而不要使用資料流
資料庫管理員通常會在其備份策略中使用資料流 (例如，完整、差異或增量備份) 來進行備份和記錄。 以下是該設計中的一些考量重點。
- 效能與成本：每日進行完整備份 + 記錄的做法可以獲得快速還原的效果，但卻會付出巨大的成本。 而納入差異/增量的資料流備份類型，則可以降低成本，卻可能影響還原的效能。 但是，快照集可以提供效能與成本的最佳組合。 由於快照集在本質上也是增量 (累加) 的一種，所以在備份期間對效能的影響最小，可以快速還原，也能節省成本。
- 對資料庫/基礎結構的影響：資料流備份的效能取決於基礎儲存體的 IOPS，以及當資料流需以遠端位置為目標時的可用網路頻寬。 快照集則不須考慮這一類的相依性，而且對 IOPS 及網路頻寬的需求量可以大幅減少。
- 重複使用性：對每一個資料庫而言，用於觸發不同資料流備份類型的命令均不同。 所以，您無法輕鬆地重複使用既有的指令碼。 此外，若有使用不同的備份類型，請務必將維護生命週期所需的相依性鏈結也納入評估。 若使用快照集，由於不需考慮相依性鏈結，所以指令碼的編寫相對簡單。
- 長期保留：完整備份有益於長期保留，因為這類備份可以單獨予以移動和復原。 但是，對短期保留的作業備份，則會偏好使用快照集。
因此，每日快照集 + 記錄並偶爾搭配長期保留所需的完整備份，會是資料庫的最佳備份原則。
記錄備份策略
增強型前置-後置指令碼架構建置於 Azure VM 備份之上，以每天備份一次的方式進行排程。 所以，設定使用 24 小時復原點目標 (RPO) 的資料遺失時間範圍，並不適合實際生產資料庫。 這個解決方案會輔以記錄備份策略，該策略會明確地將記錄備份以資料流外送的方式處理。
Blob 上的 NFS 以及 AFS 上的 NFS (預覽版) 可協助您輕鬆在資料庫 VM 上直接掛接磁碟區，並使用資料庫用戶端來傳送記錄備份。 「資料遺失時間範圍」(也就是 RPO)，應該要落在記錄備份的時間頻率之內。 此外，NFS 目標並不需要具備高超的效能，因為當您有了資料庫一致性快照集之後，有可能不會需要觸發作業備份的定期性的資料流 (完整及增量)。
注意
通常，增強型前置指令碼會在靜止資料庫以取得快照集之前，負責將傳輸中的所有記錄交易排清至記錄備份目的地。 因此，在復原期間，快照集就是資料庫一致性且可靠的復原依據。
復原策略
一旦取得資料庫一致性快照集，並將記錄備份以資料流傳送至 NFS 磁碟區後，資料庫的復原策略就可以使用 Azure VM 備份的復原功能。 記錄備份的功能則是可使用資料庫用戶端額外套用至復原策略。 以下是復原策略的幾個選項：
- 從資料庫一致性復原點建立新的 VM。 VM 應該已經與記錄掛接點連線。 使用資料庫用戶端來執行時間點復原的復原命令。
- 從資料庫一致性復原點建立磁碟，並將該磁碟連結至另一個目標 VM。 接著，掛接記錄目的地，再使用資料庫用戶端來執行時間點復原的復原命令
- 使用檔案復原選項，並產生指令碼。 在目標 VM 上執行指令碼，然後將復原點連結為 iSCSI 磁碟。 然後，使用資料庫用戶端在連結的磁碟上執行資料庫特定的驗證功能，並驗證備份資料。 此外，使用資料庫用戶端將部分資料表/檔案予以匯出/復原，而不要復原整個資料庫。
- 使用「跨區域還原」功能，在發生區域性損壞期間，從次要的配對區域中執行上述動作。
摘要
使用資料庫一致性快照集 + 使用自訂解決方案所備份的記錄，就可以建立高效能且符合成本效益的資料庫備份解決方案，該解決方案除了善用 Azure VM 備份的優點，同時也重複使用了資料庫用戶端的功能。