Meilleures pratiques et stratégies de récupération d’urgence pour la recherche SharePoint

S’APPLIQUE À :2013 2016 2019 Subscription Edition SharePoint dans Microsoft 365

Découvrez comment implémenter les meilleures pratiques de récupération d’urgence pour la recherche dans une batterie de serveurs SharePoint Server.

Cet article fournit des conseils de bonnes pratiques que vous pouvez utiliser pour développer une stratégie de récupération d’urgence prise 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 n’offrent pas le même niveau de récupération pour SharePoint Server. Nous examinons ces approches, ainsi que les avantages et les limites que vous devez connaître, et proposons des options de remplacement.

Introduction

Cet article comble l’écart entre la documentation qui fournit une feuille de route pour l’implémentation d’une stratégie de récupération d’urgence et la documentation qui vous fournit les commandes spécifiques pour configurer la récupération d’urgence pour l’application de service SharePoint ServerSearch (SSA). Nous décrivons plusieurs scénarios de récupération d'urgence types, et examinons les avantages et les limites de chaque approche. Il est insensé de penser que ces scénarios conviennent parfaitement à votre organisation, mais vous pouvez les utiliser comme repères pour établir une stratégie de récupération d'urgence qui répond aux besoins spécifiques de votre organisation.

La récupération d’urgence pour SharePoint Server et ses technologies de prise en charge est un sujet complexe, et il existe de nombreuses sources d’informations dédiées à expliquer la planification nécessaire pour vous assurer que vos objectifs métier sont atteints en cas d’événement qui active votre plan de récupération d’urgence.

En guise de meilleure pratique, nous vous recommandons de commencer par identifier et quantifier clairement les objectifs de temps de récupération (RTO) et les objectifs de point de récupération (RPO) pour votre organisation. Le RTO, le temps nécessaire à la récupération d’un sinistre, et le RPO, les données mesurées dans le temps que vous pouvez perdre à la suite d’un même sinistre, sont des métriques clés pour la planification de la récupération d’urgence. Ces deux métriques pilotées par l’entreprise préparent le terrain pour les éléments suivants :

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

Bien que l’étendue de cet article soit la récupération d’urgence pour la recherche SharePoint Server, nous vous recommandons de lire Choisir une stratégie de récupération d’urgence pour SharePoint Server en préparation au développement d’une stratégie de récupération d’urgence.

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 la recherche SharePoint Server et de la façon dont ils contribuent à l’expérience de recherche de l’utilisateur final. Les composants et les bases de données de l'application de recherche décrits dans le tableau ci-dessous fournissent le contexte d'une stratégie de récupération d'urgence.

Composants du service de recherche

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

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

Pour évaluer la complexité de l’élaboration d’une stratégie de recherche de récupération d’urgence, vous devez comprendre le mode de référencement des documents dans l’index et les bases de données de l’application Service de recherche. C’est ce système de référencement qui rend actuellement impossible l’utilisation de toute forme de technologie de réplication ou de copie des journaux de transaction pour copier les index de recherche entre des batteries de serveurs 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 récupération d’urgence cible est correctement mise à l’échelle avec le nombre approprié de composants pour prendre en charge 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 façons de vous assurer que vous aviez une application Service de recherche à basculement remplie d’index à jour et de près de 100 % d’actualisation de la recherche. Les exemples suivants illustrent les approches généralement utilisées pour la récupération d'urgence.

• L’analyse des bases de données de contenu en lecture seule était une option, où SQL Server méthodes de copie des journaux de transaction ont été utilisées pour conserver une copie des bases de données de contenu de production attachées à la batterie de serveurs de récupération d’urgence en mode lecture seule. Cela signifie qu’une SSA hébergée sur la batterie de serveurs de récupération d’urgence peut être configurée pour analyser les bases de données via une application web en lecture seule sur la batterie de serveurs de récupération d’urgence. Toutes les modifications de configuration devaient être implémentées au niveau SSA sur les deux batteries pour garantir une expérience de fidélité totale pour les utilisateurs finaux 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 la recherche SSA est sauvegardée indépendamment à l’aide d’approches de sauvegarde SQL Server conventionnelles et utilisée sur la batterie de serveurs de récupération d’urgence pour créer une SSA à 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 SSA sont effectuées à l’aide de Microsoft PowerShell ou de l’interface du 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.

À compter de SharePoint Server 2013, les modifications importantes apportées à l’architecture de recherche et à la façon dont les éléments de configuration sont stockés signifient que nous devons envisager différemment la récupération d’urgence de la recherche. Les sections suivantes décrivent ces modifications et leur impact sur les choix de récupération d’urgence disponibles.

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

Les pages Administration de site dans SharePoint Server fournissent des options qui prennent en charge une configuration flexible de l’expérience de recherche. Les nouvelles options de configuration pour les sites et les collections de sites signifient que les administrateurs de site peuvent apporter des modifications de configuration de recherche qui auparavant ne pouvaient être effectuées que par des administrateurs de batterie 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 Recherche.

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é de recherche SharePoint Server est la fonctionnalité Réindexer maintenant qui permet aux administrateurs aux niveaux Collection de sites, Web et List de demander une réindexation du conteneur lors de l’analyse suivante. Cette fonctionnalité est entièrement gérée dans la base de données de contenu, et un administrateur effectuant cette demande dans la batterie de récupération d’urgence déclenchera donc le même événement dans la batterie de production lors de l’exécution de la prochaine analyse sur la batterie de récupération d’urgence.

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

Dans la recherche SharePoint Server, le traitement des analyses de recherche et d’utilisation est géré par un composant appelé processeur Analytics. Ce composant est chargé des opérations 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 d’analyse individuels, voir Vue d’ensemble du traitement analytique 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 répond à toutes les exigences en matière de récupération d'urgence pour la capture des données de configuration et d'index est la sauvegarde et la restauration de l'application de service. Des investissements significatifs ont été réalisés dans ces opérations afin de réduire les objectifs RTO et RPO par rapport aux versions antérieures de SharePoint. La prise en charge de la modification du nombre de threads utilisés lors des processus de sauvegarde et de restauration, ainsi que les améliorations en matière de prise en charge des opérations de sauvegarde et de restauration complètes et différentielles sont toutes des victoires importantes de ce domaine.

Lorsque vous adoptez l’approche d’une sauvegarde et d’une restauration d’application service Search complètes comme stratégie de récupération d’urgence, le RPO global est régi par deux choses. Le temps écoulé depuis la dernière sauvegarde d’application de service complet correspond au RPO, et le temps nécessaire pour effectuer réellement une restauration d’application de service est le RTO. Ces deux périodes sont susceptibles d’augmenter en durée à mesure que le contenu indexé dans l’application service Search augmente, de sorte qu’une gestion minutieuse de l’attente de restauration du service en cas de déclaration de sinistre est nécessaire. Nous vous recommandons d’effectuer des restaurations de test fréquentes dans le cadre de vos exercices de gestion de la continuité de service pour vous assurer que tout contrat SLA par rapport au RTO et au RPO requis peut toujours être respecté. Le tableau suivant récapitule les options de sauvegarde et de restauration de l’application service Search.

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. À l’aide de Microsoft PowerShell, les administrateurs peuvent créer une application service Search à 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, SharePoint prend en charge un RPO et un RTO d’une semaine pour l’application de 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 sont un bref résumé des points clés contenus dans les articles Sauvegarde de recherche et Restauration :

• Sauvegarder les applications Service de recherche dans SharePoint Server

• Restaurer des applications de service de recherche dans SharePoint Server

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 de 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 montre comment effectuer une sauvegarde complète de l’application service Search nommée Contoso Search Service Application et stocker les fichiers de sauvegarde à l’emplacement \server\searchbackup.

Vous pouvez afficher l’état général de tous les travaux de sauvegarde en haut de la page État des opérations de sauvegarde et de restauration, dans la section Disponibilité. Vous pouvez afficher l’état du travail de sauvegarde en cours dans la partie inférieure de la page, dans la section Sauvegarde. La page d'état se met à jour automatiquement toutes les 30 secondes. Vous pouvez mettre à jour manuellement les détails de l'état en cliquant sur Actualiser. La sauvegarde et la récupération sont des travaux du service du minuteur. Par conséquent, le démarrage de la sauvegarde peut prendre plusieurs secondes. Si des messages d'erreur s'affichent, vous pouvez les consulter dans la colonne Message d'échec de la page État des opérations de sauvegarde et de restauration. Vous trouverez également des détails supplémentaires dans le fichier Spbackup.log situé au chemin d’accès UNC que vous avez indiqué pour le stockage du fichier de sauvegarde.

Restauration de l’application Service de recherche

Pour restaurer une application SharePoint Server service Search, la sauvegarde doit s’être terminée correctement et, si des sauvegardes sont effectuées fréquemment, l’ID de la sauvegarde spécifique à restaurer est nécessaire. Cet ID peut être facilement obtenu de plusieurs manières. La plus simple est d’ouvrir la page Historique de sauvegarde et de restauration sur la batterie de production où la sauvegarde a été effectuée et d’accéder à l’Emplacement de l’historique de sauvegarde. Vous obtenez alors la liste de toutes les entrées du fichier manifeste (psbrtoc.xml) de la sauvegarde et de la restauration. Dans la capture d’écran suivante, un ID de sauvegarde {149fc816-8927-4a32-9437-6e05c2869ab7} est facilement visible.

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 l’applet Get-SPBackupHistory de commande, 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 à l’aide de l’applet de Restore-SPFarm commande .

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"

Le RestoreMethod que vous utilisez détermine la façon dont le processus se déroule après l’exécution de l’applet de Restore-SPFarm commande.

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.

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 d’urgence 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 des bases de données en lecture seule dans la batterie de récupération d'urgence s'avère être le choix le plus judicieux, vous devez prendre en considération le fait que les modifications effectuées dans la batterie de production ne seront pas répliquées sur la batterie de récupération. Comme nous l'avons mentionné, cela inclut les mises à jour des analyses de service de recherche sur l'index, ainsi que les modifications apportées aux éléments de configuration, tels que les origines des résultats, les règles de requête et les 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 appropriée. Actuellement, il n’existe aucun moyen de parer à la perte des mises à jour d’analyse, mais des mesures peuvent être prises afin de contourner les modifications de configuration mises à jour. Vous pouvez essayer de prendre des mesures semblables à celles des 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 exportera les éléments de configuration à partir du site «http://intranet.contoso.com" ; à 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

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’exportation/importation de configuration de recherche qui prend en charge vos besoins en matière de solution de récupération d’urgence 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 surmonter ce problème, il est important d’exécuter régulièrement la commande PowerShell suivante qui actualise le plan de site sur la batterie de serveurs 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()}

En analysant les bases de données en lecture seule et en mettant à jour le plan de site régulièrement, une actualisation d’index élevée peut être maintenue dans la batterie de récupération d’urgence. La deuxième étape de l’approche combinée est ce qu’il faut faire avec les sauvegardes d’application service Search. Les deux options réellement disponibles sont indiquées dans la liste ci-dessous, mais il convient de souligner que l’option sélectionnée dépendra 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 clairement plus complexe qu’une simple sauvegarde et restauration, mais les avantages l’emportent sur les défis si l’entreprise a besoin de répondre aux exigences pour implémenter une telle solution.

Ressources supplémentaires

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

• Sauvegarder les applications Service de recherche dans SharePoint Server

• Restaurer des applications de service de recherche dans SharePoint Server

Outre les options fournies dans ces articles et dans ce document, il existe d’autres méthodes que vous pouvez utiliser pour sauvegarder et restaurer l’application de service de recherche dans SharePoint Server. Il s'agit de méthodes de granularité fine qui impliquent de restaurer indépendamment les index de recherche et les bases de données de recherche sur une nouvelle batterie de serveurs. Nous n'avons pas abordé ces étapes, mais si vous envisagez d'adopter une approche à base de script, nous vous recommandons de commencer par examiner les ressources suivantes.

• Get-SPEnterpriseSearchServiceApplicationBackupStore

• Restore-SPEnterpriseSearchServiceApplication

• Restore-SPEnterpriseSearchServiceApplicationIndex

• Sauvegardez et restaurez une application de service de recherche dans SharePoint 2013 à l’aide de VSS.