Diretrizes personalizadas de recuperação de desastres

Este artigo fornece orientações específicas para experiências sobre como recuperar seus dados do Fabric em caso de desastre regional.

Cenário de exemplo

Muitas seções de orientação neste artigo utilizam o seguinte exemplo de cenário para fins de explicação e ilustração. Consulte este cenário novamente conforme necessário.

Suponha que você tenha uma capacidade C1 na região A que possui uma Área de Trabalho W1. Se você ativou a recuperação de desastre para a capacidade C1, os dados do OneLake serão replicados para um backup na região B. Se a região A enfrentar interrupções, o serviço de Fabric em C1 realizará a ação de failover para a região B.

A imagem a seguir ilustra esse cenário. A caixa à esquerda mostra a região com interrupção. A caixa no meio representa a disponibilidade contínua dos dados após o failover, e a caixa à direita mostra a situação totalmente coberta após o cliente agir para restaurar totalmente seus serviços.

Este é o plano geral de recuperação:

1. ** Crie uma nova capacidade C2 do Fabric em uma nova região.

2. Criar um novo espaço de trabalho W2 em C2, incluindo seus itens correspondentes com os mesmos nomes que em C1.W1.

3. Copie os dados do C1.W1 interrompido para o C2.W2.

4. Siga as instruções dedicadas a cada componente para restaurar os itens em suas funções completas.

Esse plano de recuperação pressupõe que a região de residência do locatário permaneça operacional. Se a região de origem do inquilino sofrer uma interrupção, as etapas descritas neste artigo dependem da recuperação, que deve ser iniciada e concluída primeiro pela Microsoft.

Planos de recuperação para experiências específicas

As seções a seguir fornecem guias passo a passo para cada experiência Fabric para ajudar você durante o processo de recuperação.

Engenharia de Dados

Este guia guiará você através dos procedimentos de recuperação para a experiência de engenharia de dados. Ela cobre lakehouses, notebooks, definições de tarefas do Spark, funções de dados de usuário e APIs GraphQL.

Lakehouse

As casas de lago da região original permanecem indisponíveis para os clientes. Para recuperar um Lakehouse, os clientes podem recriá-lo no espaço de trabalho C2.W2. Recomendamos duas abordagens para a recuperação de Lakehouses:

Abordagem 1: usar um script personalizado para copiar as tabelas e os arquivos Delta do Lakehouse

Os clientes podem recriar os lakehouses usando um script Scala personalizado.

1. Crie o Lakehouse (por exemplo, LH1) no espaço de trabalho recém-criado C2.W2.

2. Crie um novo Notebook no espaço de trabalho C2.W2.

3. Para recuperar as tabelas e arquivos da lakehouse original, consulte os dados com caminhos da OneLake, como abfss (consulte Conectando ao Microsoft OneLake). Você pode usar o exemplo de código a seguir (consulte Introdução ao Microsoft Spark Utilities) no notebook para obter os caminhos do ABFS de arquivos e tabelas do lakehouse original. (Substitua C1.W1 pelo nome real do espaço de trabalho)

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

4. Use o exemplo de código a seguir para copiar tabelas e arquivos para a lakehouse que acabou de ser criada.

   1. No caso das tabelas Delta, você precisa copiar uma tabela de cada vez para recuperar na nova lakehouse. No caso dos arquivos do Lakehouse, você pode copiar a estrutura de arquivos completa com todas as pastas subjacentes com uma única execução.

   2. Entre em contato com a equipe de suporte para obter o carimbo de data/hora do failover requerido no script.

   %%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. Depois de executar o script, as tabelas aparecerão na nova lakehouse.

Abordagem 2: Usar Gerenciador de Armazenamento do Azure para copiar arquivos e tabelas

Para recuperar apenas arquivos ou tabelas específicas do Lakehouse original, use o Gerenciador de Armazenamento do Azure. Consulte Integrate OneLake com Gerenciador de Armazenamento do Azure para obter etapas detalhadas. Para dados de grande dimensão, use Abordagem 1.

Recuperando visões materializadas do data lake no Fabric

Após o failover, você não pode acessar as vistas materializadas do lago a partir da região original. O processo de failover não replica os cronogramas de atualização ou o histórico de execução para a região secundária. Para recuperar esses itens, complete os seguintes passos após recuperar seus dados de Lakehouse:

• Recupere as tabelas de Lakehouse usando a Abordagem 1 ou Abordagem 2 descrita anteriormente neste artigo. Copie apenas as tabelas de origem.
• Recupere os blocos de anotações que contêm suas definições de MLV. Para os passos de recuperação, veja a seção Caderno .
• Execute os blocos de anotações recuperados para recriar os MLVs no novo Lakehouse. Para obter informações sobre como criar MLVs, consulte Create a Materialized Lake View. Se você copiou MLVs na etapa anterior, execute CREATE OR REPLACE ao recriá-los.
• Recrie manualmente os cronogramas de atualização do MLV no novo espaço de trabalho. Você não pode recuperar histórico de agendamento ou métricas de execução.
• Se seus MLVs alimentam modelos semânticos ou relatórios, verifique e atualize as referências do ID do Lakehouse e do ID do conjunto de dados conforme necessário. Reconecte relatórios ao modelo semântico atualizado e valide a atualização de dados.

Notebook

Os notebooks da região principal permanecem indisponíveis para os clientes, e o código dos notebooks não se replica para a região secundária. Para recuperar o código do notebook na nova região, use uma das seguintes abordagens.

Abordagem 1: redundância gerenciada pelo usuário com integração do Git (em versão prévia pública)

Use a integração do Fabric Git para sincronizar seu notebook com seu repositório Azure DevOps (ADO). Depois que o serviço fizer failover para outra região, use o repositório para reconstruir o notebook no novo workspace que você criou.

1. Configure a Integração do Git para seu workspace e selecione Conectar e sincronizar com o repositório ADO.

   

   A imagem a seguir mostra o Notebook sincronizado.

   

2. Recuperar o Notebook do repositório ADO.

   1. No workspace recém-criado, conecte-se ao repositório do ADO Azure novamente.

      

   2. Selecione o botão Controle do código-fonte. Em seguida, selecione a ramificação relevante do repositório. Em seguida, selecione Atualizar tudo. O bloco de anotações original é exibido.

      

      

   3. Se o caderno original tiver uma casa de lago padrão, consulte a seção Casa do Lago para recuperar a casa do lago e então conecte a casa recém-recuperada ao caderno recém-recuperado.

      

   4. A integração do Git não dá suporte à sincronização de arquivos, pastas ou instantâneos do Notebook no explorador de recursos do Notebook.

      1. Se o Notebook original tiver arquivos no gerenciador de recursos do Notebook:

         1. Salve arquivos ou pastas em um disco local ou em outro local.

         2. Carregue novamente o arquivo do seu disco local ou das unidades de nuvem para o Notebook recuperado.

      2. Se o Notebook original tiver um instantâneo do Notebook, salve também o instantâneo do Notebook no seu próprio sistema de controle de versão ou no disco local.

         

         

Para obter mais informações sobre a integração do Git, consulte Introdução à integração do Git.

Abordagem 2: abordagem manual para fazer o backup do conteúdo do código

Se você não seguir a abordagem de integração do Git, salve a versão mais recente do seu código, arquivos no explorador de recursos e o snapshot do notebook em um sistema de controle de versões como o Git. Recupere manualmente o conteúdo do notebook após um desastre:

1. Use o recurso Importar caderno para importar o código do caderno que você quer recuperar.

   

2. Após a importação, vá para o espaço de trabalho desejado (por exemplo, "C2.W2") para acessá-lo.

3. Se o Notebook original tiver um lakehouse padrão, consulte a seção Lakehouse. Em seguida, conecte o lakehouse recém-recuperado (que tem o mesmo conteúdo do lakehouse padrão original) ao Notebook recém-recuperado.

4. Se o Notebook original tiver arquivos ou pastas no gerenciador de recursos, carregue novamente os arquivos ou pastas salvos no sistema de controle de versão do usuário.

Definição de trabalho do Spark

Definições de tarefas Spark (SJD) da região primária permanecem indisponíveis, e o OneLake replica o arquivo principal de definição e o arquivo de referência no notebook para a região secundária. Se você quiser recuperar o SJD na nova região, siga os passos manuais descritos nesta seção. As passagens históricas do SJD não foram recuperadas.

Você pode recuperar os itens do SJD copiando o código da região original usando Gerenciador de Armazenamento do Azure e reconectando manualmente as referências do Lakehouse após o desastre.

1. Crie um novo item SJD (por exemplo, SJD1) no novo espaço de trabalho C2.W2, com as mesmas definições e configurações do item SJD original (por exemplo, idioma, ambiente etc.).

2. Utilize o Gerenciador de Armazenamento do Azure para copiar os Libs, os Mains e os Snapshots do item SJD original para o novo item SJD.

   

3. O conteúdo do código aparece no recém-criado SJD. Você precisa adicionar manualmente a referência recém-recuperada de Lakehouse ao trabalho (consulte os passos de recuperação de Lakehouse). Os usuários precisam reinserir manualmente os argumentos originais da linha de comando.

   

Agora você pode executar ou agendar seu SJD recém-recuperado.

Para obter detalhes sobre Gerenciador de Armazenamento do Azure, consulte Integrate OneLake com Gerenciador de Armazenamento do Azure.

Funções de dados do usuário

Para recuperar suas funções de dados de usuário em uma região saudável, utilize uma das seguintes abordagens.

Abordagem 1: Com integração do Git (recomendada)

O mecanismo de recuperação preferido é a integração Fabric Git. Ao sincronizar projetos de função de dados do usuário com um repositório Azure DevOps ou GitHub, você pode rapidamente reconstruí-los em um novo espaço de trabalho após o failover.

Prepare-se para um desastre

1. Configure a integração do Fabric Git para o espaço de trabalho que hospeda a função de dados do usuário.
2. Conecte o espaço de trabalho a um repositório Azure DevOps ou GitHub.
3. Comprometa todas as funções de dados do usuário no repositório e sincronize as mudanças regularmente.
4. Armazene configurações específicas do ambiente separadamente em bibliotecas variáveis, se necessário.

Etapas da recuperação

Após um desastre regional:

1. Crie uma nova capacidade do Fabric em uma região íntegra, como a C2.
2. Crie um novo espaço de trabalho, como o W2, na nova função.
3. Conecte o espaço de trabalho ao mesmo repositório Azure DevOps ou GitHub.
4. Abra Controle do código-fonte e sincronize o conteúdo do repositório com a área de trabalho.
5. Recrie ou recupere todos os recursos dependentes do Fabric, como lakehouses, bancos de dados SQL no Fabric, armazéns e eventos empresariais.
6. Reimplante as funções de dados do usuário.
7. Valide a execução da função e a conectividade de dependências.
8. Atualize aplicações dependentes, pipelines de dados ou outros sistemas integrados para fazer referência às funções recuperadas.
9. Validação completa de ponta a ponta de todos os seus cenários.

Considerações importantes

• A integração com o Git recupera apenas código-fonte e ativos do projeto.
• Os registros históricos de execuções não foram recuperados.
• Sistemas subsequentes podem exigir a reatribuição de endpoints.

Para mais informações, veja Funções de Dados do Usuário, controle de versão e implantação.

Abordagem 2: Recuperação manual

Se a integração com o Git não estava configurada antes do desastre, você pode reconstruir manualmente as funções de dados do usuário a partir dos backups do código-fonte.

Prepare-se para um desastre

Complete regularmente as seguintes tarefas e armazene os itens em um repositório externo de controle de versão ou local de backup:

• Exporte o código-fonte da função para um repositório do GitHub.
• Documente e preserve as informações de dependência.
• Configurações do ambiente do documento.

Etapas da recuperação

Após um desastre regional:

1. Crie uma nova capacidade do Fabric em uma região íntegra, como a C2.
2. Crie um novo espaço de trabalho, como o W2.
3. Recupere todos os recursos necessários para a função, incluindo lakehouses, bancos de dados SQL no Fabric, armazéns, eventhouses e serviços externos.
4. Crie um novo projeto de função de dados do usuário.
5. Importe ou recrie o código-fonte da função.
6. Reaplique as configurações de tempo de execução.
7. Reinstale todas as dependências de funções.
8. Reimplante a função.
9. Reconfigure autenticação e autorização.
10. Recrie publicadores ou consumidores do Business Event, caso sejam usados.
11. Complete testes de validação de ponta a ponta para seus cenários e integrações.

GraphQL

Os itens graphQL da região primária não estão disponíveis após um desastre regional e as definições e configurações do GraphQL não são replicadas para a região secundária. Para recuperar o GraphQL em uma nova região, use uma das abordagens a seguir.

Abordagem 1: Redundância gerenciada pelo usuário com integração Git

A melhor maneira de tornar esse processo fácil e rápido é usar Fabric integração do Git e, em seguida, sincronizar seu GraphQL com seu repositório ADO. Após o failover do serviço para outra região, você pode usar o repositório para recompilar o GraphQL no novo workspace criado.

1. Crie um novo espaço de trabalho na capacidade e região de destino.

2. Recupere todas as fontes de dados dependentes, como lakehouse, warehouse ou bancos de dados SQL, seguindo suas respectivas etapas de recuperação.

3. Atualize a definição do GraphQL para apontar para os recursos recém-recuperados, modificando referências específicas do ambiente, como IDs de workspace de origem, IDs de itens de origem e detalhes de conexão. Esta etapa garante a associação correta no momento da implantação.

4. Reimplante itens GraphQL do repositório Git para o novo workspace. Esta etapa recria a estrutura e a configuração da API usando as definições atualizadas.

5. Reaplique as configurações de itens, incluindo papéis, controles de acesso e configuração de autenticação.

6. Atualize novamente as referências de endpoint, atualizando todos os aplicativos ou integrações para usarem o endpoint GraphQL recém-criado.

7. Atualize os pipelines de implantação existentes que apontavam para o workspace antigo para fazer referência ao workspace recém-criado.

8. Valide a funcionalidade de ponta a ponta da API.

Abordagem 2: abordagem manual

Se você não adotar a abordagem de integração do Git, poderá usar a abordagem manual a seguir para recuperar o GraphQL.

1. Crie um novo espaço de trabalho na capacidade e região de destino.

2. Recupere todas as fontes de dados dependentes, como Lakehouse, Warehouse ou bancos de dados SQL.

3. Recrie a API do GraphQL manualmente no novo workspace, incluindo definições de esquema, conexões de fonte de dados e relações.

4. Reaplique as configurações de itens, incluindo papéis, controles de acesso e configuração de autenticação.

5. Atualize novamente as referências de endpoint, atualizando todos os aplicativos ou integrações para usarem o endpoint GraphQL recém-criado.

6. Atualize os pipelines de implantação existentes que apontavam para o workspace antigo para fazer referência ao workspace recém-criado.

7. Valide a funcionalidade de ponta a ponta da API.

Considerações importantes

1. O GraphQL depende de dependências externas (como Lakehouse, Warehouse e SQL), que você deve recuperar antes da implantação do GraphQL.

2. As definições de API do GraphQL incluem referências específicas do ambiente (como sourceWorkspaceId e sourceItemId). Ao se recuperar em uma nova região, essas referências podem se tornar inválidas. Atualize-os para apontar para recursos provisionados recentemente.

3. A reassociação automática de fontes de dados não é garantida em cenários de recuperação de desastres, especialmente ao usar credenciais salvas ou conexões entre espaços de trabalho.

4. Outras configurações de items, como monitoramento, autorização, RBAC, introspecção e mais, não são mantidas após o failover. Você deve restabelecer essas configurações na nova região.

References

• Visão geral da integração do Git Fabric – Microsoft Fabric | Microsoft Learn

• Pipelines de controle do código-fonte e implantação na API para GraphQL – Microsoft Fabric | Microsoft Learn 

App

O sistema não replica os Fabric Apps, incluindo seu código, configuração e metadados, para regiões secundárias. Se a região principal falhar, o aplicativo permanece indisponível. Para recuperação, armazene o código-fonte do app fora do sistema no GitHub, Azure DevOps ou outro sistema de controle de versão. Recupere os dados do aplicativo separadamente seguindo as orientações de recuperação de desastres para cada armazenamento de dados Fabric subjacente.

Abordagem manual

Você pode recuperar manualmente um aplicativo Fabric após um desastre regional usando o código-fonte do aplicativo e a CLI do Rayfin. 

Pré-requisitos 

Antes que ocorra um desastre:

• Armazene o código-fonte do Fabric App no GitHub, Azure DevOps ou outro repositório de controle de versão. 

• Documente o processo de recuperação.  

Etapas de recuperação 

1. Crie um novo espaço de trabalho na capacidade e região de destino. 

2. Recupere recursos dependentes antes de reimplantar a aplicação.  

3. Recupere o código-fonte mais recente do Fabric App no seu repositório de controle de versão ou backup local. 

4. A partir do diretório de código-fonte do aplicativo, implante o aplicativo Fabric no workspace de recuperação usando a CLI do Rayfin. Execute rayfin up --workspace <new workspace>. 

5. Recupere o item secundário do aplicativo (banco de dados SQL no Fabric) seguindo os respectivos procedimentos de recuperação.  

6. Reaplique as configurações de nível de item, incluindo funções e controles de acesso conforme necessário.  

7. Valide a funcionalidade do aplicativo e garanta que os usuários tenham as permissões corretas.  

Importante 

• Mantenha o código-fonte do Fabric App fora da região Fabric para possibilitar a recuperação.  

• Os dados da aplicação no banco de dados não são recuperados como parte do processo de implantação do Fabric App e precisam ser restaurados separadamente.  Você pode recuperar manualmente um aplicativo Fabric após um desastre regional usando o código-fonte do aplicativo e a CLI do Rayfin. 

Azure Databricks Storage

Azure Databricks Storage armazena dados em OneLake. Para proteger seus dados contra uma queda regional, ative a configuração de recuperação de desastres na capacidade do Fabric que contém o item Azure Databricks Storage. Quando você ativa essa configuração, o OneLake replica os dados de forma assíncrona para a região pareada do Azure.

Se o OneLake iniciar um failover regional, as aplicações podem continuar acessando os dados replicados pelo endpoint global OneLake após o término do failover. O acesso contínuo pelas APIs públicas do OneLake não exige criar outro item do Azure Databricks Storage ou copiar os dados para outro workspace.

Consulte OneLake Disaster Recovery and Data Protection para consultar o comportamento, as considerações e as limitações aplicáveis.

Para planejamento específico de recuperação de desastres para Azure Databricks, veja Recuperação de desastres - Azure Databricks.

Ciência de Dados

Este guia guiará você através dos procedimentos de recuperação para a experiência da Ciência de Dados. Ele aborda modelos e experimentos de ML.

Modelo e experimento de ML

Itens de Ciência de Dados da região primária permanecem indisponíveis para os clientes, e o conteúdo e os metadados em modelos e experimentos de ML não se replicam para a região secundária. Para recuperá-los totalmente na nova região, salve o conteúdo do código em um sistema de controle de versão (como o Git) e reexecute manualmente o conteúdo do código após o desastre.

1. Recuperar o notebook. Consulte as Etapas de recuperação do Notebook.

2. Configuração, métricas de execuções anteriores e metadados não são replicados para a região pareada. Você precisa reexecutar cada versão do seu código de ciência de dados para recuperar totalmente modelos e experimentos de ML após o desastre.

data warehouse

Este guia guia você pelos procedimentos de recuperação para a carga de trabalho Fabric Data Warehouse. Cobre itens do armazém.

Depósito

Você não pode acessar armazéns da região original. Para recuperar os armazéns, execute as duas etapas a seguir.

1. Crie uma nova casa de lago provisória no espaço de trabalho C2. W2 para os dados que você copia do depósito original.

2. Popule as tabelas Delta do warehouse por meio do Explorer do warehouse e dos recursos de T-SQL (veja Tabelas no Fabric Data Warehouse).

Ingestão de dados via Lakehouse e código T-SQL

No espaço de trabalho recém-criado C2.W2:

1. Criar um lakehouse temporário "LH2" em C2.W2.

2. Recupere as tabelas Delta no lakehouse provisório do warehouse original executando as etapas de recuperação do Lakehouse.

3. Cria um novo Warehouse "WH2" no C2.W2.

4. Conectar o lakehouse provisório no seu gerenciador de warehouse.

5. Dependendo de como você implanta as definições de tabelas antes da importação de dados, o T-SQL real usado para importações pode variar. Para recuperar tabelas do Warehouse de lakehouses, você pode usar a abordagem INSERT INTO, SELECT INTO ou CREATE TABLE AS SELECT. No exemplo a seguir, usamos INSERT INTO. Se você usar o código a seguir, substitua exemplos por nomes reais de tabelas e colunas.

   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. Altere a cadeia de conexão em aplicativos que usam o seu data warehouse do Fabric.

Banco de dados espelhado

Os clientes não conseguem acessar bancos de dados espelhados da região principal, e as configurações não se replicam para a região secundária. Para recuperar um banco de dados espelhado após uma falha regional, você precisa recriá-lo em outro workspace de uma região diferente.

Data Factory

Os clientes não conseguem acessar itens da Data Factory da região principal, e as configurações nos pipelines ou itens Dataflow Gen2 não se replicam para a região secundária. Para recuperar esses itens após uma falha regional, você precisa recriar seus itens de Integração de Dados em outro workspace de uma região diferente. As seções a seguir descrevem os detalhes.

Fluxos de Dados Gen2

Para recuperar um item Dataflow Gen2 na nova região, exporte um .pqt arquivo para um sistema de controle de versões como o Git, e então recupere manualmente o conteúdo Dataflow Gen2 após o desastre.

1. Do seu item Dataflow Gen2, na aba Início do editor Power Query, selecione Exportar template.

   

2. No diálogo Exportar modelo , insira um nome (obrigatório) e uma descrição (opcional) para esse modelo. Ao concluir, selecione OK.

   

3. Após o desastre, crie um novo item de Dataflow Gen2 no novo espaço de trabalho "C2.W2".

4. No painel de exibição atual do editor de Power Query, selecione Importar de um modelo de Power Query.

   

5. No diálogo Abrir , navegue até a pasta de downloads padrão e selecione o .pqt arquivo que você salvou nas etapas anteriores. Em seguida, selecione Abrir.

6. O modelo é então importado para seu novo item Dataflow Gen2.

O recurso Salvar Como para Dataflows não é suportado em caso de recuperação de desastres.

Pipelines

Os clientes não podem acessar os pipelines em caso de um desastre regional, e as configurações não são replicadas para a região emparelhada. Construa seus pipelines críticos em múltiplos espaços de trabalho em diferentes regiões.

Copiar tarefa

Os usuários do CopyJob devem realizar medidas proativas para proteger contra um desastre regional. A abordagem a seguir garante que, após um desastre regional, os CopyJobs de um usuário permaneçam disponíveis.

Redundância gerenciada pelo usuário com integração do Git (em versão prévia pública)

A melhor forma de tornar esse processo fácil e rápido é usar a integração do Fabric Git e então sincronizar seu CopyJob com seu repositório Azure DevOps. Após o failover do serviço para outra região, você pode usar o repositório para recompilar o CopyJob no novo workspace criado.

1. Configure a integração do seu espaço de trabalho com o Git e selecione conectar e sincronizar com o repositório Azure DevOps.

   

   A imagem a seguir mostra o CopyJob sincronizado.

   

2. Recupere o CopyJob do repositório Azure DevOps.

   1. No espaço de trabalho recém-criado, conecte-se e sincronize novamente com seu repositório Azure DevOps. Todos os itens do Fabric neste repositório são automaticamente baixados para o seu novo espaço de trabalho.

      

   2. Se o CopyJob original usa um Lakehouse, os usuários podem consultar a seção Lakehouse para recuperar o Lakehouse e, em seguida, conectar o CopyJob recém-recuperado ao Lakehouse recém-recuperado.

Para obter mais informações sobre a integração do Git, consulte Introdução à integração do Git.

Tarefa do Apache Airflow

Você deve tomar medidas proativas para proteger os empregos da Apache Airflow em Fabric contra um desastre regional.

Gerencie a redundância usando integração com Fabric Git. Primeiro, sincronize seu trabalho de Airflow com seu repositório ADO. Se o serviço fizer failover para outra região, você poderá usar o repositório para recriar o job do Airflow no novo espaço de trabalho que você criou.

Siga estes passos para alcançar esse objetivo:

1. Configure a integração do seu espaço de trabalho com o Git e selecione Conectar e sincronizar com o repositório ADO.

2. Depois disso, você vê seu trabalho Airflow sincronizado com seu repositório ADO.

3. Se você precisar recuperar o trabalho do Airflow do repositório do ADO, crie um novo workspace, conecte-se e sincronize novamente com o repositório ADO do Azure. Todos os itens Fabric, incluindo o Airflow, neste repositório são transferidos automaticamente para o seu novo espaço de trabalho.

Inteligência em Tempo Real

Este guia guiará você através dos procedimentos de recuperação para a experiência da Inteligência em Tempo Real. Abrange bancos de dados KQL, conjuntos de consultas e itens de fluxo de eventos.

Activator

Os itens de ativação da região primária permanecem indisponíveis para os clientes e as definições de gatilho do Ativador não são replicadas para a região secundária. Os usuários do Activator devem tomar medidas proativas para se preparar para a recuperação de desastres regional.

Para garantir que você possa recuperar itens do Activator no caso de um desastre regional, configure a integração do Git do Fabric para fazer backup das definições de gatilho e restaurá-las em um espaço de trabalho em outra região.

1. Configure a integração do Git no Fabric para o workspace que contém seu item Activator e sincronize suas definições de gatilho com seu repositório Git.
2. Mantenha as definições de gatilho do Ativador confirmadas e sincronizadas regularmente.
3. Durante a recuperação, crie um novo workspace na região de destino (C2. W2), conecte-o ao mesmo repositório e sincronize para restaurar as definições de gatilho.
4. Reconfigure e valide todas as fontes de dados e dependências do Activator no novo workspace.

Para obter mais informações sobre a integração do Git, consulte Introdução à integração do Git.

Modelo/conjunto de consultas do Graph

Os clientes não conseguem acessar os itens do modelo Graph e do conjunto de consultas Graph da região primária, e o Fabric não replica esses itens para a região secundária. Para recuperar, crie ou use uma capacidade em uma região diferente e recrie o modelo Graph e os itens do conjunto de consultas Graph ali.

1. Crie ou use uma capacidade de Fabric existente em uma região diferente que não seja afetada pelo desastre.

2. Crie um novo espaço de trabalho ou use um espaço de trabalho existente para essa finalidade.

3. Recrie o item do modelo Graph no workspace secundário (referenciado no passo 2). Reconfigure a definição do modelo, incluindo nós, arestas e outros, para corresponder ao modelo original do Grafo.

4. Se a lakehouse original estiver na região com falha, recupere-a primeiro seguindo a seção Lakehouse.

5. Conecte uma casa de lago como fonte de dados OneLake para o item recém-criado do modelo Graph. Use a lakehouse recuperada se estiver na região em falha, ou reconecte-se à lakehouse atual se ela estiver disponível.

6. Reconfigure quaisquer cronogramas de carregamento de dados ou conexões para o modelo Graph no novo espaço de trabalho.

7. Recrie o item Graph do conjunto de consultas no espaço de trabalho secundário. Reintroduza manualmente as consultas e quaisquer configurações salvas do conjunto original de consultas do Graph.

Banco de dados/Conjunto de consultas KQL

Os usuários do banco de dados e do conjunto de consultas KQL devem tomar medidas proativas para se proteger contra desastres regionais. A abordagem a seguir garante que, em caso de desastre regional, os dados em seus bancos de dados e conjuntos de consulta KQL permaneçam seguros e acessíveis.

Execute as etapas a seguir para garantir uma solução eficaz de recuperação de desastres para bancos de dados KQL e conjuntos de consultas.

1. Configurar bancos de dados KQL independentes: Configure dois ou mais bancos de dados KQL independentes e conjuntos de consultas em capacidades dedicadas do Fabric. Configure esses bancos de dados em duas regiões diferentes do Azure (preferencialmente regiões pareadas com Azure) para maximizar a resiliência.

2. Replicar atividades de gestão: Espelhe qualquer ação de gestão que você tome em um banco de dados KQL no outro. Essa abordagem mantém ambos os bancos de dados sincronizados. Atividades principais a serem replicadas incluem:

   • Tabelas: Certifique-se de que as estruturas de tabelas e definições de esquemas sejam consistentes entre os bancos de dados.

   • Mapeamentos: duplicar todos os mapeamentos requeridos. Certifique-se de que as fontes e destinos dos dados estejam alinhados corretamente.

   • Políticas: Garantir que ambos os bancos de dados tenham políticas semelhantes de retenção, acesso e outras relevantes de dados.

3. Gerencie autenticação e autorização: Configure as permissões necessárias para cada réplica. Certifique-se de estabelecer os níveis adequados de autorização, concedendo acesso ao pessoal necessário enquanto mantém os padrões de segurança.

4. Ingestão de dados paralela: para manter os dados consistentes e prontos em várias regiões, carregue o mesmo conjunto de dados em cada banco de dados KQL ao mesmo tempo que você os ingere.

Eventstream

Um eventstream é um local centralizado na plataforma Fabric para capturar, transformar e rotear eventos em tempo real para vários destinos (por exemplo, lakehouses, bancos de dados KQL/querysets) com uma experiência sem código. Desde que os destinos suportem recuperação de desastres, os eventstreams não perdem dados. Portanto, utilize as capacidades de recuperação de desastres desses sistemas de destino para garantir a disponibilidade dos dados.

Você também pode obter geo-redundância implantando cargas de trabalho idênticas de fluxo de eventos em várias regiões do Azure como parte de uma estratégia multissite ativa/ativa. Com uma abordagem ativa/ativa multissite, você pode acessar sua carga de trabalho em qualquer uma das regiões onde a solução foi implantada. Essa abordagem é a mais complexa e dispendiosa para a recuperação de desastres, mas pode reduzir o tempo de recuperação a quase zero na maioria das situações. Para ser totalmente geo-redundante:

1. Crie réplicas das suas fontes de dados em diferentes regiões.

2. Crie itens de eventstream em regiões correspondentes.

3. Conecte esses novos itens às fontes de dados idênticas.

4. Adicionar destinos idênticos para cada fluxo de eventos em diferentes regiões.

Eventos comerciais, eventos Fabric e eventos de Azure

Embora os Business Events, Fabric Events e Azure Events compartilhem a mesma infraestrutura Real-Time hub em Microsoft Fabric, eles têm origens, comportamentos e necessidades de recuperação distintas. Entenda essas diferenças antes de planejar a recuperação após desastres:

• Fabric Events são assinaturas de eventos que reagem à atividade produzida pelos próprios recursos da Fabric. Esses eventos incluem alterações no ciclo de vida dos itens do espaço de trabalho (como criar, atualizar ou excluir lakehouses, notebooks ou warehouses), execuções de trabalhos (como execuções de pipelines ou de notebooks) e operações em arquivos e pastas no OneLake. Essas assinaturas são do tipo push e efêmeras. As assinaturas não são replicadas para a região secundária.

• Azure Eventos são assinaturas de eventos para atividades produzidas por contas de Armazenamento de Blobs do Azure. Esses recursos do Azure existem independentemente de qualquer capacidade do Fabric ou região. Embora o recurso do Armazenamento de Blobs do Azure possa continuar disponível durante uma interrupção regional do Fabric, as assinaturas configuradas no Real-Time hub não são replicadas para a região secundária e devem ser recriadas.

• Os Eventos de Negócios são uma funcionalidade distinta no Fabric Real-Time Intelligence que permite que as equipes definam, publiquem e atuem em sinais comerciais significativos. Eventos de negócios são gerados no Fabric por meio do Activator, de notebooks do Spark ou de Funções de Dados do Usuário e, em seguida, publicados no Real-Time hub, para que consumidores posteriores, como Activator, Eventhouse ou Power Automate, possam reagir a eles. Os esquemas de eventos são regidos centralmente por meio do Registro de Esquema. A Eventhouse armazena automaticamente todos os eventos de negócios publicados, portanto, sua recuperação afeta diretamente a disponibilidade do histórico de eventos de negócios. Nenhuma das configurações do publicador ou do consumidor, definições de esquema ou assinaturas é replicada para a região secundária.

Use as etapas a seguir para restaurar eventos de negócios, eventos Fabric e eventos Azure no novo workspace na região de recuperação.

Para eventos de negócios:

1. Recrie o evento de negócios usado por editores e consumidores seguindo o artigo Create Business Events in Fabric Real-Time Hub. Durante a criação do evento de negócios, você cria o recurso Conjunto de Esquemas de Eventos. O recurso Eventhouse é opcional dependendo do cenário. Se você fez backup do seu conjunto de esquemas de eventos com integração com Git, restaure-o primeiro seguindo a seção de conjunto de esquemas de eventos, depois aponte o evento de negócio para o conjunto de esquemas restaurado.

2. Recrie quaisquer itens de publicador que gerem eventos de negócios, como notebooks do Spark ou Funções de Dados do Usuário, no novo workspace, seguindo os artigos sobre publicadores: Usar a Função de Dados do Usuário como um Publicador de Eventos de Negócios, Usar o Activator como um Publicador de Eventos de Negócios, Usar o Notebook como um Publicador de Eventos de Negócios e Usar o Eventstream como um Publicador de Eventos de Negócios.

3. Recrie as assinaturas do consumidor no Real-Time hub (por exemplo, regras do Activator, gatilhos de notebook ou fluxos do Power Automate) que originalmente reagiam a eventos de negócios na região afetada, seguindo os artigos Eventhouse and Real-Time Dashboard Integration with Business Events e Consume Business Events from Activator.

4. Valide se os eventos estão fluindo de ponta a ponta verificando se as assinaturas estão ativas e se os dados estão chegando aos destinos esperados na região de recuperação.

Para eventos de Fabric:

1. Recrie as assinaturas no Real-Time hub apontando para os itens do espaço de trabalho, trabalhos ou caminhos do OneLake que você restaurou na região de recuperação, seguindo o artigo Explorar eventos do Fabric no Real-Time hub do Fabric.

2. Valide se os eventos estão fluindo de ponta a ponta verificando se as assinaturas estão ativas e se os dados estão chegando aos destinos esperados na região de recuperação.

Para eventos de Azure:

1. As contas do Armazenamento de Blobs do Azure não são afetadas por uma queda regional do Fabric. Recrie as assinaturas de eventos no Real-Time hub apontando para as mesmas contas do Armazenamento de Blobs do Azure seguindo o artigo Definir alertas para eventos do Armazenamento de Blobs do Azure no Real-Time hub.

2. Valide se os eventos estão fluindo de ponta a ponta verificando se as assinaturas estão ativas e se os dados estão chegando aos destinos esperados na região de recuperação.

Conjunto de esquemas de eventos

Um conjunto de esquemas de eventos é o item do Fabric que contém definições de tipos de evento e de esquema na Inteligência em Tempo Real. Outras capacidades se baseiam nela: os publicadores escrevem eventos que seguem seus esquemas, e os consumidores leem com base nas mesmas definições.

Conjuntos de esquemas de eventos da região principal permanecem indisponíveis para os clientes e não são replicados para a região secundária. No entanto, como um conjunto de esquemas de eventos é uma definição persistente criada previamente, e não uma assinatura efêmera, você pode fazer backup dele com antecedência e restaurá-lo, em vez de recriá-lo manualmente.

Recomendado: faça backup com integração com Fabric Git

Para recuperar um esquema de eventos definido após um desastre regional, configure a integração do Fabric Git antes que ocorra um desastre e sincronize o espaço de trabalho contendo seus conjuntos de esquemas de eventos com seu repositório Git.

1. Configure a integração do Fabric Git para o espaço de trabalho que contém seu conjunto de esquemas de eventos e sincronize-o com seu repositório Git.

2. Mantenha o conjunto de esquema de eventos comprometido e sincronizado regularmente, especialmente após adicionar tipos de eventos ou publicar novas versões de esquema.

3. Durante a recuperação, crie um novo espaço de trabalho na região de alvo (C2. W2), conectá-lo ao mesmo repositório e sincronizar para restaurar o esquema de eventos definido. Como o novo espaço de trabalho está vazio, o Git Sync traz o conteúdo do repositório para o espaço de trabalho.

4. Recrie quaisquer publicadoras e consumidores que usem o conjunto de esquemas, seguindo as orientações para esses tipos de item.

5. Valide que os publicadores podem publicar usando os tipos de eventos restaurados e que os consumidores recebem os eventos conforme esperado.

A definição sincronizada inclui os tipos de eventos no conjunto de esquemas, os esquemas e as versões dos esquemas. Não inclui cadastros de editores, assinaturas de consumidores ou histórico de eventos. Recupere esses elementos separadamente, seguindo as orientações para os tipos de itens que usam o conjunto de esquemas.

Alternativa: recriar manualmente

Se você não configurou a integração com o Git antes do desastre, recrie o conjunto de esquemas de eventos na região de recuperação seguindo Criar e gerenciar conjuntos de esquemas de eventos, depois adicione os tipos de eventos e esquemas que o conjunto original continha seguindo Criar e gerenciar esquemas de eventos em conjuntos de esquemas.

Map

Os itens de mapa da região primária permanecem indisponíveis para os clientes e os itens do Mapa não são replicados para a região secundária.

Se você quiser recuperar um item do Mapa quando ocorrer um desastre, configure a integração do Fabric Git e sincronize o item do Mapa com o repositório Git.

Durante a recuperação, depois que a nova região/capacidade no Fabric for configurada, você poderá usar o repositório para recompilar o item de mapa no espaço de trabalho que você criou. Como o novo workspace está vazio, Git sync obtém o conteúdo do repositório para o workspace vazio. Esta etapa traz o elemento do mapa de volta à vida.

Ontologia

Os usuários de ontologia devem tomar medidas proativas para se preparar para a recuperação de desastre regional. A abordagem descrita abaixo garante que, após um desastre regional, sua Ontologia permaneça recuperável e possa ser restaurada rapidamente.

A maneira mais simples e rápida de habilitar a recuperação é usar a integração do Fabric com o Git e sincronizar sua Ontologia com um repositório do Azure DevOps (ADO). Se o serviço fizer failover para outra região, você poderá usar esse repositório para recompilar a Ontologia em um workspace recém-criado.

Os itens de ontologia na região primária não estão disponíveis para os clientes após um desastre regional e os itens de Ontologia não são replicados para a região secundária.

Para recuperar um item de Ontologia durante um desastre, configure a Integração com o Git do Fabric e sincronize o item de Ontologia com seu repositório ADO com antecedência.

Durante a recuperação, depois que a nova região e a capacidade no Fabric forem configuradas, você poderá usar o repositório para recriar o item de Ontologia em um novo espaço de trabalho. Como o novo workspace está vazio, Git sync realiza o pull do conteúdo do repositório para o workspace, restaurando efetivamente o item de Ontologia.

Agente de Ontologia

Usuários do Ontology Agent devem tomar medidas proativas para se preparar para a recuperação de desastres regional. A abordagem descrita nesta seção garante que, após um desastre regional, sua experiência com o Agente de Ontologia possa ser restaurada em um espaço de trabalho recém-criado.

O Agente de Ontologia depende do item da Ontologia e de quaisquer fontes de dados conectadas à Ontologia, como lakehouses. Os clientes não conseguem acessar sessões do Agente de Ontologia na região principal após um desastre regional, e as sessões do Agente de Ontologia não são replicadas para a região secundária. Sessões ativas de chat, ações em andamento e histórico de conversas da região afetada não podem ser retomados.

Para recuperar a experiência do Ontology Agent durante um desastre, configure a integração com o Fabric Git e sincronize o item da Ontologia com seu repositório Azure DevOps (ADO) com antecedência.

Durante a recuperação, uma vez que a nova região e capacidade no Fabric estejam configuradas, complete os seguintes passos:

1. Crie um novo espaço de trabalho na nova capacidade.
2. Conecte o novo espaço de trabalho ao mesmo repositório ADO que contém o item Ontologia.
3. Use o Git Sync para restaurar o item Ontology no novo workspace.
4. Recupere quaisquer itens de dados dependentes, como lakehouses, seguindo as orientações para esses tipos de itens.
5. Confirme que os dados recuperados estão disponíveis na região pareada. Para dados com suporte do OneLake, assuma que os dados são replicados para a região pareada, mas não presuma a ordem dos dados replicados durante a recuperação.
6. Conecte o item recém-recuperado da Ontologia às fontes de dados recuperadas.
7. Inicie uma nova sessão do Agente de Ontologia e valide que o agente pode se conectar ao item da Ontologia recuperado e às fontes de dados.

Planning

Este artigo descreve os procedimentos de recuperação da experiência de planejamento no IQ. Ele descreve os passos necessários para restaurar componentes-chave, incluindo planilhas de planejamento, planilhas PowerTable, folhas de inteligência, InfoBridge e ativos de dados relacionados.

Integração do Git para restaurar itens do plano

A abordagem preferencial é sincronizar todos os itens do plano com um repositório do Azure DevOps (ADO) ou do GitHub por meio da integração do Git do Fabric. Após um failover, use o repositório para restaurar os itens no novo espaço de trabalho.

Antes do desastre (medidas proativas):

1. No workspace W1, vá para Configurações do Workspace e configure a integração do Git.

2. Selecione Conectar e sincronizar com seu ADO ou GitHub repositório.

3. Selecione os itens de plano para carregar no repositório e selecione Confirmar.

   

4. Confirme se o status do Git dos itens do plano é Sincronizado.

5. Estabelecer uma disciplina de confirmação – confirmar após cada alteração significativa em uma definição de plano para que o repositório sempre reflita o estado mais recente.

Etapas da recuperação:

1. Crie um novo espaço de trabalho W2 na capacidade C2 na região saudável.

2. No workspace W2, vá para Configurações do Workspace e reconecte-se ao mesmo repositório ADO/GitHub.

3. Selecione Controle do código-fonte. Selecione o branch do repositório relevante e selecione Atualizar Tudo. Todos os itens do plano são baixados para o W2.

Os seguintes componentes são restaurados após a recuperação:

• Planilhas do PowerTable: Configurações da tabela de origem, configuração de coluna, acesso a linhas, propriedades visuais (layout, formatos e muito mais), identificação de linha, configurações de comentário, SCD (dimensões de alteração lenta), aprovações, automações e formulários.
• Planilhas de planejamento: Propriedades da planilha (formatação, formatação condicional e muito mais), configurações de comentário, configurações de writeback, colunas de entrada de dados, linhas de entrada de dados, cenários e marcadores.
• InfoBridge: Fontes do InfoBridge, consultas do InfoBridge, etapas de transformação, destinos de gravação de retorno, configurações de gravação de retorno, mapeamentos de consultas vinculadas, grupos de consultas, propriedades visuais (mescla). Esses itens não podem ser recuperados: fontes baseadas em arquivo (CSV, Excel), planilhas entre cargas de trabalho que usam fontes baseadas em arquivo.
• Inteligência: Todos os gráficos e matrizes.

Restauração de SQL no Fabric para planejamento

Os dados inseridos em planilhas de planejamento, tabelas usadas no PowerTable e dados de write-back são armazenados em bancos de dados SQL e devem ser considerados como parte de sua estratégia de recuperação de desastre. Para recuperar bancos de dados SQL, consulte a seção banco de dados SQL .

• Restaurar metadados do plano: cada item do plano está associado a um banco de dados __fabric_plan_sys que armazena metadados para recursos de planejamento, incluindo comentários, cenários, dados de entrada e configuração de gravação de retorno. O banco de dados __fabric_plan_sys não é restaurado automaticamente e deve ser recuperado explicitamente.

• Restaurar bancos de dados de writeback: Se o seu plano usa destinos SQL de writeback, você também deve recuperar manualmente os bancos de dados associados. Os destinos de write-back do SQL configurados não são restaurados automaticamente.

• Restaurar tabelas usadas no PowerTable: Quaisquer tabelas criadas usando o PowerTable são armazenadas em um banco de dados SQL no Fabric. Você também deve recuperar essas tabelas durante a recuperação de desastres.

Agentes de operações

Os usuários do agente de operações devem tomar medidas proativas para se preparar para a recuperação de desastre regional. Seguir a abordagem descrita nesta seção ajuda a garantir que seus agentes possam ser restaurados rapidamente após uma interrupção regional.

Use a integração do Git no Fabric para sincronizar seu espaço de trabalho com um repositório. Essa abordagem permite que você reconstrua as configurações do agente em um novo workspace se o serviço fizer failover para outra região.

Os itens do agente de operações na região primária ficam indisponíveis durante um desastre regional. As configurações do agente, os modelos de comportamento e os logs de atividades não são replicados para a região secundária. Operações em andamento, sessões de chat ativas e eventos ingeridos anteriormente no momento do desastre também são perdidos.

Para se preparar para a recuperação, configure a integração do Git do Fabric e sincronize os itens do agente com o repositório do ADO antes que ocorra um desastre.

Ao recuperar, configure sua nova região e capacidade em Fabric e use o repositório sincronizado para restaurar as configurações do agente em um novo workspace. A sincronização do Git extrai o conteúdo armazenado do repositório para o espaço de trabalho vazio, recriando os itens do agente.

Depois que as configurações forem restauradas, confirme se todos os bancos de dados KQL (Eventhouse) referenciados ou fontes de dados específicas da região estarão acessíveis na nova região. Atualize as referências de endpoint nas configurações dos agentes, conforme necessário. Por fim, reinicie seus agentes e faça com que os usuários iniciem novas sessões de chat. Conversas anteriores não podem ser retomadas.

Databases

Este guia descreve os procedimentos de recuperação para a experiência dos bancos de dados.

banco de dados SQL

Para se proteger contra uma falha regional, os usuários de bancos de dados SQL podem tomar medidas proativas para exportar periodicamente seus dados e usar os dados exportados para recriar o banco de dados em um novo workspace quando necessário.

Use a ferramenta CLI do SqlPackage , que oferece portabilidade de banco de dados e facilita implantações de bancos de dados.

1. Use a ferramenta SqlPackage para exportar o banco de dados para um .bacpac arquivo. Consulte Exportar um banco de dados com SqlPackage para obter mais detalhes.
2. Armazene o .bacpac arquivo em um local seguro que esteja em uma região diferente do banco de dados. Exemplos incluem armazenar o .bacpac arquivo em um Lakehouse que está em uma região diferente, usar uma conta Armazenamento do Azure geo-redundante ou usar outro meio de armazenamento seguro que esteja em outra região.
3. Se o banco de dados SQL e a região não estiverem disponíveis, você poderá usar o .bacpac arquivo com SqlPackage para recriar o banco de dados em um workspace em uma nova região – Workspace C2. W2 na Região B, conforme descrito no cenário acima. Siga as etapas detalhadas em Importar um banco de dados com SqlPackage para recriar o banco de dados com seu .bacpac arquivo.

O banco de dados recriado é um banco de dados independente do banco de dados original e reflete o estado dos dados no momento da operação de exportação.

Considerações sobre failback

O banco de dados recriado é um banco de dados independente. Os dados adicionados ao banco de dados recriado não seriam refletidos no banco de dados original. Se você planeja fazer failback para o banco de dados original quando a região de origem estiver disponível, é necessário considerar reconciliar manualmente os dados do banco de dados recriado com o banco de dados original.

Platform

A plataforma refere-se aos serviços compartilhados subjacentes e à arquitetura que se aplicam a todas as cargas de trabalho. Esta seção descreve procedimentos de recuperação para capacidades compartilhadas do Fabric.

Monitoramento do espaço de trabalho

O monitoramento do espaço de trabalho coleta registros das atividades no espaço de trabalho em que você o habilita. Depois que você recuperar seu espaço de trabalho como C2. W2, ative o monitoramento do espaço de trabalho no W2. Ele começa a coletar dados de monitoramento para o espaço de trabalho recuperado.

Os dados de monitoramento do workspace original (C1.W1) não são transferidos, porque o monitoramento reflete a atividade do workspace no qual é executado.

Biblioteca de variáveis

Microsoft Fabric Bibliotecas de variáveis permitem que os desenvolvedores personalizem e compartilhem configurações de itens em um workspace, simplificando o gerenciamento do ciclo de vida do conteúdo. Do ponto de vista de recuperação de desastre, os usuários da biblioteca de variáveis devem adotar medidas proativas para se proteger contra um desastre regional. Essa proteção pode ser feita por meio da integração com Fabric Git, que garante que, após um desastre regional, a biblioteca de variáveis do usuário permaneça disponível. Para recuperar uma biblioteca de variáveis, siga estes passos:

• Use a integração com o Git do Fabric para sincronizar a sua biblioteca de Variáveis com o seu repositório do ADO. Em caso de desastre, você pode usar o repositório para recompilar a biblioteca variável no novo workspace criado. Use as seguintes etapas:

  1. Conecte seu workspace ao repositório Git, conforme descrito aqui.
  2. Certifique-se de manter o WS e o repositório sincronizados com Commit e Update.
  3. Recuperação – Em caso de desastre, use o repositório para recompilar a biblioteca variável em um novo workspace:

• No workspace recém-criado, conecte-se e sincronize com o repositório do ADO Azure novamente.

• Todos os itens Fabric neste repositório são baixados automaticamente para o novo Workspace.

• Depois de sincronizar seus itens do Git, abra suas Bibliotecas de Variáveis no novo workspace e selecione manualmente o conjunto de valores ativos desejado.

Plano de implantação

Um plano de implantação é um item em um espaço de trabalho Fabric. Ele agrupa os itens e define a ordem para implantá-los. Ele pode executar ações antes ou depois de cada item ser implantado. A definição de itens armazena essas configurações, entradas e referências de itens. O plano não possui um armazenamento separado para valores usados em tempo de execução.

Prepare-se para a recuperação usando a integração do Fabric Git:

1. Conecte o workspace que contém o plano a um repositório Azure DevOps ou GitHub.
2. Confirme o plano e todos os itens do espaço de trabalho usados por ele.
3. Faça commit a cada alteração para que o Git tenha as definições mais recentes.

Após um desastre regional:

1. Crie um espaço de trabalho na região saudável.
2. Conecte o espaço de trabalho ao mesmo repositório e ramo.
3. Atualize o espaço de trabalho a partir do Git. Essa etapa restaura o plano e seus itens.

O git restaura a definição completa do plano. Ele não restaura dados nem executa o estado dos itens vinculados. Use as seções deste artigo para recuperar esses itens.

Chaves gerenciadas pelo cliente para espaços de trabalho do Fabric

Você pode usar chaves gerenciadas pelo cliente (CMK) armazenadas no Azure Key Vault para adicionar uma camada extra de criptografia sobre as chaves gerenciadas pela Microsoft para dados em repouso. Se o Fabric se tornar inacessível ou inoperante em uma região, seus componentes fazem failover para uma instância de backup. Durante o failover, o recurso CMK dá suporte a operações de leitura apenas. Enquanto o serviço Azure Key Vault permanecer íntegro e as permissões para o cofre estiverem intactas, o Fabric continuará a se conectar à sua chave e permitirá que você leia dados normalmente. Isso significa que as seguintes operações não têm suporte durante o failover: habilitar e desabilitar a configuração do CMK do workspace e atualizar a chave.

Fabric Assistente de Migração para banco de dados SQL em Fabric

O Fabric Assistente de Migração pode mover um banco de dados SQL Server para um banco de dados SQL em Fabric em três etapas: o assistente de migração cria o banco de dados alvo e inicia a migração, o monitor de migração acompanha o progresso enquanto o esquema é implantado a partir de um DACPAC, o Assistente de Migração ajuda a revisar e corrigir erros de script, preparar o banco de dados, copiar dados com um trabalho de cópia e finalizar a cópia.

O progresso da migração não é replicado para outra região, e uma implantação interrompida não pode ser retomada. Essas falhas não afetam o banco de dados do SQL Server de origem, então você pode rodar o assistente de migração novamente. Se a região original não estiver disponível, siga primeiro o plano geral de recuperação neste artigo para criar capacidade C2 e espaço de trabalho W2 na região pareada, e então execute a migração no W2. Se a região original se recuperar, você pode tentar a migração novamente no workspace original.

Uma interrupção regional pode fazer com que uma migração fracasse de três maneiras:

• O banco de dados alvo não é criado

  Se o Fabric não conseguir criar o banco de dados de destino, o assistente de migração exibe um erro e a migração não inicia. Selecione Iniciar migração para tentar novamente, ou tente novamente depois.

  O assistente tenta remover um banco de dados incompleto, mas a limpeza pode falhar durante uma interrupção. Antes de tentar novamente, verifique se há um banco de dados com o nome de destino no espaço de trabalho. Confirme se é o banco de dados incompleto da tentativa fracassada antes de apagá-lo.

• A implantação falha

  Se a implantação for interrompida, o monitor de migração para de reportar o progresso, abre o banco de dados alvo e exibe um diálogo indicando que a implantação falhou. Você não pode retomar uma implantação falhada, e o banco de dados criado pela tentativa permanece no espaço de trabalho.

  Para recuperar:

  1. Confirme se o Fabric está disponível e que você tem o DACPAC usado para a migração original.
  2. Identifique o banco de dados criado pela tentativa fracassada. Apague se não contiver nada que você precise guardar. Caso contrário, mantenha e use um nome diferente para o novo banco de dados.
  3. Execute uma nova migração a partir do DACPAC de origem. A migração cria um novo banco de dados.

  Os dados são copiados por um trabalho de cópia na Data Factory. Se você sincronizou o trabalho de cópia com o Git antes da interrupção, consulte Trabalho de Cópia nas orientações do Data Factory. Caso contrário, crie um novo trabalho de cópia como parte da nova migração.

• O histórico de migração não carrega

  Se o Assistente de Migração não conseguir recuperar o histórico de migração, ele informa que as informações de migração não estão mais disponíveis. O progresso salvo no navegador atual é preservado, e o banco de dados alvo não é afetado. Atualize a página para carregar o histórico de migração novamente.

OneLake

Esta seção orienta você pelos procedimentos de recuperação para recursos do OneLake. Para obter mais informações sobre a recuperação de desastres para dados do OneLake, consulte a recuperação de desastre do OneLake.

Políticas de gerenciamento do ciclo de vida

Se o Fabric ficar inacessível ou inoperante em uma região, você ainda pode ler e atualizar sua política de ciclo de vida OneLake durante o failover. Quaisquer dados movidos para a camada de resfriamento ou para a camada fria permanecem nessa camada. Para aplicar sua apólice atual ao seu novo espaço de trabalho de recuperação, siga estes passos:

1. Chame a Política de Exportação no workspace original e salve toda a política de ciclo de vida.
2. Chame a Política de Importação em seu workspace recuperado, com sua política de ciclo de vida exportada como o corpo da solicitação.

Regras de instância de recurso

As regras de instância de recurso ajudam você a controlar com segurança o acesso aos dados no OneLake usando identidades de recursos de Azure confiáveis. Durante o failover regional, o sistema continua a aplicar as regras existentes para acesso de leitura. No entanto, você não pode criar, atualizar ou excluir regras de instância de recurso até que o workspace retorne a um estado gravável.

Informações relacionadas

• Microsoft Fabric guia de recuperação de desastre