Exporter (0) Imprimer
Développer tout

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

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 par rapport à la 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.

Diagramme de gestion de Workflow Manager 1.0

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 :

 

Nom de la base de données Description

WFManagementDB

Base de données de gestion de la batterie de serveurs Workflow Manager

SbManagementDB

Base de données de gestion de la batterie de serveurs Service Bus

WFResourceManagementDB

Magasin de gestion des ressources Workflow Manager

WFInstanceManagementDB

Magasin de gestion des instances Workflow Manager

SbGatewayDatabase

Base de données de passerelle Service Bus

SBMessageContainer01 - n

Bases de données de conteneurs de messages Service Bus

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 le sujet suivant l’implémentation de la haute disponibilité et de la récupération d’urgence pour SQL Server, voir Selecting a High Availability Solution et Description des options de récupération d’urgence pour Microsoft SQL Server (éventuellement en anglais).

noteRemarque
Quelle que soit l’option que vous choisissez pour la sauvegarde de ces bases de données, veillez à ce que les sauvegardes ne soient pas éloignées les unes des autres dans le temps. Par exemple, il est difficile de restaurer correctement Workflow Manager si les sauvegardes de ces bases de données individuelles sont effectuées dans un intervalle de plusieurs jours ou de plusieurs heures.

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

Affichage de gestion de la batterie de serveurs de Workflow Manager 1.0

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

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

 

Nom de la base de données Description

WFManagementDB

Base de données de gestion de la batterie de serveurs Workflow Manager

SbManagementDB

Base de données de gestion de la batterie de serveurs Service Bus

WFResourceManagementDB

Magasin de gestion des ressources Workflow Manager

WFInstanceManagementDB

Magasin de gestion des instances Workflow Manager

SbGatewayDatabase

Base de données de passerelle Service Bus

SBMessageContainer01 - n

Bases de données de conteneurs de messages Service Bus

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 batterie de serveurs Workflow Manager

    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.

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

    WarningAvertissement
    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 cmdlets de restauration fournies par Workflow Manager pour restaurer votre batterie de serveurs.

noteRemarque
Les étapes suivantes décrivent les processus de suppression et de recréation des bases de données de gestion de la batterie de serveurs précédentes.

Processus d’exécution des commandes de restauration

  1. Ouvrez une fenêtre PowerShell avec des privilèges élevés (Exécuter en tant qu’administrateur) sur le nouvel ordinateur.

  2. Exécutez la cmdlet Restore-SBFarm en transmettant les paramètres suivants. Cette cmdlet 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.

     

    Paramètre Description

    RunAsAccount

    Compte sous lequel les services Service Bus sont exécutés. Il doit s’agir du même compte utilisé par l’ancienne batterie de serveurs.

    GatewayDBConnectionString

    Chaîne de connexion de la base de données de passerelle existante.

    SBFarmDBConnectionString

    Chaîne de connexion de la base de données de la batterie de serveurs Service Bus créée par cette cmdlet.

    CertificateAutoGenerationKey

    SecureString contenant la phrase secrète permettant de sécuriser le certificat de la nouvelle batterie de serveurs créée par cette cmdlet.

    MessageBrokerPort

    Port utilisé pour les communications du port Message Broker. Il doit s’agir du même port utilisé pour les communications du port Message Broker dans l’ancienne batterie de serveurs. Si aucune valeur n’est spécifiée, le port par défaut est utilisé.

    HttpsPort

    Port utilisé pour les communications HTTPS. Il doit s’agir du même port utilisé pour les communications HTTPS dans l’ancienne batterie de serveurs. Si aucune valeur n’est spécifiée, le port par défaut est utilisé.

    TcpPort

    Port utilisé pour les communications TCP. Il doit s’agir du même port utilisé pour les communications TCP dans l’ancienne batterie de serveurs. Si aucune valeur n’est spécifiée, le port par défaut est utilisé.

  3. Exécutez la cmdlet 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.

  4. Exécutez la cmdlet Update-SBHost sur tous les nœuds de la batterie de serveurs.

  5. Pour chaque base de données de conteneurs, exécutez la cmdlet Restore-SBMessageContainer avec les paramètres suivants. Exécutez cette cmdlet sur l’un des ordinateurs 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 de code suivant est un exemple d’exécution de la 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. Exécutez la cmdlet Add-SBHost et transmettez 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 la cmdlet.

    PS C:\Windows\system32> $sec = ConvertTo-SecureString -Force -AsPlainText TwistAndShout#2012
    PS C:\Windows\system32> Add-SBHost -SBFarmDBConnectionString "Data Source=localhost;Initial Catalog=SBManagementDB;Integrated Security=SSPI;Asynchronous Processing=True" -CertificateAutoGenerationKey $sec
    cmdlet Add-SBHost at command pipeline position 1
    Supply values for the following parameters:
    RunAsPassword: ******************
    EnableFirewallRules: yes
  7. Exécutez la cmdlet Restore-WFFarm en utilisant les chaînes de connexion ResourceManagement et InstanceDatabase.

    L’exemple suivant illustre l’appel de la cmdlet.

    PS C:\Windows\system32> Restore-WFFarm
    cmdlet Restore-WFFarm at command pipeline position 1
    Supply values for the following parameters:
    InstanceDBConnectionString: Data Source=localhost;Initial Catalog=WFInstanceManagementDB;Integrated Security=SSPI;Asynchronous Processing=True
    ResourceDBConnectionString: Data Source=localhost;Initial Catalog=WFResourceManagementDB;Integrated Security=SSPI;Asynchronous Processing=True
    InstanceStateSyncTime: September 7, 2012 11:00:00 AM
    ConsistencyVerifierLogPath: c:\windows\System32\helloLog
    WFFarmDBConnectionString: Data Source=localhost;Initial Catalog=WFManagementDB;Integrated Security=SSPI;Asynchronous Processing=True
    CertificateAutoGenerationKey: **********
    noteRemarque
    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 cmdlet doit écrire les journaux liés au processus de restauration.

  8. Exécutez la cmdlet Add-WFHost.

    L’exemple suivant illustre l’appel de la cmdlet.

    PS C:\Windows\system32> $secWF = ConvertTo-SecureString -Force -AsPlainText pass@word1
    PS C:\Windows\system32> Add-WFHost -WFFarmDBConnectionString "Data Source=localhost;Initial Catalog=WFManagementDB;Integrated Security=SSPI;Asynchronous Processing=True" -CertificateAutoGenerationKey $secWF
    cmdlet Add-WFHost at command pipeline position 1
    Supply values for the following parameters:
    RunAsPassword: ******************
    EnableFirewallRules: yes

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.

    noteRemarque
    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*

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

noteRemarque
Les étapes décrites dans ce scénario peuvent également être suivies pour effectuer la migration d’un centre de données vers un autre, en transférant la sauvegarde la plus récente de votre base de données vers le nouveau centre de données, puis en utilisant le processus décrit dans cette section.

  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.

    noteRemarque
    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 Workflow Manager 1.0.

  3. Exécutez les cmdlets Add-SBHost et Add-WFHost, comme décrit dans la section 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.

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

noteRemarque
Lorsque vous supprimez une étendue, l’intégralité de son contenu (y compris les instances et les enregistrements de suivi) est nettoyée après quelques minutes (le processus est asynchrone).

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

 

Terme Description

Bases de données de sauvegarde

Cette opération suppose que vous avez effectué une sauvegarde de toutes les bases de données utilisées par Workflow Manager, et que l’étendue que vous envisagez de restaurer est disponible dans cette copie de sauvegarde. En d’autres termes, cette base de données joue le rôle de base de données source pour la copie du contenu de cette étendue.

Bases de données active

Ce terme fait référence aux bases de données actuellement actives dans votre batterie de serveurs Workflow Manager. En d’autres termes, il s’agit de la base de données cible pour le processus de restauration d’étendue.

Étendue à restaurer

Vous pouvez spécifier une étendue qui figure dans la hiérarchie d’étendue à restaurer à partir d’une base de données de sauvegarde.

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’é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 à l’aide des sauvegardes, comme décrit dans le lien ci-dessous. Restore a Database Backup (SQL Server Management Studio)

    ImportantImportant
    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 en transmettant 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 cmdlet.

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


Workflow Manager 1.0 MSDN Community Forum


Date de génération :

2013-10-23

Ajouts de la communauté

AJOUTER
Afficher:
© 2015 Microsoft