Recuperación ante desastres y Restauración de ámbitos en Workflow Manager 1.0

 

En este tema se proporciona información general sobre las opciones y procedimientos para la recuperación ante desastres en Workflow Manager 1.0. Incluye procedimientos para la gestión de fallos en servidores de base de datos o en servidores de aplicación, y proporciona procedimientos para la restauración de un ámbito dañado o eliminado.

• Recuperación ante desastres

• Restauración de ámbitos

Recuperación ante desastres

Workflow Manager 1.0 permite prepararse para la gestión de escenarios de desastre. En el ámbito de este tema, un desastre es un acontecimiento que provoca pérdidas series, destrucción, dificultades, etc. En el caso de un producto de servidor, se trata de cualquier suceso que provoque una interrupción prolongada de la disponibilidad del servidor y puede ir acompañado por distintos niveles de pérdida del clúster (o partes de él) que se configuró originariamente para el servidor.

Recuperación ante desastres frente a ante desastres

Normalmente, la recuperación ante desastres está vinculada con la alta disponibilidad. La Alta disponibilidad es el problema que supone asegurar que el servicio se encuentra altamente disponible en circunstancias normales, lo que incluye la creación de redundancias suficientes en el sistema y la eliminación de puntos únicos de fallo. Sin embargo, la Recuperación ante desastres es el problema que surge cuando un servicio primario se detiene a causa de circunstancias externas (como un desastre natural) y se debe continuar proporcionando el mismo nivel de servicio.

Modelo de recuperación ante desastres de alto nivel

El proceso de preparación y respuesta ante un desastre se puede dividir en varias etapas, tal como se muestra en las siguientes secciones. Este diagrama ilustra cada una de estas etapas y recoge las responsabilidades que necesita el usuario para tomar las distintas posibilidades proporcionadas por Workflow Manager.

Diferentes tipos de escenarios de desastre para Workflow Manager

En el caso de Workflow Manager, se pueden producir diferentes escenarios de desastre para los que es necesaria una preparación.

1. Un desastre cuyo resultado es la pérdida de una o más bases de datos utilizadas por Workflow Manager.

   1. Esto se puede deber a un fallo en el hardware o a un desastre relacionado con las fechas a nivel integral.

2. Un desastre cuyo resultado es la pérdida de los servidores de aplicaciones en los que se han desarrollado los archivos binarios de Workflow Manager.

3. Un desastre cuyo resultado es la pérdida del clúster completo, lo que provoca la pérdida tanto de los servidores de aplicaciones como de los de bases de datos.

Debido a que Workflow Manager contiene información relativa a los flujos de trabajo de los usuarios, las actividades y las instancias, una parte clave de la Recuperación ante desastres de Workflow Manager es la posibilidad de restablecer los datos de una instalación de Workflow Manager mediante copias de seguridad. Por lo tanto, en la mayoría de estos escenarios, la recuperación ante desastres consiste principalmente en restaurar los datos a partir de copias de seguridad y en asegurar que esos datos sean coherentes a lo largo de varios subsistemas de Workflow Manager.

Preparación para la recuperación ante desastres

La Recuperación ante desastres consiste fundamentalmente en estar preparados para una emergencia en el caso de que esta se dé. Con Workflow Manager, probablemente desee preservar los datos relativos a todas las actividades, flujos de trabajo e instancias incluso en el caso de que se produzca una catástrofe.

Workflow Manager almacena todos sus datos en bases de datos de SQL Server. Por esto, un requisito previo muy importante para la recuperación ante un desastre es la configuración de copias de seguridad periódicas y/o de soluciones de redundancia de datos, de modo que en el supuesto de que un desastre real amenace su centro de datos, haya una copia reciente de esta que se pueda usar para la restauración de la instalación de Workflow Manager.

La instalación de Workflow Manager utiliza las siguientes bases de datos.

Nombre de la base de datos	Descripción
WFManagementDB	Base de datos de administración de la granja de servidores de Workflow Manager
SbManagementDB	Base de datos de administración de la granja de servidores de CmdLets
WFResourceManagementDB	Almacén de administración de recursos de flujo de Workflow Manager
WFInstanceManagementDB	Almacén de administración de instancias de Workflow Manager
SbGatewayDatabase	Base de datos de puerta de enlace de CmdLets
SBMessageContainer01 - n	Bases de datos de contenedores de mensajes de CmdLets

En función de la importancia de los datos de flujo de trabajo que se incluyen en la instalación de Workflow Manager, se puede escoger entre varias opciones de preparación para la recuperación ante desastres. Puesto que todos los datos de Workflow Manager se almacenan en las bases de datos de SQL Server arriba mencionadas, cualquier estrategia de alta disponibilidad y de copia de seguridad basada en SQL Server se podría aplicar también para Workflow Manager.

Para obtener más información sobre sobre cómo implementar la alta disponibilidad y recuperación ante desastres para SQL Server, consulte Selección de una solución de alta disponibilidad y Descripción de las opciones de recuperación ante desastres para Microsoft SQL Server.

Nota

Independientemente de la opción que elija parar realizar las copias de seguridad de estas bases de datos, asegúrese de que estas copias de seguridad no se distancian mucho en el tiempo. Por ejemplo, es difícil restaurar Workflow Manager correctamente si las copias de seguridad de estas bases de datos independientes se han realizado con una diferencia entre si de horas o días.

El siguiente diagrama enumera los distintos componentes de una instalación de Workflow Manager.

Desde el punto de vista del administrador de una granja de servidores, hay dos partes potenciales de Workflow Manager que se podrían interrumpir en caso de producirse un desastre: Una o varias de las bases de datos implicadas, o bien uno o varios de los nodos del servidor de aplicaciones. Puede haber diferentes combinaciones de los servidores de aplicaciones y bases de datos afectados, pero los puntos de fallo son, en gran medida, la capa de datos y la capa de aplicación.

• Capa de datos

• Nivel de cálculo (Flujo de trabajo/Nivel de mensaje)

Capa de datos

Workflow Manager 1.0 almacena sus datos en las siguientes bases de datos de SQL Server.

Nombre de la base de datos	Descripción
WFManagementDB	Base de datos de administración de la granja de servidores de Workflow Manager
SbManagementDB	Base de datos de administración de la granja de servidores de CmdLets
WFResourceManagementDB	Almacén de administración de recursos de flujo de Workflow Manager
WFInstanceManagementDB	Almacén de administración de instancias de Workflow Manager
SbGatewayDatabase	Base de datos de puerta de enlace de CmdLets
SBMessageContainer01 - n	Bases de datos de contenedores de mensajes de CmdLets

En cuando a la capa de datos, hay tres tareas importantes asociadas con la recuperación ante desastres:

1. Preparación: asegurarse de que se ha elaborado la estrategia de copia de seguridad y replicación adecuada para las bases de datos, de modo que no se pierdan datos en el supuesto de que se produzca una catástrofe en el que estas estén implicadas.

   Para poder recuperarse ante una situación de desastre, es necesario estar preparado para la llegada de ese desastre. Concretamente, en lo referente a la recuperación ante desastres que implican la pérdida de bases de datos, se debe disponer de un modo que permita almacenar una copia de los datos en una ubicación diferente. Puesto que estas son bases de datos estándar de SQL, se recomienda el uso de técnicas establecidas de SQL como:

   1. Creación de reflejos de SQL

   2. Replicación de SQL

   3. Copias de seguridad únicas, así como una combinación de copias de seguridad y envío de registros

   Puede elegir cualquiera de estas técnicas en función de la naturaleza de su negocio y del nivel de fidelidad que desea conservar entre la copia de seguridad y las bases de datos primarias.

   En esencia, como administrador de su granja de Workflow Manager, debe crear copias de seguridad de estas bases de datos usando una estrategia de copias de seguridad adecuada que se ajuste a sus necesidades.Workflow Manager no proporciona ningún potencial de ayuda para la creación de estas bases de datos de copias de seguridad.

2. Restauración de las bases de datos de copias de seguridad

   En función de la estrategia de replicación de datos escogida, se utilizará una herramienta o mecanismo de restauración apropiado para restaurar las bases de datos de copias de seguridad. Existen herramientas y técnicas estándares de SQL que se pueden usar para la restauración de las bases de datos de SQL.

3. Restauración de la granja de servidores de Workflow Manager.

   Este paso hace referencia al proceso de asegurar que la granja de servidores de Workflow Manager se restaure a un estado constante y que pueda funcionar correctamente.Workflow Manager proporciona los scripts de PowerShell y la orientación necesarios para llevar a cabo este paso.

Nivel de cálculo (Flujo de trabajo/Nivel de mensaje)

Se puede crear una granja de servidores secundaria en una ubicación también secundaria que sirva de ayuda en caso de que se produzca un escenario de recuperación ante desastres. Se puede crear la granja de servidores secundaria tanto antes como después del desastre. Existen tres modelos a tener en consideración.

1. Espera pasiva

   En este modelo, se puede volver a crear la granja después de que el desastre haya tenido lugar. Esto afecta al tiempo necesario para recuperar la granja de servidores, ya que se tendrían que suministrar nuevos nodos de ejecución e instalar Workflow Manager de nuevo en estos nodos.

2. Estado de espera semiactiva

   Normalmente, se puede optar por este modelo si se quiere garantizar que la granja de servidores secundaria se crea y se pone a prueba antes de que se produzca el desastre. En este modelo, el aprovisionamiento de nodos de cálculo para la nueva granja de servidores tiene lugar antes del desastre. Después de establecer el emparejamiento de la base de datos, es necesario dirigir esta nueva granja hacia las bases de datos secundarias.

   Una vez configurada esta nueva granja de servidores, básicamente solo hay que desactivar los nodos de ejecución para que no estén funcionando en modo de inactividad. Como parte de la recuperación ante desastres, se deben ejecutar los scripts de coherencia de la base de datos proporcionados por Workflow Manager.

   Nota

   Este modelo asume que las nuevas bases de datos de contenedores de CmdLets no se crean en la principal después de llevar a cabo la configuración inicial. Si se crea una nueva base de datos de contenedores de CmdLets en la principal, entonces se tendrán que realizar pasos adicionales durante la recuperación.

3. Espera activa

   Se trata de una mejora en el Estado de espera semiactiva en la que los nodos de ejecución pueden estar activados. De este modo se agiliza el tiempo dedicado a la recuperación ante un desastre.

   Advertencia

   La espera activa no es compatible con Workflow Manager.

Proceso de recuperación ante desastres

En esta sección se describe al proceso de recuperación ante desastres efectivo que se utiliza para los distintos escenarios de desastre explicados previamente. En gran medida, el proceso recomendado consiste en restaurar las bases de datos necesarias a partir de una copia de seguridad (que se ha realizado mediante cualquiera de las técnicas estándares de SQL Server) y usar los cmdlets de restauración proporcionados por Workflow Manager para restaurar la granja de servidores.

Nota

Los siguientes pasos describen el proceso por el que se descartan las bases de datos de administración de granjas anteriores y se vuelven a crear.

Proceso de ejecución de los comandos de restauración

1. Exporte tanto el certificado de granja de servidores de Bus de servicio con clave privada como el certificado de cifrado de Bus de servicio con clave privada. Importe ambos en la carpeta Equipo Local\Personal del nuevo servidor. También puede importar los certificados raíz en Equipo local\Entidades de certificación raíz de confianza del nuevo servidor. Puede identificar el certificado de granja de servidores y el certificado de cifrado a partir de la salida Get-SBFarm.

   Nota

   La importación solo funciona si los certificados de cifrado de Bus de Servicio antiguos de los antiguos servidores WFM/SB:

   • Se generaron automáticamente durante la configuración de la granja de servidores antigua mediante la herramienta de configuración.

   • O, en caso de que usara un certificado personalizado para Bus de servicio en el entorno antiguo, deben ser certificados de comodín para el dominio, es decir, que el campo "Nombre alternativo del firmante" del certificado se creara con un valor como -*. minombrededominio.com.

   Si no se realiza la importación del certificado antiguo de Bus de servicio, el cmdlet Restore-WFFarm de los pasos siguientes producirá un error similar al siguiente. Token provider returned message: '<Error><Code>400</Code><Detail>The namespace 'WorkflowDefaultNamespace' does not have a valid issuer that can be used to issue tokens. Add a valid issuer with a valid signature to the namespace.

2. Abra una ventana de PowerShell con privilegios (Ejecutar como administrador) en el nuevo equipo.

3. Llame al cmdlet Restore-SBFarm con los parámetros siguientes. Este cmdlet crea una nueva base de datos de administración de la granja de servidores de CmdLets. La antigua base de datos de administración de la granja de servidores de CmdLets se puede eliminar entonces.

   Restore-SBFarm -FarmCertificateThumbprint <String> -GatewayDBConnectionString <String> -SBFarmDBConnectionString <String> [-AdminApiCredentials <PSCredential> ] [-AdminGroup <String> ] [-AmqpPort <Int32> ] [-AmqpsPort <Int32> ] [-EncryptionCertificateThumbprint <String> ] [-FarmDns <String> ] [-Force] [-HttpsPort <Int32> ] [-InternalPortRangeStart <Int32> ] [-MessageBrokerPort <Int32> ] [-RPHttpsPort <Int32> ] [-RunAsAccount <String> ] [-TcpPort <Int32> ] [-TenantApiCredentials <PSCredential> ] [-Confirm] [-WhatIf] [ <CommonParameters>]
   

   Nota

   Si usó los certificados de comodín personalizados en la configuración antigua de Bus de servicio y había usado dos certificados diferentes para FarmCertificate y EncryptionCertificate, debería importar ambos en cada nuevo nodo y proporcionar los parámetros FarmCertificateThumbprint y EncryptionCertificateThumbprint en el cmdlet anterior en consecuencia.

   El siguiente fragmento de código es un ejemplo de llamada a Restore-SBFarm.

   Restore-SBFarm -RunAsAccount 'farm\test' -FarmCertificateThumbprint 41FED42EC87EA556FB64A41572111B96D13FBFC2 -GatewayDBConnectionString 'Data Source=DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False' -AdminGroup 'BUILTIN\Administrators' -EncryptionCertificateThumbprint 41FED42EC87EA556FB64A41572111B96D13FBFC2
   

4. Llame al cmdlet Restore-SBGateway en uno de los nodos de la granja con los parámetros siguientes.

   Parámetro	Descripción
   SBFarmDBConnectionString	Cadena de conexión de la base de datos de la granja de servidores de Service Bus que se crea en el paso anterior.
   GatewayDBConnectionString	Cadena de conexión de la base de datos de puerta de enlace restaurada.

   El siguiente fragmento de código es un ejemplo de llamada a Restore-SBGateway.

   Restore-SBGateway -GatewayDBConnectionString 'Data Source= DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'
   

5. Para cada base de datos de contenedores, llame al cmdlet Restore-SBMessageContainer con los parámetros siguientes. Ejecute este cmdlet en una de las máquinas de la granja.

   Parámetro	Descripción
   SBFarmDBConnectionString	Cadena de conexión de la base de datos de la granja de servidores de Service Bus que se crea en el paso anterior.
   ContainerDBConnectionString	Cadena de conexión de la base de datos de contenedores.
   Id	Identificador del contenedor de mensajes restaurado. Obtenga el identificador del contenedor de mensajes restaurado en la tabla [dbo].[ContainersTable] de la base de datos de puertas de enlace, que contiene los identificadores, las cadenas de conexión, los nombres de los servidores de bases de datos y los nombres de las bases de datos de todos los contenedores de mensajes. Seleccione el identificador del contenedor cuya nombre de base de datos coincida con el nombre de la base de datos de contenedores original.

   El siguiente fragmento de código es un ejemplo de la llamada al cmdlet Restore-SBMessageContainer.

   Restore-SBMessageContainer -ContainerDBConnectionString "Data Source=localhost;Initial Catalog=SBMessageContainer01;Integrated Security=SSPI;Asynchronous Processing=True" -SBFarmDBConnectionString "Data Source=localhost;Initial Catalog= SBManagementDB;Integrated Security=SSPI;Asynchronous Processing=True" –id 1
   

6. Llame al cmdlet Add-SBHost con los siguientes parámetros.

   Parámetro	Descripción
   SBFarmDBConnectionString	Cadena de conexión de la base de datos de la granja de servidores de Service Bus que se creó en el paso anterior.
   CertificateAutoGenerationKey	Esta es la clave que se utiliza para la generación automática de certificados de SB
   RunAsPassword	SecureString que contiene la contraseña de la cuenta bajo la que se ejecutan los procesos de Service Bus.
   EnableFirewallRules	True si las reglas del firewall del host se tienen que actualizar para permitir que los datos de Service Bus atraviesen el firewall. En caso contrario, false.

   En el siguiente ejemplo se demuestra como llamar el cmdlet.

   $myPassword=convertto-securestring 'ereee' -asplaintext -force Add-SBHost -EnableFirewallRules $TRUE -RunAsPassword $myPassword -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'
   

7. Llame al cmdlet Restore-WFFarm y use ResourceManagement y las cadenas de conexión de la base de datos de instancias.

   En el siguiente ejemplo se demuestra como llamar el cmdlet.

   $mykey=convertto-securestring 'etwegff' -asplaintext -force Restore-WFFarm  -RunAsAccount 'farm\test' -InstanceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFInstanceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -ResourceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFResourceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False' -InstanceStateSyncTime 'Sunday, May 11, 2014 12:30:00 PM' -ConsistencyVerifierLogPath 'c:\log.txt' -CertificateAutoGenerationKey $myKey
   

   Nota

   InstanceStateSyncTime debe tener el formato exacto especificado en el ejemplo anterior. ConsistencyVerifierLogPath debe ser la ruta a una carpeta en la que este cmdlet escribirá los registros relacionados con el proceso de restauración.

8. Llame al cmdlet Add-WFHost.

   En el siguiente ejemplo se demuestra como llamar el cmdlet.

   Add-WFHost -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -RunAsPassword $myPassword -EnableFirewallRules $TRUE -CertificateAutoGenerationKey $myKey
   

Escenario 1: el desastre afecta a todo el clúster

En este escenario, todo el clúster se ve afectado a causa del desastre. Para la recuperación ante este escenario de desastre, el clúster completo se debe reconstruir usando las copias de seguridad de bases de datos más recientes.

1. Instale Workflow Manager 1.0 en un nuevo equipo.

   Nota

   Instale Workflow Manager 1.0 usando el instalador pero no comience a configurar la granja de servidores

2. Restaure las copias de seguridad de las bases de datos primarias usando las características de restauración de SQL Server. Este paso varía en función de la solución de copia de seguridad elegida.

   Solo se debe restaurar la siguiente base de datos.

   • WFResourceManagementDB

   • WFInstanceManagementDB

   • SbGatewayDatabase

   • SBMessageContainer*

   Importante

   No restaure las bases de datos WFManagementDB y SbManagementDb ya que estas se volverán a crear como parte de la operación de restauración.

3. Siga los pasos descritos en Proceso de ejecución de los comandos de restauración.

Escenario 2: el desastre afecta solo a las bases de datos de SQL Server

En este caso, una o más bases de datos usadas por Workflow Manager se pierden o son inaccesibles. Esto se puede deber a un fallo en el hardware o a otro desastre localizado solo en los servidores de SQL.

Nota

Los pasos de este escenario también se podrían seguir para migrar de un centro de datos a otro mediante la transferencia de la copia de seguridad más reciente de la base de datos al nuevo centro de datos, y usando el proceso descrito en esta sección.

1. Desinstale Workflow Manager 1.0 de uno de los nodos del servidor de aplicaciones.

2. Vuelva a instalar Workflow Manager 1.0 en el servidor del paso anterior.

   Nota

   Instale Workflow Manager usando el instalador pero no comience a configurar la granja de servidores

3. Restaure las copias de seguridad de las bases de datos primarias usando las características de restauración de SQL Server. Este paso varía en función de la solución de copia de seguridad elegida. Puede restaurarlo al SQL Server existente o a uno diferente, en función de la naturaleza del desastre.

4. Siga los pasos descritos en Proceso de ejecución de los comandos de restauración.

Tras completar estos pasos, tendrá una granja de servidores con un nodo que utiliza las bases de datos existentes. Esta granja de servidores se ha restaurado con las copias de seguridad de las bases de datos originales, lo que le proporciona un estado constante que le permite ser completamente funcional.

Siga los siguientes pasos con cada nodo que formara parte de la granja de servidores primaria.

1. Desinstale Workflow Manager 1.0.

2. Reinstalar Workflow Manager 1.0.

3. Ejecute los cmdlets Add-SBHost y Add-WFHost tal como se describe en Proceso de ejecución de los comandos de restauración.

Escenario 3: el desastre afecta solo a los servidores de aplicaciones

A veces puede ocurrir que solo los servidores de aplicaciones se bloqueen o se pierdan a causa de un desastre localizado y que los servidores de bases de datos queden intactos. Aunque se trata de un escenario poco frecuente en un centro de datos, la recuperación en estos casos resulta relativamente sencilla. Puesto que no se han perdido las bases de datos, probablemente quiera mantener la ubicación primaria y añadir nuevos nodos a la granja de servidores existente. Si prefiere moverse a la ubicación secundaria por alguna razón, puede copiar las bases de datos a la ubicación secundaria y hacer referencia a las nuevas bases de datos al ejecutar los pasos de recuperación.

Para recuperarse ante un escenario de desastre en un servidor de aplicaciones, siga los siguientes pasos.

1. Instale Workflow Manager 1.0 en un nuevo equipo.

2. Suelte las siguientes bases de datos.

   • WFManagementDB

   • SbManagementDB

3. Siga el procedimiento descrito en Proceso de ejecución de los comandos de restauración.

   Nota

   Si ha movido las bases de datos, diríjase a las nuevas bases de datos cuando ejecute estos pasos, de lo contrario diríjase a las bases de datos originales.

Tras completar estos pasos, tendrá una granja de servidores con un nodo que utiliza las bases de datos existentes (o desplazadas). Si lo desea, puede agregar nodos adicionales a la granja de servidores de la misma manera en que agregaría más nodos a una granja de servidores de Workflow Manager.

Restauración de ámbitos

Hay situaciones en las que se puede eliminar accidentalmente un ámbito concreto o en que el contenido de un ámbito determinado está dañado. También dispone de una copia de seguridad de las bases de datos de Workflow Manager cuando el contenido del ámbito estaban en orden. Es posible que desee restaurar solo el contenido de este ámbito desde la copia de seguridad de que dispone.

Al restaurar un ámbito, se restaura el siguiente contenido.

• Ámbitos y ámbitos secundarios junto con sus configuraciones

• Las actividades incluidas en la jerarquía de ámbitos se restauran

• Los flujos de trabajo dentro de la jerarquía de ámbitos junto con sus configuraciones

• Las instancias de los flujos de trabajo dentro de la jerarquía de ámbitos

  • Las instancias se seguirán ejecutando desde su último punto de persistencia.

• Los registros de seguimiento correspondientes a estas instancias.

• Cualquier mensaje no enviado de los flujos de trabajo dentro de la jerarquía de este ámbito

Nota

Al borrar un ámbito, todo su contenido (incluidas las instancias y los registros de seguimiento) se borra en unos minutos (el proceso es asíncrono).

La siguiente table describe la terminología clave utilizada en una operación de recuperación de ámbitos.

Término	Descripción
Bases de datos de copias de seguridad	Se asume que se ha realizado una copia de seguridad de todas las bases de datos utilizadas por Workflow Manager y que el ámbito que se va a restaurar está disponible en esta copia de seguridad. En otras palabras, esta base de datos actúa como la base de datos de origen para copiar el contenido de este ámbito.
Bases de datos activas	Este término hace referencia a las bases de datos que se encuentran activas en el momento en la granjas de servidores de Workflow Manager. En otras palabras, se trata de la base de datos de destino para el proceso de restauración del ámbito.
Ámbito que se va a restaurar.	Puede especificar cualquier ámbito de la jerarquía de ámbitos para restaurarlo a partir de una base de datos de copias de seguridad.

Workflow Manager proporciona las habilidades necesarias para habilitar este escenario. A continuación se presentan los pasos que se deben seguir para lograr la restauración de un ámbito.

• Proceso de restauración de ámbitos

• Consideraciones a tener en cuenta en la restauración de ámbitos

Proceso de restauración de ámbitos

El ámbito que desea restaurar no debe existir en la base de datos activa. Por lo tanto, si se va a restaurar un ámbito a partir de una copia de seguridad por que la base de datos activa contiene una copia dañada de dicho ámbito, es necesario eliminar este ámbito dañado de la base de datos activa.

1. Restauración de las bases de datos de SQL: El primer paso consiste en restaurar las Bases de datos SQL usando las copias de seguridad tal como se muestra en Restaurar una copia de seguridad de base de datos (SQL Server Management Studio).

   Importante

   Se deben restaurar las bases de datos de copias de seguridad en un servidor distinto. No sobrescriba las bases de datos activas.

2. Ejecute el comando de PowerShell Restore-WFScope pasando los siguientes parámetros.

   • Ruta del ámbito que se va a restaurar

   • Cadena de conexión de la base de datos de recursos de la copia de seguridad

   • Cadena de conexión de la base de datos de instancias de la copia de seguridad

   • Proporcione la hora en la que se crearon las copias de seguridad: puede ser una aproximación. Si las copias de seguridad de las bases de datos se realizaron en diferentes momentos, asegúrese de que proporciona la marca de tiempo más antigua como entrada para este paso.

   • Cadena de conexión de la base de datos de puertas de enlace

   • Cadena de conexión de una o más bases de datos de contenedores. Normalmente, solo existe una base de datos de contenedores. En caso de que su servidor cuente con varias bases de datos de contenedores, asegúrese de que proporciona todas esas cadenas de conexión a este cmdlet.

   En este punto el ámbito y su contenido se deben haber restaurado en la base de datos activa y las bases de datos de copias de seguridad recién restauradas se pueden quitar.

Consideraciones a tener en cuenta en la restauración de ámbitos

Durante la restauración de un ámbito a partir de una base de datos restaurada desde su copia de seguridad, se deben tener en cuenta los siguientes puntos acerca del proceso general de restauración.

• Solo se puede restaurar un ámbito a partir de una copia de seguridad previa de la base de datos activa actual. En otras palabras, no se puede tratar de desplazar un ámbito particular de una granja de servidores de Workflow Manager a otra.

• La restauración de ámbitos solo restaura el contenido que pertenece a un ámbito y a todos sus elementos secundarios. No restaura ningún contenido ajeno a la jerarquía secundaria de este ámbito.

• Si una actividad o un flujo de trabajo hace referencia a otra actividad fuera de esta jerarquía de ámbitos (es decir, la actividad a la que se hace referencia se encuentra en un ámbito primario sobre el ámbito que se va a restaurar), entonces la actividad a la que se hace referencia no se restaurará como parte de esta operación. Esto significa que tales flujos de trabajo no serán válidos y cualquier intento de crear una instancia de ellos resultará en un error.