根據經驗的災害復原指導

本文提供針對經驗的指引，協助您在區域災難發生時恢復您的 Fabric 資料。

範例案例

本文中的許多指引章節都使用下列範例情境作為說明與示例。 視需要回頭參考此案例。

假設您在區域 A 中有一個容量 C1，其中包含一個工作區 W1。 如果你在容量 C1 開啟了災難復原，OneLake 的資料會被複製到區域 B 的備份。若區域 A 遭遇中斷，C1 中的 Fabric 服務會故障移轉至區域 B。

下圖說明這個案例。 左側方塊顯示中斷的區域。 中間方塊代表故障轉移後資料的持續可用性，右側方塊顯示客戶採取行動，將其服務還原至完整功能後的全面覆蓋情況。

以下是一般恢復方案：

1. 在新的區域中建立新的 Fabric 容量 C2。

2. 在 C2 中建立新的 W2 工作區，包括與 C1.W1 中名稱相同的對應項目。

3. 將資料從中斷的 C1.W1 複製到 C2.W2。

4. 請遵循每個元件的專用指示，將項目還原至其完整功能。

此復原計畫假設租戶住宅區域仍能運作。 若租戶住宅區域發生停電，本文所述步驟取決於其恢復，且必須先由 Microsoft 啟動並完成。

體驗專屬的復原計畫

以下章節將提供每種 Fabric 體驗的逐步指南，協助你完成復原過程。

資料工程

本指南會逐步引導您完成資料工程體驗的恢復程序。 它涵蓋湖屋、筆記本、Spark 工作定義、使用者資料函式以及 GraphQL API。

Lakehouse

來自原始區域的 Lakehouses 仍然無法供客戶使用。 若要復原 Lakehouse，客戶可以在工作區 C2.W2 中重新建立。 我們建議使用兩種途徑來復原湖倉：

方法 1：使用自訂指令碼複製 Lakehouse Delta 資料表和檔案

客戶可以使用自訂 Scala 指令碼重新建立 Lakehouse。

1. 在新建立的工作區 C2.W2 中建立 Lakehouse (例如 LH1)。

2. 在工作區 C2.W2 中建立新的筆記本。

3. 若要從原始湖屋恢復資料表與檔案，請參考帶有 OneLake 路徑的資料，例如 abfss（參見 連接至 Microsoft OneLake）。 你可以在筆記本中使用以下程式碼範例（參見 Introduction to Microsoft Spark Utilities）來取得原始 lakehouse 檔案和資料表的 ABFS 路徑。 （請以實際的工作區名稱替換 C1.W1 ）

   notebookutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
   

4. 使用下列程式碼範例，將資料表和檔案複製到新建立的 Lakehouse。

   1. 針對 Delta 資料表，您必須一次複製一個資料表，才能在新的 Lakehouse 中復原。 在 Lakehouse 檔案的情況下，您可以透過一次執行來複製完整的檔案結構，包括所有底層資料夾。

   2. 請聯絡支援小組，以取得指令碼中所需的容錯移轉時間戳記。

   %%spark
   val source="abfs path to original Lakehouse file or table directory"
   val destination="abfs path to new Lakehouse file or table directory"
   val timestamp= //timestamp provided by Support
   
   notebookutils.fs.cp(source, destination, true)
   
   val filesToDelete = notebookutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelete <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelete.name}"
       println(s"Deleting file $destFileToDelete")
       notebookutils.fs.rm(destFileToDelete, false)
   }
   
   notebookutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. 執行腳本之後，資料表會出現在新的湖庫中。

方法二：使用 Azure 儲存體總管 複製檔案和資料表

若要只從原始湖屋中恢復特定的 Lakehouse 檔案或資料表，請使用 Azure 儲存體總管。 詳細步驟請參閱 Integration OneLake with Azure 儲存體總管。 針對大型資料大小，請使用方法 1。

恢復 Fabric 系統中生成的湖泊視圖

切換後，你無法從原始區域進入實體化的湖景。 故障轉移程序不會將更新排程或執行歷史複製到次要區域。 要恢復這些項目，請在恢復 Lakehouse 資料後完成以下步驟：

• 請使用本文前述的方法 1 或方法 2 來恢復湖屋資料表。 只複製來源資料表。
• 找回包含你 MLV 定義的筆記本。 關於恢復步驟，請參閱 筆記本 章節。
• 運行復原的筆記本以在新的 Lakehouse 中重現MLVs。 關於建立MLV的資訊，請參閱 「建立實體湖景」。 如果你在前一步複製了 MLV，重新建立時請執行 CREATE 或 REPLACE 。
• 手動在新工作區重新建立 MLV 的刷新排程。 你無法恢復排程歷史或執行指標。
• 如果您的 MLV 為語意模型或報告提供數據，請根據需要驗證並更新 Lakehouse ID 和資料集 ID 的引用。 重新連結報告與更新的語意模型並驗證資料的新鮮性。

Notebook

主要區域的筆記本仍然無法提供給客戶，筆記本中的程式碼也不會複製到次要區域。 要在新區域恢復筆記本程式碼，請使用以下其中一種方法。

方法 1：使用者管理的備援與 Git 整合（公開預覽版）

使用 Fabric Git 整合來同步你的筆記本與 Azure DevOps（ADO）倉庫。 服務容錯移轉到另一個區域後，使用存放庫在您建立的新工作區中重新建置筆記本。

1. 為您的工作區配置 Git 整合，然後選取 [與 ADO 存放庫連接并同步。

   

   下圖顯示已同步的筆記本。

   

2. 從 ADO 存放庫復原筆記本。

   1. 在新建立的工作區中，再次連接到你的 Azure ADO 倉庫。

      

   2. 選取 [原始檔控制] 按鈕。 然後選取存放庫的相關分支。 然後選取 [更新所有]。 原始筆記本隨即出現。

      

      

   3. 如果原始筆記本中有預設的湖屋，請參考 湖屋章節 來恢復湖屋，然後將新找回的湖屋連接到新找回的筆記本。

      

   4. Git 整合功能不支援在筆記本資源瀏覽器中同步處理檔案、資料夾或筆記本快照。

      1. 如果原始筆記本在筆記本資源總管中有檔案：

         1. 將檔案或資料夾儲存到本地磁碟或其他地點。

         2. 將檔案從本機磁碟或雲端磁碟機重新上傳至復原的筆記本。

      2. 如果原始筆記本有筆記本快照，亦請將筆記本快照儲存至您自己的版本控制系統或本機磁碟。

         

         

如需有關 Git 整合的詳細資訊，請參閱 Git 整合簡介。

方法 2：備份程式碼內容的手動方式

如果你不採用 Git 整合方式，請將最新版本的程式碼、檔案存於資源總管，並將筆記本快照存入版本控制系統（如 Git）。 災難後手動恢復筆記本內容：

1. 使用 匯入筆記本 功能來匯入你想要恢復的筆記本程式碼。

   

2. 匯入之後，請移至所需的工作區 (例如 "C2.W2") 進行存取。

3. 如果原始筆記本有預設的 Lakehouse，請參閱 Lakehouse 區段。 然後，將新復原的 Lakehouse (與原始預設 Lakehouse 的內容相同) 連線至新復原的筆記本。

4. 如果原始筆記本在資源總管中有檔案或資料夾，請重新上傳儲存在使用者版本控制系統中的檔案或資料夾。

Spark 作業定義

主要區域的 Spark 工作定義（SJD）仍然不可用，OneLake 會將筆記本中的主定義檔與參考檔複製到次要區域。 如果你想在新區域恢復 SJD，請依照本節所述的手動步驟操作。 SJD 的歷史運行紀錄未被恢復。

你可以透過使用 Azure 儲存體總管 從原始區域複製程式碼，並在災難發生後手動重新連接 Lakehouse 參考來恢復 SJD 項目。

1. 在新的工作區 C2 中建立一個新的 SJD 項目（例如 SJD1）。W2，並使用與原始 SJD 項目相同的設定與設定（例如語言、環境等）。

2. 使用 Azure 儲存體總管 將原始 SJD 項目中的 Libs、Mains 和 Snapshots 複製到新的 SJD 項目。

   

3. 程式碼內容會出現在新建立的 SJD 中。 你需要手動將新復原的 Lakehouse 參照新增至作業中（請參閱 Lakehouse 復原步驟）。 使用者需要手動重新輸入原始的命令列參數。

   

現在，您可以執行或排程剛復原的 SJD。

關於Azure 儲存體總管的詳細資訊，請參見 Integration OneLake with Azure 儲存體總管。

使用者資料功能

要恢復使用者資料在健康區域的功能，請採用以下方法之一。

方法一：搭配 Git 整合（建議）

首選的復原機制是 Fabric Git 整合。 透過將使用者資料功能專案與 Azure DevOps 或 GitHub 儲存庫同步，您可以在故障轉移後快速在新工作空間中重建它們。

災難發生前做好準備

1. 為承載使用者資料功能的工作區配置 Fabric Git 整合。
2. 將工作空間連接到 Azure DevOps 或 GitHub 倉庫。
3. 將所有使用者資料函式提交到資料庫，並定期同步變更。
4. 如有需要，將環境專屬設定分別存放在變數函式庫中。

復原步驟

在一場區域災難之後：

1. 在狀況良好的區域（例如 C2）建立新的 Fabric 容量。
2. 在新的容量中建立新的工作區，例如 W2。
3. 將工作空間連接到同一個 Azure DevOps 或 GitHub 儲存庫。
4. 開 源 控制並同步儲存庫內容與工作區。
5. 重建或恢復所有相依的 Fabric 資源，例如湖屋、Fabric 中的 SQL 資料庫、倉庫及商業事件。
6. 重新部署使用者資料功能。
7. 驗證函式執行與相依性連通性。
8. 更新下游應用程式、資料管線或其他整合項目，使其參照已復原的功能。
9. 完成所有情境的端到端驗證。

重要考慮

• Git 整合僅能恢復原始碼與專案資產。
• 歷史執行日誌不會被恢復。
• 下游系統可能需要端點重新綁定。

欲了解更多資訊，請參閱 使用者資料功能、原始碼控制與部署。

方法二：手動恢復

如果災難發生前沒有設定 Git 整合，你可以手動從原始碼備份重建使用者資料功能。

災難發生前做好準備

定期完成以下任務，並將項目存放於外部的原始碼控制儲存庫或備份地點：

• 將函式原始碼匯出到 GitHub 倉庫。
• 記錄並保存相依性資訊。
• 文件環境設定。

復原步驟

在一場區域災難之後：

1. 在狀況良好的區域（例如 C2）建立新的 Fabric 容量。
2. 建立一個新的工作區，例如 W2。
3. 復原函式所需的全部資源，包括湖屋、Fabric 中的 SQL 資料庫、倉庫、事件屋，以及外部服務。
4. 建立一個新的使用者資料功能專案。
5. 匯入或重建函式原始碼。
6. 重新套用執行時的設定。
7. 重新安裝所有函式相依項。
8. 重新部署函數。
9. 重新設定驗證與授權。
10. 若有使用商業事件發佈者或取用者，請重新建立。
11. 完成對您的情境與整合進行端對端驗證測試。

GraphQL

區域災難後，主要區域的 GraphQL 項目無法取得，GraphQL 的定義與配置也無法複製到次要區域。 要在新區域恢復 GraphQL，請採用以下方法之一。

方法一：使用者管理冗餘與 Git 整合

讓這個過程簡單快速的最佳方式是使用 Fabric Git 整合，然後將 GraphQL 與 ADO 倉庫同步。 服務容錯移轉到另一個區域後，你可以使用存放庫在你建立的新工作區中重新建置 GraphQL。

1. 在目標容量與區域建立新工作區。

2. 依照各自的復原步驟，恢復所有相依的資料來源，如 Lakehouse、Warehouse 或 SQL 資料庫。

3. 透過修改環境特定的參考資料，如來源工作區 ID、來源項目 ID 及連線細節，更新 GraphQL 定義以指向新恢復的資源。 此步驟可確保在部署時正確綁定。

4. 將 Git 儲存庫中的 GraphQL 項目重新部署到新工作區。 此步驟透過使用更新的定義重建 API 結構與設定。

5. 重新套用物品設定，包括角色、存取控制和認證設定。

6. 透過更新任何應用程式或整合，重新套用端點參考，以使用新建立的 GraphQL 端點。

7. 更新任何指向舊工作區的現有部署管線，讓它能參考新建立的工作區。

8. 驗證 API 的端對端功能。

方法二：手動方法

如果你不採用 Git 整合方法，可以使用以下手動方法來恢復 GraphQL。

1. 在目標容量與區域建立新工作區。

2. 恢復所有相依的資料來源，例如 Lakehouse、Warehouse 或 SQL 資料庫。

3. 在新工作區手動重建 GraphQL API，包括結構定義、資料來源連結與關聯。

4. 重新套用物品設定，包括角色、存取控制和認證設定。

5. 透過更新任何應用程式或整合，重新套用端點參考，以使用新建立的 GraphQL 端點。

6. 更新任何指向舊工作區的現有部署管線，讓它能參考新建立的工作區。

7. 驗證 API 的端對端功能。

重要考慮

1. GraphQL 依賴外部相依關係（例如 Lakehouse、Warehouse 和 SQL），而你必須在部署 GraphQL 前恢復這些依賴。

2. GraphQL API 定義包含環境特定的參考（例如 sourceWorkspaceId 和 sourceItemId）。 在新區域恢復時，這些參考可能會失效。 更新它們指向新配置的資源。

3. 在災難復原情境下，尤其是使用儲存的憑證或跨工作空間連線時，資料來源的自動重新綁定並不保證。

4. 其他項目設定如監控、授權、RBAC、內省等，在故障轉移後不會延續。 你必須在新區域重新建立這些設定。

References

• Fabric Git 整合概述 - Microsoft Fabric |Microsoft Learn

• GraphQL API 中的原始碼控制與部署管線 - Microsoft Fabric |Microsoft Learn 

App

系統不會將 Fabric 應用程式，包括其程式碼、設定和元資料，複製到次要區域。 如果主要區域失效，該應用程式將無法使用。 為了恢復，請將應用程式原始碼存放在系統外的 GitHub、Azure DevOps 或其他原始碼控制系統中。 依照每個底層 Fabric 資料儲存的災難復原指引，分別恢復應用程式資料。

手動方式

你可以在區域災難發生後，使用應用程式原始碼和 Rayfin CLI 手動恢復 Fabric 應用程式。 

Prerequisites 

災難發生前：

• 將 Fabric App 原始碼儲存在 GitHub、Azure DevOps 或其他原始碼控制倉庫中。 

• 記錄恢復過程。  

復原步驟 

1. 在目標容量與區域建立新工作區。 

2. 在重新部署應用程式前，先恢復相依資源。  

3. 從你的原始碼控制庫或本地備份中取得最新的 Fabric App 原始碼。 

4. 從應用程式來源目錄，使用 Rayfin CLI 將 Fabric 應用程式部署到復原工作區。 執行 rayfin up --workspace <new workspace>。 

5. 依照其各自的復原程序，復原應用程式的子項目（Fabric 中的 SQL 資料庫）。  

6. 視需要重新套用項目層級設定，包括角色和存取控制。  

7. 驗證應用程式功能，並確保使用者擁有正確的權限。  

重要 

• 將 Fabric App 原始碼維持在 Fabric 區域外，以啟用復原。  

• 資料庫中的應用程式資料不會在 Fabric 應用程式部署過程中被恢復，必須另行還原。  你可以在區域災難發生後，使用應用程式原始碼和 Rayfin CLI 手動恢復 Fabric 應用程式。 

Azure Databricks Storage

Azure Databricks Storage 將資料儲存在 OneLake。 為了保護你的資料免於區域性中斷，請啟用包含 Azure Databricks 儲存項目的 Fabric 容量的災難復原設定。 啟用此設定後，OneLake 會非同步將資料複製到 Azure 配對區域。

若 OneLake 發起區域故障轉移，應用程式可在故障轉移結束後，透過 OneLake 全球端點繼續存取複製的資料。 透過 OneLake 公開 API 持續存取，不需要建立另一個 Azure Databricks 儲存項目或將資料複製到其他工作區。

請檢視 OneLake 災難復原與資料保護 ，了解適用的行為、考量與限制。

關於 Azure Databricks 專屬的災難復原規劃，請參見 Disaster recovery - Azure Databricks。

資料科學

本指南會逐步引導您完成數據科學體驗的恢復程序。 其涵蓋 ML 模型和實驗。

機器學習模型與實驗

主要區域的資料科學項目仍無法提供給客戶，機器學習模型與實驗中的內容與元資料也無法複製到次要區域。 若要在新區域中將其完全復原，請將程式碼內容儲存在版本控制系統中 (例如 Git)，並在災害發生後手動重新執行程式碼內容。

1. 復原筆記型電腦。 請參閱 Notebook 恢復步驟。

2. 設定、歷史上的指標和元資料都不會複製到配對區域。 你需要重跑每個版本的資料科學程式碼，才能在災難後完全恢復機器學習模型和實驗。

Data Warehouse

本指南將引導你了解Fabric Data Warehouse工作量的復原程序。 涵蓋倉庫中的品項。

倉儲

你無法從原本區域進入倉庫。 若要復原倉儲，請使用以下兩個步驟。

1. 在工作區 C2.W2 中，為從原始倉儲複製的資料建立一個新的暫存湖屋。

2. 利用倉庫的 Explorer 與 T-SQL 功能（參見 Fabric Data Warehouse 中的資料表）來填充倉庫的 Delta 資料表。

透過 Lakehouse 和 T-SQL 程式碼的資料擷取

在新建立的工作區 C2.W2 中：

1. 在 C2.W2 中建立臨時 lakehouse「LH2」。

2. 遵循 Lakehouse 恢復步驟，從原倉儲中復原臨時 Lakehouse 的 Delta 資料表。

3. 在 C2.W2 中建立新倉儲 "WH2"。

4. 在倉儲管理器中連接臨時 Lakehouse。

5. 根據你在資料匯入前部署資料表定義的方式，實際用於匯入的 T-SQL 可能會有所不同。 若要從湖屋復原倉庫資料表，可以使用 INSERT INTO、SELECT INTO 或 CREATE TABLE AS SELECT 的方法。 在以下範例中，我們使用 INSERT INTO。 如果你使用以下程式碼，請將樣本替換成實際的表格和欄位名稱。

   USE WH1
   
   INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
   
   SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
   FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
   GO
   

6. 在使用您 Fabric 倉儲的應用程式中變更連線字串。

鏡像資料庫

客戶無法存取主要區域的鏡像資料庫，設定也無法複製到次要區域。 要在區域故障後恢復鏡像資料庫，你需要從不同區域在另一個工作區重新建立它。

Data Factory

客戶無法從主要區域存取資料工廠項目，且管線或 Dataflow Gen2 項目中的設定與設定不會複製到次要區域。 要在區域故障後恢復這些項目，你需要在另一個區域的工作區重新建立資料整合項目。 下列各節概述了詳細資料。

資料流程第 2 代

要在新區域恢復 Dataflow Gen2 項目，請將檔案匯出 .pqt 到版本控制系統（如 Git），然後在災難發生後手動恢復 Dataflow Gen2 的內容。

1. 從你的 Dataflow Gen2 項目中，在 Power Query 編輯器的 Home 標籤中，選擇匯出範本。

   

2. 在 匯出範本 對話框中，輸入該範本的名稱（必須）和描述（可選）。 完成時，選取確定。

   

3. 災害發生之後，請在新的工作區 "C2.W2" 中建立新的資料流程 Gen2 項目。

4. 從Power Query編輯器目前檢視的窗格中，選擇 從Power Query模板匯入。

   

5. 在 「開啟 」對話框中，瀏覽到你的預設下載資料夾，選擇 .pqt 你在前幾步中儲存的檔案。 然後選擇「開啟」。

6. 接著，範本會匯入至新的資料流程 Gen2 項目。

在災難復原時，資料流的 另存為 功能不被支援。

Pipelines

客戶若發生區域性災害時無法存取管道，而且組態不會複寫至對應區域。 在不同區域的多個工作區中建置關鍵管線。

複製作業

CopyJob 用戶必須採取主動措施，以防止區域性災害。 下列方法可確保在發生區域性災害之後，使用者的 CopyJobs 仍可供使用。

使用 Git 整合的使用者管理備援 （公開預覽版）

讓這個過程簡單快速的最佳方法是使用 Fabric Git 整合，然後將你的 CopyJob 與 Azure DevOps 倉庫同步。 服務故障轉移至另一個區域之後，您可以使用存放庫在您所建立的新工作區中重建 CopyJob。

1. 設定工作區的 Git 整合，並選擇 連線並同步 Azure DevOps 存放庫。

   

   下圖顯示同步的 CopyJob。

   

2. 從 Azure DevOps 存放庫恢復 CopyJob。

   1. 在新建立的工作區中，再次連線並同步到你的 Azure DevOps 倉庫。 此儲存庫中的所有 Fabric 項目都會自動下載到你的新工作區。

      

   2. 如果原始的 CopyJob 使用 Lakehouse，使用者可以參考 Lakehouse 區段 來恢復 Lakehouse，然後將新恢復的 CopyJob 連接到新恢復的 Lakehouse。

如需有關 Git 整合的詳細資訊，請參閱 Git 整合簡介。

Apache Airflow 任務

您必須主動採取措施，保護 Fabric 的 Apache Airflow 工作，免於區域災難發生。

透過使用 Fabric Git 整合來管理冗餘。 首先，將你的 Airflow 工作與 ADO 倉庫同步。 如果服務切換到其他區域，你可以用儲存庫在你建立的新工作區重建 Airflow 工作。

請遵循以下步驟達成此目標：

1. 設定你工作區的 Git 整合，選擇 連接並同步 到 ADO 倉庫。

2. 之後你會看到你的 Airflow 工作同步到 ADO 倉庫。

3. 如果你需要從 ADO 倉庫恢復 Airflow 工作，請建立一個新工作區，連接後再次同步到 Azure ADO 倉庫。 此倉庫中所有 Fabric 項目，包括 Airflow，都會自動下載到你的新工作區。

即時智慧

本指南會逐步引導您完成即時智慧體驗的恢復程序。 它涵蓋 KQL 資料庫、查詢集及事件串流項目。

Activator

主要區域的啟動器物品仍無法提供給客戶，啟動器觸發定義也不會複製到次要區域。 啟動者必須主動採取措施，為區域災難復原做準備。

為了確保在區域災難發生時能恢復 Activator 項目，請設定 Fabric Git 整合，備份觸發定義並在其他區域的工作區中還原。

1. 為包含你的 Activator 項目的工作區設定 Fabric Git 整合，並將觸發定義與你的 Git 儲存庫同步。
2. 請定期提交並同步您的 Activator 觸發程序定義。
3. 在復原時，請在目標區域（C2.W2）中建立新的工作區，將其連線至相同的儲存庫，然後進行同步以還原觸發程序定義。
4. 重新配置並驗證新工作區中的所有 Activator 資料來源與相依關係。

如需有關 Git 整合的詳細資訊，請參閱 Git 整合簡介。

圖模型/查詢集

客戶無法從主要區域存取 Graph 模型和 Graph 查詢集項目，而 Fabric 也不會將這些項目複製到次要區域。 若要復原，請在不同的區域建立或使用容量，並在該區域重新建立 Graph 模型和 Graph 查詢集項目。

1. 在未受災難影響的其他區域建立或使用現有的 Fabric 容量。

2. 建立一個新工作區，或使用現有的工作區。

3. 在次要工作區（步驟 2 參考）中重新建立圖形模型項目。 重新配置模型定義，包括節點、邊等，以符合原始圖譜模型。

4. 如果原始湖屋位於故障區域，請先依照湖屋部分進行復原。

5. 將湖屋連結為新建立的圖模型項目的 OneLake 資料來源。 ** 如果湖倉在故障區域且已修復，請使用恢復的湖倉；如果現有的湖倉仍可用，則重新連接。

6. 在新工作區中重新配置圖模型的資料載入排程或連線。

7. 在次要工作區中重新建立 Graph 查詢集項目。 手動重新輸入原始 Graph 查詢集中所有已儲存的查詢設定。

KQL 資料庫/查詢集

KQL 資料庫與查詢集使用者必須採取主動措施，以防範區域災害。 以下方法確保在區域災害發生時，您的 KQL 資料庫與查詢集中的資料保持安全且可存取。

使用下列步驟，保證 KQL 資料庫和查詢集的有效災害復原解決方案。

1. 建立獨立的 KQL 資料庫：在專用 Fabric 容量上配置兩個或以上獨立的 KQL 資料庫與查詢集。 將這些資料庫設置在兩個不同的 Azure 區域（最好是 Azure 配對區域）以最大化韌性。

2. 複製管理活動：將你在一個 KQL 資料庫中所做的管理操作鏡像到另一個資料庫中。 此方法能保持兩個資料庫的同步。需要複製的關鍵活動包括：

   • 資料表：確保資料表結構與結構定義在各資料庫間保持一致。

   • 映射：複製任何所需的映射。 確保資料來源與目的地正確對齊。

   • 政策：確保兩個資料庫的資料保留、存取及其他相關政策相近。

3. 管理認證與授權：為每個副本設定所需權限。 確保建立適當的授權等級，允許所需人員存取，同時維持安全標準。

4. 平行資料擷取：若要讓資料在多個區域中保持一致且就緒，請在您擷取資料時，將相同的資料集載入每個 KQL 資料庫中。

Eventstream

事件串流是 Fabric 平台中一個集中式的地方，用來捕捉、轉換並路由即時事件到各種目的地（例如湖屋、KQL 資料庫/查詢集），並提供無程式碼體驗。 只要目的地支援災難復原，事件串流就不會遺失資料。 因此，利用這些目的地系統的災難復原能力來保證資料的可用性。

你也可以透過在多個 Azure 區域部署相同的事件串流工作負載，作為多站點主動/主動策略的一部分來實現地理冗餘。 採用多站點主動-主動架構時，你可以在任何已部署的區域中存取你的工作負載。 這種方法是最複雜且成本最高的災害復原方法，但在大部分情況下，它可以將恢復時間減少到接近零。 若要達到完整的地理備援：

1. 在不同地區建立資料來源的複製品。

2. 在對應區域建立事件串流項目。

3. 將這些新項目連線到相同的資料來源。

4. 為不同區域的每個 Eventstream 新增相同的目的地。

商業活動、Fabric 活動與 Azure 活動

雖然商業活動、Fabric活動和Azure活動在Microsoft Fabric共享相同的 Real-Time 樞紐基礎設施，但它們擁有不同的起源、行為及復原需求。 在規劃災難復原前，請了解這些差異：

• Fabric 活動是會對 Fabric 資源本身所產生的事件作出回應的事件訂閱。 這些事件包括工作區項目生命週期變更（例如建立、更新或刪除湖屋、筆記本或倉庫）、工作執行（如管線運行或筆記本執行），以及 OneLake 檔案與資料夾操作。 這些訂閱是推送式且短暫的。 訂閱不會被複製到次要區域。

• Azure Events 是由 Azure Blob 儲存體 帳戶產生的活動訂閱。 這些 Azure 資源獨立於任何 Fabric 容量或區域之外。 雖然 Azure Blob 儲存體 資源本身在 Fabric 區域發生故障期間可能仍可使用，但在 Real-Time hub 中設定的訂閱不會複寫到次要區域，因此必須重新建立。

• 商業事件是Fabric Real-Time情報中的一項獨特功能，允許團隊定義、發布並對有意義的商業訊號採取行動。 商業事件由 Fabric 內部透過 Activator、Spark 筆記本或使用者資料函數產生，然後發佈至 Real-Time 樞紐，讓下游消費者如 Activator、Eventhouse 或 Power Automate 能對事件做出反應。 事件結構由結構登錄中心管理。 Eventhouse 會自動儲存所有已發佈的商業事件，因此其恢復直接影響商業事件歷史的可用性。 發佈者或消費者的設定、結構定義或訂閱不會被複製到次要區域。

請依照以下步驟在復原區域的新工作區中還原商業事件、Fabric 事件和 Azure 事件。

商務活動：

1. 請參考文章《在Fabric Real-Time Hub創建商業活動》，重現出版商與消費者使用的商業活動。 在建立商業事件時，你會建立事件結構集資源。 活動屋資源是可選的，視情境而定。 如果你用 Git 整合備份了事件結構集，請先依照 事件結構集的部分還原它，然後將業務事件指向還原的結構集。

2. 在新工作區中，請依照以下發佈者文章，重新建立任何會產生商務事件的發佈者項目，例如 Spark 筆記本或使用者資料函數：使用使用者資料函數作為商務事件發佈者、使用 Activator 作為商務事件發佈者、使用筆記本作為商務事件發佈者，以及 使用 Eventstream 作為商務事件發佈者。

3. 請依照文章 Eventhouse 與 Real-Time 儀表板整合商務事件 和 從 Activator 取用商務事件 中的說明，在 Real-Time 中心重新建立原本會回應受影響區域中商務事件的取用者訂閱（例如 Activator 規則、筆記本觸發程序或 Power Automate 流程）。

4. 驗證事件是否端到端流動，確認訂閱是否有效，且資料是否抵達復原區域的預期目的地。

針對 Fabric 活動：

1. 請參閱在 Fabric Real-Time hub 中探索 Fabric 事件一文，在 Real-Time hub 中重新建立訂閱，使其指向您在復原區域中還原的工作區項目、作業或 OneLake 路徑。

2. 驗證事件是否端到端流動，確認訂閱是否有效，且資料是否抵達復原區域的預期目的地。

For Azure events：

1. Azure Blob 儲存體 帳戶不會受到 Fabric 區域故障的影響。 在 Real-Time 中心重新建立指向相同Azure Blob 儲存體帳號的活動訂閱，請參考文章「在 Real-Time 中心設定Azure Blob 儲存體事件提醒」。

2. 驗證事件是否端到端流動，確認訂閱是否有效，且資料是否抵達復原區域的預期目的地。

事件結構描述集

事件結構描述集是在即時智慧中，用來保存事件類型和結構描述定義的 Fabric 項目。 其他功能則在此基礎上發展：出版商撰寫符合其結構的事件，消費者則依照相同定義閱讀。

主要區域的事件結構集仍無法提供給客戶，且不會複製到次要區域。 然而，因為事件結構集是持久的作者定義，而非短暫訂閱，你可以事先備份並還原，而不必手動重新撰寫。

建議：使用 Fabric Git 整合進行備份

要在區域災難後恢復事件結構集，請在災難發生前設定 Fabric Git 整合，並將包含事件結構集的工作區與 Git 儲存庫同步。

1. 為包含你事件結構集的工作區設定 Fabric Git 整合，並與你的 Git 倉庫同步。

2. 請定期提交並同步事件結構集，尤其是在新增事件類型或發布新架構版本後。

3. 在復原期間，請在目標區域（C2.W2）建立新的工作區，將其連接到同一個儲存庫，並進行同步以還原事件結構描述集合。 由於新工作區是空的，Git 同步會將儲存庫的內容帶到工作區。

4. 依照這些項目類型的相關指引，重新建立任何使用該結構集的發佈者和取用者。

5. 驗證出版商是否能針對恢復的事件類型發佈，且消費者是否如預期收到事件。

同步定義包含結構集合中的事件類型、結構以及結構版本。 它不包含出版商註冊、消費者訂閱或活動歷史。 依照使用結構集的項目類型的指引，分別恢復這些資料。

另一種選擇：手動重建

如果你在災難發生前沒有設定 Git 整合，請依照 「建立並管理事件結構集合」在復原區域重新建立事件結構集合，然後依照 「在結構集合中建立並管理事件結構」來新增原本結構集合中包含的事件類型和結構。

Map

主要區域的地圖物品仍無法提供給客戶，且地圖項目不會複製到次要區域。

如果你想在災難發生時找回地圖上的物品，可以設定 Fabric Git 整合，並且用 Git 倉庫同步你的地圖物品。

在復原過程中，當 Fabric 中新區域/容量設定好後，你可以用這個 repo 在你建立的新工作區重建地圖項目。 由於新工作區是空的，Git sync 會將 repo 的內容輸入空工作區。 此步驟會讓地圖物品復活。

本體

本體使用者必須主動採取措施，為區域災難復原做好準備。 以下所述方法確保在區域災難發生後，你的本體論仍可恢復且能迅速恢復。

啟用復原最簡單且最快的方式是使用 Fabric Git 整合，並將你的 Ontology 與 Azure DevOps（ADO）倉庫同步。 如果服務切換至其他區域，你可以利用這個儲存庫在新建立的工作空間中重建「Ontology」。

主區域的本體項目在區域災難後無法提供給客戶，且本體項目也無法複製到次要區域。

要在災難期間恢復本體項目，請事先設定 Fabric Git 整合，並同步將本體項目與你的 ADO 儲存庫連結。

在復原期間，一旦 Fabric 中新區域和容量設定好，你可以利用該倉庫在新工作區重建 Ontology 項目。 由於新工作區是空的，Git sync 會將儲存庫的內容拉入工作區，實際上還原了 Ontology 項目。

本體代理

Ontology Agent 使用者必須主動採取措施，為區域災難復原做準備。 本節所述方法確保在區域災難發生後，您的 Ontology Agent 體驗能在新建立的工作空間中恢復。

本體代理依賴於本體項目以及與本體相關的任何資料來源，例如 Lakehouse。 區域災難發生後，客戶無法存取主要區域的 Ontology Agent 會話，且 Ontology Agent 會話不會複製到次要區域。 受影響區域的活躍聊天會話、進行中的動作和對話紀錄無法恢復。

要在災難發生時恢復 Ontology Agent 體驗，請先設定 Fabric Git 整合，並將 Ontology 項目與 Azure DevOps（ADO）儲存庫提前同步。

在恢復期間，一旦 Fabric 中新區域和容量建立，請完成以下步驟：

1. 在新容量中建立一個新的工作空間。
2. 將新工作區連接到包含本體項目的同一個 ADO 儲存庫。
3. 使用 Git 同步 將 Ontology 項目還原到新工作區。
4. 依照相關資料類型的指引，恢復任何相依資料項目，例如 Lakehouse。
5. 確認恢復的資料是否在配對區域內可用。 對於以 OneLake 為後盾的資料，假設資料已複製到配對區域，但不要假設復原時複製資料的排序。
6. 將新恢復的本體項連接到恢復的資料來源。
7. 啟動新的 Ontology Agent 會話，並驗證該代理是否能連接已恢復的 Ontology 項目及資料來源。

Planning

本文描述了 IQ 規劃經驗的復原程序。 它概述了恢復關鍵元件所需的步驟，包括規劃表、PowerTable 表、情報表、InfoBridge 及相關資料資產。

用於還原計畫項目的 Git 整合

首選方法是透過 Fabric Git 整合，將所有計畫項目與 Azure DevOps（ADO）或 GitHub 倉庫同步。 故障轉移後，利用儲存庫還原新工作區中的項目。

災前（主動措施）：

1. 在 Workspace W1 裡，到 工作區設定 並設定 Git 整合。

2. 選擇連接並同步你的 ADO 或 GitHub 倉庫。

3. 選擇要上傳到資料庫的計畫項目，並選擇 提交。

   

4. 確認計畫項目的 Git 狀態 已 同步。

5. 建立提交紀律——每次計畫定義有重大變更後提交，確保儲存庫始終反映最新狀態。

復原步驟：

1. 在健康區域中的 C2 容量內建立新的 W2 工作區。

2. 在 Workspace W2 裡，進入 Workspace 設定，重新連接到同一個 ADO/GitHub 儲存庫。

3. 選取 Source Control。 選擇相關的儲存庫分支，並選擇 「全部更新」。 所有方案項目都已下載至 W2。

以下元件在恢復後會被恢復：

• PowerTable 表格： 來源資料表設定、欄位配置、列存取、視覺屬性（版面配置、格式等）、列識別、註解設定、緩慢變動的維度（SCD）、核准、自動化與表單。
• 規劃表： 工作表屬性（格式、條件格式等）、註解設定、回寫設定、資料輸入欄位、資料輸入列、情境和書籤。
• InfoBridge： InfoBridge 來源、InfoBridge 查詢、轉換步驟、寫回目的地、寫回設定、連結查詢映射、查詢群組、視覺屬性（混合）。 這些項目無法被復原：基於檔案的來源（CSV、Excel）、使用基於檔案的跨工作負載工作表。
• 智力： 所有圖表和矩陣。

Fabric SQL 還原用於規劃

規劃表中輸入的資料、PowerTable 中使用的資料表及寫回資料，皆儲存在 SQL 資料庫中，必須納入您的災難復原策略。 要恢復 SQL 資料庫，請參閱 SQL 資料庫 章節。

• 還原計畫中繼資料：每個計畫項目都與一個__fabric_plan_sys資料庫相關聯，該資料庫儲存規劃功能中的元資料，包括註解、情境、資料輸入及回寫設定。 __fabric_plan_sys資料庫不會自動還原，必須明確還原。

• 還原寫回資料庫：如果您的計畫使用 SQL 寫回目的地，也必須手動恢復相關的資料庫。 已設定的 SQL 寫回目的地不會自動還原。

• PowerTable 中使用的還原資料表：使用 PowerTable 建立的任何資料表都會儲存在 Fabric 的 SQL 資料庫中。 你也必須在 DR 期間恢復這些資料表。

營運代理

營運代理使用者應主動採取措施，為區域災難復原做準備。 遵循本節所述方法，有助於確保您的代理在區域性停電後能迅速恢復。

使用 Fabric Git 整合將工作空間與儲存庫同步。 此方法使你能在服務故障切換到其他區域時，在新工作空間中重建代理設定。

在區域性災難期間，主要區域中的作業代理程式項目將無法使用。 代理設定、行為模型和活動日誌不會被複製到次要區域。 進行中的操作、活躍的聊天會話，以及災難發生時先前接收的事件也會遺失。

為準備復原，請設定 Fabric Git 整合，並在災難發生前將代理項目與 ADO 儲存庫同步。

恢復時，請先在 Fabric 中設定新區域和容量，然後使用同步的儲存庫將代理設定還原到全新工作區。 Git 同步會將儲存的內容從儲存庫拉入空白工作區，重新建立你的代理項目。

設定恢復後，確認任何參考的 Eventhouse（KQL）資料庫或區域特定資料來源在新區域中都能存取。 視需要更新代理程式組態中的端點參照。 最後，重新啟動你的客服人員，並讓使用者重新開啟聊天會話。 之前的對話無法恢復。

Databases

本指南說明了資料庫體驗的復原程序。

SQL 資料庫

為了防止區域故障，SQL 資料庫的使用者可以採取主動措施，定期匯出其資料，並在需要時使用匯出的資料在新的工作區中重新建立資料庫。

使用 SqlPackage CLI 工具，提供資料庫可攜性並促進資料庫部署。

1. 使用 SqlPackage 工具將資料庫匯出至 .bacpac 檔案。 如需詳細資訊，請參閱 使用 SqlPackage 匯出資料庫 。
2. 將 .bacpac 檔案存放在與資料庫位於不同區域的安全位置。 例如，將 .bacpac 檔案儲存在位於不同區域的 Lakehouse 中、使用具有地理備援的 Azure 儲存體帳戶，或使用位於不同區域的其他安全儲存媒體。
3. 如果 SQL 資料庫和區域無法使用，您可以搭配 SqlPackage 使用 .bacpac 檔案，在新區域 （工作區 C2） 的工作區中重新建立資料庫。W2 位於區域 B 中，如上述案例所述。 請遵循 使用 SqlPackage 匯入資料庫 中詳述的步驟，以使用檔案 .bacpac 重新建立資料庫。

重新建立的資料庫是獨立於原始資料庫的資料庫，並反映匯出作業時的資料狀態。

容錯回復考量

重新建立的資料庫是獨立的資料庫。 新增到重建資料庫的資料不會反映在原始資料庫中。 如果您打算在主要區域恢復可用時切換回原始資料庫，則需要考慮手動將重建資料庫中的資料核對並整合回原始資料庫。

Platform

平台是指適用於所有工作負載的基礎共用服務和架構。 本節描述共享 Fabric 能力的復原程序。

工作區監視

工作區監控會收集你啟用此功能之工作區中的活動記錄。 在你將工作區還原為 C2.W2 之後，於 W2 上啟用工作區監控。 它開始收集恢復工作空間的監控資料。

來自原始工作區 (C1.W1) 的監視資料不會沿用過來，因為監視反映的是其執行所在工作區的活動。

變數函式庫

Microsoft Fabric 變數函式庫讓開發者能在工作空間內自訂並分享項目設定，簡化內容生命週期管理。 從災難恢復的角度來看，可變庫用戶必須主動防範區域災難。 此保護可透過 Fabric Git 整合實現，確保區域災難發生後，使用者的變數函式庫仍可使用。 要恢復變數函式庫，請依照以下步驟進行：

• 使用 Fabric Git 整合來同步你的變數函式庫與 ADO 倉庫。 如果發生災難，您可以使用存放庫在您建立的新工作區中重建變數程式庫。 請使用下列步驟：

  1. 將您的工作區連線到 Git 存放庫，如 這裡所述。
  2. 請務必讓 WS 和存放庫與 認可 和 更新保持同步。
  3. 復原 - 如果發生災難，請使用存放庫在新工作區中重建變數程式庫：

• 在新建立的工作區中，再次連線並同步到你的 Azure ADO 倉庫。

• 此倉庫中的所有 Fabric 項目都會自動下載到您的新工作區。

• 從 Git 同步項目後，在新的工作區中開啟變數庫，然後手動選擇所需的 活躍值集。

部署計劃

部署計畫是 Fabric 工作區中的一個項目。 它會將物品分組並設定部署順序。 它可以在每個物品部署前或部署後執行動作。 項目定義儲存這些設定、輸入和項目參考。 此方案沒有為執行階段使用的值提供獨立的儲存區。

透過使用 Fabric Git 整合來準備復原：

1. 將包含該計畫的工作區連接到 Azure DevOps 或 GitHub 儲存庫。
2. 提交計畫及其所使用的所有工作區項目。
3. 提交每個變更，讓 Git 擁有最新的定義。

在一場區域災難之後：

1. 在健康區域創造一個工作空間。
2. 將工作區連接到相同的存放庫和分支。
3. 從 Git 更新工作區。 此步驟可恢復設計圖及其項目。

Git 會恢復完整的計畫定義。 它不會還原連結項目的資料或執行狀態。 請利用本文的章節來找回這些物品。

Fabric 工作區的客戶管理金鑰

你可以使用儲存在 Azure Key Vault 中的客戶管理金鑰（CMK），在 Microsoft 管理的金鑰基礎上，為靜態資料加一層加密。 如果 Fabric 在某區域變得無法存取或無法運作，其元件會切換到備份實例。 在容錯移轉期間，CMK 功能支援唯讀作業。 只要 Azure Key Vault 服務保持健康且 Vault 權限保持完整，Fabric 會繼續連接到你的金鑰，並允許你正常讀取資料。 這表示容錯移轉期間不支援下列作業：啟用和停用工作區 CMK 設定，以及更新金鑰。

Fabric 移轉小幫手 適用於 Fabric 中的 SQL 資料庫

Fabric 移轉小幫手 可以在三個階段內將 SQL Server 資料庫移至 SQL 資料庫Fabric：遷移精靈建立目標資料庫並開始遷移，遷移監控器在從 DACPAC 部署結構時追蹤進度，移轉小幫手 協助你檢視並修正腳本錯誤、準備資料庫、使用複製工作複製資料，以及完成複製。

遷移進度不會被複製到其他區域，且中斷的部署無法恢復。 這些失敗不會影響來源 SQL Server 資料庫，所以你可以重新執行遷移助理。 如果原始區域無法使用，先依照本文的一般復原計畫，在配對區域建立容量 C2 和工作空間 W2，然後在 W2 執行遷移。 如果原本的區域恢復了，你可以在原本的工作區重新嘗試遷移。

區域性中斷可能導致移民失敗，原因有三種：

• 目標資料庫並未建立

  如果 Fabric 無法建立目標資料庫，遷移精靈會顯示錯誤，遷移不會開始。 選擇 開始遷移 以重試，或稍後再試。

  精靈嘗試移除不完整的資料庫，但在中斷時清理可能失敗。 在重試之前，請檢查工作區是否有目標名稱的資料庫。 確認是失敗嘗試留下的不完整資料庫再刪除。

• 部署失敗

  若部署中斷，遷移監控器會停止回報進度，開啟目標資料庫，並顯示部署失敗的對話框。 你無法恢復失敗部署，且該嘗試建立的資料庫仍留在工作區中。

  若要復原：

  1. 確認 Fabric 是否可用，且你有使用 DACPAC 進行原始遷移。
  2. 找出因失敗嘗試而建立的資料庫。 如果裡面沒有你需要保留的東西，就刪除它。 否則，保留它，並用另一個名稱來命名新資料庫。
  3. 從來源 DACPAC 執行新的遷移。 遷移會建立一個新的資料庫。

  資料是由 Data Factory 中的複製作業所複製。 如果你在中斷前已將複製工作與 Git 同步，請參考 Data Factory 指引中的複製工作。 否則，請建立新的複製作業，作為新遷移的一部分。

• 遷移歷史無法載入

  如果 移轉小幫手 無法取得遷移歷史，就會回報遷移資訊不再可用。 目前瀏覽器中儲存的進度會被保留，目標資料庫也不會受到影響。 重新整理頁面以重新載入遷移歷史。

OneLake

本節將引導您了解 OneLake 功能復原的流程。 欲了解更多關於 OneLake 資料災難復原的資訊，請參見 OneLake 災難復原。

生命週期管理原則

如果 Fabric 在某區域變得無法存取或無法運作，你仍然可以在故障轉移時讀取並更新你的 OneLake 生命週期政策。 任何移到冷級或冷級的資料都會留在那個層級。 要將現有政策套用到新的復原工作區，請依照以下步驟操作：

1. 在原始工作區中執行「匯出原則」，並儲存整個生命週期原則。
2. 在你恢復的工作區上呼叫匯入政策，並以你匯出的生命週期政策作為請求實體。

資源實例規則

資源實例規則透過使用受信任的 Azure 資源身份，協助你安全地控制 OneLake 中的資料存取。 在區域故障轉移期間，系統仍持續執行現有的讀取存取規則。 不過，在工作區恢復可寫狀態之前，你無法建立、更新或刪除資源實例規則。

相關資訊

• Microsoft Fabric災難復原指南