體驗特定災害復原指導

本文件提供了體驗特定指導，適用於在發生區域災害時復原 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. 請遵循每個元件的專用指示，將項目還原至其完整功能。

體驗特定復原方案

下列各節提供每個 Fabric 體驗的逐步指南，可協助客戶完成恢復程序。

資料工程

本指南會逐步引導您完成資料工程體驗的恢復程序。 其涵蓋 Lakehouse、Notebooks 和 Spark 工作定義。

Lakehouse

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

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

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

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

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

3. 若要從原始 Lakehouse 復原資料表和檔案，請參閱 OneLake 路徑的資料，例如 abfss (請參閱連線至 Microsoft OneLake)。 您可以在筆記本中使用下列程式碼範例 (請參閱 Microsoft Spark 公用程式簡介)，從原始 Lakehouse 取得檔案和資料表的 ABFS 路徑。 (將 C1.W1 取代為實際工作區名稱)

   mssparkutils.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
   
   mssparkutils.fs.cp(source, destination, true)
   
   val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelte <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
       println(s"Deleting file $destFileToDelete")
       mssparkutils.fs.rm(destFileToDelete, false)
   }
   
   mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. 在您執行指令碼之後，資料表就會出現在新的 Lakehouse 中。

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

若要只從原始 Lakehouse 復原特定的 Lakehouse 檔案或資料表，請使用 Azure 儲存體總管。 如需詳細步驟，請參閱整合 OneLake 與 Azure 儲存體總管。 針對大型資料大小，請使用方法 1。

注意

上述兩種方法均可復原 Delta 格式資料表的中繼資料和資料，因為中繼資料與 OneLake 中的資料位於同一位置並儲存。 針對使用 Spark 資料定義語言 (Data Definition Language, DDL) 指令碼/命令建立的非 Delta 格式資料表 (例如 CSV、Parquet 等)，使用者須負責維護和重新執行 Spark DDL 指令碼/命令來進行復原。

筆記本

來自主要區域的 Notebooks 仍無法供客戶使用，且 Notebooks 中的程式碼不會複寫至次要地區。 若要復原新區域中的 Notebook 程式碼，有兩種方法可以復原 Notebook 程式碼內容。

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

讓此流程變得簡單且快速的最佳方式是使用 Fabric Git 整合，然後將筆記本與您的 ADO 存放庫同步處理。 服務容錯移轉至另一個區域之後，您可以使用存放庫在您建立的新工作區中重建筆記本。

1. 設定 Git 整合，然後選取 [連線並與 ADO 存放庫同步處理]。

   

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

   

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

   1. 在新建立的工作區中，再次連線到您的 Azure ADO 存放庫。

      

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

      

      

   3. 如果原始筆記本有預設的 Lakehouse，則使用者可以參閱 Lakehouse 區段來復原 Lakehouse，然後將新復原的 Lakehouse 連線至新復原的筆記本。

      

   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。 請注意，SJD 的歷史執行不會復原。

您可以從原始區域複製程式碼，方法是使用 Azure 儲存體總管，並在災害發生後手動重新連線 Lakehouse 參考，進而復原 SJD 項目。

1. 在新工作區 C2.W2 中建立新的 SJD 項目 (例如 SJD1)，其設定和組態與原始 SJD 項目 (例如語言、環境等) 相同。

2. 使用 Azure 儲存體總管，將程式庫、電源和快照從原始 SJD 項目複製到新的 SJD 項目。

   

3. 程式碼內容會出現在新建立的 SJD 中。 您必須手動將新復原的 Lakehouse 參考新增至工作 (請參閱 Lakehouse 恢復步驟)。 使用者需要手動重新輸入原始命令列引數。

   

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

如需有關 Azure 儲存體總管的詳細資料，請參閱整合 OneLake 與 Azure 儲存體總管。

資料科學

本指南會逐步引導您完成資料可選體驗的恢復程序。 其涵蓋 ML 模型和實驗。

ML 模型和實驗

主要區域中的資料科學項目仍無法供客戶使用，而且 ML 模型和實驗中的內容和中繼資料不會複寫到次要地區。 若要在新區域中將其完全復原，請將程式碼內容儲存在版本控制系統中 (例如 Git)，並在災害發生後手動重新執行程式碼內容。

1. 復原筆記本。 請參閱 Notebook 恢復步驟。

2. 設定、過去執行計量及中繼資料不會複寫到配對的區域。 您必須重新執行資料科學程式碼的每個版本，才能在災害發生後完整復原 ML 模型和實驗。

資料倉儲

本指南會逐步引導您完成資料倉儲體驗的恢復程序。 其涵蓋倉儲。

倉儲

來自原始區域的倉儲仍無法供客戶使用。 若要復原倉儲，請使用以下兩個步驟。

1. 在工作區 C2.W2 中為您從原始倉儲複製的資料建立新的臨時 Lakehouse。

2. 利用倉儲總管和 T-SQL 功能填入倉儲的 Delta 資料表 (請參閱 Microsoft Fabric 中資料倉儲中的資料表)。

注意

建議您根據您的開發做法，對倉儲程式碼 (結構描述、資料表、檢視、預存程序、函式定義和安全性程式碼) 進行版本設定並將其儲存在安全位置 (例如 Git)。

透過 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 方法，從 Lakehouses 復原倉儲資料表。 在此範例中，我們還會使用 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 倉儲變更應用程式中的連接字串。

注意

對於需要跨區域災害復原和完全自動化商務持續性的客戶，我們建議在不同的 Fabric 區域中保留兩個 Fabric 倉儲設定，並透過對兩個站點進行定期部署和資料擷取來維護程式碼和資料同位。

鏡像資料庫

來自主要區域的鏡像資料庫仍然無法供客戶使用，且設定不會復寫到次要區域。 若要在發生區域性失敗時復原它，您必須在不同的區域在另一個工作區中重新建立鏡像資料庫。

Data Factory

來自主要區域的 Data Factory 項目仍然無法供客戶使用，而且資料管線或資料流程 gen2 項目中的設定和組態不會複寫到次要地區。 若要在發生區域失敗時復原這些項目，您需要從不同的區域的另一個工作區中重新建立資料整合項目。 下列各節概述了詳細資料。

資料流程第 2 代

如果您想要在新區域中復原資料流程 Gen2 項目，您需要將 PQT 檔案匯出至 Git 等版本控制系統，然後在災害發生後手動復原資料流程 Gen2 內容。

1. 從您的資料流程 Gen2 項目中，於 Power Query 編輯器的 [首頁] 索引標籤中，選取 [匯出範本]。

   

2. 在 [匯出範本] 對話方塊中，輸入此範本的名稱 (必填) 和描述 (選填)。 完成時，選取確定。

   

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

4. 從 Power Query 編輯器的目前檢視窗格中，選取 [從 Power Query 範本匯入]。

   

5. 在 [開啟] 對話方塊中，瀏覽至您的預設下載資料夾，然後選取您在先前步驟中儲存的 .pqt 檔案。 然後選取 [開啟]。

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

資料管線

客戶無法在發生區域性災害時存取資料管線，且設定不會複寫到配對的區域。 建議您在不同區域的多個工作區中，建置關鍵資料管線。

Real-Time Intelligence

本指南會逐步引導您完成即時智慧體驗的恢復程序。 其涵蓋 KQL 資料庫/查詢集和 Eventstream。

KQL 資料庫/查詢集

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

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

1. 建立獨立的 KQL 資料庫：在專用 Fabric 容量上設定兩個或多個獨立的 KQL 資料庫/查詢集。 這些應該跨兩個不同的 Azure 區域 (最好是 Azure 配對區域) 進行設定，以最大化復原性。

2. 複寫管理活動：在一個 KQL 資料庫中採取的任何管理動作均應鏡像到另一個資料庫。 這可確保這兩個資料庫保持同步。要複寫的主要活動包括：

   • 資料表：確定資料表結構和結構描述定義在各資料庫之間保持一致。

   • 對應：複製任何必要對應。 請確定資料來源和目的地正確對齊。

   • 原則：確定這兩個資料庫都有類似的資料保留、存取和其他相關原則。

3. 管理驗證和授權：針對每個複本，設定必要權限。 請確定已建立適當的授權層級，同時授予必要人員存取權，並維護安全性標準。

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

Eventstream

Eventstream 是 Fabric 平台中的集中位置，可擷取、轉換和路由即時事件到各個目的地 (例如 Lakehouses、KQL 資料庫/查詢集)，且沒有程式碼體驗。 只要災害復原支援目的地，Eventstream 就不會遺失資料。 因此，客戶應該使用這些目的地系統的災害復原功能來保證資料可用性。

客戶也可以在多個 Azure 區域中部署相同的 Eventstream 工作負載，作為多網站主動/主動策略的一部分，進而達成異地備援。 藉助多網站主動/主動方法，客戶可以在任何已部署區域中存取其工作負載。 這種方法是最複雜且成本最高的災害復原方法，但在大部分情況下，它可以將恢復時間減少到接近零。 若要完全異地備援，客戶可以

1. 在不同的區域中建立其資料來源的複本。

2. 在對應的區域中建立 Eventstream 項目。

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

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

相關資訊

• Microsoft Fabric 災害復原指南