Orientação de recuperação de desastres específica para situações

Este documento fornece orientações específicas para a experiência na recuperação dos seus dados Fabric em caso de desastre regional.

Cenário de exemplo

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

Digamos que você tenha uma capacidade C1 na região A que tenha um espaço de trabalho W1. Se ativou recuperação em desastres para capacidade C1, os dados do OneLake são replicados para um backup na região B. Se a região A enfrentar interrupções, o serviço Fabric em C1 passa para a região B.

A imagem a seguir ilustra esse cenário. A caixa à esquerda mostra a região afetada. 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 depois que o cliente age para restaurar seus serviços para o pleno funcionamento.

Eis o plano geral de recuperação:

1. Crie uma nova capacidade Fabric C2 numa nova região.

2. Crie 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 C2.W2.

4. Siga as instruções dedicadas para cada componente para restaurar os itens para a sua função completa.

Este plano de recuperação assume que a região de residência dos inquilinos permanece operacional. Se a região de origem do inquilino sofrer uma interrupção, os passos descritos neste documento dependem da sua recuperação, que deve ser iniciada e concluída primeiro pela Microsoft.

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

As secções seguintes fornecem guias passo a passo para cada experiência Fabric, ajudando os clientes durante o processo de recuperação.

Engenheria de Dados

Este guia orienta você pelos procedimentos de recuperação para a experiência de Engenharia de Dados. Abrange lakehouses, notebooks, definições de tarefas do Spark, funções de dados do utilizador e APIs GraphQL.

Casa do Lago

As residências à beira do lago da região original permanecem indisponíveis para os clientes. Para recuperar uma casa do lago, os clientes podem recriá-la no espaço de trabalho C2. W2. Recomendamos duas abordagens para recuperar casas de lago:

Abordagem 1: Usando script personalizado para copiar tabelas e arquivos Lakehouse Delta

Os clientes podem recriar lakehouses usando um script Scala personalizado.

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

2. Crie um novo bloco de anotações no espaço de trabalho C2. W2.

3. Para recuperar as tabelas e ficheiros do lakehouse original, consulte os dados com os caminhos OneLake, como abfss (ver Ligar ao Microsoft OneLake). Pode usar o seguinte exemplo de código (ver Introdução às Microsoft Spark Utilities) no notebook para obter os caminhos ABFS dos ficheiros e tabelas do lakehouse original. (Substituir C1. W1 com o 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 o lakehouse recém-criado.

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

   2. Entre em contato com a equipa de suporte para obter a marca temporal necessária do failover 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 aparecem na nova casa do lago.

Abordagem 2: Usar o Explorador de Armazenamento do Azure para copiar ficheiros e tabelas

Para recuperar apenas ficheiros ou tabelas específicas de um Lakehouse a partir do Lakehouse original, use o Explorador de Armazenamento do Azure. Consulte Integrar OneLake com Explorador de Armazenamento do Azure para passos detalhados. Para tamanhos de dados grandes, use a Abordagem 1.

A recuperação de Fabric materializou vistas para o lago

As visualizações materializadas do Lago da região original continuam indisponíveis para os clientes após o failover. Os horários de atualização e o histórico de execução não são replicados para a região secundária. Para os recuperar, complete os seguintes passos após recuperar os seus dados de Lakehouse.

• Recupere as tabelas de Lakehouse usando a Aproximação 1 ou Abordagem 2 descrita acima. Copie apenas as tabelas de origem.
• Recupera os cadernos que contêm as definições do teu MLV. Consulte a secção do Caderno para os passos de recuperação.
• Executar os cadernos recuperados para recriar os MLVs no novo Lakehouse. Para informações sobre a criação de MLVs, consulte Criar uma Vista de Lago Materializada. Se os MLVs foram também copiados na etapa anterior, execute CREATE OR REPLACE ao recriá-los.
• Recrie manualmente os agendamentos de atualização do MLV 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 os seus MLVs fornecem modelos semânticos ou relatórios, verifique e atualize as referências do ID Lakehouse e do ID do conjunto de dados conforme necessário. Reconecte os relatórios ao modelo semântico atualizado e valide a novidade dos dados.

Bloco de Notas

Os notebooks da região primária permanecem indisponíveis para os clientes, e o código nos notebooks não é replicado para a região secundária. Para recuperar código de Notebook na nova região, existem duas abordagens para recuperar o seu conteúdo.

Abordagem 1: Redundância gerenciada pelo usuário com integração Git (em visualização pública)

A melhor forma de tornar isto fácil e rápido é usar integração com o Fabric Git e depois sincronizar o teu portátil com o repositório ADO. Depois que o serviço fizer failover para outra região, você poderá usar o repositório para reconstruir o bloco de anotações no novo espaço de trabalho criado.

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

   

   A imagem a seguir mostra o bloco de anotações sincronizado.

   

2. Recupere o bloco de anotações do repositório ADO.

   1. No espaço de trabalho recém-criado, ligue-se novamente ao seu repositório Azure ADO.

      

   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 notas original é apresentado.

      

      

   3. Se o notebook original tiver uma casa de lago padrão, os usuários podem consultar a seção Lakehouse para recuperar a casa do lago e, em seguida, conectar a casa do lago recém-recuperada ao notebook recém-recuperado.

      

   4. A integração do Git não suporta sincronizar ficheiros, pastas ou instantâneos do notebook no explorador de recursos do notebook.

      1. Se o bloco de notas original tiver ficheiros no explorador de recursos do bloco de notas:

         1. Certifique-se de salvar arquivos ou pastas em um disco local ou em algum outro lugar.

         2. Recarregue o ficheiro a partir do seu disco local ou unidades na nuvem para o bloco de notas recuperado.

      2. Se o bloco de anotações original tiver um instantâneo do bloco de anotações, também salve o instantâneo 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 backup do conteúdo do código

Se você não adotar a abordagem de integração do Git, poderá salvar a versão mais recente do código, os arquivos no explorador de recursos e o instantâneo do bloco de anotações em um sistema de controle de versão, como o Git, e recuperar manualmente o conteúdo do bloco de anotações após um desastre:

1. Use o recurso "Importar bloco de anotações" para importar o código do bloco de anotações que você 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 uma 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 bloco de notas original tiver ficheiros ou pastas no explorador de recursos, volte a carregar os ficheiros ou pastas guardados no sistema de controlo de versão do utilizador.

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 bloco de anotações serão replicados para a região secundária por meio do OneLake. Se você quiser recuperar o SJD na nova região, você pode seguir as etapas manuais descritas abaixo para recuperar o SJD. As execuções históricas do SJD não serão restauradas.

Podes recuperar os itens SJD copiando o código da região original usando o Explorador 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 Explorador de Armazenamento do Azure para copiar Libs, Mains e 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 recém-recuperada do Lakehouse ao trabalho (Para mais detalhes, consulte as etapas de recuperação do Lakehouse). Os usuários precisarão reinserir os argumentos de linha de comando originais manualmente.

   

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

Para detalhes sobre Explorador de Armazenamento do Azure, consulte Integrar OneLake com Explorador de Armazenamento do Azure.

Funções de dados do utilizador

Para recuperar as suas funções de dados de utilizador numa região saudável, utilize uma das seguintes abordagens.

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

O mecanismo de recuperação preferido é a integração Fabric Git. Ao sincronizar projetos de funções de dados de utilizador com um repositório Azure DevOps ou GitHub, pode reconstruí-los rapidamente num 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 aloja a função de dados do utilizador.
2. Ligue o espaço de trabalho a um repositório Azure DevOps ou GitHub.
3. Guarde todos os dados do utilizador no repositório e sincronize as alterações regularmente.
4. Armazene as definições específicas do ambiente separadamente em bibliotecas variáveis, se necessário.

Etapas de recuperação

Após um desastre regional:

1. Crie uma nova capacidade do Fabric numa região em bom estado, como a C2.
2. Crie um novo espaço de trabalho, como o W2, na nova capacidade.
3. Ligue o espaço de trabalho ao mesmo repositório Azure DevOps ou GitHub.
4. Abra Controlo de código-fonte e sincronize o conteúdo do repositório com o espaço de trabalho.
5. Recrie ou restaure todos os recursos dependentes do Fabric, como lakehouses, bases de dados SQL no Fabric, armazéns e Business Events.
6. Reimplementar as funções de dados do utilizador.
7. Validar a execução da função e a conectividade de dependências.
8. Atualize as aplicações posteriores, os pipelines de dados ou outros sistemas integrados para referenciarem as funções recuperadas.
9. Validação completa de ponta a ponta de todos os teus cenários.

Considerações importantes

• A integração com o Git recupera apenas código-fonte e ativos do projeto.
• Os registos históricos de execuções não são recuperados.
• Os sistemas a jusante podem exigir a reassociação dos pontos terminais.

Para mais informações, consulte Controlo de código-fonte e implementação das funções de dados do utilizador.

Abordagem 2: Recuperação manual

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

Prepare-se para um desastre

Complete regularmente as seguintes tarefas e armazene os artefactos num repositório externo de controlo de versões ou numa localização de backup:

• Exportar o código-fonte da função para um repositório GitHub.
• Documente e preserve a informação das dependências.
• Definições do ambiente do documento.

Etapas de recuperação

Após um desastre regional:

1. Crie uma nova capacidade do Fabric numa região em bom estado, 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, bases de dados SQL no Fabric, armazéns, eventhouses e serviços externos.
4. Crie um novo projeto de função de dados do utilizador.
5. Importa ou recria o código-fonte da função.
6. Reaplique as definições de configuração em tempo de execução.
7. Reinstala todas as dependências de funções.
8. Reimplemente a função.
9. Reconfigure autenticação e autorização.
10. Recrie editores ou consumidores de Eventos de Negócio, caso sejam utilizados.
11. Complete testes de validação de ponta a ponta para os 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 GraphQL não são replicadas para a região secundária. Para recuperar o GraphQL numa nova região, utilize uma das seguintes abordagens.

Abordagem 1: Redundância gerida pelo utilizador com integração Git

A melhor forma de tornar este processo fácil e rápido é usar a integração do Fabric Git e depois sincronizar o seu GraphQL com o seu repositório ADO. Depois de o serviço passar para outra região, podes usar o repositório para reconstruir o GraphQL no novo espaço de trabalho que criaste.

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

2. Recupere todas as fontes de dados dependentes, como bases de dados Lakehouse, Warehouse ou SQL, seguindo os respetivos passos 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 da área de trabalho de origem, IDs de artefactos de origem e detalhes da ligação. Esta etapa assegura a ligação correta no momento da implantação.

4. Redistribua artefactos GraphQL do repositório Git para o novo espaço de trabalho. Esta etapa recria a estrutura e configuração da API utilizando as definições atualizadas.

5. Reaplique as definições do artefacto, incluindo funções, controlos de acesso e configuração de autenticação.

6. Reaplique referências de endpoint atualizando quaisquer aplicações ou integrações para usar o endpoint recém-criado do GraphQL.

7. Atualize quaisquer pipelines de implantação existentes que apontavam para o antigo espaço de trabalho, de modo a que passem a referenciar o espaço de trabalho recém-criado.

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

Abordagem 2: Abordagem manual

Se não adotar a abordagem de integração do Git, pode usar a seguinte abordagem manual para recuperar o GraphQL.

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

2. Recuperar todas as fontes de dados dependentes, como bases de dados Lakehouse, Warehouse ou SQL.

3. Recrie manualmente a API GraphQL no novo espaço de trabalho, incluindo definições de esquema, ligações de fontes de dados e relações.

4. Reaplique as definições do artefacto, incluindo funções, controlos de acesso e configuração de autenticação.

5. Reaplique referências de endpoint atualizando quaisquer aplicações ou integrações para usar o endpoint recém-criado do GraphQL.

6. Atualize quaisquer pipelines de implantação existentes que apontavam para o antigo espaço de trabalho, de modo a que passem a referenciar o espaço de trabalho recém-criado.

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

Considerações importantes

1. O GraphQL baseia-se em dependências externas (como Lakehouse, Warehouse e SQL), que deve recuperar antes da implementação do GraphQL.

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

3. A religação automática das fontes de dados não é garantida em cenários de recuperação de desastres, especialmente quando se utilizam credenciais guardadas ou ligações entre espaços de trabalho.

4. Outras definições de artefactos, como monitorização, autorização, RBAC, introspeção, entre outras, não são preservadas após o failover. Deve restabelecer estas definições na nova região.

References

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

• Controlo de código-fonte e pipelines de implementação na API para GraphQL - Microsoft Fabric | Microsoft Learn 

App

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

Abordagem manual

Pode recuperar manualmente uma aplicação Fabric após um desastre regional usando o código-fonte da aplicação e a CLI Rayfin. 

Prerequisites 

Antes de ocorrer um desastre:

• Armazene o código-fonte da Fabric App no GitHub, Azure DevOps ou noutro repositório de controlo de versão. 

• Documente o processo de recuperação.  

Passos de recuperação 

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

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

3. Recupere o código-fonte mais recente da Fabric App do seu repositório de controlo de versões ou backup local. 

4. A partir do diretório de origem da aplicação, implemente a aplicação Fabric no espaço de trabalho de recuperação usando a CLI Rayfin. Execute rayfin up --workspace <new workspace>. 

5. Recupere o item filho da aplicação (Fabric SQL Database) seguindo os respetivos procedimentos de recuperação.  

6. Reaplique as definições do nível do artefacto, incluindo funções e controlos de acesso conforme necessário.  

7. Valide a funcionalidade da aplicação e assegure que os utilizadores têm as permissões corretas.  

Importante 

• Manter o código-fonte da Fabric App fora da região Fabric para permitir a recuperação.  

• Os dados da aplicação na base de dados não são recuperados como parte do processo de implementação do Fabric App e devem ser restaurados separadamente.  Pode recuperar manualmente uma aplicação Fabric após um desastre regional usando o código-fonte da aplicação e a CLI Rayfin. 

Ciência de Dados

Este guia orienta você pelos procedimentos de recuperação para a experiência de Ciência de Dados. Abrange modelos e experiências de ML.

Modelo e Experimento de ML

Os 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 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 execute manualmente o conteúdo do código novamente após o desastre.

1. Recupere o bloco de notas. Consulte as etapas de recuperação do Notebook.

2. A configuração, as métricas de execução histórica 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 modelos e experimentos de ML após o desastre.

Armazém de Dados

Este guia guia-o pelos procedimentos de recuperação para a experiência no Data Warehouse. Abrange armazéns.

Armazém

Os armazéns da região original permanecem indisponíveis para os clientes. Para recuperar armazéns, use 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 irá copiar do armazém original.

2. Preenche as tabelas Delta do armazém aproveitando o Explorador do armazém e as capacidades T-SQL (ver Tabelas em data warehousing em Microsoft Fabric).

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

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

1. Crie uma casa de lago provisória "LH2" em C2. W2.

2. Recupere as tabelas Delta no lakehouse interino do armazém original seguindo as etapas de recuperação Lakehouse.

3. Crie um novo armazém "WH2" em C2. W2.

4. Conecte a casa do lago provisória em seu explorador de armazém.

5. Dependendo de como você vai implantar definições de tabela antes da importação de dados, o T-SQL real usado para importações pode variar. Você pode usar a abordagem INSERT INTO, SELECT INTO ou CREATE TABLE AS SELECT para recuperar tabelas de armazém de lakehouses. Mais adiante no exemplo, vamos utilizar o comando INSERT INTO. (Se você usar o código abaixo, 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. Por fim, altera a cadeia de conexão nas aplicações que usam o seu armazém Fabric.

Base de dados espelhada

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, você precisa recriar seu 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 definições e configurações em pipelines ou itens gen2 do fluxo de dados não serão replicadas para a região secundária. Para recuperar esses itens no caso de uma falha regional, você precisará 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 você quiser recuperar um item Dataflow Gen2 na nova região, precisará 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. A partir do seu item Dataflow Gen2, no separador Início 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. Quando terminar, selecione OK.

   

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

4. No painel de visualizaçã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 salvo nas etapas anteriores. Em seguida, selecione Abrir.

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

A funcionalidade Salvar como de fluxos de dados não é suportada em situações de recuperação de desastres.

Tubulações

Os clientes não podem aceder a pipelines em caso de um desastre regional, e as configurações não são replicadas para a região emparelhada. Recomendamos a criação dos seus pipelines críticos em vários espaços de trabalho em diferentes regiões.

Tarefa de Cópia

Os usuários do CopyJob devem tomar medidas proativas para se 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 Git (em visualização pública)

A melhor forma de tornar este processo fácil e rápido é usar integração com o Fabric Git e depois sincronizar o seu CopyJob com o seu repositório ADO. Depois que o serviço fizer failover para outra região, você poderá usar o repositório para reconstruir o CopyJob no novo espaço de trabalho criado.

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

   

   A imagem a seguir mostra o CopyJob sincronizado.

   

2. Recupere o CopyJob do repositório ADO.

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

      

   2. Se o CopyJob original usar um Lakehouse, os utilizadores podem consultar a seção do 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 utilizadores do Apache Airflow Job in Fabric devem tomar medidas proativas para se proteger contra um desastre regional.

Recomendamos gerir a redundância com integração do Fabric Git. Primeiro, sincronize a sua tarefa do Airflow com o seu repositório ADO. Se o serviço fizer failover para outra região, você poderá usar o repositório para reconstruir o Trabalho de Fluxo de Ar no novo espaço de trabalho criado.

Aqui estão os passos para conseguir isso:

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

2. Depois disso, irá ver que a sua tarefa de Airflow foi sincronizada com o repositório ADO.

3. Se precisares de recuperar o trabalho Airflow do repositório ADO, cria um novo espaço de trabalho, liga-te e sincroniza novamente com o repositório Azure ADO. Todos os itens Fabric, incluindo o Airflow, neste repositório serão automaticamente descarregados para o seu novo espaço de trabalho.

Informação em Tempo Real

Este guia orienta você pelos procedimentos de recuperação para a experiência de Inteligência em Tempo Real. Abrange bases de dados/conjuntos de consultas KQL e fluxos de eventos.

Activator

Os itens ativadores da região principal continuam indisponíveis para os clientes, e as definições de gatilhos ativadores não são replicadas para a região secundária. Os utilizadores do ativador devem tomar medidas proativas para se preparar para a recuperação regional de desastres.

Para garantir que pode recuperar itens Ativadores em caso de desastre regional, configure a integração com o Fabric Git para fazer backup das definições de gatilhos e restaurá-las num espaço de trabalho noutra região.

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

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

Modelo de grafo/conjunto de consultas

Os itens do Graph Model e do Graph Queryset da região principal continuam indisponíveis para os clientes, e estes itens não são replicados para a região secundária. Para recuperar, crie ou use uma capacidade numa região diferente e recrie os itens do Modelo de Grafo e do Conjunto de Consultas de Grafo aí.

1. Crie ou use uma capacidade Fabric existente numa 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 nessa função.

3. Recrie o item do Modelo de Grafo no espaço de trabalho secundário (referenciado no passo 2). Reconfigure a definição do modelo, incluindo nós, arestas, etc., para corresponder ao Modelo de Grafo original.

4. Se a casa original do lago estiver na região em decadência, recupere-a primeiro seguindo a secção da Casa do Lago.

5. Ligue uma casa de lago como fonte de dados OneLake para o item recém-criado do Modelo de Grafo. Use um data lakehouse recuperado se este estivesse na região com falhas, ou reconecte-se ao data lakehouse existente se este continuar disponível.

6. Reconfigure quaisquer horários de carregamento de dados ou ligações para o Modelo de Grafo no novo espaço de trabalho.

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

Banco de dados KQL/Queryset

Os usuários do banco de dados/conjunto de consultas KQL devem tomar medidas proativas para se proteger contra 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.

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

1. Estabelecer bases de dados KQL independentes: Configurar duas ou mais bases de dados/conjuntos de consultas KQL independentes em capacidades Fabric dedicadas. Estas devem ser configuradas em duas regiões diferentes do Azure (preferencialmente regiões emparelhadas com o 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 espelhada no outro. Isso garante que ambos os bancos de dados permaneçam sincronizados. As principais atividades a serem replicadas incluem:

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

   • Mapeamento: duplique todos os mapeamentos necessários. Certifique-se de que as fontes de dados e os destinos estão alinhados corretamente.

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

3. Gerenciar autenticação e autorização: para cada réplica, configure as permissões necessárias. Certifique-se de que os níveis de autorização adequados sejam estabelecidos, concedendo acesso ao pessoal necessário, mantendo os padrões de segurança.

4. Ingestão paralela de dados: 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 em que o ingere.

Eventstream

Um fluxo de eventos é um local centralizado na plataforma Fabric para capturar, transformar e encaminhar eventos em tempo real para vários destinos (por exemplo, lakehouses, bases de dados/conjuntos de consultas KQL) com uma experiência sem código. Desde que os destinos sejam suportados pela recuperação de desastres, os fluxos de eventos não perderão dados. Portanto, os clientes devem usar os recursos de recuperação de desastres desses sistemas de destino para garantir a disponibilidade dos dados.

Os clientes também podem alcançar geo-redundância ao implementar cargas de trabalho Eventstream idênticas em múltiplas regiões do Azure como parte de uma estratégia multi-site ativo/ativo. Com uma abordagem ativa/ativa em vários locais, os clientes podem aceder ao seu workload em qualquer uma das regiões implementadas. Essa abordagem é a mais complexa e dispendiosa para a recuperação de desastres, mas pode reduzir o tempo de recuperação para quase zero na maioria das situações. Para serem totalmente redundantes geograficamente, os clientes podem

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

2. Crie itens Eventstream nas regiões correspondentes.

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

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

Eventos Empresariais, Eventos Fabric e Eventos Azure

Embora os Business Events, Fabric Events e Azure Events partilhem a mesma infraestrutura Real-Time hub em Microsoft Fabric, têm origens, comportamentos e requisitos de recuperação distintos que devem ser compreendidos antes de planear a recuperação em desastres:

• Os Eventos do Fabric são subscrições de eventos que reagem à atividade gerada pelos próprios recursos do Fabric, incluindo alterações no ciclo de vida dos itens do espaço de trabalho (como a criação, atualização ou eliminação de lakehouses, notebooks ou warehouses), execuções de tarefas (como execuções de pipelines ou de notebooks) e operações em ficheiros e pastas no OneLake. Estas subscrições são do tipo push e efémeras. As subscrições não são replicadas para a região secundária.

• Os Azure Events são subscrições de eventos para atividades produzidas por contas do Armazenamento de Blobs do Azure. Estes recursos do Azure existem independentemente de qualquer capacidade ou região do Fabric. Embora o próprio recurso Armazenamento de Blobs do Azure possa permanecer disponível durante uma interrupção regional Fabric, as subscrições configuradas no hub Real-Time não são replicadas para a região secundária e têm de ser recriadas.

• Os Eventos Empresariais são uma funcionalidade distinta da Inteligência em Tempo Real do Fabric que permite às equipas definir, publicar e agir com base em sinais de negócio relevantes. Os eventos empresariais são gerados no Fabric através do Activator, de notebooks do Spark ou de Funções de Dados do Utilizador, sendo depois publicados no Real-Time hub, onde consumidores subsequentes, como o Activator, o Eventhouse ou o Power Automate, podem reagir aos mesmos. Os esquemas de eventos são governados centralmente através do Registo de Esquemas. O Eventhouse armazena automaticamente todos os eventos empresariais publicados, pelo que a sua recuperação afeta diretamente a disponibilidade do histórico de eventos empresariais. Nenhuma das configurações do editor ou consumidor, definições de esquema ou subscrições é replicada para a região secundária.

Use os seguintes passos para restaurar os Business Events, Fabric Events e Azure Events no novo espaço de trabalho na região de recuperação.

Para Eventos Empresariais:

1. Recrie o evento empresarial utilizado por editores e consumidores seguindo o artigo Criar Eventos Empresariais no Fabric Real-Time Hub. Durante a criação do evento de negócio, cria-se o recurso Event Schema Set (Conjunto de Esquemas de Evento). O recurso da Casa de Eventos é opcional dependendo do cenário. Se fizeste backup do teu conjunto de esquemas de eventos com integração com Git, restaura-o primeiro seguindo a secção do conjunto de esquemas de eventos, depois aponta o evento de negócio para o conjunto de esquemas restaurado.

2. Recrie quaisquer itens do publisher que gerem eventos empresariais, como cadernos Spark ou Funções de Dados do Utilizador, no novo espaço de trabalho seguindo os artigos do publisher: Usar a Função de Dados do Utilizador como Publisher de Eventos Empresariais, Usar o Ativador como Publisher de Eventos Empresariais, Usar o Caderno como Eventos Empresariais Publisher, e usar o Eventstream como Business Events Publisher.

3. Recrie as subscrições de consumidor no hub Real-Time (por exemplo, regras do Activator, disparadores de blocos de notas ou fluxos do Power Automate) que originalmente reagiam a eventos empresariais na região afetada, seguindo os artigos Integração do Eventhouse e do Dashboard em Tempo Real com Eventos Empresariais e Consumir Eventos Empresariais a partir do Activator.

4. Valide que os eventos estão a fluir de ponta a ponta, verificando que as subscrições estão ativas e que os dados estão a chegar aos destinos esperados na região de recuperação.

Para eventos do Fabric:

1. Recrie as subscrições no Real-Time hub para que apontem para os itens da área de trabalho, tarefas ou caminhos do OneLake que foram restaurados na região de recuperação, seguindo o artigo Explorar eventos do Fabric no Fabric Real-Time hub.

2. Valide que os eventos estão a fluir de ponta a ponta, verificando que as subscrições estão ativas e que os dados estão a chegar aos destinos esperados na região de recuperação.

Para eventos Azure:

1. As contas do Armazenamento de Blobs do Azure não são afetadas por uma falha regional do Fabric. Recrie as subscrições de eventos no Real-Time hub, a apontar 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 que os eventos estão a fluir de ponta a ponta, verificando que as subscrições estão ativas e que os dados estão a chegar aos destinos esperados na região de recuperação.

Esquema de evento definido

Um conjunto de esquemas de eventos é o Fabric item que contém definições de tipo de evento e esquema em Real-Time Intelligence. Outras capacidades baseiam-se nela: os editores escrevem eventos que seguem os seus esquemas, e os consumidores interpretam as mesmas definições.

Os 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, e não uma subscrição efémera, pode criar previamente uma cópia de segurança e restaurá-lo em vez de voltar a criá-lo manualmente.

Recomendado: backup com integração do Fabric Git

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

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

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

3. Durante a recuperação, crie um novo espaço de trabalho na região-alvo (C2. W2), liga-o ao mesmo repositório e sincroniza 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 editoras e consumidores que utilizem o conjunto de esquemas, seguindo as orientações para esses tipos de itens.

5. Valide que os editores podem publicar nos tipos de evento 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 do esquema. Não inclui registos de editores, subscrições de consumidores ou histórico de eventos. Recupere-os separadamente, seguindo as orientações para os tipos de itens que utilizam o conjunto de esquemas.

Alternativa: recriar manualmente

Se 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 gerir conjuntos de esquemas de eventos, depois adicione os tipos de eventos e esquemas que o conjunto original continha, seguindo Criar e gerir esquemas de eventos em conjuntos de esquemas.

Map

Os itens do mapa da região principal continuam indisponíveis para os clientes e os itens do mapa não são replicados para a região secundária.

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

Durante a recuperação, depois de a nova região/capacidade no Fabric estar configurada, podes usar o repositório para reconstruir o item Map no novo espaço de trabalho que criaste. Como o novo espaço de trabalho está vazio, o Git sync coloca o conteúdo do repositório no espaço de trabalho vazio. Este passo traz o item do Mapa de volta à vida.

Ontologia

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

A forma mais simples e rápida de permitir a recuperação é usar a integração com o Fabric Git e sincronizar a sua Ontologia com um repositório Azure DevOps (ADO). Caso o serviço faça failover para outra região, pode usar este repositório para reconstruir a Ontologia num espaço de trabalho 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 Git do Fabric e sincronize o item de Ontologia com o seu repositório ADO antecipadamente.

Durante a recuperação, uma vez que a nova região e capacidade no Fabric estejam configuradas, pode usar o repositório para reconstruir o item Ontology num novo espaço de trabalho. Como o novo espaço de trabalho está vazio, o Git sync puxa o conteúdo do repositório para o espaço de trabalho, restaurando efetivamente o item Ontologia.

Plano

Este artigo descreve os procedimentos de recuperação da experiência Plan no IQ. Descreve os passos necessários para restaurar componentes-chave, incluindo Planeamento, PowerTable, Inteligência, InfoBridge e ativos de dados relacionados.

Integração com o Git para restaurar itens do plano

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

Pré-desastre (medidas proativas):

1. No workspace W1, vai às Definições do Workspace e configura a integração com o Git.

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

3. Selecione os itens do Plano para carregar para o repositório e selecione Commit.

   

4. Confirme que o estado Git dos itens do Plano está Sincronizado.

5. Estabeleça uma disciplina de commits – faça um commit após cada alteração significativa na definição de um plano, para que o repositório reflita sempre o estado mais recente.

Passos de recuperação:

1. Crie um novo espaço de trabalho W2 dentro da capacidade C2 na zona saudável.

2. No workspace W2, vai às Definições do Workspace e volta a ligar-te ao mesmo repositório ADO/GitHub.

3. Selecione Controlo de Versões. Selecione o ramo do repositório relevante e selecione Atualizar Tudo. Todos os itens do Plano são descarregados para o W2.

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

• Folhas da PowerTable: Definições da tabela de origem, configuração das colunas, acesso às linhas, propriedades visuais (layout, formatos, entre outras), identificação das linhas, definições de comentários, dimensões de alteração lenta (SCD), aprovações, automatizações e formulários.
• Folhas de planeamento: Propriedades da folha (formatação, formatação condicional e mais), definições de comentários, definições de writeback, colunas de entrada de dados, linhas de entrada de dados, cenários e favoritos.
• InfoBridge: origens do InfoBridge, consultas do InfoBridge, passos de transformação, destinos de reescrita, definições de reescrita, mapeamentos de consultas associadas, grupos de consultas, propriedades visuais (mistura). Estes itens não podem ser recuperados: fontes baseadas em ficheiros (CSV, Excel), folhas de trabalho cruzadas que usam fontes baseadas em ficheiros.
• Inteligência: Todos os gráficos e matrizes.

Restauro do Fabric SQL para o plano

Os dados introduzidos em folhas de planeamento, tabelas usadas no PowerTable e dados de writeback são armazenados em bases de dados SQL e devem ser considerados como parte da sua estratégia de recuperação de desastres. Para recuperar bases de dados SQL, consulte a secção de bases de dados SQL .

• Restaurar metadados de plano: Cada item de Plano está associado a uma base de dados __fabric_plan_sys que armazena metadados para funcionalidades de planeamento, incluindo comentários, cenários, dados de entrada e configuração de writeback. A base de dados __fabric_plan_sys não é restaurada automaticamente e tem de ser recuperada explicitamente.

• Restaurar bases de dados de escrita diferida: Se o seu plano utiliza destinos SQL de escrita diferida, deve também recuperar manualmente as bases de dados associadas. Os destinos de writeback SQL configurados não são restaurados automaticamente.

• Restaurar tabelas usadas no PowerTable: Quaisquer tabelas criadas através do PowerTable são armazenadas numa base de dados Fabric SQL. Também tens de recuperar estas tabelas durante o DR.

Agentes de operações

Os utilizadores dos agentes de operações devem tomar medidas proativas para se preparar para a recuperação regional de desastres. Seguir a abordagem descrita nesta secção ajuda a garantir que os seus agentes possam ser restaurados rapidamente após uma interrupção regional.

Use a integração do Fabric Git para sincronizar o seu espaço de trabalho com um repositório. Esta abordagem permite-lhe reconstruir configurações de agentes num novo espaço de trabalho caso o serviço faça failover para outra região.

Os itens dos agentes operacionais na região principal não estão disponíveis em caso de desastre regional. Configurações de agentes, modelos de comportamento e registos de atividade não são replicados para a região secundária. Operações em andamento, sessões ativas de chat e eventos previamente ingeridos no momento do desastre também são perdidos.

Para preparar a recuperação, configure a integração com o Fabric Git e sincronize os seus itens de agente com o seu repositório ADO antes de ocorrer um desastre.

Ao recuperar, configura a tua nova região e capacidade no Fabric, depois usa o repositório sincronizado para restaurar as configurações do agente num espaço de trabalho novo. O git sync retira o conteúdo armazenado do repositório para o espaço de trabalho vazio, recriando os itens do teu agente.

Uma vez restauradas as configurações, confirme que quaisquer bases de dados Eventhouse (KQL) referenciadas ou fontes de dados específicas por região estão acessíveis na nova região. Atualize as referências dos endpoints nas configurações do agente conforme necessário. Por fim, reinicie os seus agentes e peça aos utilizadores para iniciar 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 do banco de dados transacional.

base 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 espaço de trabalho quando necessário.

Isso pode ser conseguido usando a ferramenta SqlPackage CLI 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 ficheiro .bacpac numa Lakehouse que esteja numa região diferente, usar uma Conta Armazenamento do Azure geo-redundante, ou usar outro meio de armazenamento seguro que esteja numa 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 espaço de trabalho 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 a reversão para estado original

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 planear fazer um failback para a base de dados original quando a região inicial estiver disponível, será necessário considerar a reconciliação manual dos dados da base de dados recriada para a base de dados original.

Platform

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

Monitoramento de espaço de trabalho

A monitorização do espaço de trabalho recolhe registos sobre a atividade no espaço de trabalho onde a ativas. Depois de recuperares o teu espaço de trabalho como C2. W2, ativa a monitorização do espaço de trabalho no W2. Começa a recolher dados de monitorização para o espaço de trabalho recuperado.

Os dados de monitorização do espaço de trabalho original (C1.W1) não são transferidos, porque a monitorização reflete a atividade do espaço de trabalho em que é executada.

Biblioteca de variáveis

As bibliotecas Microsoft Fabric Variable permitem aos programadores personalizar e partilhar configurações de itens dentro de um espaço de trabalho, simplificando a gestão do ciclo de vida do conteúdo. Do ponto de vista da recuperação de desastres, os usuários de bibliotecas variáveis devem se proteger proativamente contra um desastre regional. Isto pode ser feito através da integração Fabric Git, que garante que, após um desastre regional, a biblioteca de variáveis do utilizador permaneça disponível. Para recuperar uma biblioteca de variáveis, recomendamos o seguinte:

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

  1. Conecte seu espaço de trabalho ao repositório Git conforme descrito aqui.
  2. Certifique-se de manter o WS e o repositório sincronizados com Confirmar e Atualizar.
  3. Recuperação - Em caso de desastre, use o repositório para reconstruir a biblioteca de variáveis em um novo espaço de trabalho:

• No espaço de trabalho recém-criado, ligue-se e sincronize novamente com o seu repositório Azure ADO.

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

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

Chaves geridas pelo cliente para os workspaces do Fabric

Pode usar chaves geridas pelo cliente (CMK) armazenadas no Azure Key Vault para adicionar uma camada adicional de encriptação por cima das chaves geridas pela Microsoft para os dados em repouso. No caso de o Fabric se tornar inacessível ou inoperacional numa região, os seus componentes passarão para uma instância de backup. Durante o failover, o recurso CMK suporta operações em modo de leitura. Enquanto o serviço Azure Key Vault se mantiver saudável e as permissões para o cofre estiverem intactas, o Fabric continuará a conectar-se à sua chave e permitirá a leitura normal dos dados. Isso significa que as seguintes operações não são suportadas durante o failover: habilitar e desabilitar a configuração CMK do espaço de trabalho e atualizar a chave.

OneLake

Esta secção orienta-o pelos procedimentos de recuperação das funcionalidades do OneLake. Para mais informações sobre recuperação de desastres para dados OneLake, consulte recuperação de desastres OneLake.

Políticas de gerenciamento do ciclo de vida

No caso de o Fabric se tornar inacessível ou inoperacional numa região, a sua política de ciclo de vida OneLake ainda pode ser lida e atualizada durante o failover. Quaisquer dados movidos para o nível frio ou frio permanecerão nesse nível. Pode seguir estes passos para aplicar a sua apólice existente ao seu novo espaço de trabalho de recuperação:

1. Chama a política de exportação no teu espaço de trabalho original e guarda a política de ciclo de vida completa.
2. Invoque a Política de Importação na sua área de trabalho recuperada, com a sua política do ciclo de vida exportada no corpo do pedido.

Regras de instância de recurso

As regras de instância de recursos ajudam-no a controlar de forma segura o acesso aos dados no OneLake usando identidades de recursos Azure de confiança. Durante o failover regional, o sistema continua a aplicar as regras existentes de acesso de leitura. No entanto, não pode criar, atualizar ou eliminar regras da instância do recurso até que o espaço de trabalho volte a um estado de escrita.

Informações relacionadas

• Microsoft Fabric guia de recuperação de desastres