Récupération d’urgence et restauration d’étendue dans Workflow Manager 1.0

Cette rubrique fournit une vue d’ensemble des options et des procédures de récupération d’urgence pour Workflow Manager 1.0. Elle décrit des procédures de gestion des défaillances au niveau du serveur de base de données et du serveur d’applications, ainsi que des procédures de restauration d’une étendue endommagée ou supprimée.

• Récupération d'urgence

• Restauration d’étendue

Récupération d'urgence

Workflow Manager 1.0 vous permet de vous préparer à la gestion de scénarios d’incidents. Dans le cadre de cette rubrique, un incident est un événement ayant provoqué une perte sérieuse, une destruction, une difficulté, etc. Dans le cas d’un produit serveur, il s’agit d’un événement ayant entraîné une interruption prolongée de la disponibilité du serveur, qui est accompagnée par différents degrés de perte au niveau du cluster d’origine (ou des parties de ce cluster) qui était configuré pour le serveur.

Récupération d’urgence et haute disponibilité

En règle générale, la récupération d’urgence va de pair avec la haute disponibilité. La haute disponibilité est la garantie que le service reste hautement disponible dans des circonstances normales, notamment en créant assez de redondances dans le système et en éliminant les points d’échec uniques. En revanche, la récupération d’urgence concerne le processus par lequel un service principal qui tomberait en panne en cas de force majeure (telle qu’une catastrophe naturelle) doit continuer à offrir le même niveau de service.

Modèle de récupération d’urgence de haut niveau

Le processus de préparation et de réponse à un incident peut être divisé en plusieurs étapes, comme décrit dans les sections suivantes. Ce diagramme illustre chacune de ces étapes et met en avant les responsabilités que l’utilisateur doit prendre par rapport aux fonctionnalités fournies par Workflow Manager.

Différents types de scénarios d’incidents pour Workflow Manager

Dans le cas de Workflow Manager, vous pouvez vous préparer à plusieurs scénarios d’incidents.

1. Un incident qui entraînerait la perte d’une ou de plusieurs bases de données utilisées par Workflow Manager.

   1. Cette situation pourrait avoir été causée par une défaillance matérielle ou un incident à l’échelle du centre de données.

2. Un incident entraînant la perte des serveurs d’applications sur lesquels les fichiers binaires de Workflow Manager ont été déployés.

3. Un incident entraînant la perte de l’intégralité du cluster, au cours duquel les serveurs d’applications et les bases de données sont perdus.

Étant donné que Workflow Manager contient des informations relatives aux flux de travail, activités et instances des utilisateurs, une fonctionnalité essentielle de la récupération d’urgence Workflow Manager réside dans la possibilité de restaurer les données d’une installation de Workflow Manager à l’aide de copies de sauvegarde. Par conséquent, dans la plupart de ces scénarios, la récupération d’urgence consiste principalement à restaurer les données à partir de sauvegardes et à s’assurer que les données sont cohérentes entre plusieurs sous-systèmes de Workflow Manager.

Préparation à la récupération d’urgence

La récupération d’urgence consiste principalement à être préparé pour une situation d’urgence, par exemple, en cas d’incident. Avec Workflow Manager, vous souhaiterez sans doute conserver les données liées à l’ensemble des flux de travail, activités et instances si un incident se produisait.

Workflow Manager stocke l’intégralité de ses données dans des bases de données SQL Server. Une condition préalable et essentielle à la récupération d’urgence est la configuration de solutions de sauvegardes régulières et/ou de redondance des données. Ainsi, si un incident réel frappait votre centre de données, il y aurait toujours une copie récente de votre base de données que vous pourriez utiliser pour restaurer votre installation Workflow Manager.

Votre installation Workflow Manager utilise les bases de données suivantes :

En fonction de la criticité des données des flux de travail dont vous disposez dans votre installation Workflow Manager, vous avez le choix entre plusieurs options de préparation à la récupération d’urgence. Sachant que toutes les données de Workflow Manager sont stockées dans les bases de données SQL Server mentionnées précédemment, toute stratégie de haute disponibilité et de sauvegarde basée sur un serveur SQL Server doit s’appliquer également à Workflow Manager.

Pour plus d'informations sur l’implémentation de la haute disponibilité et la récupération d’urgence pour SQL Server, voir Sélection d'une solution haute disponibilité et Description des options de récupération d'urgence pour Microsoft SQL Server.

Le diagramme suivant répertorie les différents composants d’une installation Workflow Manager.

Du point de vue de l’administrateur de la batterie de serveurs, il peut y avoir deux parties de Workflow Manager qui risquent de s’arrêter en cas d’incident : une ou plusieurs des bases de données impliquées, ou un ou plusieurs nœuds du serveur d’applications. Plusieurs combinaisons de serveurs d’applications et de bases de données pourraient tomber en panne, mais à un haut niveau, la couche Données et la couche Application sont les points d’échec.

• Couche Données

• Couche Calculs (couche Flux de travail/Messages)

Couche Données

Workflow Manager 1.0 stocke ses données dans les bases de données SQL Server suivantes.

Pour ce qui concerne la couche Données, trois tâches essentielles sont associées à la récupération d’urgence :

1. Préparation : assurez-vous de mettre en œuvre la bonne stratégie de sauvegarde/réplication pour vos bases de données de manière à ne pas perdre de données en cas d’incident ayant un impact sur vos bases de données.

   Pour récupérer d’un incident, vous devez y être préparé. Plus précisément, en ce qui concerne la récupération suite à un incident impliquant la perte de bases de données, vous devez mettre en place une méthode de stockage d’une copie des données dans un autre emplacement. Sachant que ces bases de données sont des bases de données SQL standard, il est recommandé d’utiliser des techniques SQL éprouvées telles que :

   1. Mise en miroir SQL

   2. Réplication SQL

   3. Sauvegardes simples, ainsi qu’une combinaison de sauvegardes et de copie des journaux de transaction

   Vous pouvez choisir l’une de ces techniques en fonction de la nature de votre activité et du niveau de fidélité des données que vous souhaitez obtenir entre votre sauvegarde et les bases de données primaires.

   En substance, en tant qu’administrateur de votre batterie de serveurs Workflow Manager, il vous incombe de créer des sauvegardes de ces bases de données en utilisant une stratégie de sauvegarde adéquate qui correspond aux besoins de votre organisation.Workflow Manager n’offre aucune fonctionnalité d’aide à la création de ces bases de données de sauvegarde.

2. Restauration des bases de données de sauvegarde

   En fonction de votre stratégie de réplication des données, vous devez utiliser un outil/mécanisme de restauration approprié pour restaurer vos bases de données de sauvegarde. Il existe des outils et des techniques SQL standard permettant de restaurer vos bases de données SQL.

3. Restauration de la Workflow Manager batterie de serveurs

   Cette étape décrit le processus permettant de s’assurer que la batterie de serveurs Workflow Manager soit restaurée dans un état cohérent et puisse fonctionner correctement.Workflow Manager offre les scripts PowerShell nécessaires ainsi que les instructions vous permettant de réaliser cette étape.

Couche Calculs (couche Flux de travail/Messages)

La création d’une deuxième batterie de serveurs dans un second emplacement peut être utile dans le cadre des scénarios de récupération d’urgence. Vous pouvez créer la deuxième batterie de serveurs avant ou après l’incident. Trois modèles sont à prendre en considération.

1. Reprise progressive

   Dans ce modèle, vous pouvez recréer la batterie de serveurs après un incident. Cela a un impact sur le temps nécessaire à la restauration de la batterie de serveurs, étant donné que vous configurez de nouveaux nœuds de calcul et que vous y réinstallez Workflow Manager.

2. Secours semi-automatique

   Vous choisissez généralement ce modèle lorsque vous souhaitez vous assurer que votre deuxième batterie de serveurs est créée et testée avant même qu’un incident ne survienne. Dans ce modèle, vous configurez des nœuds de calcul dans la nouvelle batterie de serveurs avant qu’un incident ne se produise. Après avoir établi la relation de jumelage entre les bases de données, vous mettez en correspondance cette nouvelle batterie de serveurs avec les bases de données secondaires.

   Après avoir configuré cette nouvelle batterie de serveurs, vous devez DÉSACTIVER les nœuds de calcul de manière à ce qu’ils ne soient pas exécutés avec un état Inactif. Dans le cadre d’un scénario de récupération d’urgence, vous devez exécuter les scripts de cohérence des bases de données fournis par Workflow Manager.

   Notes

   Ce modèle part du principe que les bases de données de conteneurs Service Bus ne sont pas créées dans la batterie de serveurs primaire après l’installation initiale. Si une base de données de conteneurs Service Bus est créée dans la batterie de serveurs primaire, vous devez effectuer des étapes supplémentaires lors du processus de récupération.

3. Serveur de secours

   Ce modèle constitue une amélioration par rapport au modèle de secours semi-automatique, dans le sens où les nœuds de calcul peuvent être actifs et que ce modèle permet d’accélérer le processus de récupération d’urgence.

   Avertissement

   Workflow Manager ne prend pas en charge le serveur de secours.

Processus de récupération d’urgence

Cette section décrit le processus réel de récupération d’urgence mis en place suite aux scénarios d’incidents mentionnés précédemment. À grande échelle, il est recommandé de restaurer les bases de données requises à partir d’une sauvegarde (que vous aurez effectuée au préalable à l’aide d’une technique SQL Server standard), puis d’utiliser les applets de commande de restauration fournies par Workflow Manager pour restaurer votre batterie de serveurs.

Processus d’exécution des commandes de restauration

1. Exportez le certificat de batterie de serveurs ServiceBus avec la clé privée et le certificat de chiffrement Service Bus avec la clé privée. Importez les deux certificats dans le dossier Ordinateur local\Personnel du nouveau serveur. Importez également les certificats racine dans le dossier Ordinateur local\Autorité racine approuvée du nouveau serveur. Vous pouvez identifier le certificat de batterie de serveurs et le certificat de chiffrement à partir de la sortie Get-SBFarm.

   Remarque

   L’importation ne fonctionne que si les anciens certificats de chiffrement ServiceBus du ou des anciens serveurs WFM/SB : Ont été générés automatiquement lors de l’ancienne configuration de batterie de serveurs par l’outil de configuration. Ou, si vous aviez utilisé un certificat personnalisé pour ServiceBus dans l’ancien environnement, il doit s’agir de certificats avec caractères génériques pour votre domaine, par exemple, le champ « Autre nom de l’objet » du certificat a été créé avec une valeur telle que - *.mydomainname.com. Si l’importation de l’ancien certificat ServiceBus n’est pas effectuée, l’applet de commande Restore-WFFarm indiquée dans les étapes suivantes échoue avec une erreur semblable à l’erreur suivante. 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. Ouvrez une fenêtre PowerShell avec des privilèges élevés (Exécuter en tant qu’administrateur) sur le nouvel ordinateur.

3. Exécutez l’applet de commande Restore-SBFarm avec les paramètres suivants. Cette applet de commande crée une base de données de gestion de la batterie de serveurs Service Bus. Vous pouvez ensuite supprimer l’ancienne base de données de gestion de la batterie de serveurs Service Bus.

   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>]
   

   Notes

   Si vous aviez utilisé des certificats avec caractères génériques personnalisés dans l’ancienne configuration ServiceBus et utilisé deux certificats différents pour FarmCertificate et EncryptionCertificate, vous devrez importer les deux certificats sur chaque nouveau nœud et fournir les paramètres FarmCertificateThumbprint et EncryptionCertificateThumbprint dans l’applet de commande ci-dessus, respectivement.

   L’extrait de code suivant est un exemple d’appel de 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. Exécutez l’applet de commande Restore-SBGateway sur l’un des nœuds de la batterie de serveurs avec les paramètres suivants.

   Paramètre	Description
   SBFarmDBConnectionString	Chaîne de connexion de la base de données de la batterie de serveurs Service Bus créée au cours de l’étape précédente.
   GatewayDBConnectionString	Chaîne de connexion de la base de données de passerelle restaurée.

   L’extrait de code suivant est un exemple d’appel de 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. Pour chaque base de données de conteneur, exécutez l’applet de commande Restore-SBMessageContainer avec les paramètres suivants. Exécutez cette applet de commande sur l'une des machines de la batterie de serveurs.

   Paramètre	Description
   SBFarmDBConnectionString	Chaîne de connexion de la base de données de la batterie de serveurs Service Bus créée au cours de l’étape précédente.
   ContainerDBConnectionString	Chaîne de connexion de la base de données de conteneurs.
   Id	ID du conteneur de messages restauré. Récupérez l’ID du conteneur de messages restauré à partir de la table [dbo].[ContainersTable] de la base de données de passerelle, laquelle contient les ID, les chaînes de connexion, les noms des serveurs de base de données et les noms des bases de données de tous les conteneurs de messages. Choisissez l’ID du conteneur dont le nom de base de données correspond à celui de la base de données de conteneurs d’origine.

   L'extrait suivant est un exemple d’exécution de l’applet de commande 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. Exécutez l’applet de commande Add-SBHost avec les paramètres suivants.

   Paramètre	Description
   SBFarmDBConnectionString	Chaîne de connexion de la base de données de la batterie de serveurs Service Bus créée au cours de l’étape précédente.
   CertificateAutoGenerationKey	Il s’agit de la clé utilisée pour la génération automatique de certificats Service Bus.
   RunAsPassword	SecureString contenant le mot de passe du compte sous lequel les processus Service Bus sont exécutés.
   EnableFirewallRules	La valeur est True si les règles de pare-feu doivent être mises à jour de manière à autoriser les données Service Bus à traverser le pare-feu, sinon False.

   L’exemple suivant illustre l’appel de l’applet de commande.

   $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. Exécutez l’applet de commande Restore-WFFarm en utilisant les chaînes de connexion de base de données ResourceManagement et Instance.

   L’exemple suivant illustre l’appel de l’applet de commande.

   $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
   

   Notes

   InstanceStateSyncTime doit suivre le format exact spécifié dans l’exemple précédent. ConsistencyVerifierLogPath doit correspondre au chemin d’accès au dossier dans lequel cette applet de commande doit écrire les journaux liés au processus de restauration.

8. Exécutez l’applet de commande Add-WFHost.

   L’exemple suivant illustre l’appel de l’applet de commande.

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

Scénario 1 : un incident affecte l’intégralité du cluster

Dans ce scénario, le cluster entier est affecté par un incident. Pour récupérer de cet événement, vous devez recréer l’intégralité du cluster en utilisant les sauvegardes de bases de données les plus récentes.

1. Installez Workflow Manager 1.0 sur un nouvel ordinateur.

   Notes

   Installez Workflow Manager 1.0 à l’aide du programme d’installation, mais ne démarrez pas la configuration de la batterie de serveurs.

2. Restaurez les bases de données primaires sauvegardées à l’aide des fonctionnalités de restauration de SQL Server. Cette étape peut être différente en fonction du choix de votre solution de sauvegarde.

   Seule la base de données suivante doit être restaurée.

   • WFResourceManagementDB

   • WFInstanceManagementDB

   • SbGatewayDatabase

   • SBMessageContainer*

   Important
   Ne restaurez pas les bases de données WFManagementDB et SbManagementDb, car elles seront recréées dans le cadre de l’opération de restauration.

3. Suivez les étapes décrites dans la section Processus d’exécution des commandes de restauration.

Scénario 2 : un incident affecte uniquement les bases de données SQL Server

Dans ce scénario, une ou plusieurs bases de données utilisées par Workflow Manager sont perdues ou inaccessibles. Cette situation peut avoir été causée par une défaillance matérielle ou un incident touchant uniquement les serveurs SQL Server.

1. Désinstallez Workflow Manager 1.0 de l’un des nœuds du serveur d’applications existant.

2. Réinstallez Workflow Manager 1.0 sur le serveur mentionné dans l’étape précédente.

   Notes

   Installez Workflow Manager à l’aide du programme d’installation, mais ne démarrez pas la configuration de la batterie de serveurs.

3. Restaurez les bases de données primaires sauvegardées à l’aide des fonctionnalités de restauration de SQL Server. Cette étape peut être différente en fonction du choix de votre solution de sauvegarde. Selon la nature de l’incident, vous pouvez effectuer la restauration sur le serveur SQL Server existant ou sur un autre serveur SQL Server.

4. Suivez les étapes décrites dans la section Processus d’exécution des commandes de restauration.

Lorsque vous avez terminé ces étapes, vous disposez d’une batterie de serveurs à un nœud qui utilise les bases de données existantes. Cette batterie de serveurs a été restaurée à partir de vos copies de sauvegarde des bases de données d’origine, et a été amenée à un état cohérent lui permettant d’être entièrement fonctionnelle.

Pour chaque nœud faisant partie de la batterie de serveurs primaire, procédez comme suit.

1. Désinstallez Workflow Manager 1.0.

2. Réinstallez le Workflow Manager 1.0.

3. Exécutez les applets de commande Add-SBHost et Add-WFHost comme décrit dans Processus d’exécution des commandes de restauration.

Scénario 3 : un incident affecte uniquement les serveurs d’applications

Parfois, il est possible que seuls vos serveurs d’applications s’arrêtent ou soient perdus à cause d’un incident localisé, et que vos serveurs de bases de données soient intacts. Bien que ce scénario soit exceptionnel au sein d’un centre de données, il est assez facile de récupérer d’un tel incident. Étant donné que vous n’avez pas perdu vos bases de données, vous souhaitez sans doute continuer avec l’emplacement principal et ajouter de nouveaux nœuds à la batterie de serveurs existante. Si, pour une raison quelconque, vous préférez basculer sur le second emplacement; vous pouvez toujours copier les bases de données sur le second emplacement et utiliser les nouvelles bases de données lorsque vous effectuez les étapes de récupération.

Pour récupérer d’un scénario d’incident touchant un serveur d’applications, procédez comme suit.

1. Installez Workflow Manager 1.0 sur un nouvel ordinateur.

2. Supprimez les bases de données suivantes.

   • WFManagementDB

   • SbManagementDB

3. Suivez la procédure décrite dans la section Processus d’exécution des commandes de restauration.

   Notes

   Si vous avez déplacé les bases de données, faites référence aux nouvelles bases de données lorsque vous effectuez ces étapes, sinon, faites référence aux bases de données d’origine.

Lorsque vous avez terminé ces étapes, vous disposez d’une batterie de serveurs à un nœud qui utilise les bases de données existantes (ou celles ayant été déplacées). Le cas échéant, vous pouvez ajouter des nœuds à la batterie de serveurs de la même manière que vous ajoutez des nœuds à une batterie de serveurs Workflow Manager.

Restauration d’étendue

Vous pouvez rencontrer certaines situations au cours desquelles vous supprimez accidentellement une étendue spécifique, ou au cours desquelles du contenu d’une étendue spécifique est endommagé. Vous disposez également d’une sauvegarde de vos bases de données Workflow Manager au moment où le contenu de l’étendue était en état de fonctionnement. Vous souhaitez peut-être restaurer uniquement le contenu de cette étendue à partir de la copie de sauvegarde dont vous disposez.

Lorsque vous restaurez une étendue, vous restaurez le contenu suivant.

• Étendues et étendues enfants ainsi que leurs configurations

• Activités au sein de la hiérarchie de l’étendue en cours de restauration

• Flux de travail au sein de la hiérarchie de l’étendue ainsi que leurs configurations

• Instances des flux de travail au sein de la hiérarchie de l’étendue

  • Les instances continuent leur exécution à partir de leur dernier point de persistance.

• Enregistrement de suivi correspondant à ces instances

• Messages non remis pour les flux de travail au sein de la hiérarchie de l’étendue.

Le tableau suivant décrit la terminologie clé utilisée dans une opération de restauration d’étendue.

Workflow Manager offre des fonctionnalités permettant de mettre en œuvre ce scénario. Pour effectuer une restauration d’étendue, procédez comme suit.

• Processus de restauration d’étendue

• Éléments à prendre en considération pour la restauration d’une étendue

Processus de restauration d’étendue

L’étendue que vous souhaitez restaurer ne doit pas exister dans la ou les bases de données actives. Ainsi, si vous restaurez une étendue à partir d’une sauvegarde, car votre base de données active contient une copie endommagée de cette étendue, vous devez d’abord supprimer cette étendue endommagée de votre base de données active.

1. Pour restaurer les bases de données SQL : La première étape consiste à restaurer les bases de données SQL en utilisant les sauvegardes de la manière décrite dans Restaurer une sauvegarde de base de données (SQL Server Management Studio).

   Important
   Vous devez restaurer les bases de données de sauvegarde vers un autre serveur. Ne remplacez pas les bases de données actives.

2. Exécutez la commande PowerShell Restore-WFScope avec les paramètres suivants :

   • Chemin d’accès de l’étendue à restaurer

   • Chaîne de connexion de la base de données des ressources (sauvegarde)

   • Chaîne de connexion de la base de données des instances (sauvegarde)

   • Indiquez le moment de création des sauvegardes (il peut s’agir d’une approximation grossière). Au cours de cette étape, si les bases de données ont été sauvegardées à différents moments, assurez-vous d’indiquer l’horodateur le plus ancien.

   • Chaîne de connexion de la base de données de passerelle

   • Chaînes de connexion d’une ou plusieurs bases de données de conteneurs. Généralement, vous n’avez qu’une base de données de conteneurs. Si votre serveur en possède plusieurs, assurez-vous d’indiquer toutes ces chaînes de connexion à cette applet de commande.

   À ce point, l’étendue et son contenu doivent avoir été restaurés dans la base de données active, et les bases de données de sauvegarde nouvellement restaurées peuvent être supprimées.

Éléments à prendre en considération pour la restauration d’une étendue

Bien qu’une opération de restauration d’étendue permet de restaurer votre étendue à partir d’une ou plusieurs bases de données sauvegardées et restaurées, vous devez tenir compte des points suivants en ce qui concerne le processus de restauration global.

• Vous pouvez uniquement restaurer une étendue à partir d’une copie de sauvegarde précédente de la base de données active. En d’autres termes, vous ne pouvez pas essayer de déplacer une étendue particulière depuis une batterie de serveurs Workflow Manager vers une autre.

• La restauration d’étendue permet uniquement de restaurer le contenu appartenant à une étendue et à tous ses enfants. Elle ne permet pas de restaurer du contenu situé hors de la hiérarchie enfant de cette étendue.

• Si une activité ou un flux de travail fait référence à une autre activité située en dehors de la hiérarchie de cette étendue (c’est-à-dire, l’activité se trouve dans une étendue parente à un niveau supérieur par rapport à l’étendue en cours de restauration), l’activité référencée ne sera pas restaurée au cours de cette opération. Cela signifie que de tels flux de travail ne seraient pas valides et que toute tentative de création d’une instance de tels flux de travail provoquerait des erreurs.