Erfarenhetsspecifik vägledning för återställning efter katastrof

Den här artikeln ger erfarenhetsspecifik vägledning för att återställa din Fabric-data vid en regional katastrof.

Exempelscenario

Många vägledningsavsnitt i denna artikel använder följande exempelscenario för förklaring och illustration. Gå tillbaka till det här scenariot efter behov.

Anta att du har en kapacitet C1 i region A som har en arbetsyta W1. Om du har aktiverat katastrofåterställning för kapacitet C1, replikeras OneLake-data till en säkerhetskopia i region B. Om region A drabbas av störningar, redundansväxlar Fabric-tjänsten i C1 till region B.

Följande bild illustrerar det här scenariot. Rutan till vänster visar det störda området. Rutan i mitten representerar fortsatt tillgänglighet för data efter redundansväxling, och rutan till höger visar den fullständigt täckta situationen när kunden agerar för att återställa sina tjänster till full funktion.

Här är den allmänna återställningsplanen:

1. Skapa en ny Fabric-kapacitet C2 i en ny region.

2. Skapa en ny W2-arbetsyta i C2, inklusive motsvarande objekt med samma namn som i C1. W1.

3. Kopiera data från den störda C1. W1 till C2. W2.

4. Följ de dedikerade anvisningarna för varje komponent för att återställa objekt till deras fullständiga funktion.

Den här återställningsplanen förutsätter att klientorganisationens hemregion förblir i drift. Om hyresgästens hemregion drabbas av ett avbrott är stegen som beskrivs i denna artikel beroende av dess återställning, vilket först måste initieras och slutföras av Microsoft.

Erfarenhetsspecifika återställningsplaner

Följande avsnitt ger steg-för-steg-guider för varje Fabric-upplevelse för att hjälpa dig genom återhämtningsprocessen.

Datateknik

Den här guiden vägleder dig genom återställningsprocedurerna för data engineering-upplevelsen. Den täcker sjöhus, anteckningsböcker, Spark-jobbdefinitioner, användardatafunktioner och GraphQL-API:er.

Sjöhus

Lakehouses från den ursprungliga regionen är fortfarande otillgängliga för kunder. För att återställa ett sjöhus kan kunderna återskapa det i arbetsytan C2. W2. Vi rekommenderar två metoder för att återställa sjöhus:

Metod 1: Använda anpassat skript för att kopiera Lakehouse Delta-tabeller och -filer

Kunder kan återskapa lakehouses med hjälp av ett anpassat Scala-skript.

1. Skapa lakehouse (till exempel LH1) i den nyligen skapade arbetsytan C2. W2.

2. Skapa en ny notebook-fil i arbetsytan C2. W2.

3. Om du vill återställa tabellerna och filerna från det ursprungliga sjöhuset läser du data med OneLake-sökvägar som abfss (se Ansluta till Microsoft OneLake). Du kan använda följande kodexempel (se Introduktion till Microsoft Spark Utilities) i notebook för att hämta ABFS-sökvägarna för filer och tabeller från det ursprungliga datahuset. (Ersätt C1.W1 med det faktiska arbetsytenamnet)

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

4. Använd följande kodexempel för att kopiera tabeller och filer till det nyligen skapade lakehouse.

   1. För Delta-tabeller måste du kopiera tabell ett i taget för att återställa i det nya sjöhuset. När det gäller Lakehouse-filer kan du kopiera hela filstrukturen med alla underliggande mappar med ett enda utförande.

   2. Kontakta supportteamet för tidsstämpeln för den övergång som krävs i skriptet.

   %%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. När du har kört skriptet visas tabellerna i det nya sjöhuset.

Metod 2: Använd Azure Storage Explorer för att kopiera filer och tabeller

Om du bara vill återställa specifika Lakehouse-filer eller tabeller från det ursprungliga sjöhuset använder du Azure Storage Explorer. Mer information finns i Integrera OneLake med Azure Storage Explorer. För stora datastorlekar använder du Metod 1.

Återställning av materialiserade sjövyer för Fabric

Efter failover kan du inte få tillgång till materialiserade sjövyer från det ursprungliga området. Failover-processen replikerar inte uppdateringsscheman eller exekveringshistorik till den sekundära regionen. För att återställa dessa objekt, genomför följande steg efter att du återställt dina Lakehouse-data:

• Återställ Lakehouse-tabellerna genom att använda Approach 1 eller Approach 2 som beskrivits tidigare i denna artikel. Kopiera endast källtabellerna.
• Återställ de notebook-filer som innehåller dina MLV-definitioner. För återhämtningssteg, se avsnittet Anteckningsbok .
• Kör de återställda notebook-filerna för att återskapa MLV:erna i nya Lakehouse. Information om hur du skapar MLV:er finns i Skapa en materialiserad sjövy. Om du kopierade MLV:er i det tidigare steget, kör CREATE OR REPLACE när du återskapar dem.
• Återskapa manuellt MLV-uppdateringsscheman i den nya arbetsytan. Du kan inte återställa schemahistorik eller exekveringsmått.
• Om dina MLV:er används för att mata in information i semantiska modeller eller rapporter, bör du kontrollera och uppdatera lakehouse-ID:t och datamängds-ID:t efter behov. Återanslut rapporter till den uppdaterade semantiska modellen och verifiera datas färskhet.

bärbar dator

Anteckningsböcker från primärregionen är fortfarande otillgängliga för kunder, och koden i anteckningsböckerna replikeras inte till sekundärregionen. För att återställa anteckningsbokskod i den nya regionen, använd en av följande metoder.

Metod 1: Användarhanterad redundans med Git-integrering (i offentlig förhandsversion)

Använd Fabric Git-integration för att synkronisera din notebook med ditt Azure DevOps (ADO)-repo. Efter att tjänsten har gått över till en annan region, använd repoet för att bygga om anteckningsboken i den nya arbetsytan du skapat.

1. Konfigurera Git-integrering för din arbetsyta och välj Anslut och synkronisera med ADO-lagringsplats.

   

   Följande bild visar den synkroniserade notebook-filen.

   

2. Återställa notebook-filen från ADO-lagringsplatsen.

   1. På den nyligen skapade arbetsytan ansluter du till din Azure ADO-lagringsplats igen.

      

   2. Välj källkontroll-knappen. Välj sedan relevant gren av lagringsplatsen. Välj sedan Uppdatera alla. Den ursprungliga anteckningsboken visas.

      

      

   3. Om den ursprungliga anteckningsboken har ett standardlakehouse kan du läsa avsnittet Lakehouse om du vill återställa lakehouset och sedan ansluta det nyligen återställda lakehouset till den nyligen återställda anteckningsboken.

      

   4. Git-integreringen stöder inte synkronisering av filer, mappar eller notebook-ögonblicksbilder i notebook-resursutforskaren.

      1. Om den ursprungliga anteckningsboken har filer i resursutforskaren för anteckningsboken:

         1. Spara filer eller mappar på en lokal disk eller på en annan plats.

         2. Ladda upp filen igen från din lokala disk eller molndiskar till den återställda anteckningsboken.

      2. Om den ursprungliga notebook-filen har en ögonblicksbild, sparar du även ögonblicksbilden till ditt eget versionskontrollsystem eller din lokala disk.

         

         

Mer information om Git-integrering finns i Introduktion till Git-integrering.

Metod 2: Manuell metod för att säkerhetskopiera kodinnehåll

Om du inte använder Git-integrationsmetoden, spara den senaste versionen av din kod, filer i resursutforskaren och notebook-snapshoten i ett versionshanteringssystem som Git. Återställ innehållet i anteckningsboken manuellt efter en katastrof:

1. Använd funktionen Importera anteckningsbok för att importera den anteckningsbokskod du vill återställa.

   

2. Efter importen går du till önskad arbetsyta (till exempel "C2. W2") för att komma åt den.

3. Om den ursprungliga notebook-filen har ett standardlakehouse, se avsnittet Lakehouse. Anslut sedan det nyligen återställda lakehouse (som har samma innehåll som det ursprungliga standard lakehouse) till den nyligen återställda notebook-filen.

4. Om den ursprungliga notebook-filen har filer eller mappar i resursutforskaren laddar du upp filerna eller mapparna som sparats i användarens versionskontrollsystem igen.

Definition av Spark-jobb

Spark-jobbdefinitioner (SJD) från primärregionen förblir otillgängliga, och OneLake replikerar huvuddefinitionsfilen och referensfilen i anteckningsboken till sekundärregionen. Om du vill återställa SJD i den nya regionen, följ de manuella stegen som beskrivs i detta avsnitt. Historiska spår av SJD återfinns inte.

Du kan återställa SJD-objekten genom att kopiera koden från den ursprungliga regionen med hjälp av Azure Storage Explorer och manuellt återansluta Lakehouse-referenser efter katastrofen.

1. Skapa ett nytt SJD-objekt (till exempel SJD1) i det nya arbetsområdet C2. W2, med samma inställningar och konfigurationer som det ursprungliga SJD-objektet (till exempel språk, miljö och så vidare).

2. Använd Azure Storage Explorer för att kopiera Libs, Mains och Snapshots från det ursprungliga SJD-objektet till det nya SJD-objektet.

   

3. Kodinnehållet finns i den nyskapade SJD. Du behöver manuellt lägga till den nyligen återfunna Lakehouse-referensen till jobbet (se Lakehouse-återhämtningsstegen). Användare behöver manuellt mata in de ursprungliga kommandoradsargumenten igen.

   

Nu kan du köra eller schemalägga din nyligen återställda SJD.

Mer information om Azure Storage Explorer finns i Integrate OneLake med Azure Storage Explorer.

Användardatafunktioner

För att återställa dina användardatafunktioner i ett hälsosamt område, använd en av följande metoder.

Metod 1: Med Git-integration (rekommenderas)

Den föredragna återhämtningsmekanismen är Fabric Git-integration. Genom att synkronisera användardatafunktionsprojekt med ett Azure DevOps- eller GitHub-repository kan du snabbt rekonstruera dem i en ny arbetsyta efter failover.

Förbered dig inför en katastrof

1. Konfigurera Fabric Git-integration för arbetsytan som är värd för användardatafunktionen.
2. Koppla arbetsytan till ett Azure DevOps- eller GitHub-arkiv.
3. Sätt all användardatafunktion i arkivet och synkronisera ändringar regelbundet.
4. Spara miljöspecifika inställningar separat i variabelbibliotek om det behövs.

Återställningssteg

Efter en regional katastrof:

1. Skapa en ny Fabric-kapacitet i en hälsosam region, som C2.
2. Skapa en ny arbetsyta, som W2, i den nya kapaciteten.
3. Koppla arbetsytan till samma Azure DevOps- eller GitHub-repository.
4. Öppna Källkontroll och synkronisera innehållet i lagringsplatsen med arbetsytan.
5. Återskapa eller återställ alla beroende Fabric-resurser, till exempel lakehouses, SQL-databaser i Fabric, datalager och Business Events.
6. Omdistribuera användardatafunktionerna.
7. Validera funktionsexekvering och beroendekoppling.
8. Uppdatera nedströmsapplikationer, datapipelines eller andra integrerade system så att de hänvisar till de återställda funktionerna.
9. Fullständig fullständig validering av alla dina scenarier.

Viktiga överväganden

• Git-integration återställer endast källkod och projektresurser.
• Historiska avrättningsloggar återfinns inte.
• Nedströmssystem kan kräva ombindning av slutpunkter.

För mer information, se Källkodshantering och distribution för användardatafunktioner.

Metod 2: Manuell återhämtning

Om Git-integrationen inte konfigurerades före katastrofen kan du manuellt rekonstruera användardatafunktioner från källkodsbackuper.

Förbered dig inför en katastrof

Utför regelbundet följande uppgifter och lagra objekten i ett externt versionshanteringsarkiv eller en backupplats:

• Exportera källkoden för funktionen till ett GitHub-arkiv.
• Dokumentera och bevara beroendeinformation.
• Dokumentmiljöinställningar.

Återställningssteg

Efter en regional katastrof:

1. Skapa en ny Fabric-kapacitet i en hälsosam region, som C2.
2. Skapa en ny arbetsyta, till exempel W2.
3. Återställ alla resurser som krävs av funktionen, inklusive lakehouses, SQL-databaser i Fabric, lagerlokaler, eventhouses och externa tjänster.
4. Skapa ett nytt projekt för användardata.
5. Importera eller återskapa funktionens källkod.
6. Tillämpa körningskonfigurationsinställningarna igen.
7. Installera om alla funktionsberoenden.
8. Omdistribuera funktionen.
9. Konfigurera om autentisering och auktorisation.
10. Återskapa utgivare eller konsumenter för affärshändelser, om sådana används.
11. Genomför end-to-end-valideringstester för dina scenarier och integrationer.

GraphQL

GraphQL-objekt från den primära regionen är inte tillgängliga efter en regional katastrof och GraphQL-definitioner och konfigurationer replikeras inte till den sekundära regionen. Om du vill återställa GraphQL i en ny region använder du någon av följande metoder.

Metod 1: Användarstyrd redundans med Git-integration

Det bästa sättet att göra den här processen enkel och snabb är att använda Fabric Git-integrering och sedan synkronisera GraphQL med din ADO-lagringsplats. När tjänsten växlar över till en annan region kan du använda repot för att bygga upp GraphQL på nytt i den nya arbetsyta som du skapade.

1. Skapa en ny arbetsyta i målkapaciteten och regionen.

2. Återställ alla beroende datakällor, till exempel Lakehouse-, Warehouse- eller SQL-databaser, genom att följa respektive återställningssteg.

3. Uppdatera GraphQL-definitionen för att peka på de nyligen återställda resurserna genom att ändra miljöspecifika referenser såsom källarbetsyts-ID:n, källartikel-ID:n och anslutningsdetaljer. Det här steget säkerställer korrekt bindning vid distributionstillfället.

4. Distribuera om GraphQL-objekt från Git-arkivet till den nya arbetsytan. Det här steget återskapar API-strukturen och konfigurationen med hjälp av de uppdaterade definitionerna.

5. Applicera om objektinställningar, inklusive roller, åtkomstkontroller och autentiseringskonfiguration.

6. Tillämpa slutpunktsreferenser igen genom att uppdatera program eller integreringar för att använda den nyligen skapade GraphQL-slutpunkten.

7. Uppdatera alla befintliga distributionspipelines som pekade på den gamla arbetsytan så att de hänvisar till den nyligen skapade arbetsytan.

8. Verifiera funktionerna från slutpunkt till slutpunkt för API:et.

Metod 2: Manuell metod

Om du inte använder Git-integreringsmetoden kan du använda följande manuella metod för att återställa GraphQL.

1. Skapa en ny arbetsyta i målkapaciteten och regionen.

2. Återställa alla beroende datakällor, till exempel Lakehouse-, Warehouse- eller SQL-databaser.

3. Återskapa GraphQL-API:et manuellt på den nya arbetsytan, inklusive schemadefinitioner, datakällanslutningar och relationer.

4. Applicera om objektinställningar, inklusive roller, åtkomstkontroller och autentiseringskonfiguration.

5. Tillämpa slutpunktsreferenser igen genom att uppdatera program eller integreringar för att använda den nyligen skapade GraphQL-slutpunkten.

6. Uppdatera alla befintliga distributionspipelines som pekade på den gamla arbetsytan så att de hänvisar till den nyligen skapade arbetsytan.

7. Verifiera funktionerna från slutpunkt till slutpunkt för API:et.

Viktiga överväganden

1. GraphQL förlitar sig på externa beroenden (till exempel Lakehouse, Warehouse och SQL), som du måste återställa före GraphQL-distributionen.

2. GraphQL API-definitioner innehåller miljöspecifika referenser (till exempel sourceWorkspaceId och sourceItemId). När du återställer i en ny region kan dessa referenser bli ogiltiga. Uppdatera dem så att de pekar på nyligen etablerade resurser.

3. Automatisk ombindning av datakällor garanteras inte i haveriberedskapsscenarier, särskilt när du använder sparade autentiseringsuppgifter eller anslutningar mellan arbetsytor.

4. Andra objektinställningar som övervakning, auktorisering, RBAC, introspektion och mer följer inte med efter failover. Du måste återupprätta de här inställningarna i den nya regionen.

References

• Översikt över Fabric Git-integrering – Microsoft Fabric | Microsoft Learn

• Pipelines för källkontroll och distribution i API för GraphQL – Microsoft Fabric | Microsoft Learn 

App

Systemet replikerar inte Fabric Apps, inklusive deras kod, konfiguration och metadata, till sekundära regioner. Om primärregionen misslyckas förblir appen otillgänglig. För återställning, lagra appens källkod utanför systemet i GitHub, Azure DevOps eller något annat källkontrollsystem. Återställ appdata separat genom att följa riktlinjerna för katastrofåterställning för varje underliggande Fabric-datalager.

Manuell strategi

Du kan manuellt återställa en Fabric App efter en regional katastrof genom att använda applikationens källkod och Rayfin CLI. 

Prerequisites 

Innan en katastrof inträffar:

• Lagra Fabric App-källkoden i GitHub, Azure DevOps eller ett annat källkontrollarkiv. 

• Dokumentera processen för återhämtning.  

Återhämtningssteg 

1. Skapa en ny arbetsyta i målkapaciteten och regionen. 

2. Återställ beroende resurser innan du distribuerar applikationen igen.  

3. Hämta den senaste källkoden för Fabric App från ditt versionskontrollarkiv eller lokal backup. 

4. Från applikationskällskatalogen distribuerar du Fabric App till återställningsarbetsytan genom att använda Rayfin CLI. Kör rayfin up --workspace <new workspace>. 

5. Återställ appens barnobjekt (SQL-databas i Fabric) genom att följa dess respektive återställningsprocedurer.  

6. Återställ vid behov inställningar på objektnivå, inklusive roller och åtkomstkontroller.  

7. Verifiera applikationens funktionalitet och se till att användarna har rätt behörigheter.  

Viktigt 

• Underhåll källkoden för Fabric App utanför Fabric-regionen för att möjliggöra återställning.  

• Applikationsdata i databasen återställs inte som en del av Fabric App-distributionsprocessen och måste återställas separat.  Du kan manuellt återställa en Fabric App efter en regional katastrof genom att använda applikationens källkod och Rayfin CLI. 

Azure Databricks Storage

Azure Databricks Storage lagrar data i OneLake. För att skydda dina data mot ett regionalt avbrott, aktivera katastrofåterställningsinställningen för den Fabric-kapacitet som innehåller Azure Databricks Storage-objektet. När du aktiverar denna inställning replikerar OneLake asynkront datan till Azures parkopplade region.

Om OneLake initierar en regional failover kan applikationer fortsätta att komma åt den replikerade datan via OneLakes globala endpoint efter att failovern är klar. Fortsatt åtkomst via OneLakes publika API:er kräver inte att man skapar ett nytt Azure Databricks Storage-objekt eller kopierar datan till en annan arbetsyta.

Gå igenom OneLake Disaster Recovery and Data Protection för tillämpliga beteenden, överväganden och begränsningar.

För Azure Databricks-specifik katastrofåterställningsplanering, se Disaster recovery - Azure Databricks.

Datavetenskap

Den här guiden vägleder dig genom återställningsprocedurerna för Data Science-upplevelse. Den omfattar ML-modeller och experiment.

ML-modell och experiment

Data Science-objekt från primärregionen är fortfarande otillgängliga för kunder, och innehållet och metadata i ML-modeller och experiment replikeras inte till sekundärregionen. Om du vill återställa dem helt i den nya regionen sparar du kodinnehållet i ett versionskontrollsystem (till exempel Git) och kör kodinnehållet igen manuellt efter katastrofen.

1. Återställ anteckningsboken. Se Notebook-återställningssteg.

2. Konfiguration, historiskt körda metriker och metadata replikeras inte till den parade regionen. Du behöver köra om varje version av din data science-kod för att fullt ut återställa ML-modeller och experiment efter katastrofen.

Datalager

Den här guiden guidar dig genom återhämtningsprocedurerna för den Fabric Data Warehouse arbetsbelastningen. Det omfattar lagervaror.

Lager

Du kan inte komma åt lager från den ursprungliga regionen. Använd följande två steg för att återställa lager.

1. Skapa ett nytt tillfälligt lakehouse i arbetsytan C2.W2 för de data som du kopierar från det ursprungliga warehouse.

2. Fyll lagrets Delta-tabeller genom att använda warehouse Explorer och T-SQL-funktionerna (se Tabeller i Fabric Data Warehouse).

Datainmatning via Lakehouse- och T-SQL-kod

I nyskapade arbetsytan C2. W2:

1. Skapa ett interim lakehouse "LH2" i C2.W2.

2. Återställ Delta-tabellerna i det tillfälliga lakehouse från det ursprungliga lagret genom att följa stegen för återställning av lakehouse.

3. Skapa ett nytt lager "WH2" i C2. W2.

4. Anslut det temporära lakehouse i din databasutforskare.

5. Beroende på hur du distribuerar tabelldefinitioner innan dataimport kan den faktiska T-SQL-filen som används för import variera. För att återställa Warehouse-tabeller från lakehouses kan du använda metoderna INSERT INTO, SELECT INTO eller CREATE TABLE AS SELECT. I följande exempel använder vi INSERT INTO. Om du använder följande kod, ersätt exempel med faktiska tabell- och kolumnnamn.

   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. Byt anslutningssträngen i de applikationer som använder ditt Fabric-lager.

Speglad databas

Kunder kan inte komma åt speglade databaser från primärregionen, och inställningarna replikeras inte till sekundärregionen. För att återställa en speglad databas efter ett regionalt fel måste du återskapa den i en annan arbetsyta från en annan region.

Data Factory

Kunder kan inte komma åt Data Factory-objekt från primärregionen, och inställningarna och konfigurationerna i pipelines eller Dataflow Gen2-objekt replikeras inte till sekundärregionen. För att återställa dessa objekt efter ett regionalt fel behöver du återskapa dina Data Integration-objekt i en annan arbetsyta från en annan region. I följande avsnitt beskrivs informationen.

Dataflöden Gen2

För att återställa ett Dataflow Gen2-objekt i den nya regionen, exportera en .pqt fil till ett versionshanteringssystem som Git och återställ sedan manuellt Dataflow Gen2-innehållet efter katastrofen.

1. Från ditt Dataflow Gen2-objekt, i fliken Hem i Power Query-redigeraren, välj Exportera mall.

   

2. I dialogen för exportmall skriver du in ett namn (obligatoriskt) och en beskrivning (valfritt) för denna mall. När du är klar klickar du på OK.

   

3. Efter katastrofen skapar du ett nytt Dataflow Gen2-objekt i den nya arbetsytan "C2. W2".

4. Välj Importera från en Power Query-mall i det aktuella visningsfönstret i Power Query-redigeraren.

   

5. I öppna-dialogen, bläddra till din standardmapp för nedladdningar och välj filen .pqt du sparade i föregående steg. Välj sedan Öppna.

6. Mallen importeras sedan till ditt nya Dataflow Gen2-objekt.

Spara som-funktionen för Dataflows stöds inte vid katastrofåterställning.

Pipelines

Kunder kan inte komma åt pipelines i händelse av regional katastrof och konfigurationerna replikeras inte till den kopplade regionen. Bygg dina kritiska pipelines i flera arbetsytor över olika regioner.

Kopieringsjobb

CopyJob-användare måste vidta proaktiva åtgärder för att skydda mot en regional katastrof. Följande metod säkerställer att en användares CopyJobs förblir tillgängliga efter en regional katastrof.

Användarhanterad redundans med Git-integrering (i offentlig förhandsversion)

Det bästa sättet att göra denna process enkel och snabb är att använda Fabric Git-integration, och sedan synkronisera din CopyJob med ditt Azure DevOps-repo. När tjänsten växlar över till en annan region kan du använda förvaret för att återskapa CopyJob i den nya arbetsytan du skapade.

1. Konfigurera din arbetsytas Git-integration och välj koppla upp och synka med Azure DevOps-repo.

   

   Följande bild visar det synkroniserade CopyJob.

   

2. Återställ CopyJob från Azure DevOps-repot.

   1. I det nyskapade arbetsutrymmet, koppla upp och synka till ditt Azure DevOps-repo igen. Alla Fabric-objekt i detta arkiv laddas automatiskt ner till din nya arbetsyta.

      

   2. Om det ursprungliga CopyJob använder ett Lakehouse kan användarna referera till avsnittet Lakehouse för att återställa Lakehouse och sedan ansluta det nyligen återställda CopyJob till det nyligen återställda Lakehouse.

Mer information om Git-integrering finns i Introduktion till Git-integrering.

Apache Airflow-jobb

Du måste vidta proaktiva åtgärder för att skydda Apache Airflow-jobb i Fabric mot en regional katastrof.

Hantera redundans genom att använda Fabric Git-integration. Först, synkronisera ditt Airflow-jobb med ditt ADO-repo. Om tjänsten går över till en annan region kan du använda arkivet för att bygga om Airflow-jobbet i den nya arbetsytan du skapat.

Följ dessa steg för att uppnå detta mål:

1. Konfigurera din arbetsytas Git-integration och välj Connect och synka med ADO-repot.

2. Efter det ser du att ditt Airflow-jobb är synkat med ditt ADO-repo.

3. Om du behöver återställa Airflow-jobbet från ADO-lagringsplatsen skapar du en ny arbetsyta, ansluter och synkroniserar till din Azure ADO-lagringsplats igen. Alla Fabric-artiklar, inklusive Airflow, i detta arkiv laddas automatiskt ner till din nya arbetsplats.

Realtidsinformation

Den här guiden vägleder dig genom återställningsprocedurerna för realtidsinformationsupplevelsen. Den täcker KQL-databaser, frågeuppsättningar och händelseströmsobjekt.

Activator

Aktivatorobjekt från den primära regionen är fortfarande inte tillgängliga för kunder, och Utlösardefinitioner för Aktivering replikeras inte till den sekundära regionen. Användare av Activator måste vidta proaktiva åtgärder för att förbereda sig inför regional katastrofåterställning.

För att säkerställa att du kan återställa Aktivatorobjekt i händelse av en regional katastrof konfigurerar du Fabric Git-integrering för att säkerhetskopiera utlösardefinitioner och återställa dem på en arbetsyta i en annan region.

1. Konfigurera Fabric Git-integrering för arbetsytan som innehåller ditt Activator-objekt och synkronisera dina utlösardefinitioner med din Git-lagringsplats.
2. Behåll aktiveringsutlösarens definitioner bekräftade och synkroniserade regelbundet.
3. Under återställningen skapar du en ny arbetsyta i målregionen (C2. W2), anslut den till samma lagringsplats och synkronisera för att återställa utlösardefinitionerna.
4. Konfigurera om och verifiera alla aktivatordatakällor och beroenden i den nya arbetsytan.

Mer information om Git-integrering finns i Introduktion till Git-integrering.

Grafmodell/frågesamling

Kunder kan inte komma åt Graph Model- och Graph-frågesetsobjekt från primärregionen, och Fabric replikerar inte dessa objekt till sekundärregionen. För att återhämta dig, skapa eller använda en kapacitet i en annan region och återskapa Graph-modellen och objekten i Graph-frågeuppsättningen där.

1. Skapa eller använd en befintlig Fabric kapacitet i en annan region som inte påverkas av katastrofen.

2. Skapa en ny arbetsyta eller använd en befintlig arbetsyta i den kapaciteten.

3. Återskapa Graph-modellobjektet i det sekundära arbetsytet (refererat i steg 2). Omkonfigurera modelldefinitionen, inklusive noder, kanter och andra, för att matcha den ursprungliga Graph-modellen.

4. Om det ursprungliga sjöhuset finns i den misslyckade regionen kan du återställa det först genom att följa Lakehouse-avsnittet.

5. Koppla ett sjöhus som OneLake-datakälla för det nyligen skapade Graph-modellobjektet. Använd det återställda sjöhuset om det fanns i den misslyckade regionen eller återansluta till det befintliga sjöhuset om det förblir tillgängligt.

6. Omkonfigurera eventuella dataladdningsscheman eller anslutningar för grafmodellen i den nya arbetsytan.

7. Återskapa Graph-frågesetobjektet i den sekundära arbetsytan. Mata manuellt in frågorna och eventuella sparade frågekonfigurationer från den ursprungliga Graph-frågeuppsättningen.

KQL-databas/frågeuppsättning

KQL-databaser och frågesetanvändare måste vidta proaktiva åtgärder för att skydda mot en regional katastrof. Följande metod säkerställer att vid en regional katastrof förblir data i dina KQL-databaser och frågeuppsättningar säkra och tillgängliga.

Använd följande steg för att garantera en effektiv haveriberedskapslösning för KQL-databaser och frågeuppsättningar.

1. Sätt upp oberoende KQL-databaser: Konfigurera två eller flera oberoende KQL-databaser och frågeuppsättningar på dedikerade Fabric-kapaciteter. Sätt upp dessa databaser över två olika Azure-regioner (helst Azure-parade regioner) för att maximera motståndskraften.

2. Replikera hanteringsaktiviteter: Spegela alla hanteringsåtgärder du utför i en KQL-databas i den andra. Detta tillvägagångssätt håller båda databaserna synkroniserade. Viktiga aktiviteter att replikera inkluderar:

   • Tabeller: Se till att tabellstrukturerna och schemadefinitionerna är konsekventa över databaserna.

   • Mappning: Duplicera alla nödvändiga mappningar. Se till att datakällor och destinationer stämmer överens korrekt.

   • Policyer: Säkerställ att båda databaserna har liknande datalagring, åtkomst och andra relevanta policyer.

3. Hantera autentisering och auktorisation: Ställ in de nödvändiga behörigheterna för varje replik. Se till att du fastställer rätt behörighetsnivåer som ger tillgång till rätt personal samtidigt som säkerhetsstandarderna upprätthålls.

4. Parallell datainmatning: Om du vill hålla data konsekventa och redo i flera regioner läser du in samma datauppsättning i varje KQL-databas samtidigt som du matar in den.

Evenemangsström

En händelseström är en central plats i Fabric plattform för att samla in, transformera och dirigera realtidshändelser till olika mål (till exempel lakehouses, KQL-databaser/frågeuppsättningar) med en kodfri upplevelse. Så länge destinationerna stödjer katastrofåterställning förlorar inte händelseströmmar data. Använd därför katastrofåterställningsmöjligheterna i dessa destinationssystem för att garantera datatillgänglighet.

Du kan också uppnå geo-redundans genom att distribuera identiska händelseströmsarbetsbelastningar i flera Azure-regioner som en del av en multi-site active/active-strategi. Med en active/active-arkitektur för flera platser kan du komma åt din arbetslast i vilken som helst av de driftsatta regionerna. Den här metoden är den mest komplexa och kostsamma metoden för haveriberedskap, men det kan minska återställningstiden till nära noll i de flesta situationer. För att vara helt georedundant:

1. Skapa kopior av dina datakällor i olika regioner.

2. Skapa eventstream-objekt i motsvarande regioner.

3. Anslut dessa nya objekt till identiska datakällor.

4. Lägg till identiska mål för varje händelseström i olika regioner.

Affärshändelser, Fabric händelser och Azure händelser

Även om Business Events, Fabric Events och Azure Events delar samma Real-Time hubbinfrastruktur i Microsoft Fabric, har de distinkta ursprung, beteenden och återställningskrav. Förstå dessa skillnader innan du planerar för katastrofåterställning:

• Fabric Events är evenemangsprenumerationer som reagerar på aktivitet som produceras av Fabric-resurser själva. Dessa händelser omfattar ändringar i livscykeln för objekt på arbetsytan (till exempel när man skapar, uppdaterar eller tar bort lakehouses, notebook-filer eller datalager), jobbkörningar (såsom pipelinekörningar eller körning av notebook-filer) samt fil- och mappåtgärder i OneLake. Dessa prenumerationer är push-baserade och tillfälliga. Prenumerationerna replikeras inte till sekundärregionen.

• Azure Händelser är händelseprenumerationer på aktiviteter som skapats av Azure Blob Storage konton. Dessa Azure resurser finns oberoende av någon Fabric kapacitet eller region. Även om Azure Blob Storage-resursen i sig kan förbli tillgänglig under ett regionalt avbrott i Fabric, replikeras inte de prenumerationer som konfigurerats i Real-Time-hubben till den sekundära regionen och måste återskapas.

• Affärshändelser är en distinkt funktion i Fabric Real-Time Intelligence som gör det möjligt för team att definiera, publicera och agera på meningsfulla affärssignaler. Affärshändelser genereras inifrån Fabric via Activator, Spark Notebooks eller User Data Functions, och publiceras sedan till Real-Time hubb där nedströmsanvändare som Activator, Eventhouse eller Power Automate kan reagera på dem. Händelsescheman styrs centralt genom Schema Registry. Eventhouse lagrar automatiskt varje publicerad affärshändelse, så dess återställning påverkar direkt tillgängligheten för affärshändelsehistorik. Ingen av utgivar- eller konsumentkonfigurationerna, schemadefinitionerna eller prenumerationerna replikeras till den sekundära regionen.

Använd följande steg för att återställa Business Events, Fabric-händelser och Azure-händelser i den nya arbetsytan i återställningsregionen.

För affärshändelser:

1. Återskapa affärshändelsen som används av utgivare och konsumenter genom att följa artikeln Skapa affärshändelser i Fabric Real-Time Hub. När du skapar affärshändelsen skapar du resursen Händelseschemauppsättning. Eventhouse-resursen är valfri beroende på scenariot. Om du säkerhetskopierade din händelseschema-uppsättning med Git-integration, återställ den först genom att följa avsnittet för händelseschema-uppsättningen, och peka sedan affärshändelsen mot den återställda schema-uppsättningen.

2. Återskapa alla utgivarobjekt som genererar affärshändelser, till exempel Spark-notebook-filer eller användardatafunktioner, i den nya arbetsytan genom att följa de här artiklarna: Använd användardatafunktion som utgivare för affärshändelser, Använd Activator som utgivare för affärshändelser, Använd Notebook som utgivare för affärshändelser och Använd Eventstream som utgivare för affärshändelser.

3. Återskapa konsumentprenumerationerna i Real-Time-hubben (till exempel Activator-regler, anteckningsboksutlösare eller Power Automate-flöden) som ursprungligen reagerade på affärshändelser i den berörda regionen med hjälp av artiklarna Eventhouse och integrering av Real-Time-dashboard med affärshändelser och Använd affärshändelser från Activator.

4. Kontrollera att händelser flödar från slutpunkt till slutpunkt genom att kontrollera att prenumerationer är aktiva och att data anländer till de förväntade destinationerna i återställningsregionen.

För Fabric händelser:

1. Återskapa prenumerationer i Real-Time-hubben som pekar på objekten på arbetsytan, jobb eller sökvägar i OneLake som du har återställt i återställningsregionen genom att följa anvisningarna i artikeln Utforska Fabric-händelser i Fabric Real-Time-hubben.

2. Kontrollera att händelser flödar från slutpunkt till slutpunkt genom att kontrollera att prenumerationer är aktiva och att data anländer till de förväntade destinationerna i återställningsregionen.

För Azure händelser:

1. Azure Blob Storage-konton påverkas inte av ett regionalt avbrott i Fabric. Återskapa händelseprenumerationerna i Real-Time hubb som pekar på samma Azure Blob Storage konton genom att följa artikeln Ange aviseringar för Azure Blob Storage händelser i Real-Time hubb.

2. Kontrollera att händelser flödar från slutpunkt till slutpunkt genom att kontrollera att prenumerationer är aktiva och att data anländer till de förväntade destinationerna i återställningsregionen.

Händelseschemauppsättning

En händelseschemamängd är den Fabric delen som innehåller händelsetyp- och schemadefinitioner i Real-Time Intelligence. Andra funktioner bygger vidare på den: utgivare skriver händelser som följer dess scheman, och konsumenter läser enligt samma definitioner.

Händelsescheman från primärregionen förblir otillgängliga för kunder, och de replikeras inte till sekundärregionen. Men eftersom en händelseschema-uppsättning är en hållbar definierad definition snarare än en flyktig prenumeration, kan du säkerhetskopiera den i förväg och återställa den istället för att återskapa den för hand.

Rekommenderas: säkerhetskopiera med Fabric Git-integration

För att återställa ett händelseschema efter en regional katastrof, sätt upp Fabric Git-integration innan en katastrof inträffar och synkronisera arbetsytan som innehåller dina händelseschema-uppsättningar med ditt Git-repository.

1. Konfigurera Fabric Git-integration för arbetsytan som innehåller din event schema-uppsättning och synkronisera den med ditt Git-repository.

2. Se till att uppsättningen händelsescheman checkas in och synkroniseras regelbundet, särskilt efter att händelsetyper har lagts till eller nya schemaversioner har publicerats.

3. Under återställningen skapar du en ny arbetsyta i målregionen (C2. W2), koppla den till samma repository och synka för att återställa händelseschemaset. Eftersom den nya arbetsytan är tom tar Git Sync innehållet från arkivet in i arbetsytan.

4. Återskapa alla publicister och konsumenter som använder schema-uppsättningen, enligt riktlinjerna för dessa objekttyper.

5. Verifiera att utgivare kan publicera mot de återställda händelsetyperna och att konsumenter får händelser som förväntat.

Den synkroniserade definitionen inkluderar händelsetyperna i schemamängden, scheman och schemaversionerna. Den inkluderar inte utgivarregistreringar, konsumentprenumerationer eller evenemangshistorik. Återställ dessa separat, enligt riktlinjerna för de objekttyper som använder schemasetet.

Alternativ: återskapa manuellt

Om du inte konfigurerade Git-integration före katastrofen, återskapa händelseschema-setet i återställningsregionen genom att följa Create and manage event schema sets, och lägg sedan till händelsetyperna och scheman som det ursprungliga schema-setet innehöll genom att följa Create and manage event schemas in schema sets.

Map

Mappningsobjekt från den primära regionen är fortfarande inte tillgängliga för kunder och mappningsobjekten replikeras inte till den sekundära regionen.

Om du vill återställa ett mappningsobjekt när ett haveri inträffar konfigurerar du Fabric Git-integrering och synkronisera kartobjektet med git-lagringsplatsen.

När det nya regionen/kapaciteten i Fabric har konfigurerats under återhämtningsprocessen kan du använda arkivet för att återskapa kartobjektet i den nya arbetsytan som skapades. Eftersom den nya arbetsytan är tom hämtar Git sync innehållet från lagringsplatsen till den tomma arbetsytan. Det här steget ger liv åt kartobjektet igen.

Ontologi

Ontologianvändare måste vidta proaktiva åtgärder för att förbereda sig för regional katastrofåterhämtning. Den metod som beskrivs nedan säkerställer att ontologin efter en regional katastrof förblir återställningsbar och kan återställas snabbt.

Det enklaste och snabbaste sättet att aktivera återställning är att använda Fabric Git-integrering och synkronisera din ontologi med en Azure DevOps-lagringsplats (ADO). Om tjänsten växlar till en reservregion kan du använda den här lagringsplatsen för att återskapa ontologin i en nyskapad arbetsyta.

Ontologiobjekt i den primära regionen är inte tillgängliga för kunder efter en regional katastrof och Ontologiobjekt replikeras inte till den sekundära regionen.

Om du vill återställa ett ontologiobjekt under en katastrof konfigurerar du Fabric Git-integrering och synkronisera ontologiobjektet med din ADO-lagringsplats i förväg.

När den nya regionen och kapaciteten i Fabric har konfigurerats under återställningen kan du använda lagringsplatsen för att återskapa ontologiobjektet på en ny arbetsyta. Eftersom den nya arbetsytan är tom hämtar Git sync innehållet från lagringsplatsen till arbetsytan och återställer effektivt ontologiobjektet.

Ontologiagent

Användare av Ontology Agents måste vidta proaktiva åtgärder för att förbereda sig för regional katastrofåterställning. Metoden som beskrivs i detta avsnitt säkerställer att din Ontology Agent-upplevelse kan återställas i en nyskapad arbetsyta efter en regional katastrof.

Ontology Agent beror på ontologiobjektet och på alla datakällor som är kopplade till ontologin, såsom lakehouses. Kunder kan inte komma åt Ontology Agent-sessioner i primärregionen efter en regional katastrof, och Ontology Agent-sessioner replikeras inte till sekundärregionen. Aktiva chattsessioner, pågående åtgärder och konversationshistorik från den berörda regionen kan inte återupptas.

För att återställa Ontology Agent-upplevelsen under en katastrof, konfigurera Fabric Git-integration och synkronisera Ontology-objektet med ditt Azure DevOps (ADO)-repository i förväg.

Under återhämtningen, när den nya regionen och kapaciteten i Fabric är etablerade, slutför följande steg:

1. Skapa en ny arbetsyta i den nya kapacitetenheten.
2. Koppla den nya arbetsytan till samma ADO-repository som innehåller Ontologi-objektet.
3. Använd Git sync för att återställa Ontology-objektet i den nya arbetsytan.
4. Återställ alla beroende dataobjekt, såsom lakehouses, genom att följa riktlinjerna för dessa objekttyper.
5. Bekräfta att de återvunna uppgifterna finns tillgängliga i den parkopplade regionen. För OneLake-backad data, anta att datan replikeras till den parade regionen, men förutsätt inte att replikerade data behåller sin ordning under återställning.
6. Koppla det nyligen återvunna Ontology-objektet till de återvunna datakällorna.
7. Starta en ny Ontology Agent-session och verifiera att agenten kan ansluta till det återställda Ontology-objektet och datakällorna.

Planning

Den här artikeln beskriver återhämtningsprocedurerna för planeringsupplevelsen i IQ. Den beskriver de steg som krävs för att återställa nyckelkomponenter, inklusive planeringsblad, PowerTable-blad, intelligensblad, InfoBridge och relaterade datatillgångar.

Git-integrering för att återställa planobjekt

Den bästa metoden är att synkronisera alla planobjekt med en Azure DevOps (ADO) eller GitHub lagringsplats med hjälp av Fabric Git-integrering. Efter en redundansväxling använder du lagringsplatsen för att återställa objekten på den nya arbetsytan.

Före en katastrof (proaktiva åtgärder):

1. I arbetsytan W1 går du till Arbetsyteinställningar och konfigurerar Git-integrering.

2. Välj Anslut och synkronisera med din ADO eller GitHub lagringsplats.

3. Välj de objekt i planen som ska laddas upp till lagringsplatsen och välj Commit.

   

4. Bekräfta att Git-statusen för planobjekt är Synkroniserad.

5. Inför en disciplinerad commit-rutin – gör en commit efter varje betydande ändring i en plandefinition så att repositoryt alltid återspeglar det senaste tillståndet.

Återställningssteg:

1. Skapa en ny arbetsyta W2 i kapaciteten C2 i den felfria regionen.

2. I arbetsytan W2 går du till Arbetsyteinställningar och återansluter till samma ADO/GitHub-lagringsplats.

3. Välj Källkontroll. Välj relevant lagringsplatsgren och välj Uppdatera alla. Alla planobjekt laddas ned till W2.

Följande komponenter återställs efter återställning:

• PowerTable-blad: Inställningar för källtabeller, kolumnkonfiguration, radåtkomst, visuella egenskaper (layout, format med mera), radidentifiering, kommentarsinställningar, långsamt föränderliga dimensioner (SCD), godkännanden, automatiseringar och formulär.
• Planeringsblad: Bladegenskaper (formatering, villkorsstyrd formatering med mera), kommentarsinställningar, tillbakaskrivningsinställningar, dataindatakolumner, dataindatarader, scenarier och bokmärken.
• InfoBridge: InfoBridge-källor, InfoBridge-frågor, omvandlingssteg, tillbakaskrivningsmål, tillbakaskrivningsinställningar, länkade frågemappningar, frågegrupper, visuella egenskaper (blandning). Det går inte att återställa dessa objekt: filbaserade källor (CSV, Excel), blad för flera arbetsbelastningar som använder filbaserade källor.
• Intelligens: Alla diagram och matriser.

Återställning av SQL i Fabric för planering

Data som anges i planeringsblad, tabeller som används i PowerTable och tillbakaskrivningsdata lagras i SQL-databaser och måste betraktas som en del av din strategi för haveriberedskap. Information om hur du återställer SQL-databaser finns i avsnittet SQL-databas .

• Metadata för återställningsplan: Varje planobjekt är associerat med en __fabric_plan_sys databas som lagrar metadata för planeringsfunktioner, inklusive kommentarer, scenarier, dataindata och konfiguration av tillbakaskrivning. Den __fabric_plan_sys databasen återställs inte automatiskt och måste återställas uttryckligen.

• Återställa tillbakaskrivningsdatabaser: Om planen använder SQL-tillbakaskrivningsmål måste du även återställa de associerade databaserna manuellt. Konfigurerade SQL-tillbakaskrivningsmål återställs inte automatiskt.

• Återställ tabeller som används i PowerTable: Alla tabeller som skapas med PowerTable lagras i en SQL-databas i Fabric. Du måste också återställa dessa tabeller vid DR.

Driftagenter

Användare av driftagenten bör vidta proaktiva åtgärder för att förbereda sig för regional katastrofåterställning. Genom att följa den metod som beskrivs i det här avsnittet ser du till att dina agenter kan återställas snabbt efter ett regionalt avbrott.

Använd Fabric Git-integrering för att synkronisera din arbetsyta med en lagringsplats. Med den här metoden kan du rekonstruera agentkonfigurationer på en ny arbetsyta om tjänsten redundansväxlar till en annan region.

Operations Agent-objekt i primärregionen är inte tillgängliga vid en regional katastrof. Agentkonfigurationer, beteendemodeller och aktivitetsloggar replikeras inte till den sekundära regionen. Pågående åtgärder, aktiva chattsessioner och tidigare inmatade händelser vid tidpunkten för katastrofen går också förlorade.

För att förbereda för återställning konfigurerar du Fabric Git-integrering och synkroniserar dina agentobjekt med ADO-lagringsplatsen innan ett haveri inträffar.

När du återställer konfigurerar du din nya region och kapacitet i Fabric och använder sedan den synkroniserade lagringsplatsen för att återställa agentkonfigurationer till en ny arbetsyta. Git Sync hämtar det lagrade innehållet från lagringsplatsen till den tomma arbetsytan och återskapar dina agentobjekt.

När konfigurationerna har återställts kontrollerar du att alla refererade Eventhouse-databaser (KQL) eller regionspecifika datakällor är tillgängliga i den nya regionen. Uppdatera slutpunktsreferenser i agentkonfigurationer efter behov. Starta slutligen om dina agenter och låt användarna initiera nya chattsessioner. Tidigare konversationer kan inte återupptas.

Databases

Denna guide beskriver återställningsprocedurerna för databasens upplevelse.

SQL database

För att skydda mot ett regionalt fel kan användare av SQL-databaser vidta proaktiva åtgärder för att regelbundet exportera sina data och använda exporterade data för att återskapa databasen på en ny arbetsyta när det behövs.

Använd SqlPackage CLI-verktyget som erbjuder databasportabilitet och underlättar databasdistributioner.

1. Använd SqlPackage-verktyget för att exportera databasen till en .bacpac fil. Mer information finns i Exportera en databas med SqlPackage .
2. Lagra .bacpac filen på en säker plats som ligger i en annan region än databasen. Exempel inkluderar att lagra .bacpac filen i en Lakehouse som ligger i en annan region, använda ett geo-redundant Azure Storage-konto, eller använda ett annat säkert lagringsmedium i en annan region.
3. Om SQL-databasen och regionen inte är tillgängliga kan du använda .bacpac filen med SqlPackage för att återskapa databasen på en arbetsyta i en ny region – Arbetsyta C2. W2 i region B enligt beskrivningen i scenariot ovan. Följ stegen som beskrivs i Importera en databas med SqlPackage för att återskapa databasen med din .bacpac fil.

Den återskapade databasen är en oberoende databas från den ursprungliga databasen och återspeglar datatillståndet vid tidpunkten för exportåtgärden.

Överväganden för återställning efter fel

Den återskapade databasen är en oberoende databas. Data som läggs till i den återskapade databasen skulle inte återspeglas i originaldatabasen. Om du planerar att gå tillbaka till den ursprungliga databasen när hemregionen blir tillgänglig behöver du överväga att manuellt stämma av data från den återskapade databasen till den ursprungliga databasen.

HorizonDB-databas

För att skydda mot ett regionalt fel kan användare av HorizonDB-databaser vidta proaktiva åtgärder för att periodiskt exportera sin data och använda den exporterade datan för att återskapa databasen i en ny arbetsyta vid behov.

Använd PostgreSQL pg_dump och pg_restore kommandoradsverktygen för att säkerhetskopiera och återställa databasen.

1. Installera Azure CLI och logga in med en Microsoft Entra-identitet som har behörighet att läsa källdatabasen. Ersätt <tenant-id> med ID:t för tenanten som innehåller din HorizonDB-databas:

   az login --tenant <tenant-id> --allow-no-subscriptions
   

2. Hämta en Microsoft Entra-åtkomsttoken för PostgreSQL och sätt den som miljövariabeln PGPASSWORD. Följande kommandon gäller för Bash:

   PGPASSWORD="$(az account get-access-token --resource https://ossrdbms-aad.database.windows.net --query accessToken --output tsv)"
   export PGPASSWORD
   

   pg_dump och pg_restore använder PGPASSWORD som databaslösenord. Behandla tokenen som en hemlighet. Spara det inte i skript, anslutningssträngar eller dumpfiler.

3. I samma skal, använd pg_dump för att exportera databasen till en dumpfil i eget format. Ersätt platshållarvärdena med anslutningsdetaljerna för din HorizonDB-databas. För <user>, använd PostgreSQL-användarnamnet kopplat till Microsoft Entra-identiteten du loggade in med:

   pg_dump "host=<source-host> port=5432 dbname=<source-database> user=<user> sslmode=require" --format=custom --file=<source-database>.dump
   

4. Lagra dumpfilen på en säker plats som ligger i en annan region än databasen. Exempel inkluderar att lagra filen i ett lakehouse i en annan region, använda ett geo-redundant Azure-lagringskonto eller använda en annan säker lagringsplats utanför regionen.

5. Om HorizonDB-databasen och regionen inte är tillgängliga, skapa en HorizonDB-databas i en arbetsyta i en ny region—Workspace C2. W2 i Region B som beskrivs i exempelscenariot. Se till att din Microsoft Entra-identitet har behörighet att skapa objekt och skriva data i måldatabasen. Tokens går ut, så skaffa en ny token innan du återställer:

   PGPASSWORD="$(az account get-access-token --resource https://ossrdbms-aad.database.windows.net --query accessToken --output tsv)"
   export PGPASSWORD
   pg_restore --dbname="host=<target-host> port=5432 dbname=<target-database> user=<user> sslmode=require" --no-owner <source-database>.dump
   

   Byt ut platshållarna för målanslutningen med den nya databasens anslutningsdetaljer och PostgreSQL-användarnamnet för din Microsoft Entra-identitet. Om du använder en annan identitet eller klientorganisation för måldatabasen, upprepa inloggningssteget innan du hämtar token.

6. Efter varje säkerhetskopierings- eller återställningssession, ta bort token från din shell-miljö:

   unset PGPASSWORD
   

Den återskapade databasen är oberoende av den ursprungliga databasen och speglar datans tillstånd vid tidpunkten för pg_dump-operationen. Dumpen innehåller en databas och inkluderar inte klusterövergripande objekt, såsom roller. Återskapa alla nödvändiga roller och behörigheter i den nya regionen.

Överväganden för återställning efter fel

Data som läggs till i den återskapade databasen återspeglas inte i originaldatabasen. Om du planerar att växla tillbaka till den ursprungliga databasen när hemregionen blir tillgänglig, stäm manuellt av data från den återskapade databasen med den ursprungliga databasen.

Platform

Plattform refererar till underliggande delade tjänster och arkitektur som gäller för alla arbetsbelastningar. Detta avsnitt beskriver återhämtningsprocedurer för delade Fabric-funktioner.

Övervakning av arbetsyta

Arbetsytsövervakning samlar in loggar om aktivitet i arbetsytan där du aktiverar det. Efter att du återställt din arbetsyta som C2. W2, aktivera övervakning av arbetsytor på W2. Den börjar samla in övervakningsdata för det återvunna arbetsutrymmet.

Övervakningsdata från den ursprungliga arbetsytan (C1. W1) förs inte över, eftersom övervakningen speglar aktiviteten i arbetsytan den körs på.

Variabelbibliotek

Microsoft Fabric variabelbibliotek gör det möjligt för utvecklare att anpassa och dela objektkonfigurationer på en arbetsyta, vilket effektiviserar innehållslivscykelhanteringen. Från haveriberedskapssynpunkt måste användare av variabelbibliotek proaktivt skydda mot en regional katastrof. Detta skydd kan göras via Fabric Git-integration, vilket säkerställer att efter en regional katastrof förblir användarens Variable-bibliotek tillgängligt. För att återställa ett variabelbibliotek, följ följande steg:

• Använd Fabric Git-integrering för att synkronisera ditt variabelbibliotek med din ADO-lagringsplats. Vid haveri kan du använda lagringsplatsen för att återskapa variabelbiblioteket på den nya arbetsytan som du skapade. Följ stegen nedan:

  1. Anslut din arbetsyta till Git-lagringsplatsen enligt beskrivningen här.
  2. Se till att hålla WS och lagringsplatsen synkroniserade med Commit och Update.
  3. Återställning – Vid haveri använder du lagringsplatsen för att återskapa variabelbiblioteket på en ny arbetsyta:

• På den nyligen skapade arbetsytan ansluter du och synkroniserar till din Azure ADO-lagringsplats igen.

• Alla Fabric objekt på den här lagringsplatsen laddas ned automatiskt till din nya arbetsyta.

• När du har synkroniserat dina objekt från Git öppnar du dina variabelbibliotek på den nya arbetsytan och väljer den önskade aktiva värdeuppsättningen manuellt.

Distributionsplan

En distributionsplan är ett objekt i en Fabric-arbetsyta. Den grupperar föremål och ställer in ordningen för att placera dem. Den kan köra handlingar före eller efter att varje föremål placeras ut. Föremålsdefinitionen lagrar dessa inställningar, indata och föremålsreferenser. Planen har inte någon separat lagringsplats för värden som används under körning.

Förbered dig för återhämtning genom att använda Fabric Git-integration:

1. Koppla arbetsytan som innehåller planen till ett Azure DevOps- eller GitHub-arkiv.
2. Genomför planen och alla objekt i arbetsytan som används av planen.
3. Checka in varje ändring så att Git har de senaste definitionerna.

Efter en regional katastrof:

1. Skapa en arbetsplats i den hälsosamma regionen.
2. Anslut arbetsytan till samma lagringsplats och gren.
3. Uppdatera arbetsytan från Git. Detta steg återställer planen och dess föremål.

Git återställer hela plandefinitionen. Den återställer inte data eller kör-tillstånd för de länkade föremålen. Använd avsnitten i den här artikeln för att återställa dessa föremål.

Kundhanterade nycklar för Fabric-arbetsytor

Du kan använda kundhanterade nycklar (CMK) lagrade i Azure Key Vault för att lägga till ett extra lager av kryptering ovanpå Microsoft-hanterade nycklar för data i vila. Om Fabric blir otillgänglig eller obrukbar i en region, går dess komponenter över till en backup-instans. Under failover stöder CMK-funktionen skrivskyddade operationer. Så länge Azure Key Vault-tjänsten fungerar som den ska och behörigheterna till nyckelvalvet är intakta fortsätter Fabric att ansluta till nyckeln och låter dig läsa data som vanligt. Det innebär att följande åtgärder inte stöds under redundansväxling: aktivera och inaktivera cmk-inställningen för arbetsytan och uppdatera nyckeln.

Fabric Migration Assistant för SQL-databas i Fabric

Fabric Migration Assistant kan flytta en SQL Server-databas till en SQL-databas i Fabric i tre steg: migreringsguiden skapar måldatabasen och startar migreringen, migreringsövervakaren följer framsteg medan schemat distribueras från en DACPAC, Migration Assistant hjälper dig att granska och rätta skriptfel, förbereda databasen, kopiera data med ett kopieringsjobb och slutföra kopieringen.

Migreringsframsteg replikeras inte till en annan region, och en avbruten distribution kan inte återupptas. Dessa fel påverkar inte källdatabasen i SQL Server, så du kan köra migreringsassistenten igen. Om den ursprungliga regionen inte är tillgänglig, följ först den allmänna återställningsplanen i denna artikel för att skapa kapacitet C2 och arbetsyta W2 i den parade regionen, och kör sedan migreringen i W2. Om den ursprungliga regionen återställs kan du försöka migrera igen i den ursprungliga arbetsytan.

En regional störning kan få en migration att misslyckas på tre sätt:

• Måldatabasen skapas inte

  Om Fabric inte kan skapa måldatabasen visar migreringsguiden ett fel och migreringen startar inte. Välj Start migration för att försöka igen, eller försök igen senare.

  Trollkarlen försöker ta bort en ofullständig databas, men rensningen kan misslyckas vid en störning. Innan du försöker igen, kontrollera om det finns en databas med det avsedda namnet i arbetsytan. Bekräfta att det är den ofullständiga databasen från det misslyckade försöket innan du raderar den.

• Utplaceringen misslyckas

  Om utrullningen avbryts slutar migreringsövervakaren rapportera framsteg, öppnar måldatabasen och visar en dialog som visar att utrullningen misslyckades. Du kan inte återuppta en misslyckad distribution, och databasen som skapats av försöket stannar kvar i arbetsområdet.

  Så här återställer du:

  1. Bekräfta att Fabric finns tillgängligt och att du har DACPAC som användes för den ursprungliga migreringen.
  2. Identifiera databasen som skapats av det misslyckade försöket. Radera den om den inte innehåller något du behöver behålla. Annars, behåll den och använd ett annat namn för den nya databasen.
  3. Kör en ny migrering från källans DACPAC. Migreringen skapar en ny databas.

  Data kopieras av ett kopieringsjobb i Data Factory. Om du synkroniserade kopieringsjobbet med Git innan avbrottet, se Copy Job i Data Factory-guiden. Annars, skapa ett nytt kopieringsjobb som en del av den nya migreringen.

• Migrationshistoriken laddas inte

  Om Migration Assistant inte kan hämta migrationshistoriken rapporterar den att migrationsinformation inte längre är tillgänglig. Framsteg sparade i den aktuella webbläsaren bevaras, och måldatabasen påverkas inte. Uppdatera sidan för att ladda migreringshistoriken igen.

Utgående åtkomstskydd för arbetsyta

Med utgående åtkomstskydd för arbetsytor i Microsoft Fabric kan administratörer skydda utgående dataanslutningar från objekt på sina arbetsytor till externa resurser. Med den här funktionen kan administratörer blockera alla utgående anslutningar och sedan endast tillåta godkända anslutningar till externa resurser via säkra anslutningar. Om Fabric blir otillgängligt eller ur funktion i en region kan du fortfarande läsa arbetsytenivåns OAP-regler (blockinställningar för utgående åtkomst, git-integration i OAP och dataanslutningsregler). Infrastrukturen för anslutningsreglerna växlar över till en backup-instans. Spark-jobb från primärregionen är fortfarande otillgängliga för kunder.

OneLake

I det här avsnittet går vi igenom återställningsprocedurerna för OneLake-funktioner. Mer information om haveriberedskap för OneLake-data finns i OneLake-haveriberedskap.

Principer för livscykelhantering

Om Fabric blir otillgängligt eller inte fungerar i en region, kan du fortfarande läsa och uppdatera din livscykelpolicy för OneLake vid redundansväxling. All data som flyttas till den svala eller kalla nivån förblir på den nivån. För att tillämpa din befintliga policy på din nya återställningsarbetsplats, följ följande steg:

1. Anropa Exportera policy i den ursprungliga arbetsytan och spara hela livscykelpolicyn.
2. Anropa importprincipen på den återställda arbetsytan med din exporterade livscykelprincip som begärandetext.

Regler för resursinstans

Resursinstansregler hjälper dig att på ett säkert sätt styra åtkomsten till data i OneLake med hjälp av betrodda Azure resursidentiteter. Vid regional redundansväxling fortsätter systemet att tillämpa befintliga regler för läsåtkomst. Du kan dock inte skapa, uppdatera eller ta bort resursinstansregler förrän arbetsytan återgår till ett skrivbart tillstånd.

Relaterad information

• Microsoft Fabric guide för katastrofåterställning