Matière de reprise après sinistre et les stratégies de recherche de SharePoint 2016

Article
02/23/2018

**Sapplique à :**SharePoint Server 2016

**Dernière rubrique modifiée :**2018-01-03

Découvrez comment mettre en œuvre les meilleure reprise après sinistre de pratique pour la recherche d’une batterie de SharePoint Server 2016 ou SharePoint Server 2013.

Cet article présente les méthodes recommandées que vous pouvez utiliser pour élaborer une stratégie de reprise après sinistre pris en charge pour la recherche dans SharePoint Server. La plupart des approches utilisées pour la récupération d’urgence dans les versions antérieures de SharePoint Server ne fournissent pas le même niveau de récupération pour SharePoint Server 2016 et SharePoint Server 2013. Nous examiner ces approches et fournissent des options de remplacement ainsi que les avantages et les limites que vous devez connaître.

Contenu de cet article :

Introduction
Architecture de l'application Service de recherche
Vue d'ensemble de la structure d'index de l'application Service de recherche
Techniques de récupération d'urgence courantes
Techniques prises en charge pour la récupération
Ressources supplémentaires

Introduction

Cet article comble le fossé entre les documentation qui fournit une feuille de route pour la mise en œuvre d’une stratégie de récupération d’urgence et qui vous donne les commandes spécifiques à la configuration de la récupération après sinistre pour l’Application de Service de recherche ( SharePoint Server (SSA). Nous décrivent plusieurs scénarios de récupération d’urgence standard et examiner les avantages et les limitations de chaque approche. Il est irréaliste de penser que ces scénarios sont une solution idéale pour votre organisation, mais vous pouvez les utiliser comme un guide pour une stratégie de reprise après sinistre qui répond aux exigences spécifiques de votre organisation.

Reprise après sinistre pour SharePoint Server et de ses technologies de prise en charge est un sujet complexe, et il existe de nombreuses sources d’informations dédié à l’explication de la planification nécessaires pour garantir que les objectifs de votre entreprise sont respectées s’il existe un événement qui active votre plan de récupération après sinistre.

Avant tout, nous vous recommandons de commencer par identifier et quantifier clairement des objectifs de temps de récupération (RTO) et des objectifs de point de récupération (RPO) pour votre organisation. L’objectif RTO correspond au temps nécessaire pour procéder à la récupération d’urgence suite à un incident, et l’objectif RPO correspond aux données, mesurées en temps, que vous pouvez perdre en raison du même incident. Tous deux constituent des mesures clés pour la planification de la récupération d’urgence. Elles se focalisent sur l’activité et établissent de bonnes bases pour procéder aux étapes suivantes :

Procédures de sauvegarde et restauration, supports et stockage
Emplacement où vous procédez à la récupération
Taille et complexité de votre solution de récupération

Vous ne pouvez pas développer de stratégie de récupération efficace ni évaluer des solutions techniques sans ces repères.

Important

Concentrez-vous sur la continuité des activités et sur les exigences de récupération informatique, plutôt que sur les étapes obligatoires pour créer une stratégie de récupération d’urgence.

Bien que la portée de cet article est la reprise après sinistre pour la recherche de SharePoint Server, nous vous conseillons de lire Choisir une stratégie de récupération d’urgence pour SharePoint Server en vue de l’élaboration d’une stratégie de récupération après sinistre.

Architecture de l’application Service de recherche

Avant d’examiner les différentes façons de développer une stratégie de récupération d’urgence, le tableau suivant fournit une description des composants de recherche de SharePoint Server et comment ils contribuent à l’expérience de recherche de l’utilisateur final. Les composants d’application de recherche et les bases de données décrites dans le tableau suivant fournissent un contexte pour une stratégie de récupération d’urgence.

Composants du service de recherche

Composant ou base de données	Description
Composant d’index	Sert de représentation logique d’une copie d’index. Le composant d’index inclut : Des partitions d’index Vous pouvez diviser l’index en partitions discrètes, chacune contenant une partie distincte de l’index. L’index de recherche constitue le regroupement de toutes les partitions d’index. Une partition d’index est stockée dans un jeu de fichiers sur un disque. Des copies d’index Chaque partition d’index contient une ou plusieurs copies d’index contenant les mêmes informations.
Composant de traitement des requêtes	Permet d’analyser et de traiter les requêtes et les résultats de la recherche.
Composant d’administration	Permet d’exécuter des processus système obligatoires pour la recherche. Il peut y avoir plusieurs composants d’administration de la recherche par application Service de recherche, mais un seul à la fois peut être actif.
Composant d’analyse	Permet d’analyser le contenu en fonction de ce qui est indiqué dans la base de données d’analyse.
Composant de traitement de contenu	Permet d’exécuter plusieurs processus sur les éléments analysés, tels que l’analyse syntaxique et le mappage de propriété.
Composant de traitement de l’analyse	Permet d’exécuter l’analyse de la recherche et l’analyse de l’utilisation.
Base de données d’administration de la recherche	Permet de stocker les données de configuration de recherche. Il existe une seule base de données d’administration de la recherche par application Service de recherche.
Base de données d’analyse	Permet de stocker l’historique d’analyse et de gérer les opérations d’analyse.
Base de données de liens	Permet de stocker certaines des informations extraites par le composant de traitement de contenu. Elle stocke également les informations relatives aux clics publicitaires.
Base de données de création de rapports d’analyse	Permet de stocker les résultats de l’analyse de l’utilisation.

Il existe plusieurs façons de distribuer des composants de recherche pour fournir une topologie de recherche hautement disponible et hautement évolutive, comme le montre le schéma ci-dessous. Dans ce schéma, les composants de recherche sont déployés sur différents serveurs d’applications pour assurer la redondance. En outre, les serveurs d’applications sont déployés sur différents serveurs hôtes de virtualisation, ce qui augmente le niveau de tolérance de panne et offre une grande évolutivité.

Search topology with redundant components

Pour plus d’informations sur la distribution des composants de recherche sur les serveurs de la batterie de serveurs, voir Planifier l’architecture de recherche d’entreprise dans SharePoint Server 2016 et recherchez des diagrammes techniques àSearch in SharePoint Server 2016.

Pour apprécier la complexité du développement d’une stratégie de récupération d’urgence recherche, vous devez comprendre comment les documents sont référencés dans les bases de données et d’index de l’Application de Service de recherche. Il est de ce système de référence qui actuellement ne permet pas d’utiliser n’importe quel formulaire de réplication ou de journaux de technologie expédition pour copier les index de recherche entre des batteries de SharePoint Server.

Vue d’ensemble de la structure d’index de l’application Service de recherche

Étant donné que la structure de l’index de l’application Service de recherche SharePoint est très complexe, une description détaillée dépasserait le cadre du présent article. En termes simples, l’index se compose de nombreuses petites portions formant une série de groupes de données pouvant être mis à jour. Ces groupes pouvant être mis à jour peuvent être considérés comme des partitions organisées dans les colonnes d’un tableau. Par défaut, six de ces groupes se trouvent dans l’index de recherche. Ces groupes sont les suivants :

Principal : contient les champs en bloc ; le texte intégral est stocké ici.
Listes de contrôle d’accès : implique le filtrage de sécurité et l’analyse de sécurité rapide.
Chemin et titre : contient le chemin et le titre.
Recommandations : notez que ces données sont mises à jour quotidiennement.
Collègues (Personnes) : implique un groupe distinct de mises à jour pour les champs de personnes.
Liens de mise en réseau : contient les liens de mise en réseau.

Considérez chaque groupe de mise à jour comme une structure d’index pour les champs de ce groupe, dont la structure ressemble à une base de données SQL Server. Les groupes de mise à jour sont partitionnés au niveau du stockage en plusieurs fichiers qui contiennent chacun une partie de la structure de l’index. Chacun de ces fichiers contient une partie différente de l’index global. Le contenu est réparti sur ces partitions à l’aide d’un identificateur pour chaque document unique. Cet identificateur est le DocID, qui est également un compteur.

Lors de la création d’une application Service de recherche, le compteur démarre à zéro. Le DocID est incrémenté d’une application chaque fois qu’un nouvel élément est découvert lors d’une analyse, et le compteur continue à augmenter au fur et à mesure que de nouveaux éléments sont découverts. La valeur du compteur n’est jamais diminuée. Même si un document est supprimé, la valeur correspondante sur le compteur n’est jamais réutilisée. L’ajout et la suppression progressifs de documents ou d’éléments provenant de bibliothèques et de listes impliquent également que les DocID ne sont pas consécutifs à l’intérieur d’un site ou d’une bibliothèque. Par conséquent, il est impossible de prédire le DocID d’un document dans le corpus de la recherche.

Cet aspect peut présenter des difficultés dans le cadre d’une stratégie de réplication de recherche, car, dans deux batteries de serveurs quelles qu’elles soient, rien ne garantit ou ne laisse même la possibilité que les valeurs DocID correspondront à un document dans la batterie de serveurs. Étant donné que les valeurs DocID ne correspondront pas, il est impossible de répliquer les données d’index ou les données analytiques liées à la valeur DocID. Les résultats de la recherche ne seront pas valides, car le même document aura un DocID différent sur chaque batterie de serveurs.

Lorsque nous examinerons le mode de création d’une stratégie de récupération d’urgence à fidélité optimale pour l’application Service de recherche, il est important que les deux exigences suivantes soient respectées :

Les composants et les bases de données qui stockent les données nécessaires pour la configuration et l’exécution d’une requête sont identifiés et correctement restaurés sur la batterie de récupération d’urgence cible à l’aide d’une méthode appropriée.
La batterie de serveurs de reprise après sinistre cible est correctement mis à l’échelle avec le bon nombre de composants pour prendre en charge de la taille du service de recherche.

Ces deux activités seront référencées dans les sections suivantes et les détails techniques seront inclus dans les sections d’implémentation.

Techniques de récupération d’urgence courantes

Dans les versions antérieures de SharePoint, il existe plusieurs méthodes permettant de s’assurer que vous avez un Application de Service de recherche rempli avec les index à jour et près de fraîcheur de recherche de 100 pour cent de basculement. Les exemples suivants illustrent les méthodes généralement utilisées pour la reprise après sinistre.

L’analyse des bases de données de contenu en lecture seule constituait une possibilité. Les méthodes de copie des journaux de transaction de SQL Server étaient alors utilisées pour conserver une copie des bases de données de contenu de production attachées à la batterie de récupération d’urgence en mode de lecture seule. Cela signifie qu’une application Service de recherche hébergée sur la batterie de récupération d’urgence pouvait être configurée pour analyser les bases de données via une application web en lecture seule sur la batterie de récupération d’urgence. Toute modification de configuration a dû être implémentée au niveau de l’application Service de recherche sur les deux batteries de serveurs afin de garantir une expérience à fidélité optimale pour les utilisateurs finals en cas de basculement.
Grâce à l’option de double analyse, la batterie de récupération analyse également la batterie de production, ce qui explique pourquoi le même contenu a été découvert et indexé. Les modifications de configuration apportées aux propriétés gérées ou aux types de fichiers analysés, les IFilters installés etc., ont dû être implémentés à la fois dans les batteries de production et de récupération d’urgence, mais cela a pu être effectué sans difficulté grâce à une stratégie de contrôle des modifications adéquate.

Les autres options pour les stratégies de récupération d’urgence ne proposent pas le même niveau d’actualisation de l’index de recherche, mais si l’actualisation de l’index ou le temps de récupération ne sont pas essentiels, ce sont des options à envisager. En général, ces options sont plus complexes à configurer et à implémenter. Les exemples ci-dessous illustrent des approches types.

La base de données d’administration de recherche de l’application Service de recherche a pu être sauvegardée indépendamment. La base de données d’administration de recherche de l’application Service de recherche est sauvegardée indépendamment à l’aide d’approches de sauvegarde SQL Server conventionnelles et utilisée sur la batterie de récupération d’urgence pour créer une application Service de recherche à l’aide de Microsoft PowerShell. Cette opération restaure la configuration de la recherche, mais pas les index. Une analyse complète est nécessaire pour remplir les index de recherche et terminer la récupération.
Une sauvegarde et une restauration complètes de l’application Service de recherche. Une sauvegarde et une restauration complètes de l’application Service de recherche est effectuée à l’aide de Microsoft PowerShell ou à l’aide de l’interface de l’le site Web Administration centrale de SharePoint. Cette opération permet de sauvegarder les bases de données et les index de recherche de l’application Service de recherche, ce qui leur permet d’être restaurés sur la batterie de récupération d’urgence pour remplir l’application Service de recherche sur cette batterie.

Dans SharePoint Server 2016 ou SharePoint Server 2013, des changements importants dans l’architecture de recherche et comment les éléments de configuration sont stockés implique que nous devons penser différemment à la reprise après sinistre de recherche. Les sections suivantes décrivent ces modifications et leur impact sur les choix de récupération après sinistre qui sont disponibles.

Modifications fonctionnelles et de configuration apportées à l’expérience de recherche

Les pages de l’Administration du Site de SharePoint Server fournissent des options qui prennent en charge une configuration flexible de l’expérience de recherche. Les nouvelles options de configuration des sites et des collections de sites signifie que les administrateurs de site peuvent apporter des modifications recherche précédemment peuvent uniquement être effectuées par les administrateurs de batterie de serveurs ou de recherche. La capture d’écran suivante montre les deux emplacements où vous pouvez configurer les options de recherche, sous Administration de la Collection de sites ou dans la zone Rechercher.

Configure search on the Site Settings page

Vous pouvez effectuer une modification de configuration sur un élément de recherche, tel que Règles de requête ou Origines des résultats, à partir de la liste sous Administration de la collection de sites ou Recherche, et le résultat sera le même. Toutefois, l’emplacement où une modification est stockée a un impact direct sur la récupération d’urgence. Toutes les modifications apportées à une collection de sites ou une application web seront stockées uniquement dans la base de données d’administration de l’application Service de recherche. À moins que cette base de données ne soit restaurée à partir d’une sauvegarde vers la batterie de récupération d’urgence, les modifications de configuration ne seront pas disponibles dans l’environnement récupéré.

Une autre nouvelle fonctionnalité SharePoint Server recherche est la capacité de réindexation maintenant qui permet aux administrateurs de niveau Collection de sites Web et que la liste demande une réindexation du conteneur au cours de la prochaine analyse. Cette fonctionnalité est gérée entièrement au sein de la base de données de contenu, et par conséquent un administrateur cette demande au sein de la batterie de serveurs de reprise après sinistre déclenche le même événement dans la batterie de serveurs lors de la prochaine analyse s’exécute sur la batterie de serveurs de reprise après sinistre.

Recommandations utilisateur fondées sur l’analyse pour la recherche

Dans SharePoint Server recherche le traitement d’analytique de recherche et de l’utilisation est géré par un composant appelé le processeur Analytique. Ce composant a les responsabilités suivantes :

Gestion du traitement des informations d’analyse de la recherche
Traitement de l’analyse de l’utilisation
Fourniture des informations relationnelles utilisées par le processeur de contenu pour prendre en charge la fonctionnalité de suggestions de recherche
Fourniture d’informations statistiques sur la popularité des documents (par exemple, les visites et clics sur les pages) utilisées par le processeur de contenu pour améliorer les calculs de pertinence et de classement.

Pour en savoir plus sur les processus analytique individuel, consultez Vue d’ensemble du traitement de l’analyse dans SharePoint Server pour plus d’informations.

Les informations traitées sont stockées dans l’index de recherche, ainsi que par les bases de données de rapports et de liens. Par conséquent, la seule méthode permettant de s’assurer que ces informations traitées sont répliquées sur la batterie de récupération d’urgence par synchronisation consiste à effectuer une sauvegarde et une restauration complètes de l’application Service de recherche.

Améliorations de la sauvegarde et de la restauration de l’application de service

L’approche qui satisfait à toutes les exigences de la reprise après sinistre pour la capture de données d’index et de la configuration est service application sauvegarde et restauration. Ces opérations ont investi considérablement afin de réduire le RTO et le RPO par rapport aux versions antérieures de SharePoint. Prise en charge de la modification du nombre de threads utilisés dans les processus de sauvegarde et de restauration ainsi que les améliorations de prise en charge des opérations de sauvegarde et de restauration complètes et différentielles sont tous les gains clés dans ce domaine.

Lors de l’adoption de l’approche d’une sauvegarde et d’une restauration complètes de l’application Service de recherche en tant que stratégie de récupération d’urgence, l’objectif RPO global est régi par deux éléments. Le temps écoulé depuis la dernière sauvegarde complète de l’application de service correspond au RPO, et le temps réellement nécessaire pour effectuer une restauration de l’application de service correspond au RTO. Ces deux durées sont susceptibles d’augmenter à mesure que le contenu indexé dans l’application Service de recherche augmente. Par conséquent, une gestion prudente de la prévision d’une restauration du service en cas d’urgence est nécessaire. Nous avons recommandé la réalisation de tests de restaurations réguliers dans le cadre de vos exercices de gestion de la continuité du service pour s’assurer que tout contrat de niveau de service stipulant des objectifs RTO et RPO peut toujours être honoré. Le tableau suivant récapitule les options de sauvegarde et de restauration pour l’application Service de recherche.

Option	Limites
Analyser les bases de données en lecture seule dans la batterie de serveurs de récupération d’urgence.	Aucune modification de configuration de la collection de sites ou de la recherche au niveau du web n’est répliquée sur la batterie de serveurs de récupération d’urgence.
Effectuer une double analyse d’une batterie de serveurs de production.	Aucune modification de la configuration de la collection de sites ou de la recherche au niveau du web n’est répliquée sur la batterie de serveurs de récupération d’urgence. Les mises à jour des index de recherche fondés sur l’analyse ne sont pas répliquées sur la batterie de serveurs de récupération d’urgence.
Restaurer la base de données d’administration de la recherche sur la batterie de serveurs de récupération d’urgence et recréer le service.	Les mises à jour des index de recherche fondés sur l’analyse ne sont pas restaurées sur la batterie de serveurs de récupération d’urgence, car l’index sera vide lorsque l’application de service sera créée, et une analyse complète sera nécessaire.
Effectuer une sauvegarde et une restauration complètes de l’application Service de recherche.	Aucune limitation de la fidélité de l’index de recherche mais la restauration d’une application de service de grande taille peut prendre plusieurs heures et avoir un impact sur le temps de récupération lors d’un basculement.

Techniques de récupération prises en charge

Il n’existe qu’une seule technique de récupération d’urgence prise en charge qui permet une récupération à fidélité optimale, qui comprend toutes les améliorations de traitement de l’analyse apportées à l’index de recherche et tous les éléments de configuration de recherche au niveau de l’application de service, de la collection de sites et du web dans la batterie de production. Cette approche nécessite une sauvegarde complète de l’application Service de recherche suivie d’une restauration complète de l’application de service sur la batterie de récupération d’urgence. Les index et la configuration sont restaurés au même point dans le temps où la sauvegarde a été effectuée ; si la sauvegarde a été effectuée il y a quelques jours, une nouvelle analyse sera donc nécessaire pour mettre à jour les index. Les étapes spécifiques de cette approche sont décrites plus loin dans le présent document.

La technique consistant à effectuer une sauvegarde de la base de données d’administration de l’application Service de recherche et de la restaurer sur le site de récupération d’urgence est également prise en charge. En utilisant Microsoft PowerShell, les administrateurs peuvent créer une application Service de recherche à l’aide de la sauvegarde. Toutefois, cela permettra uniquement de récupérer la configuration réelle de l’application Service de recherche et tous les paramètres de recherche personnalisés des sites et sites web SharePoint ; l’index de recherche ne sera pas récupéré. Une analyse complète sera nécessaire afin de remplir le corpus pour la recherche. En outre, l’augmentation analytique des index de recherche ne peut pas être récupérée, car les signaux utilisés pour sa génération résident uniquement sur la batterie de production.

Une autre approche peut être utilisée si le but principal de l’inclusion de la recherche dans la stratégie de récupération d’urgence est d’aider à garantir l’actualisation des index de recherche au moment du basculement. En utilisant l’une des deux méthodes, l’index peut être actualisé de manière optimale, mais avec l’introduction d’une configuration complexe et de plusieurs limites. La complexité survient, car soit les robots de la batterie de récupération d’urgence doivent être configurés pour analyser la batterie de production, soit les bases de données de contenu doivent être répliquées dans un état lisible sur la batterie de récupération d’urgence pour prendre en charge une analyse locale. Cette approche a des limites, car la configuration de l’application Service de recherche en production n’est pas du tout répliquée sur la batterie de récupération d’urgence et car les mises à jour d’index de recherche suite au traitement de données analytiques sont également absentes. Si ces limites sont acceptables, cette technique très flexible permet de garantir une actualisation d’index et une disponibilité de recherche élevées dans la batterie de récupération d’urgence.

La dernière approche consiste à combiner les deux techniques décrites précédemment pour obtenir une stratégie unique permettant une actualisation d’index de recherche élevée au moment du basculement mais impliquant aussi la possibilité d’avoir à effectuer une restauration complète afin de transmettre les informations d’analyse et la configuration de recherche à la batterie de récupération d’urgence.

Dans ce cas, une sauvegarde complète et une analyse locale ou distante sont effectuées, et un processus pour la restauration est mis à disposition si nécessaire. Le démarrage du processus de restauration complète survient généralement si le basculement vers le site de récupération d’urgence est plus important qu’une interruption temporaire du service normal et que le retour à la production n’est pas possible dans un délai convenu. Dans ce cas, le processus de restauration est invoqué pour confirmer que l’expérience de recherche à fidélité optimale est disponible sur le site de récupération d’urgence. Une nouvelle analyse est ensuite lancée pour actualiser entièrement l’index de recherche.

Certaines implications doivent être prises en compte lors de la restauration d’une application Service de recherche qui utilise l’option de remplacement. L’application de service sera hors ligne pendant la restauration, ce qui signifie qu’aucune mise à jour ou requête ne sera traitée. Pour une entreprise où la recherche n’est pas une fonction essentielle, ce n’est sans doute pas un problème. Néanmoins, si la fonctionnalité de requête de recherche doit être disponible lors de la restauration, une autre solution peut alors être envisagée. L’autre solution consiste à toujours créer une application Service de recherche pendant le processus de restauration et, une fois la restauration terminée, à exécuter une nouvelle analyse pour mettre à jour l’index. Une fois l’analyse terminée, faites basculer l’association d’application de service vers la nouvelle application de service et continuez à travailler sans interruption. L’ancienne application de service peut ensuite être supprimée. Le plus grand défi concerne la capacité, car le fait de doubler l’espace de l’index et de la base de données est obligatoire pour héberger deux applications de service en parallèle. Le caractère essentiel ou non des services de recherche pour une entreprise indiquera si elle devra prendre ce paramètre en considération ou non.

En somme, il est utile d’examiner les exigences attendues en matière d’objectif RPO et RTO de l’application Service de recherche. Actuellement, Office 365 SharePoint prend en charge des objectifs RPO et RTO d’une semaine pour l’application Service de recherche. Si vous y réfléchissez, cela implique que les éléments de configuration, les informations d’analyse traitées et l’actualisation de la recherche seraient tous obsolètes d’une semaine au maximum au moment de l’exécution d’une restauration. Une fois de plus, selon le taux prévu de modifications de l’environnement et le caractère essentiel de la configuration de la recherche, il peut s’avérer prudent d’exécuter des sauvegardes quotidiennement ou même plusieurs fois par jour pour faire en sorte que des objectifs RPO et RTO optimaux soient atteints pour l’entreprise. Il n’est pas nécessaire de maintenir plusieurs copies de sauvegarde comme vous le feriez pour des sauvegardes de contenu, car le contenu de la recherche est très fluide et temporaire ; une ou deux sauvegardes complètes tout au plus seraient donc conservées.

Sauvegarde et restauration de l’application de service

Les informations suivantes résument brièvement les principaux points contenus dans les articles sur la sauvegarde et la restauration de la recherche sur TechNet :

La fréquence à laquelle les sauvegardes de service de recherche doivent être effectuées sera influencée par beaucoup de facteurs mais le plus important sera, avant tout, l’objectif RPO requis par l’entreprise. À mesure de l’augmentation de la taille de l’index de recherche, le temps nécessaire pour sauvegarder et restaurer l’application de service deviendra de plus en plus long. Seule une sauvegarde de recherche peut être effectuée à la fois, et le temps nécessaire pour effectuer la sauvegarde correspond à l’objectif RPO minimal pouvant être atteint. La durée totale de la restauration sur la batterie de récupération d’urgence correspond donc à l’objectif RTO minimal pouvant être atteint et, tout comme le temps de sauvegarde, il va s’allonger au fil du temps. Si les périodes de sauvegarde ou de restauration commencent à dépasser ceux des contrats de niveau de service requis pour les objectifs RPO et RTO de recherche, l’entreprise doit prendre des décisions et considérer une approche moins axée sur la fidélité et plus flexible, comme nous le décrirons plus tard, ou modifier les contrats de niveau de service pour définir un objectif réalisable à atteindre.

Sauvegarde de l’application Service de recherche

Pour sauvegarder l’application Service de recherche, vous pouvez utiliser Microsoft PowerShell ou l’interface utilisateur de l’Administration centrale. La cmdlet PowerShell requise est la suivante :

Backup-SPFarm -Directory <Backup Folder> - BackupMethod <Full | Differential> -Item <Full Path to Search Service Application>

Voici un exemple :

Backup-SPFarm -Directory \\server\searchbackup - BackupMethod Full -Item "Farm\Shared Services\Shared Services Applications\Contoso Search Service Application"

Cet exemple effectue une sauvegarde complète de l’application Service de recherche nommée application Service de recherche Contoso et stocke les fichiers de sauvegarde à l’emplacement \\server\searchbackup.

Notes

Le commutateur BackupMethod s’applique uniquement aux bases de données de recherche. Dans tous les cas, les index de recherche sont entièrement sauvegardés, quelle que soit l’option choisie.

Vous pouvez afficher l’état général de toutes les tâches de sauvegarde en haut de la page de sauvegarde et restaurer l’état des travaux dans la section préparation . Vous pouvez afficher l’état de la sauvegarde en cours dans la partie inférieure de la page dans la section sauvegarde . La page d’état met automatiquement à jour toutes les 30 secondes. Vous pouvez mettre à jour manuellement les détails d’état en cliquant sur Actualiser. Sauvegarde et restauration sont des travaux du minuteur. Par conséquent, il peut prendre plusieurs secondes pour commencer la sauvegarde. Si vous recevez des erreurs, vous pouvez les consulter dans la colonne Message d’échec de la page État du travail de restauration et de sauvegarde. Vous trouverez plus de détails dans le fichier Spbackup.log dans le chemin d’accès UNC que vous avez spécifié pour stocker le fichier de sauvegarde.

Restauration de l’application Service de recherche

Pour restaurer un SharePoint Server et application de service de recherche, la sauvegarde doit s’est terminé avec succès et si des sauvegardes sont effectuées fréquemment, l’ID de la sauvegarde spécifique à restaurer est nécessaire. Ce code peut être facilement obtenu de plusieurs manières. Le plus simple est d’ouvrir la page de sauvegarde et restauration de l’historique sur la batterie de serveurs de production où la sauvegarde a été effectuée et entrez l' Emplacement du répertoire de sauvegarde. Cela fournit une liste de toutes les entrées dans le fichier manifeste de sauvegarde et de restauration (psbrtoc.xml). Dans la capture d’écran suivante, un ID de sauvegarde de {149fc816-8927-4a32-9437-6e05c2869ab7} est facilement visible.

SharePoint Backup and Restore History page

Au lieu d’utiliser la page Historique de sauvegarde et de restauration, une autre solution consiste à ouvrir directement le manifeste de la sauvegarde et de la restauration, et à examiner l’entrée souhaitée. Étant donné que la taille de ce fichier augmente à chaque sauvegarde et restauration, l’examen de ce fichier n’est peut-être pas l’approche optimale, surtout si les opérations de sauvegarde et de restauration sont très fréquentes.

L’exemple suivant montre des entrées types du fichier spbrtoc.xml, et vous pouvez voir que l’ID de sauvegarde peut facilement être identifié.

<?xml version="1.0" encoding="utf-8"?>
<SPBackupRestoreHistory>
 <SPHistoryObject>
 <SPId>149fc816-8927-4a32-9437-6e05c2869ab7</SPId>
 <SPRequestedBy>REDMOND\pkmacct</SPRequestedBy>
 <SPBackupMethod>Full</SPBackupMethod>
 <SPRestoreMethod>None</SPRestoreMethod>
 <SPStartTime>01/11/2016 02:30:27</SPStartTime>
 <SPFinishTime>01/11/2016 02:38:48</SPFinishTime>
 <SPIsBackup>True</SPIsBackup>
 <SPConfigurationOnly>False</SPConfigurationOnly>
 <SPBackupDirectory>\\server\backups\spbr0000\</SPBackupDirectory>
 <SPDirectoryName>spbr0000</SPDirectoryName>
 <SPDirectoryNumber>0</SPDirectoryNumber>
 <SPTopComponent>Farm\Shared Services\Shared Services Applications\Search Service Application Prod</SPTopComponent>
 <SPTopComponentId>013aa694-673d-46d1-9313-fbba6df691e7</SPTopComponentId>
 <SPWarningCount>0</SPWarningCount>
 <SPErrorCount>0</SPErrorCount>
 </SPHistoryObject>
</SPBackupRestoreHistory>

Une autre méthode disponible consiste à utiliser la cmdlet Get-SPBackupHistory, qui peut également fournir les mêmes informations que le fichier spbrtoc.xml.

Les deux exemples suivants montrent comment effectuer l’opération de restauration en utilisant la cmdlet Restore-SPFarm.

Restore-SPFarm -Directory <BackupFolder> -Item "<ServiceApplicationName>" -RestoreMethod Overwrite [-BackupId <GUID>]

Restore-SPFarm -Directory \\server\searchbackup - Item "Farm\Shared Services\Shared Services Applications\Contoso Search Service Application" -RestoreMethod New -BackupID "149fc816-8927-4a32-9437-6e05c2869ab7"

Notes

Si aucun ID de sauvegarde n’est fourni, la sauvegarde du répertoire la plus récente disponible est alors utilisée.

La méthode RestoreMethod que vous utilisez détermine la façon dont le processus va se dérouler après l’exécution de la cmdlet Restore-SPFarm.

Si l’option new est sélectionnée, l’administrateur exécutant la cmdlet est invité à indiquer un emplacement sur la nouvelle batterie de serveurs pour chaque composant et base de données de la sauvegarde. Cela peut être particulièrement utile si la topologie de la batterie de serveurs et la convention d’affectation de noms dans la batterie de récupération d’urgence ne correspondent pas exactement à celle de la production, ce qui est un scénario fréquent. Si l’application Service de recherche est en cours de restauration sur une batterie contenant des noms et une topologie du serveur correspondants, l’option overwrite peut alors être utilisée. Cette option n’est généralement utilisée que lors d’une restauration sur la même batterie de serveurs, c’est-à-dire la source de la sauvegarde.

Notes

Pour utiliser l’option overwrite, au moins une restauration doit avoir été effectuée à l’aide de l’option new. Si ce n’est pas le cas, une application Service de recherche existante utilisant une configuration et une affectation de noms identiques doit être disponible sur la batterie de récupération d’urgence.

Lors de la restauration d’une application Service de recherche, une pause automatique surviendra pendant et après la restauration. Pour reprendre l’application de service une fois la restauration terminée, utilisez la commande PowerShell suivante.

$ssa = Get-SPEnterpriseSearchServiceApplication <SearchServiceApplicationName> $ssa.ForceResume($ssa.IsPaused())

Un point également important pour l’administrateur concerne le processus utilisé pour restaurer une application Service de recherche qui possède plusieurs réplicas par partition. Le processus de restauration procède à la restauration uniquement sur l’un des réplicas dans chaque partition, et une tâche en arrière-plan gère la réplication des informations de partition sur tous les autres réplicas de chaque partition. L’indexation et la requête de recherche sont en ligne et fonctionnelles pendant ce processus, mais les pages d’administration de l’application Service de recherche peuvent indiquer que les réplicas sont dégradés jusqu’à la fin de cette opération.

Approche de récupération après sinistre combinée

Comme nous l’avons déjà mentionné, la sauvegarde et la restauration de l’application de service constituant la seule approche prise en charge pour maintenir une solution de récupération d’urgence à fidélité optimale, il devient particulièrement difficile d’atteindre de faibles délais RPO/RTO pour la recherche. Les temps de sauvegarde et de restauration peuvent augmenter au fil du temps, à mesure que la taille du corpus indexé augmente. Cela peut conduire à des délais RPO et RTO bien plus élevés que ce que vous espériez.

Pour réussir à surpasser les difficultés et atteindre de faibles délais RPO/RTO, vous pouvez adopter une double approche. La liste suivante illustre cette solution :

Utilisez l’analyse des bases de données de contenu en lecture seule ou la double analyse du site de production afin de maintenir un niveau d’actualisation d’index de recherche acceptable dans la batterie de récupération d’urgence.
Effectuez des sauvegardes de l’application Service de recherche, et restaurez-les régulièrement sur la batterie de récupération d’urgence ou mettez-les à disposition au cas où le site principal ne serait pas récupérable.

Si l’analyse de bases de données en lecture seule dans la reprise après sinistre, batterie de serveurs est le choix préféré, puis vous devez prendre en compte le fait que les modifications dans la batterie de serveurs ne sera pas répliqué à la ferme de récupération. Comme nous l’avons mentionné, cela inclut les mises à jour analytique du service de recherche pour l’index et les modifications apportées aux éléments de configuration sources de résultat, règles de requête, des modifications de schéma. Si vous adoptez une approche combinée, il est très important de comprendre toutes les implications et de mettre en place une stratégie adéquate. Actuellement, il n’y a aucun moyen de contourner la perte de mises à jour analytique pris en charge, mais peuvent prendre des mesures pour éviter les mises à jour des modifications de configuration. Vous pouvez essayer les actions similaires aux exemples suivants.

Assurez-vous que toutes les origines des résultats, règles de requête et modifications de schéma de recherche personnalisées considérées comme vitales pour l’entreprise sont effectuées au niveau de l’application Service de recherche dans l’Administration centrale et non dans les collections de site ou les sous-sites. Par exemple, prenons le cas du portail intranet d’une entreprise qui dépend de règles de requête spécifiques pour gérer le contenu de la page d’accueil. Ces règles doivent être créées sur la batterie de production et répliquées manuellement sur la batterie de récupération d’urgence pour que cette configuration puisse être disponible. De même, les mappages personnalisés de propriétés analysées sur des propriétés gérées doivent être implémentés au niveau de l’application de service sur les deux batteries de serveurs.

Il est possible de capturer des éléments de configuration de la recherche au niveau du site et du web, puis de les exporter vers un fichier XML à l’aide de PowerShell. Par exemple, l’exemple PowerShell suivant exporte des éléments de configuration à partir du site « http://intranet.contoso.com » vers un fichier XML nommé intranetcontosocom.xml. Cette approche a été publiée et diffusée à la communauté SharePoint, et est utilisée avec son autorisation. Vous pouvez accéder à ce billet de blog en suivant ce lien : Importation et exportation des paramètres de configuration de recherche dans SharePoint 2013

Add-PSSnapin Microsoft.SharePoint.PowerShell-ea 0
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.search") | Out-Null
$context = New-Object Microsoft.SharePoint.Client.ClientContext("http://intranet.contoso.com")
$searchConfigurationPortability = New-Object Microsoft.SharePoint.Client.Search.Portability.searchconfigurationportability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.searchobjectowner($context,"SPSite")
$value = $searchConfigurationPortability.ExportSearchConfiguration($owner)
$context.ExecuteQuery()
[xml]$schema = $value.Value
$schema.OuterXml | Out-File intranetcontosocom.xml -Encoding UTF8

Notes

Dans l’exemple précédent, nous avons exporté la configuration à partir du site SharePoint. Vous pouvez utiliser l’énumération SearchObjectLevel pour obtenir ces paramètres : SSA, SPSiteSubscription, SPSite et SPWeb.

L’exemple suivant montre comment importer les paramètres issus d’un autre environnement.

[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.search") | Out-Null
$context = New-Object Microsoft.SharePoint.Client.ClientContext("http://dr.contoso.com")
$searchConfigurationPortability = New-Object Microsoft.SharePoint.Client.Search.Portability.searchconfigurationportability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.searchobjectowner($context,"SPSite")
[xml]$schema = gc .\schema.xml
$searchConfigurationPortability.ImportSearchConfiguration($owner,$schema.OuterXml)
$context.ExecuteQuery()

Vous pouvez personnaliser ces exemples pour développer un processus d’importation/exportation de configuration recherche qui prend en charge vos exigences pour une solution de récupération après sinistre combinée.

Lors de l’analyse des bases de données de contenu en lecture seule dans la batterie de récupération d’urgence, le tableau du plan de site dans la base de données de configuration SharePoint ne sera pas mis à jour pour enregistrer les sites nouvellement créés dans la batterie de serveurs de production. Cela signifie que ces sites, ainsi que leur contenu, ne seront pas indexés pendant les analyses complètes ou incrémentielles. Pour remédier à ce problème, il est important d’exécuter régulièrement la commande PowerShell suivante afin d’actualiser le plan de site sur la batterie de récupération d’urgence pour toutes les bases de données de contenu sur l’application web donnée.

Get-SPContentDatabase -WebApplication https://intranet.contoso.com | % {$_.refreshsitesinconfigurationdatabase()}

Par l’analyse de bases de données en lecture seule et régulièrement mise à jour de la carte de site, un niveau élevé de fraîcheur des index peut être conservé dans la batterie de serveurs de reprise après sinistre. La deuxième étape de l’approche combinée est que faire avec les sauvegardes d’application de service de recherche. Il existe deux possibilités réelles illustré ici, dans la liste suivante mais les Remarque que le choix sélectionné dépend des besoins de l’entreprise.

Si l’entreprise peut fonctionner correctement et exécuter ses principales fonctions sans disposer d’une recherche à fidélité optimale (c’est-à-dire que les éléments de configuration de base dans l’application Service de recherche de l’administration et la capacité à maintenir une actualisation d’index de recherche élevée permettent à l’entreprise de fonctionner sur le site de récupération d’urgence), il se peut alors que l’application de service ne soit jamais restaurée sur le site de récupération d’urgence. La restauration de l’application Service de recherche ne peut être exigée que s’il s’avère évident que le site principal ne sera pas disponible pendant une longue période. Cela signifie que la restauration automatique sur le site principal n’est pas possible, et que la restauration complète de l’application Service de recherche est nécessaire pour rétablir toutes les fonctionnalités en ligne de l’entreprise qui dépendent de la recherche. Une période spécifique peut être sélectionnée pour déclencher la restauration.
S’il est nécessaire de maintenir autant que possible une recherche à fidélité optimale sur le site de récupération d’urgence en cas de basculement, des processus de sauvegarde et de restauration réguliers pourraient alors être exécutés. Les scénarios possibles consistent en des procédures de sauvegarde et de restauration quotidiennes ou hebdomadaires, utilisées avec l’analyse de la base de données en lecture seule pour maintenir l’actualisation au plus près des 100 %. Le problème survient quand l’index de recherche est si volumineux que la restauration prend plusieurs heures, ce qui représente un certain risque pour les objectifs RTO/RPO.

Cette approche combinée est nettement plus complexe qu’une simple sauvegarde et restauration, mais les avantages l’emportent sur les défis si l’entreprise a besoin de la configuration requise pour mettre en œuvre d’une telle solution.

Ressources supplémentaires

Pour plus d’informations, nous vous recommandons d’utiliser les ressources suivantes.

Outre les options fournies dans ces articles et, dans ce document, il existe les autres méthodes que vous pouvez utiliser pour sauvegarder et restaurer l’application de service de recherche dans SharePoint Server. Ces méthodes sont la granularité plus fine et impliquent la restauration indépendamment de l’index de recherche et rechercher des bases de données vers une nouvelle batterie de serveurs. Nous n’avons pas traité ces étapes, mais si vous envisagez d’utiliser une approche scriptée, nous vous recommandons de commencer par consulter les ressources suivantes.

Voir aussi

Planifier la haute disponibilité et la récupération d’urgence pour SharePoint Server