Guía de recuperación ante desastres específica de la experiencia

Este artículo ofrece orientación específica de cada experiencia sobre cómo recuperar sus datos de Fabric en caso de desastre regional.

Escenario de ejemplo

Muchas secciones de orientación en este artículo utilizan el siguiente ejemplo de escenario para fines de explicación e ilustración. Consulte este escenario según sea necesario.

Imagine que tiene una capacidad C1 en la región A que tiene un área de trabajo W1. Si ha activado la recuperación ante desastres para la capacidad C1, los datos de OneLake se replican en una copia de seguridad en la región B. Si la región A se enfrenta a interrupciones, el servicio Fabric en C1 cambia automáticamente a la región B.

Este escenario se ilustra en la imagen siguiente. En el cuadro de la izquierda se muestra la región interrumpida. En el cuadro central se representa la disponibilidad continua de los datos después de la conmutación por error y, en el cuadro de la derecha, se muestra la situación completamente cubierta después de que el cliente actúe para restaurar sus servicios a su plena funcionalidad.

Este es el plan de recuperación general:

1. Cree una nueva capacidad de Fabric C2 en una nueva región.

2. Cree un área de trabajo W2 en C2, incluidos sus elementos correspondientes con los mismos nombres que en C1.W1.

3. Copie los datos del C1.W1 interrumpido a C2.W2.

4. Siga las instrucciones dedicadas de cada componente para restaurar los elementos a su funcionamiento completo.

Este plan de recuperación supone que la región de origen del cliente permanece operativa. Si la región de origen del inquilino sufre una interrupción, los pasos descritos en este artículo dependen de su recuperación, que primero debe ser iniciada y completada por Microsoft.

Planes de recuperación personalizados por experiencia

Las siguientes secciones ofrecen guías paso a paso para cada experiencia Fabric para ayudarte durante el proceso de recuperación.

Ingeniería de datos

En esta guía se detallan los procedimientos de recuperación de la experiencia de ingeniería de datos. Abarca lakehouses, cuadernos, definiciones de trabajo de Spark, funciones de datos del usuario y API de GraphQL.

Lakehouse

Los almacenes de lago de la región original siguen sin estar disponibles para los clientes. Para recuperar un almacén de lago, los clientes pueden volver a crearlo en el área de trabajo C2.W2. Recomendamos dos enfoques para la recuperación de los lakehouses:

Enfoque 1: Uso de un script personalizado para copiar tablas y archivos Delta del Lakehouse

Los clientes pueden volver a crear los almacenes de lago mediante un script de Scala personalizado.

1. Cree el lakehouse (por ejemplo, LH1) en el área de trabajo recién creada C2.W2.

2. Cree un cuaderno en el área de trabajo C2.W2.

3. Para recuperar las tablas y los archivos del lago original, consulte los datos con rutas de acceso de OneLake como abfss (consulte Conectando a Microsoft OneLake). Puede usar el siguiente ejemplo de código (consulte Introducción a las utilidades de Microsoft Spark) en el cuaderno para obtener las rutas de acceso ABFS de archivos y tablas del Lakehouse original. (Sustituir C1.W1 por el nombre real del espacio de trabajo)

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

4. Use el ejemplo de código siguiente para copiar tablas y archivos en el almacén de lago recién creado.

   1. En el caso de las tablas Delta, debe copiar cada tabla individualmente para recuperarlas en el nuevo lakehouse. En el caso de los archivos de Lakehouse, puede copiar la estructura completa de archivos con todas las carpetas subyacentes en una sola ejecución.

   2. Póngase en contacto con el equipo de soporte técnico para obtener la marca de tiempo de la conmutación por error necesaria en el 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. Una vez ejecutado el script, las tablas aparecen en el nuevo lakehouse.

Enfoque 2: Uso de Explorador de Azure Storage para copiar archivos y tablas

Para recuperar solo archivos o tablas específicos desde el Lakehouse original, use Explorador de Azure Storage. Consulte Integrate OneLake con Explorador de Azure Storage para ver los pasos detallados. Para tamaños de datos grandes, use Enfoque 1.

Recuperación de vistas materializadas de lago de Fabric

Tras la conmutación por error, no puedes acceder a las vistas materializadas del lago desde la región original. El proceso de conmutación por error no replica los programas de actualización ni el historial de ejecución a la región secundaria. Para recuperar estos elementos, completa los siguientes pasos después de recuperar tus datos de Lakehouse:

• Recupera las tablas de Lakehouse utilizando el Enfoque 1 o el Enfoque 2 descritos anteriormente en este artículo. Copie solo las tablas de origen.
• Recupere los cuadernos que contienen sus definiciones de MLV. Para los pasos de recuperación, consulta la sección de Cuadernos .
• Ejecute los cuadernos recuperados para volver a crear los MLV en el nuevo Lakehouse. Para obtener información sobre cómo crear MLV, consulte Creación de una vista materializada de Lago. Si copiaste MLVs en el paso anterior, ejecuta CREATE OR REPLACE cuando los recrees.
• Recrea manualmente los horarios de actualización de MLV en el nuevo espacio de trabajo. No puedes recuperar el historial de calendarios ni métricas de ejecución.
• Si los MLV alimentan los informes o modelos semánticos, compruebe y actualice las referencias del Lakehouse ID y del identificador del conjunto de datos según sea necesario. Vuelva a conectar los informes al modelo semántico actualizado y valide la actualización de los datos.

Notebook

Los cuadernos de la región primaria siguen sin estar disponibles para los clientes, y el código en los cuadernos no se replica en la región secundaria. Para recuperar código de cuaderno en la nueva región, utiliza uno de los siguientes métodos.

Enfoque 1: Redundancia administrada por el usuario con integración de Git (en versión preliminar pública)

Utiliza la integración de Fabric Git para sincronizar tu portátil con tu repositorio de Azure DevOps (ADO). Después de que el servicio cambie a otra región, usa el repositorio para reconstruir el cuaderno en el nuevo espacio de trabajo que has creado.

1. Configure la integración de Git para su área de trabajo y seleccione Conectar y sincronizar con el repositorio de ADO.

   

   En la imagen siguiente se muestra el cuaderno sincronizado.

   

2. Recupere el cuaderno del repositorio de ADO.

   1. En el área de trabajo recién creada, vuelva a conectarse al repositorio de ADO de Azure.

      

   2. Seleccione el botón Control de código fuente . Después, seleccione la rama correspondiente del repositorio. Luego, seleccione Actualizar todo. Aparece el bloc de notas original.

      

      

   3. Si el cuaderno original tiene una casa de lago por defecto, consulta la sección de casa del lago para recuperarla y luego conecta la casa recién recuperada con la libreta recuperada.

      

   4. La integración de Git no admite la sincronización de archivos, carpetas ni instantáneas de cuadernos en el explorador de recursos del cuaderno.

      1. Si el cuaderno original tiene archivos en el explorador de recursos del cuaderno:

         1. Guarda archivos o carpetas en un disco local o en otra ubicación.

         2. Vuelva a cargar el archivo desde el disco local o las unidades en la nube en el cuaderno recuperado.

      2. Si el cuaderno original tiene una instantánea de cuaderno, guárdela también en su propio sistema de control de versiones o en el disco local.

         

         

Para más información sobre la integración de Git, vea Introducción a la integración de Git.

Enfoque 2: Enfoque manual para realizar copias de seguridad del contenido de código

Si no adoptas el enfoque de integración con Git, guarda la última versión de tu código, archivos en el explorador de recursos y la instantánea del cuaderno en un sistema de control de versiones como Git. Recuperar manualmente el contenido del cuaderno tras un desastre:

1. Usa la función Importar cuaderno para importar el código del cuaderno que quieras recuperar.

   

2. Después de la importación, vaya al área de trabajo deseada (por ejemplo, "C2.W2") para acceder a ella.

3. Si el cuaderno original tiene un lakehouse predeterminado, consulte la sección Lakehouse. Después, conecte el lakehouse recién recuperado (que tiene el mismo contenido que el lakehouse predeterminado original) al notebook recién recuperado.

4. Si el cuaderno original tiene archivos o carpetas en el explorador de recursos, vuelva a cargar los archivos o carpetas guardados en el sistema de control de versiones del usuario.

Definición de trabajo de Spark

Las definiciones de trabajos Spark (SJD) de la región primaria siguen sin estar disponibles, y OneLake replica el archivo principal de definición y el archivo de referencia en el cuaderno a la región secundaria. Si quieres recuperar el SJD en la nueva región, sigue los pasos manuales descritos en esta sección. No se recuperan las etapas históricas del SJD.

Para recuperar los elementos SJD, copie el código de la región original mediante Explorador de Azure Storage y vuelva a conectar manualmente las referencias de Lakehouse después del desastre.

1. Crea un nuevo elemento SJD (por ejemplo, SJD1) en el nuevo espacio de trabajo C2. W2, con los mismos ajustes y configuraciones que el elemento SJD original (por ejemplo, lenguaje, entorno, etc.).

2. Utiliza Explorador de Azure Storage para copiar Libs, Mains e instantáneas del elemento SJD original al nuevo elemento SJD.

   

3. El contenido del código aparece en el SJD recién creado. Necesitas añadir manualmente la referencia recién recuperada de Lakehouse al trabajo (consulta los pasos de recuperación de Lakehouse). Los usuarios deben volver a introducir manualmente los argumentos originales de la línea de comandos.

   

Ahora puede ejecutar o programar su SJD recién recuperada.

Para obtener más información sobre Explorador de Azure Storage, consulte Integrate OneLake con Explorador de Azure Storage.

Funciones de datos de usuario

Para recuperar tus funciones de datos de usuario en una región saludable, utiliza uno de los siguientes métodos.

Enfoque 1: Con integración de Git (recomendado)

El mecanismo de recuperación preferido es la integración Fabric Git. Al sincronizar los proyectos de funciones de datos de usuario con un repositorio de Azure DevOps o GitHub, puedes reconstruirlos rápidamente en un nuevo espacio de trabajo tras el failover.

Prepárate antes de un desastre

1. Configura la integración de Fabric Git para el espacio de trabajo que alberga la función de datos del usuario.
2. Conecta el espacio de trabajo a un repositorio de Azure DevOps o GitHub.
3. Compromete todas las funciones de datos del usuario en el repositorio y sincroniza los cambios regularmente.
4. Guarda los ajustes específicos del entorno por separado en bibliotecas variables si es necesario.

Pasos de la recuperación

Tras un desastre regional:

1. Crear una nueva capacidad de Fabric en una zona sana, como C2.
2. Crea un nuevo espacio de trabajo, como W2, en la nueva capacidad.
3. Conecta el espacio de trabajo al mismo repositorio de Azure DevOps o GitHub.
4. Abra Control de código fuente y sincronice el contenido del repositorio con el área de trabajo.
5. Recrea o recupera todos los recursos dependientes de Fabric, como lakehouses, bases de datos SQL en Fabric, almacenes y Eventos empresariales.
6. Redistribuye las funciones de datos de usuario.
7. Valida la ejecución de funciones y la conectividad de dependencias.
8. Actualice las aplicaciones dependientes, las canalizaciones de datos u otros componentes integrados para que hagan referencia a las funciones recuperadas.
9. Valida completamente de principio a fin todos tus escenarios.

Consideraciones importantes

• La integración con Git solo recupera el código fuente y los activos del proyecto.
• No se han recuperado los registros históricos de ejecuciones.
• Los sistemas posteriores pueden requerir reasignación de endpoints.

Para más información, consulte Control de código fuente e implementación de las funciones de datos de usuario.

Enfoque 2: Recuperación manual

Si la integración con Git no estaba configurada antes del desastre, puedes reconstruir manualmente las funciones de datos del usuario a partir de copias de seguridad del código fuente.

Prepárate antes de un desastre

Completar regularmente las siguientes tareas y almacenar los elementos en un repositorio externo de control de versiones o en una ubicación de copia de seguridad:

• Exporta el código fuente de la función a un repositorio de GitHub.
• Documenta y conserva la información de dependencias.
• Configuración del entorno del documento.

Pasos de la recuperación

Tras un desastre regional:

1. Crear una nueva capacidad de Fabric en una zona sana, como C2.
2. Crea un nuevo espacio de trabajo, como W2.
3. Recuperar todos los recursos necesarios para la función, incluyendo casas de lago, bases de datos SQL en Fabric, almacenes, casas de eventos y servicios externos.
4. Crea un nuevo proyecto de función de datos de usuario.
5. Importa o recrea el código fuente de la función.
6. Reaplica los ajustes de configuración en tiempo de ejecución.
7. Reinstala todas las dependencias de funciones.
8. Vuelve a implementar la función.
9. Reconfigura la autenticación y la autorización.
10. Recrea los editores o consumidores de eventos de negocio, si se utilizan.
11. Realiza pruebas de validación de extremo a extremo para tus escenarios e integraciones.

GraphQL

Los elementos de GraphQL de la región primaria no están disponibles después de un desastre regional y las definiciones y configuraciones de GraphQL no se replican en la región secundaria. Para recuperar GraphQL en una nueva región, use uno de los métodos siguientes.

Enfoque 1: Redundancia gestionada por el usuario con integración de Git

La mejor manera de facilitar y agilizar este proceso es usar Fabric integración de Git y, a continuación, sincronizar GraphQL con el repositorio de ADO. Una vez que el servicio conmuta por error a otra región, puede usar el repositorio para recompilar GraphQL en el nuevo área de trabajo que creó.

1. Cree una nueva área de trabajo en la capacidad y la región de destino.

2. Recupere todos los orígenes de datos dependientes, como Lakehouse, Warehouse o SQL Database, siguiendo sus respectivos pasos de recuperación.

3. Actualizar la definición de GraphQL para apuntar a los recursos recién recuperados modificando referencias específicas del entorno como IDs de espacios de trabajo de origen, IDs de elementos fuente y detalles de conexión. Este paso garantiza un enlace correcto en el momento de la implementación.

4. Redistribuye los elementos de GraphQL desde el repositorio Git en el nuevo espacio de trabajo. Este paso vuelve a crear la estructura y la configuración de la API mediante las definiciones actualizadas.

5. Reaplica la configuración de los elementos, incluyendo roles, controles de acceso y configuración de autenticación.

6. Vuelva a aplicar las referencias de punto de conexión mediante la actualización de las aplicaciones o integraciones para usar el punto de conexión de GraphQL recién creado.

7. Actualice las canalizaciones de implementación existentes que apuntaban al área de trabajo anterior para hacer referencia al área de trabajo recién creada.

8. Valide la funcionalidad de un extremo a otro de la API.

Enfoque 2: Enfoque manual

Si no adopta el enfoque de integración de Git, puede usar el siguiente enfoque manual para recuperar GraphQL.

1. Cree una nueva área de trabajo en la capacidad y la región de destino.

2. Recupere todos los orígenes de datos dependientes, como Lakehouse, Warehouse o bases de datos SQL.

3. Vuelva a crear graphQL API manualmente en el nuevo área de trabajo, incluidas las definiciones de esquema, las conexiones del origen de datos y las relaciones.

4. Reaplica la configuración de los elementos, incluyendo roles, controles de acceso y configuración de autenticación.

5. Vuelva a aplicar las referencias de punto de conexión mediante la actualización de las aplicaciones o integraciones para usar el punto de conexión de GraphQL recién creado.

6. Actualice las canalizaciones de implementación existentes que apuntaban al área de trabajo anterior para hacer referencia al área de trabajo recién creada.

7. Valide la funcionalidad de un extremo a otro de la API.

Consideraciones importantes

1. GraphQL se basa en dependencias externas (como Lakehouse, Warehouse y SQL), que debe recuperar antes de la implementación de GraphQL.

2. Las definiciones de API de GraphQL incluyen referencias específicas del entorno (como sourceWorkspaceId y sourceItemId). Al recuperarse en una nueva región, estas referencias podrían no ser válidas. Actualícelos para que apunten a los recursos recién aprovisionados.

3. No se garantiza la reenlazación automática de orígenes de datos en escenarios de recuperación ante desastres, especialmente cuando se usan credenciales guardadas o conexiones entre áreas de trabajo.

4. La configuración de otros elementos, como la monitorización, la autorización, RBAC, la introspección, entre otros, no se conserva tras la conmutación por error. Debe volver a establecer esta configuración en la nueva región.

References

• Introducción a la integración de Git de Fabric: Microsoft Fabric | Microsoft Learn

• Control de código fuente y canalizaciones de implementación en la API para GraphQL - Microsoft Fabric | Microsoft Learn 

App

El sistema no replica las aplicaciones Fabric, incluyendo su código, configuración y metadatos, a regiones secundarias. Si la región principal falla, la aplicación sigue sin estar disponible. Para recuperar, almacena el código fuente de la app fuera del sistema en GitHub, Azure DevOps u otro sistema de control de versiones. Recupera los datos de la app por separado siguiendo las directrices de recuperación ante desastres para cada almacén de datos Fabric subyacente.

Enfoque manual

Puedes recuperar manualmente una aplicación Fabric tras un desastre regional usando el código fuente de la aplicación y la CLI de Rayfin. 

Requisitos previos 

Antes de que ocurra un desastre:

• Guarda el código fuente de Fabric App en GitHub, Azure DevOps u otro repositorio de control de versiones. 

• Documenta el proceso de recuperación.  

Pasos de recuperación 

1. Cree una nueva área de trabajo en la capacidad y la región de destino. 

2. Recuperar recursos dependientes antes de volver a desplegar la aplicación.  

3. Recupera el código fuente más reciente de Fabric App desde tu repositorio de control de versiones o copia de seguridad local. 

4. Desde el directorio fuente de la aplicación, despliega la aplicación Fabric en el espacio de trabajo de recuperación usando la CLI de Rayfin. Ejecute rayfin up --workspace <new workspace>. 

5. Recupera el elemento hijo de la app (base de datos SQL en Fabric) siguiendo sus respectivos procedimientos de recuperación.  

6. Reaplica la configuración a nivel de objeto, incluyendo roles y controles de acceso, según sea necesario.  

7. Valida la funcionalidad de la aplicación y asegúrate de que los usuarios tengan los permisos adecuados.  

Importante 

• Mantén el código fuente de Fabric App fuera de la región Fabric para permitir la recuperación.  

• Los datos de la aplicación en la base de datos no se recuperan como parte del proceso de despliegue de Fabric App y deben restaurarse por separado.  Puedes recuperar manualmente una aplicación Fabric tras un desastre regional usando el código fuente de la aplicación y la CLI de Rayfin. 

Azure Databricks Storage

Azure Databricks Storage almacena datos en OneLake. Para proteger tus datos frente a una caída regional, activa la configuración de recuperación ante desastres en la capacidad de Fabric que contiene el elemento de almacenamiento de Azure Databricks. Cuando activas esta configuración, OneLake replica de forma asíncrona los datos a la región emparejada de Azure.

Si OneLake inicia un conmutador por error regional, las aplicaciones pueden seguir accediendo a los datos replicados a través del endpoint global de OneLake una vez finalizada la conmutación por error. El acceso continuo a través de las APIs públicas de OneLake no requiere crear otro elemento de Azure Databricks Storage ni copiar los datos a otro espacio de trabajo.

Revisa OneLake Disaster Recovery and Data Protection para conocer el comportamiento, consideraciones y limitaciones aplicables.

Para la planificación de recuperación ante desastres específica de Azure Databricks, consulte Disaster recovery - Azure Databricks.

Ciencia de datos

En esta guía se detallan los procedimientos de recuperación de la experiencia de ciencia de datos. Se describen modelos y experimentos de ML.

Modelo y experimento de aprendizaje automático

Los elementos de Ciencia de Datos de la región primaria permanecen inaccesibles para los clientes, y el contenido y los metadatos en los modelos y experimentos de ML no se replican en la región secundaria. Para recuperarlos completamente en la nueva región, guarde el contenido del código en un sistema de control de versiones (como Git) y vuelva a ejecutar manualmente el contenido del código después del desastre.

1. Recupere el cuaderno. Consulte los pasos de recuperación de portátiles.

2. La configuración, las métricas de ejecuciones históricas y los metadatos no se replican a la región emparejada. Necesitas volver a ejecutar cada versión de tu código de ciencia de datos para recuperar completamente los modelos y experimentos de ML tras el desastre.

Almacén de Datos

Esta guía te guía por los procedimientos de recuperación para la carga de trabajo Fabric Data Warehouse. Cubre los artículos del almacén.

Almacén

No puedes acceder a los almacenes de la región original. Para recuperar los almacenes, siga estos dos pasos.

1. Crea una nueva casa temporal en el espacio de trabajo C2. W2 para los datos que copies del almacén original.

2. Llena las tablas Delta del almacén utilizando el Explorador del almacén y las capacidades de T-SQL (ver Tablas en Fabric Data Warehouse).

Ingesta de datos a través del Lakehouse y del código T-SQL

En el área de trabajo C2.W2 recién creada:

1. Cree un almacén de lago provisional "LH2" en C2.W2.

2. Siga los pasos de recuperación del Lakehouse para recuperar las tablas Delta en el lakehouse provisional del almacén original.

3. Cree un almacén "WH2" en C2.W2.

4. Conecte el almacén de lago provisional en el explorador de almacenamiento.

5. Dependiendo de cómo despliegues las definiciones de tablas antes de importar datos, el T-SQL real que se usa para las importaciones puede variar. Para recuperar tablas de Warehouse de lakehouses, puedes usar el enfoque INSERT INTO, SELECT INTO o CREATE TABLE AS SELECT. En el siguiente ejemplo, usamos INSERT INTO. Si usas el siguiente código, sustituye los ejemplos por nombres reales de tablas y columnas.

   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. Cambia la cadena de conexión en las aplicaciones que usan tu almacén de Fabric.

Base de datos reflejada

Los clientes no pueden acceder a bases de datos espejadas desde la región primaria, y la configuración no se replica a la región secundaria. Para recuperar una base de datos espejada tras un fallo regional, necesitas recrearla en otro espacio de trabajo de otra región.

Fábrica de Datos

Los clientes no pueden acceder a los elementos Data Factory de la región principal, y los ajustes y configuraciones en pipelines o en los elementos de Dataflow Gen2 no se replican en la región secundaria. Para recuperar estos elementos tras un fallo regional, necesitas recrear tus elementos de Integración de Datos en otro espacio de trabajo de otra región. En las secciones siguientes se describen los detalles.

Flujos de datos Gen2

Para recuperar un elemento de Dataflow Gen2 en la nueva región, exporta un .pqt archivo a un sistema de control de versiones como Git, y luego recupera manualmente el contenido de Dataflow Gen2 tras el desastre.

1. Desde tu elemento de Dataflow Gen2, en la pestaña de inicio del editor de Power Query, selecciona Exportar plantilla.

   

2. En el cuadro de diálogo Exportar plantilla , introduce un nombre (obligatorio) y una descripción (opcional) para esta plantilla. Cuando termine, seleccione Aceptar.

   

3. Después del desastre, cree un elemento de Dataflow Gen2 en el nuevo área de trabajo "C2.W2".

4. En el panel de vista actual del editor de Power Query, seleccione Importar en una plantilla de Power Query.

   

5. En el cuadro de Abierto, navega a tu carpeta de descargas predeterminadas y selecciona el .pqt archivo que guardaste en los pasos anteriores. A continuación, seleccione Abrir.

6. Después, la plantilla se importa al nuevo elemento Flujo de datos Gen2.

La función de Guardar Como para Dataflows no está soportada en caso de recuperación ante desastres.

Tuberías

Los clientes no pueden acceder a canalizaciones en caso de desastre regional y las configuraciones no se replican en la región emparejada. Crea tus canalizaciones críticas en múltiples espacios de trabajo distribuidos en distintas regiones.

Copiar trabajo

Los usuarios de CopyJob deben adoptar medidas proactivas para protegerse frente a un desastre regional. El siguiente enfoque garantiza que, después de un desastre regional, los CopyJobs de un usuario permanecen disponibles.

Redundancia administrada por el usuario con la integración de Git (en versión preliminar pública)

La mejor manera de hacer este proceso fácil y rápido es usar la integración de Fabric Git y luego sincronizar tu CopyJob con tu repositorio de Azure DevOps. Una vez que el servicio se traslade a otra región, puede usar el repositorio para recompilar el CopyJob en el nuevo área de trabajo que creó.

1. Configura la integración de Git de tu espacio de trabajo y selecciona conectar y sincronizar con el repositorio de Azure DevOps.

   

   En la siguiente imagen se muestra el CopyJob sincronizado.

   

2. Recupera el CopyJob del repositorio de Azure DevOps.

   1. En el espacio de trabajo recién creado, conéctate y sincronicía de nuevo con tu repositorio de Azure DevOps. Todos los elementos de Fabric en este repositorio se descargan automáticamente en tu nuevo espacio de trabajo.

      

   2. Si el copyJob original usa una instancia de Lakehouse, los usuarios pueden hacer referencia a la sección Lakehouse para recuperar Lakehouse y, a continuación, conectar el copyJob recién recuperado a la instancia de Lakehouse recién recuperada.

Para más información sobre la integración de Git, vea Introducción a la integración de Git.

Trabajo de Apache Airflow

Debes tomar medidas proactivas para proteger los empleos de Apache Airflow en Fabric ante un desastre regional.

Gestiona la redundancia usando la integración de Fabric Git. Primero, sincroniza tu tarea de Airflow con tu repositorio de ADO. Si el servicio realiza una conmutación por error a otra región, puedes usar el repositorio para reconstruir el trabajo de Airflow en el nuevo espacio de trabajo que creaste.

Sigue estos pasos para lograr este objetivo:

1. Configura la integración con Git de tu espacio de trabajo y selecciona Conectar y sincronízalo con el repositorio ADO.

2. Después de eso, ves tu trabajo Airflow sincronizado con tu repositorio ADO.

3. Si necesita recuperar el trabajo de Flujo de aire desde el repositorio de ADO, cree una nueva área de trabajo, conéctese y sincronice con el repositorio de ADO de Azure. Todos los elementos de Fabric, incluido Airflow, en este repositorio se descargan automáticamente en tu nuevo espacio de trabajo.

Inteligencia en tiempo real

En esta guía se detallan los procedimientos de recuperación de la experiencia de inteligencia en tiempo real. Cubre bases de datos KQL, conjuntos de consultas y elementos de flujo de eventos.

Activator

Los elementos de Activator de la región primaria siguen sin estar a disposición de los clientes, y las definiciones de activación de Activator no se replican en la región secundaria. Los usuarios activadores deben realizar pasos proactivos para prepararse para la recuperación ante desastres regional.

Para asegurarse de que puede recuperar elementos activadores en caso de desastre regional, configure Fabric integración de Git para realizar copias de seguridad de definiciones de desencadenadores y restaurarlos en un área de trabajo de otra región.

1. Configure la integración de Git de Fabric para el área de trabajo que contiene su elemento de Activator y sincronice las definiciones de los desencadenadores con su repositorio de Git.
2. Mantén las definiciones de activación de Activator registradas y sincronizadas periódicamente.
3. Durante la recuperación, cree un área de trabajo en la región de destino (C2). W2), conéctelo al mismo repositorio y sincronice para restaurar las definiciones del desencadenador.
4. Vuelva a configurar y validar todos los orígenes de datos y dependencias de Activator en el nuevo área de trabajo.

Para más información sobre la integración de Git, vea Introducción a la integración de Git.

Modelo de Grafo/Conjunto de consultas

Los clientes no pueden acceder a los elementos del modelo Graph y el conjunto de consultas de Graph desde la región primaria, y Fabric no replica estos elementos a la región secundaria. Para recuperarse, cree o use una capacidad en una región diferente y vuelva a crear el modelo de Graph y los elementos del conjunto de consultas de Graph en esa región.

1. Cree o use una capacidad de Fabric existente en otra región que no se vea afectada por el desastre.

2. Cree una nueva área de trabajo o use un área de trabajo existente en esa capacidad.

3. Recrea el elemento del modelo Graph en el espacio de trabajo secundario (referenciado en el paso 2). Reconfigura la definición del modelo, incluyendo nodos, aristas y otros, para que coincida con el modelo original de Graph.

4. Si el lakehouse original se encuentra en la región con errores, recupérelo primero siguiendo la sección Lakehouse.

5. Conecta una casa de lago como fuente de datos OneLake para el nuevo elemento del modelo Graph. Use el lakehouse recuperado si se encontraba en la región fallida, o reconéctese al lakehouse existente si permanece disponible.

6. Reconfigura cualquier horario de carga de datos o conexión para el modelo Graph en el nuevo espacio de trabajo.

7. Recrea el elemento del conjunto de consultas Graph en el espacio de trabajo secundario. Vuelve a introducir manualmente las consultas y cualquier configuración guardada del conjunto original de consultas del Graph.

Base de datos KQL / Queryset

Los usuarios de bases de datos y consultas KQL deben tomar medidas proactivas para protegerse frente a un desastre regional. El siguiente enfoque garantiza que, en caso de un desastre regional, los datos en tus bases de datos y conjuntos de consultas KQL permanezcan seguros y accesibles.

Siga estos pasos para garantizar una solución de recuperación ante desastres eficaz para bases de datos y conjuntos de consultas de KQL.

1. Configura bases de datos KQL independientes: Configura dos o más bases de datos KQL independientes y conjuntos de consultas en capacidades dedicadas de Fabric. Configura estas bases de datos en dos regiones de Azure diferentes (preferiblemente regiones emparejadas con Azure) para maximizar la resiliencia.

2. Replica las actividades de gestión: Imita cualquier acción de gestión que realices en una base de datos KQL en la otra. Este enfoque mantiene ambas bases de datos sincronizadas. Las actividades clave a replicar incluyen:

   • Tablas: Asegúrate de que las estructuras de las tablas y las definiciones de esquemas sean consistentes entre las bases de datos.

   • Mapeo: Duplique cualquier mapeo requerido. Asegúrate de que las fuentes y destinos de los datos estén correctamente alineados.

   • Políticas: Asegúrese de que ambas bases de datos tengan políticas similares de retención, acceso y otras políticas relevantes.

3. Gestionar la autenticación y autorización: Establecer los permisos necesarios para cada réplica. Asegúrate de establecer los niveles adecuados de autorización, otorgando acceso al personal necesario manteniendo los estándares de seguridad.

4. Ingesta de datos paralelos: para mantener los datos coherentes y listos en varias regiones, cargue el mismo conjunto de datos en cada base de datos KQL al mismo tiempo que la ingiere.

Flujo de eventos

Un flujo de eventos es un lugar centralizado en la plataforma de Fabric para capturar, transformar y enrutar eventos en tiempo real a varios destinos (por ejemplo, lakehouses, bases de datos KQL o conjuntos de consultas) con una experiencia sin necesidad de programación. Mientras los destinos soporten la recuperación ante desastres, los eventstreams no pierden datos. Por lo tanto, utiliza las capacidades de recuperación ante desastres de esos sistemas de destino para garantizar la disponibilidad de los datos.

También puedes lograr redundancia geográfica implementando cargas de trabajo idénticas de secuencias de eventos en varias regiones de Azure como parte de una estrategia multisitio activo-activo. Con un enfoque activo/activo multisitio, puedes acceder a tu carga de trabajo en cualquiera de las regiones donde se ha implementado. Este enfoque es el más complejo y costoso para la recuperación ante desastres, pero puede reducir el tiempo de recuperación a casi cero en la mayoría de las situaciones. Para ser totalmente geo-redundante:

1. Crea réplicas de tus fuentes de datos en diferentes regiones.

2. Crea elementos de flujo de eventos en regiones correspondientes.

3. Conectar estos nuevos elementos a los orígenes de datos idénticos.

4. Agregar destinos idénticos para cada secuencia de eventos en regiones diferentes.

Eventos empresariales, eventos de Fabric y eventos de Azure

Aunque los eventos empresariales, eventos Fabric y eventos Azure comparten la misma infraestructura Real-Time hub en Microsoft Fabric, tienen orígenes, comportamientos y necesidades de recuperación distintos. Comprende estas diferencias antes de planificar la recuperación ante desastres:

• Los Fabric Events son suscripciones a eventos que reaccionan a la actividad producida por los propios recursos de Fabric. Estos eventos incluyen cambios del ciclo de vida de los elementos del espacio de trabajo (como la creación, actualización o eliminación de lakehouses, notebooks o almacenes de datos), ejecuciones de trabajos (como ejecuciones de canalizaciones o de notebooks) y operaciones de archivos y carpetas en OneLake. Estas suscripciones son de tipo push y efímeras. Las suscripciones no se replican a la región secundaria.

• Eventos de Azure son suscripciones a eventos de la actividad generada por las cuentas de Azure Blob Storage. Estos recursos Azure existen independientemente de cualquier capacidad o región de Fabric. Aunque el recurso Azure Blob Storage en sí podría permanecer disponible durante una caída regional Fabric, las suscripciones configuradas en Real-Time hub no se replican en la región secundaria y deben recrearse.

• Los eventos empresariales son una funcionalidad distinta en Fabric Real-Time Intelligence que permite a los equipos definir, publicar y actuar en señales empresariales significativas. Los eventos de negocio se generan dentro de Fabric mediante Activator, cuadernos de Spark o Funciones de datos de usuario y, a continuación, se publican en Real-Time hub, donde los consumidores posteriores, como Activator, Eventhouse o Power Automate, pueden reaccionar a ellos. Los esquemas de eventos se rigen de forma centralizada a través del Registro de esquemas. Eventhouse almacena automáticamente todos los eventos empresariales publicados, por lo que su recuperación afecta directamente a la disponibilidad del historial de eventos empresariales. Ninguna de las configuraciones de publicador o consumidor, definiciones de esquema o suscripciones se replican en la región secundaria.

Siga estos pasos para restaurar eventos empresariales, eventos de Fabric y eventos de Azure en la nueva área de trabajo de la región de recuperación.

Para eventos empresariales:

1. Vuelva a crear el evento empresarial usado por editores y consumidores siguiendo el artículo Creación de eventos empresariales en Fabric Real-Time Hub. Durante la creación del evento empresarial, se crea el recurso Conjunto de esquemas de eventos. El recurso Eventhouse es opcional en función del escenario. Si has hecho una copia de seguridad de tu conjunto de esquemas de eventos con integración en Git, restaura primero siguiendo la sección de conjunto de esquemas de eventos, y luego apunta el evento empresarial al conjunto de esquemas restaurado.

2. Vuelva a crear los elementos de publicador que generen eventos de negocio, como cuadernos de notas de Spark o Funciones de datos de usuario, en el nuevo área de trabajo siguiendo los artículos sobre publicadores: Usar la Función de datos de usuario como publicador de eventos de negocio, Usar Activator como publicador de eventos de negocio, Usar Notebook como publicador de eventos de negocio y Usar Eventstream como publicador de eventos de negocio.

3. Vuelva a crear las suscripciones de consumidores en Real-Time hub (por ejemplo, reglas de Activator, desencadenadores de cuadernos o flujos de Power Automate) que originalmente reaccionaban a eventos empresariales en la región afectada siguiendo los artículos Integración de Eventhouse y el panel en tiempo real con eventos empresariales y Consumir eventos empresariales desde Activator.

4. Valide que los eventos fluyan de un extremo a otro comprobando que las suscripciones están activas y que los datos llegan a los destinos esperados en la región de recuperación.

Para eventos de Fabric:

1. Recrea las suscripciones en Real-Time hub que apunten a los elementos del espacio de trabajo, trabajos o rutas de OneLake que restauraste en la región de recuperación siguiendo las instrucciones del artículo Explorar eventos de Fabric en Fabric Real-Time hub.

2. Valide que los eventos fluyan de un extremo a otro comprobando que las suscripciones están activas y que los datos llegan a los destinos esperados en la región de recuperación.

Para eventos de Azure:

1. Las cuentas de Azure Blob Storage no se ven afectadas por una caída regional de Fabric. Vuelva a crear las suscripciones de eventos en Real-Time hub para que apunten a las mismas cuentas de Azure Blob Storage siguiendo el artículo Configurar alertas sobre eventos de Azure Blob Storage en Real-Time hub.

2. Valide que los eventos fluyan de un extremo a otro comprobando que las suscripciones están activas y que los datos llegan a los destinos esperados en la región de recuperación.

Conjunto de esquemas de eventos

Un conjunto de esquema de eventos es el elemento Fabric que contiene las definiciones de tipo de evento y esquema en Real-Time Intelligence. Otras capacidades se construyen sobre ella: los editores escriben eventos que se ajustan a sus esquemas, y los consumidores leen según las mismas definiciones.

Los conjuntos de esquemas de eventos de la región principal permanecen inaccesibles para los clientes y no se replican en la región secundaria. Sin embargo, dado que un conjunto de esquema de eventos es una definición duradera y autorada en lugar de una suscripción efímera, puedes hacer una copia de seguridad previa y restaurarlo en lugar de reescribirlo manualmente.

Recomendado: hacer una copia de seguridad con integración de Fabric Git

Para recuperar un esquema de eventos establecido tras un desastre regional, configura la integración de Fabric Git antes de que ocurra un desastre y sincroniza el espacio de trabajo que contiene tus conjuntos de esquemas de eventos con tu repositorio Git.

1. Configura la integración de Fabric Git para el espacio de trabajo que contiene tu conjunto de esquemas de eventos y sincronízalo con tu repositorio Git.

2. Mantén el esquema de eventos confirmado y sincronizado regularmente, especialmente después de añadir tipos de eventos o publicar nuevas versiones de esquema.

3. Durante la recuperación, crea un nuevo espacio de trabajo en la región objetivo (C2. W2), conectarlo al mismo repositorio y sincronizarlo para restaurar el esquema de eventos establecido. Como el nuevo espacio de trabajo está vacío, Git Sync lleva el contenido del repositorio al espacio de trabajo.

4. Recrea cualquier editor y consumidor que use el conjunto de esquemas, siguiendo las directrices para esos tipos de artículos.

5. Valida que los editores puedan publicar utilizando los tipos de eventos restaurados y que los consumidores reciban los eventos según lo previsto.

La definición sincronizada incluye los tipos de eventos en el conjunto de esquemas, los esquemas y las versiones de los esquemas. No incluye registros de editores, suscripciones de consumidores ni historial de eventos. Recupéralos por separado, siguiendo las directrices para los tipos de elemento que usan el conjunto de esquemas.

Alternativa: recrear manualmente

Si no configuraste la integración con Git antes del desastre, recrea el conjunto de esquemas de eventos en la región de recuperación siguiendo Crear y gestionar conjuntos de esquemas de eventos, luego añade los tipos de eventos y esquemas que contenía el conjunto original siguiendo Crear y gestionar esquemas de eventos en conjuntos de esquemas.

Mapa

Los elementos de mapa de la región primaria siguen sin estar disponibles para los clientes y los elementos de mapa no se replican en la región secundaria.

Si quiere recuperar un elemento de mapa cuando se produzca un desastre, configure la integración de Fabric Git y sincronice el elemento de mapa con el repositorio de Git.

Durante la recuperación, después de configurar la nueva región o capacidad en Fabric, puede usar el repositorio para reconstruir el elemento de mapa en la nueva área de trabajo que ha creado. Dado que la nueva área de trabajo está vacía, Git sync obtiene el contenido del repositorio en el área de trabajo vacía. Este paso reactiva el elemento de mapa.

Ontología

Los usuarios de ontología deben realizar pasos proactivos para prepararse para la recuperación ante desastres regional. El enfoque descrito a continuación garantiza que, después de un desastre regional, la ontología permanece recuperable y se puede restaurar rápidamente.

La manera más sencilla y rápida de habilitar la recuperación es usar Fabric integración de Git y sincronizar la ontología con un repositorio de Azure DevOps (ADO). Si el servicio conmuta por error a otra región, puede usar este repositorio para volver a generar la ontología en un área de trabajo recién creada.

Los elementos de ontología de la región primaria no están disponibles para los clientes después de un desastre regional y los elementos de ontología no se replican en la región secundaria.

Para recuperar un elemento de ontología durante un desastre, configure la integración de Fabric Git y sincronice el elemento de ontología con su repositorio de ADO con antelación.

Durante la recuperación, una vez configurada la nueva región y la capacidad en Fabric, puede usar el repositorio para volver a generar el elemento de ontología en un nuevo espacio de trabajo. Dado que la nueva área de trabajo está vacía, Git sync extrae el contenido del repositorio en el área de trabajo, restaurando eficazmente el elemento Ontology.

Agente de ontología

Los usuarios de Ontology Agent deben tomar medidas proactivas para prepararse para la recuperación regional ante desastres. El enfoque descrito en esta sección garantiza que, tras un desastre regional, la experiencia de tu Ontology Agent pueda restaurarse en un espacio de trabajo recién creado.

El Agente de Ontología depende del elemento de la Ontología y de cualquier fuente de datos que esté conectada a la Ontología, como los lakehouses. Los clientes no pueden acceder a las sesiones del Agente de Ontología en la región principal tras un desastre regional, y las sesiones del Agente de Ontología no se replican en la región secundaria. No se pueden reanudar las sesiones de chat activas, las acciones en curso y el historial de conversaciones de la región afectada.

Para recuperar la experiencia del Agente de Ontología durante un desastre, configura la integración de Fabric Git y sincroniza el elemento de Ontología con tu repositorio de Azure DevOps (ADO) con antelación.

Durante la recuperación, una vez que la nueva región y capacidad en Fabric estén establecidas, completa los siguientes pasos:

1. Crea un nuevo espacio de trabajo en la nueva capacidad.
2. Conecta el nuevo espacio de trabajo al mismo repositorio ADO que contiene el elemento Ontología.
3. Usa Git sync para restaurar el elemento Ontology en el nuevo espacio de trabajo.
4. Recupera cualquier elemento de datos dependiente, como los lakehouses, siguiendo las indicaciones para esos tipos de elementos.
5. Confirma que los datos recuperados están disponibles en la región emparejada. Para los datos respaldados por OneLake, suponga que los datos se replican en la región emparejada, pero no asuma ningún orden de los datos replicados durante la recuperación.
6. Conecta el elemento de Ontología recién recuperado con las fuentes de datos recuperadas.
7. Inicia una nueva sesión con el Agente de Ontología y valida que el agente puede conectarse al elemento recuperado de la Ontología y a las fuentes de datos.

Planning

Este artículo describe los procedimientos de recuperación para la experiencia de planificación en IQ. Detalla los pasos necesarios para restaurar componentes clave, incluyendo hojas de planificación, hojas PowerTable, hojas de inteligencia, InfoBridge y activos de datos relacionados.

Integración de Git para restaurar elementos del plan

El enfoque preferido es sincronizar todos los elementos de plan con un repositorio de Azure DevOps (ADO) o GitHub mediante la integración de Git de Fabric. Después de una conmutación por error, use el repositorio para restaurar los elementos en el nuevo espacio de trabajo.

Antes del desastre (medidas preventivas):

1. En el área de trabajo W1, vaya a Configuración del área de trabajo y configure la integración de Git.

2. Seleccione Conectar y sincronizar con el repositorio de ADO o GitHub.

3. Seleccione los elementos del plan que se van a cargar en el repositorio y seleccione Confirmar.

   

4. Confirme que el estado de Git de los elementos del plan está sincronizado.

5. Establece una disciplina de commits: haz un commit después de cada cambio significativo en la definición de un plan, para que el repositorio refleje siempre el estado más reciente.

Pasos de recuperación:

1. Cree un espacio de trabajo W2 dentro de la capacidad C2 en la región en buen estado.

2. En el área de trabajo W2, vaya a Configuración del área de trabajo y vuelva a conectarse al mismo repositorio de ADO/GitHub.

3. Seleccione Control de código fuente. Seleccione la rama del repositorio correspondiente y seleccione Actualizar todo. Todos los elementos del plan se descargan en W2.

Los siguientes componentes se restauran después de la recuperación:

• Hojas de PowerTable: Configuración de la tabla de origen, configuración de columnas, acceso a filas, propiedades visuales (diseño, formatos, etc.), identificación de filas, configuración de comentarios, dimensiones de variación lenta (SCD), aprobaciones, automatizaciones y formularios.
• Hojas de planificación: Propiedades de hoja (formato, formato condicional, etc.), configuración de comentarios, configuración de reescritura, columnas de entrada de datos, filas de entrada de datos, escenarios y marcadores.
• InfoBridge: Orígenes de InfoBridge, consultas de InfoBridge, pasos de transformación, destinos de reescritura, configuración de reescritura, asignaciones de consultas vinculadas, grupos de consultas, propiedades visuales (blend). Estos elementos no se pueden recuperar: orígenes basados en archivos (CSV, Excel) y hojas de cargas de trabajo cruzadas que usan orígenes basados en archivos.
• Inteligencia: Todos los gráficos y matrices.

Restauración de Fabric SQL para planificación

Los datos introducidos en hojas de planeación, tablas usadas en PowerTable y datos de escritura diferida se almacenan en bases de datos SQL y se deben considerar como parte de la estrategia de recuperación ante desastres. Para recuperar bases de datos SQL, consulte la sección base de datos SQL.

• Metadatos del plan de restauración: cada elemento de plan está asociado a una base de datos de __fabric_plan_sys que almacena metadatos para las características de planeación, incluidos comentarios, escenarios, entradas de datos y configuración de escritura diferida. La base de datos __fabric_plan_sys no se restaura automáticamente y debe recuperarse explícitamente.

• Restaurar bases de datos de writeback: Si su plan utiliza destinos de writeback de SQL, también debe recuperar manualmente las bases de datos asociadas. Los destinos de escritura diferida de SQL configurados no se restauran automáticamente.

• Restaurar tablas usadas en PowerTable: Cualquier tabla creada usando PowerTable se almacena en una base de datos SQL en Fabric. Debe también recuperar estas tablas durante DR.

Agentes de operaciones

Los usuarios del agente de operaciones deben realizar pasos proactivos para prepararse para la recuperación ante desastres regional. Siguiendo el enfoque descrito en esta sección ayuda a garantizar que los agentes se puedan restaurar rápidamente después de una interrupción regional.

Use la integración de Git de Fabric para sincronizar el área de trabajo con un repositorio. Este enfoque le permite reconstruir las configuraciones del agente en una nueva área de trabajo si el servicio conmuta por error a otra región.

Los elementos del agente de operaciones de la región principal no están disponibles ante un desastre regional. Las configuraciones del agente, los modelos de comportamiento y los registros de actividad no se replican en la región secundaria. También se pierden las operaciones en curso, las sesiones de chat activas y los eventos ingeridos previamente en el momento del desastre.

Para prepararse para la recuperación, configure Fabric integración de Git y sincronice los elementos del agente con el repositorio de ADO antes de que se produzca un desastre.

Durante la recuperación, configure la nueva región y la capacidad en Fabric y, a continuación, use el repositorio sincronizado para restaurar las configuraciones del agente en un área de trabajo nueva. La sincronización de Git recupera el contenido almacenado del repositorio al área de trabajo vacía, recreando los elementos de tu agente.

Una vez restauradas las configuraciones, confirme que las bases de datos de Eventhouse (KQL) a las que se hace referencia o los orígenes de datos específicos de la región sean accesibles en la nueva región. Actualice las referencias de punto de conexión en las configuraciones del agente según sea necesario. Por último, reinicie los agentes y haga que los usuarios inicien nuevas sesiones de chat. No se pueden reanudar las conversaciones anteriores.

Databases

Esta guía describe los procedimientos de recuperación para la experiencia de las bases de datos.

SQL database

Para protegerse frente a un error regional, los usuarios de bases de datos SQL pueden tomar medidas proactivas para exportar periódicamente sus datos y usar los datos exportados para volver a crear la base de datos en una nueva área de trabajo cuando sea necesario.

Utiliza la herramienta CLI de SqlPackage que proporciona portabilidad de bases de datos y facilita el despliegue de bases de datos.

1. Use la herramienta SqlPackage para exportar la base de datos a un .bacpac archivo. Consulte Exportación de una base de datos con SqlPackage para obtener más información.
2. Guarda el .bacpac archivo en un lugar seguro que esté en una región diferente a la base de datos. Ejemplos incluyen almacenar el .bacpac archivo en un Lakehouse que esté en otra región, usar una cuenta de Azure Storage geo-redundante, o usar otro medio de almacenamiento seguro que esté en otra región.
3. Si la base de datos SQL y la región no están disponibles, puede usar el .bacpac archivo con SqlPackage para volver a crear la base de datos en un área de trabajo en una nueva región: área de trabajo C2. W2 en la región B, tal como se describe en el escenario anterior. Siga los pasos que se detallan en Importación de una base de datos con SqlPackage para volver a crear la base de datos con el .bacpac archivo.

La base de datos recreada es una base de datos independiente de la base de datos original y refleja el estado de los datos en el momento de la operación de exportación.

Consideraciones de retorno después de una conmutación

La base de datos recreada es una base de datos independiente. Los datos añadidos a la base de datos recreada no se reflejarían en la base de datos original. Si planeas hacer una vuelta a la base de datos original cuando la región de origen esté disponible, debes considerar conciliar manualmente los datos de la base de datos recreada con la base de datos original.

Platform

La plataforma hace referencia a los servicios compartidos y la arquitectura subyacentes que se aplican a todas las cargas de trabajo. Esta sección describe los procedimientos de recuperación para capacidades compartidas de Fabric.

Supervisión del área de trabajo

La monitorización del espacio de trabajo recopila registros sobre la actividad en el espacio donde la habilitas. Después de recuperar tu espacio de trabajo como C2. W2, activa la monitorización del espacio de trabajo en W2. Empieza a recopilar datos de monitorización para el espacio de trabajo recuperado.

Los datos de monitorización del espacio de trabajo original (C1.W1) no se conservan, ya que la monitorización refleja la actividad del espacio de trabajo en el que se ejecuta.

Biblioteca de variables

Microsoft Fabric bibliotecas de variables permiten a los desarrolladores personalizar y compartir configuraciones de elementos dentro de un área de trabajo, lo que simplifica la administración del ciclo de vida del contenido. Desde el punto de vista de la recuperación ante desastres, los usuarios de la biblioteca de variables deben protegerse proactivamente frente a un desastre regional. Esta protección puede realizarse mediante la integración de Fabric Git, que garantiza que tras un desastre regional, la biblioteca de Variables del usuario siga disponible. Para recuperar una biblioteca de variables, sigue estos pasos:

• Utiliza la integración de Git de Fabric para sincronizar la biblioteca de variables con el repositorio de ADO. En caso de desastre, puede usar el repositorio para volver a generar la biblioteca de variables en el nuevo área de trabajo que ha creado. Siga estos pasos:

  1. Conecte el área de trabajo al repositorio de Git como se describe aquí.
  2. Asegúrese de mantener el WS y el repositorio sincronizados con confirmación y actualización.
  3. Recuperación: en caso de desastre, use el repositorio para volver a generar la biblioteca de variables en una nueva área de trabajo:

• En el área de trabajo recién creada, conéctese y sincronice con el repositorio de ADO de Azure de nuevo.

• Todos los elementos Fabric de este repositorio se descargan automáticamente en el nuevo área de trabajo.

• Después de sincronizar los elementos desde Git, abra las bibliotecas de variables en el nuevo área de trabajo y seleccione manualmente el conjunto de valores activos deseado.

Plan de implementación

Un plan de despliegue es un elemento en un espacio de trabajo Fabric. Agrupa los elementos y establece el orden para desplegarlos. Puede ejecutar acciones antes o después de que se despliegue cada ítem. La definición de los elementos almacena estos ajustes, entradas y referencias de elementos. El plan no tiene un almacén separado para los valores usados en tiempo de ejecución.

Prepárate para la recuperación usando la integración de Fabric Git:

1. Conecta el espacio de trabajo que contiene el plano a un repositorio de Azure DevOps o GitHub.
2. Confirma el plan y todos los elementos del espacio de trabajo que usa.
3. Haz commit en cada cambio para que Git tenga las definiciones más recientes.

Tras un desastre regional:

1. Crea un espacio de trabajo en la zona saludable.
2. Conecta el espacio de trabajo al mismo repositorio y rama.
3. Actualiza el espacio de trabajo desde Git. Este paso restaura el plano y sus elementos.

Git restaura la definición completa del plan. No restaura los datos ni el estado de ejecución de los elementos vinculados. Utiliza las secciones de este artículo para recuperar esos objetos.

Claves administradas por el cliente para áreas de trabajo de Fabric

Puedes usar claves gestionadas por el cliente (CMK) almacenadas en Azure Key Vault para añadir una capa extra de cifrado sobre las claves gestionadas por Microsoft para los datos en reposo. Si Fabric se vuelve inaccesible o inoperable en una región, sus componentes pasan a una instancia de respaldo. Durante la conmutación por error, la característica CMK admite operaciones de solo lectura. Mientras el servicio Azure Key Vault siga en funcionamiento y los permisos para el vault estén intactos, Fabric sigue conectándose a tu clave y te permite leer datos con normalidad. Esto significa que no se admiten las siguientes operaciones durante la conmutación por error: habilitar y deshabilitar la configuración de CMK del área de trabajo y actualizar la clave.

Fabric Migration Assistant para la base de datos SQL de Fabric

El Fabric Migration Assistant puede mover una base de datos SQL Server a una base de datos SQL en Fabric en tres etapas: el asistente de migración crea la base de datos objetivo y comienza la migración, el monitor de migración sigue el progreso mientras el esquema se despliega desde un DACPAC, el Migration Assistant te ayuda a revisar y corregir errores de script, preparar la base de datos, copiar datos con un trabajo de copia y finalizar la copia.

El progreso de migración no se replica a otra región, y un despliegue interrumpido no puede reanudarse. Estos fallos no afectan a la base de datos de SQL Server de origen, así que puedes ejecutar el asistente de migración de nuevo. Si la región original no está disponible, primero sigue el plan general de recuperación de este artículo para crear capacidad C2 y espacio de trabajo W2 en la región emparejada, y luego ejecuta la migración en W2. Si la región original se recupera, puedes intentar la migración de nuevo en el espacio de trabajo original.

Una interrupción regional puede provocar que una migración fracase de tres maneras:

• La base de datos objetivo no se crea

  Si Fabric no puede crear la base de datos objetivo, el asistente de migración muestra un error y la migración no se inicia. Selecciona Iniciar migración para intentarlo de nuevo, o inténtalo de nuevo más tarde.

  El asistente intenta eliminar una base de datos incompleta, pero la limpieza puede fallar si se produce una interrupción. Antes de volver a intentarlo, comprueba en el espacio de trabajo si hay una base de datos con el nombre objetivo. Confirma que es la base de datos incompleta del intento fallido antes de eliminarla.

• El despliegue falla

  Si el despliegue se interrumpe, el monitor de migración deja de informar del progreso, abre la base de datos objetivo y muestra un diálogo indicando que el despliegue ha fallado. No puedes reanudar un despliegue fallido, y la base de datos creada por el intento permanece en el espacio de trabajo.

  Para recuperar:

  1. Confirma que Fabric está disponible y que tienes el DACPAC usado para la migración original.
  2. Identifica la base de datos creada por el intento fallido. Bórrala si no contiene nada que necesites conservar. Si no, mantenlo y usa un nombre diferente para la nueva base de datos.
  3. Ejecuta una nueva migración desde el DACPAC de origen. La migración crea una nueva base de datos.

  Los datos se copian mediante un trabajo de copia en Data Factory. Si sincronizaste el trabajo de copia con Git antes de la interrupción, consulta Copy Job en la guía de Data Factory. De lo contrario, crea un nuevo trabajo de copia como parte de la nueva migración.

• El historial de migración no carga

  Si el Migration Assistant no puede recuperar el historial de migración, informa que la información de migración ya no está disponible. El progreso guardado en el navegador actual se conserva y la base de datos de destino no se ve afectada. Actualiza la página para cargar el historial de migración de nuevo.

OneLake

Esta sección le guía por los procedimientos de recuperación de las características de OneLake. Para obtener más información sobre la recuperación ante desastres para los datos de OneLake, consulte Recuperación ante desastres de OneLake.

Directivas de administración del ciclo de vida

Si Fabric queda inaccesible o inoperativo en una región, puedes seguir leyendo y actualizando la directiva de ciclo de vida de OneLake durante la conmutación por error. Cualquier dato que se mueva a la capa templada o fría permanece en esa capa. Para aplicar tu póliza actual a tu nuevo espacio de trabajo de recuperación, sigue estos pasos:

1. Use Export Policy en su espacio de trabajo original y guarde la directiva completa del ciclo de vida.
2. Llame a Import Policy en el área de trabajo recuperada, con la directiva de ciclo de vida exportado como cuerpo de la solicitud.

Reglas de instancia de recursos

Las reglas de instancia de recursos le ayudan a controlar de forma segura el acceso a los datos de OneLake mediante identidades de recursos de Azure de confianza. Durante la conmutación por error regional, el sistema sigue aplicando reglas existentes para el acceso de lectura. Sin embargo, no puede crear, actualizar ni eliminar reglas de instancia del recurso hasta que el área de trabajo vuelva a un estado editable.

Información relacionada

• Microsoft Fabric guía de recuperación ante desastres