Diretrizes personalizadas de recuperação de desastres

Este documento fornece diretrizes específicas de experiência para recuperar seus dados de Fabric em caso de desastre regional.

Cenário de exemplo

Muitas seções de orientação neste documento usam o cenário de exemplo a seguir 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 residência do locatário sofrer uma interrupção, as etapas descritas neste documento estarão condicionadas à sua recuperação, que deve ser iniciada e concluída 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 os clientes 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

As exibições do Lago materializadas da região original permanecem indisponíveis para os clientes após o failover. Os agendamentos de atualização e o histórico de execução não são replicados para a região secundária. Para recuperá-los, conclua as etapas a seguir depois de recuperar seus dados do Lakehouse.

• Recupere as tabelas do Lakehouse usando a Abordagem 1 ou a Abordagem 2 descrita acima. Copie apenas as tabelas de origem.
• Recupere os blocos de anotações que contêm suas definições de MLV. Consulte a seção Notebook para obter as etapas de recuperação.
• 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 os MLVs também foram copiados na etapa anterior, execute CREATE OR REPLACE ao recriá-los.
• Recrie os agendamentos de atualização MLV manualmente no novo espaço de trabalho. O histórico de agendamento e as métricas de execução não são recuperáveis.
• 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 Jupyter da região primária permanecem indisponíveis para os clientes e o código nos notebooks Jupyter não é replicado na região secundária. Para recuperar o código do Notebook na nova região, existem duas abordagens para recuperar o conteúdo do código do Notebook.

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

A melhor maneira de tornar isso fácil e rápido é usar Fabric integração do Git e sincronizar seu notebook com o repositório do ADO. Após o failover do serviço para outra região, você poderá usar o repositório para recompilar o Notebook no novo espaço de trabalho criado.

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 Notebook original tiver um lakehouse padrão, os usuários poderão referenciar a seção Lakehouse para recuperar o lakehouse e, em seguida, conectar o lakehouse recém-recuperado ao Notebook 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. Certifique-se de salvar os arquivos ou pastas em um disco local ou em outro lugar.

         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 não adotar a abordagem de integração com o Git, é possível salvar a versão mais recente do código, os arquivos do gerenciador de recursos e o instantâneo do Notebook em um sistema de controle de versão, como o Git, e recuperar manualmente o conteúdo do Notebook após um desastre:

1. Use o recurso "Importar Notebook" para importar o código do Notebook que deseja 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

As definições de trabalho do Spark (SJD) da região primária permanecem indisponíveis para os clientes, e o arquivo de definição principal e o arquivo de referência no notebook serão replicados para a região secundária através do OneLake. Se desejar recuperar o SJD na nova região, você poderá seguir as etapas manuais descritas abaixo para recuperar o SJD. As execuções anteriores do SJD não serão 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 aparecerá no SJD recém-criado. Você precisará adicionar manualmente a referência do Lakehouse recuperada recentemente no trabalho (consulte as etapas de recuperação do Lakehouse). Os usuários precisarão 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 artefatos 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 do workspace de origem, IDs de artefato de origem e detalhes da conexão. Esta etapa garante a associação correta no momento da implantação.

4. Implante novamente os artefatos GraphQL do repositório Git no novo espaço de trabalho. Esta etapa recria a estrutura e a configuração da API usando as definições atualizadas.

5. Reaplique as configurações do artefato, 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 do artefato, 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 artefato, como monitoramento, autorização, RBAC, introspecção e muito mais, não são transferidas 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 do Fabric) seguindo o respectivo procedimento de recuperação.  

6. Reaplique as configurações de nível do artefato, incluindo papéis 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. 

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

Os itens da Ciência de Dados da região primária permanecem indisponíveis para os clientes, e o conteúdo e os metadados nos modelos e experimentos de ML não serão replicados 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. A configuração, as métricas executadas historicamente e os metadados não serão replicados para a região emparelhada. Você terá que executar novamente cada versão do seu código de ciência de dados para recuperar totalmente os experimentos e modelos de ML após o desastre.

data warehouse

Este guia orienta você pelos procedimentos de recuperação para a experiência de Data Warehouse. Ele aborda os Warehouses.

Depósito

Os warehouses da região original permanecem indisponíveis para os clientes. Para recuperar os armazéns, execute as duas etapas a seguir.

1. Crie um novo Lakehouse provisório no espaço de trabalho C2.W2 para os dados que você copiará do warehouse original.

2. Preencha as tabelas Delta do armazém aproveitando o Explorador do armazém e as funcionalidades do T-SQL (consulte Tabelas no data warehousing do Microsoft Fabric).

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ê implantará as definições de tabela antes da importação de dados, o T-SQL real usado para as importações pode variar. Você pode usar a abordagem INSERT INTO, SELECT INTO ou CREATE TABLE AS SELECT para restaurar as tabelas do Warehouse a partir de lakehouses. Mais adiante no exemplo, estaríamos usando INSERT INTO flavor. (Se você usar o código abaixo, substitua os exemplos pelos 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. Por fim, altere a cadeia de conexão nos aplicativos que usam seu armazém Fabric.

Banco de dados espelhado

Os bancos de dados espelhados da região primária permanecem indisponíveis para os clientes e as configurações não são replicadas para a região secundária. Para recuperá-lo no caso de uma falha regional, é necessário recriar o banco de dados espelhado em outro espaço de trabalho de uma região diferente.

Data Factory

Os itens do Data Factory da região primária permanecem indisponíveis para os clientes e as configurações em pipelines ou itens gen2 de fluxo de dados não serão replicadas para a região secundária. Para recuperar esses itens no caso de uma falha regional, será necessário recriar seus itens de Integração de Dados em outro espaço de trabalho de uma região diferente. As seções a seguir descrevem os detalhes.

Fluxos de Dados Gen2

Se desejar recuperar um item do Dataflow Gen2 na nova região, será necessário exportar um arquivo PQT para um sistema de controle de versão como o Git e, em seguida, recuperar manualmente o conteúdo do Dataflow Gen2 após o desastre.

1. No item Dataflow Gen2, na guia Página Inicial do editor de Power Query, selecione Exportar modelo.

   

2. Na caixa de 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. Na caixa de diálogo Abrir, navegue até a pasta de downloads padrão e selecione o arquivo .pqt que você salvou nas etapas anteriores. Em seguida, selecione Abrir.

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

Não há suporte para o recurso Salvar como de fluxos de dados em caso de recuperação de desastre.

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. É recomendável criar seus pipelines críticos em vários workspaces em diferentes regiões.

Trabalho de cópia

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 maneira de tornar esse processo fácil e rápido é usar Fabric integração do Git e, em seguida, sincronizar seu CopyJob 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 CopyJob no novo workspace criado.

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

   

   A imagem a seguir mostra o CopyJob sincronizado.

   

2. Recupere o CopyJob do repositório do ADO.

   1. 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.

      

   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

Os usuários do Apache Airflow em Fabric devem tomar medidas proativas para se protegerem contra desastres regionais.

Recomendamos gerenciar a redundância com a integração do Git com o Fabric. Primeiro, sincronize sua tarefa do Airflow com seu repositório do ADO. Se o serviço passar por um failover para outra região, você poderá usar o repositório para reconstruir o Airflow Job no novo espaço de trabalho que você criou.

Estas são as etapas para fazer isso:

1. Configure a integração Git do seu workspace e selecione "conectar e sincronizar" com o repositório ADO.

2. Depois disso, você verá que o trabalho do Airflow foi sincronizado com o repositório do 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 serão baixados automaticamente para seu novo workspace.

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/conjuntos de consultas KQL e fluxos 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 itens modelo de grafo e conjunto de consultas do Graph da região primária permanecem indisponíveis para os clientes e esses itens não são replicados para a região secundária. Para recuperar, criar ou usar uma capacidade em uma região diferente e recriar os itens Graph Model e Graph Queryset.

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 Modelo de Grafo no espaço de trabalho secundário (referenciado na etapa 2). Reconfigure a definição do modelo, incluindo nós, bordas, etc., para corresponder ao modelo original do Graph.

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

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

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

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

Banco de dados/Conjunto de consultas KQL

Os usuários do banco de dados/conjunto de consultas KQL devem tomar medidas proativas para se protegerem em relação a um desastre regional. A abordagem a seguir garante que, no caso de um desastre regional, os dados em seus conjuntos de consultas de bancos de dados 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. Estabelecer bancos de dados KQL independentes: configure dois ou mais bancos de dados KQL independentes e conjuntos de consultas em capacidades dedicadas do Fabric. Elas devem ser configuradas em duas regiões diferentes do Azure (preferencialmente regiões emparelhadas do Azure) para maximizar a resiliência.

2. Replicar atividades de gerenciamento: qualquer ação de gerenciamento executada em um banco de dados KQL deve ser refletida no outro. Isso garante que ambos os bancos de dados permaneçam em sincronia. As principais atividades a serem replicadas incluem:

   • Tabelas: verifique se as estruturas de tabela e as definições de esquema estão consistentes em ambos os bancos de dados.

   • Mapeamentos: duplicar todos os mapeamentos requeridos. Verifique se as fontes de dados e os destinos estão corretamente alinhados.

   • Políticas: verifique se os dois bancos de dados têm retenção de dados, acesso e outras políticas relevantes de modo semelhante.

3. Gerenciar a autenticação e a autorização: para cada réplica, configure as permissões necessárias. Verifique se você estabeleceu níveis de autorização adequados, concedendo acesso ao pessoal necessário e mantendo 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 tenham suporte para recuperação de desastres, os fluxos de eventos não perderão dados. Portanto, os clientes devem usar as funcionalidades de recuperação de desastres desses sistemas de destino para garantir a disponibilidade dos dados.

Os clientes também podem obter redundância geográfica implantando cargas de trabalho idênticas do Eventstream em várias regiões da Azure, como parte de uma estratégia de ativo/ativo em múltiplos sites. Com uma abordagem ativa/ativa em vários sites, os clientes podem acessar sua carga de trabalho em qualquer uma das regiões implantadas. 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 ter total redundância geográfica, os clientes podem

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

2. Criar itens do Eventstream nas 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 eventos empresariais, eventos Fabric e eventos de Azure compartilhem a mesma infraestrutura de hub Real-Time em Microsoft Fabric, eles têm origens, comportamentos e requisitos de recuperação distintos que devem ser compreendidos antes do planejamento de recuperação de desastre:

• Eventos do Fabric são assinaturas de eventos que reagem a atividades geradas pelos próprios recursos do Fabric, incluindo alterações no ciclo de vida de itens do workspace (como criar, atualizar ou excluir lakehouses, notebooks ou warehouses), execuções de trabalhos (como execuções de pipelines ou execuções de notebooks) e operações em arquivos e pastas do 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 Armazenamento de Blobs do Azure em si possa permanecer disponível durante uma interrupção regional Fabric, as assinaturas configuradas no hub Real-Time 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 Hub em Tempo Real apontando para os itens do workspace, jobs ou caminhos do OneLake que foram restaurados na região de recuperação, seguindo o artigo Explorar eventos do Fabric no Hub em Tempo Real 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 interrupção regional no 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.

Plano

Este artigo descreve os procedimentos de recuperação da experiência do Plan no IQ. Ele descreve as etapas necessárias para restaurar os principais componentes, incluindo Planejamento, PowerTable, Inteligência, InfoBridge e ativos de dados relacionados.

Integração do Git para recuperar itens de Plan

A abordagem preferida é sincronizar todos os itens do Plan com um repositório Azure DevOps (ADO) ou GitHub usando integração com Fabric Git. 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 Plan para enviar para o repositório e selecione Commit.

   

4. Confirme que o status Git dos itens do Plano está 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 transferidos 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 do Fabric SQL para Plano

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, entradas de dados e configuração de writeback. 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: todas as tabelas criadas usando o PowerTable são armazenadas em um banco de dados SQL 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.

Banco de dados transacional

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

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.

Isso pode ser feito usando a ferramenta da CLI do SqlPackage que fornece portabilidade de banco de dados e facilita implantações de banco 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 arquivo .bacpac em um Lakehouse que está em uma região diferente, usar uma conta de Armazenamento do Azure com redundância geográfica ou usar outro meio de armazenamento seguro que esteja em uma região diferente.
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 reverter para o banco de dados original quando a região inicial estiver disponível, será necessário considerar a conciliação manual dos 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. Isso pode ser feito por meio da integração do Git com o Fabric, o que garante que, após um desastre regional, a biblioteca de variáveis de um usuário permaneça disponível. Para recuperar uma biblioteca de variáveis, recomendamos o seguinte:

• 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.

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

Você pode usar CMK (chaves gerenciadas pelo cliente) armazenadas no Azure Key Vault para adicionar uma camada adicional de criptografia sobre as chaves gerenciadas pela Microsoft para dados em repouso. Caso Fabric se torne inacessível ou inoperável em uma região, seus componentes farão failover para uma instância de backup. Durante o failover, o recurso CMK dá suporte a operações de leitura apenas. Desde que o serviço Azure Key Vault permaneça íntegro e as permissões para o cofre estejam intactas, Fabric continuarão a se conectar à sua chave e permitirão que você leia os 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.

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

Caso Fabric se torne inacessível ou inoperável em uma região, sua política de ciclo de vida do OneLake ainda poderá ser lida e atualizada durante o failover. Todos os dados movidos para a camada fria ou fria permanecerão nessa camada. Você pode seguir estas etapas para aplicar sua política existente ao seu novo espaço de trabalho de recuperação:

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