Planifier la sauvegarde et la récupération dans SharePoint Server 2010

S’applique à : SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

Cet article décrit les différentes étapes du processus de planification de la sauvegarde et de la récupération, qui inclut la détermination des stratégies de sauvegarde et de récupération pour un environnement Microsoft SharePoint Server et le choix des outils à utiliser. Il n’est pas nécessaire d’exécuter les étapes dans l’ordre indiqué, et le processus peut être itératif.

Lorsque vous planifiez l’utilisation de la sauvegarde et de la récupération pour la récupération d’urgence, prenez en compte les événements, les échecs et les erreurs courants ; les urgences locales ; et les urgences régionales.

Pour plus d’informations sur la sauvegarde et la restauration de Microsoft SharePoint Server, voir Vue d’ensemble de la sauvegarde et de la récupération (SharePoint Server 2010).

Dans cet article :

• Définir les impératifs de l'entreprise

• Choisir quoi protéger et quoi récupérer au sein de votre environnement

• Choisir les outils de sauvegarde et de récupération SharePoint

• Déterminer les stratégies

• Planifier l'amélioration de la sauvegarde et de la récupération

Définir les impératifs de l’entreprise pour les batteries de serveurs et services SharePoint

Pour définir les impératifs de l’entreprise, déterminez ce qui suit pour chaque batterie de serveurs et service de l’environnement :

• L’objectif de point de récupération (RPO, Recovery Point Objective) est l’objectif en termes de durée maximale entre la dernière sauvegarde disponible et un point de défaillance potentielle quelconque. Il est déterminé par le volume de données que l’entreprise peut se permettre de perdre en cas de panne.

• L’objectif de temps de récupération (RTO, Recovery Time Objective) est l’objectif en termes de durée maximale que prendra un processus de récupération de données. Il est déterminé par le délai d’indisponibilité que l’entreprise peut accepter pour le site ou le service.

• L’objectif de niveau de récupération (RLO, Recovery Level Objective) est l’objectif qui définit la granularité avec laquelle vous devez pouvoir récupérer des données, c’est-à-dire si vous devez pouvoir récupérer l’intégralité de la batterie de serveurs, de l’application Web, de la collection de sites, du site, de la liste ou de la bibliothèque, ou encore de l’élément.

Des objectifs RPO et RTO plus courts, et une plus fine granularité de l’objectif RLO, sont généralement plus coûteux.

Une feuille de calcul pour vous aider à planifier vos stratégies de sauvegarde et de restauration pour votre environnement SharePoint Server 2010 peut être téléchargée à partir de la page Classeur de planification de sauvegarde et de restauration des produits SharePoint 2010 (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=184385&clcid=0x40C) (éventuellement en anglais).

Choisir quoi protéger et quoi récupérer dans votre environnement SharePoint

Vos impératifs d’entreprise vous aideront à déterminer les composants de votre environnement que vous devez protéger, et la granularité nécessaire pour pouvoir les récupérer.

Le tableau suivant répertorie les composants d’un environnement SharePoint que vous pourriez choisir de protéger, et les outils que vous pouvez utiliser pour sauvegarder et récupérer chaque composant.

1La sauvegarde et la restauration au niveau de la batterie de serveurs et de la base de données peuvent être utilisées pour la récupération de la collection de sites si une seule collection de sites est stockée dans une base de données.

2Les sauvegardes au niveau de la batterie et de la base de données peuvent être utilisées avec la récupération de base de données non attachée à SharePoint Server pour restaurer des collections de sites, des sites, des éléments et des configurations.

3Le contenu stocké dans des magasins d’objets blob distants ne peut pas être restauré à l’aide de DPM.

4Les modifications apportées à Web.config peuvent être sauvegardées en utilisant la sauvegarde du système de fichiers à partir de DPM 2010.

5Les configurations IIS peuvent être récupérées par le biais d’une sauvegarde complète à partir de DPM 2010.

6DPM 2010 peut récupérer cet élément à l’aide d’une combinaison de sauvegarde complète et de sauvegarde SharePoint Server. Il ne peut pas être sauvegardé et récupéré comme un objet.

7Les packages de solutions entièrement fiables sont stockés dans la base de données de configuration, et les solutions en bac à sable (sandbox) sont stockées dans les bases de données de contenu. Ils peuvent être récupérés dans le cadre d’une récupération de base de données de contenu ou de batterie.

8Les paramètres de configuration peuvent être récupérés à partir de sauvegardes au niveau de la batterie. Pour plus d’informations, voir Restaurer une batterie de serveurs (SharePoint Foundation 2010)Restaurer une batterie de serveurs (SharePoint Server 2010).

9La base de données de contenu Administration centrale et la base de données de configuration pour une batterie SharePoint Server 2010 peuvent être récupérées, mais uniquement dans le cadre d’une récupération de batterie complète dans la même batterie, avec les mêmes ordinateurs.

Choisir quoi récupérer à partir des bases de données de contenu SharePoint

À partir d’une base de données de contenu, vous pouvez récupérer des collections de sites, des sites, des listes et des bibliothèques.

Les outils de sauvegarde et de récupération offrent des niveaux différents de récupération du contenu dans une base de données de contenu. La récupération d’un objet dans une base de données de contenu est toujours plus complexe que la récupération de la totalité de la base de données de contenu.

Protection des personnalisations

Les personnalisations sur les sites SharePoint peuvent être les suivantes :

• Les pages maîtres, les mises en page et les feuilles de style en cascade. Ces objets sont stockés dans la base de données de contenu pour une application Web.

• Les composants WebPart, les définitions de site ou liste, les colonnes personnalisées, de nouveaux types de contenu, les champs personnalisés, les actions personnalisées, les flux de travail codés, ou les activités et conditions de flux de travail.

• Les solutions tierces et les fichiers binaires associés et les clés de Registre, par exemple IFilters.

• Les modifications des fichiers XML standard.

• Les définitions de site personnalisé (Webtemp.xml).

• Modifications apportées au fichier Web.config.

La façon dont les personnalisations sont déployées et les modifications sont effectuées dans le fichier Web.config a un impact significatif sur les outils utilisables pour sauvegarder et récupérer les personnalisations. Pour laisser le maximum de chances à la récupération, nous vous recommandons de déployer les personnalisations en utilisant des packages de solutions et de configurer le fichier Web.config à l’aide de l’Administration centrale ou d’un modèle objet et d’API SharePoint.

Protection des flux de travail

Les flux de travail constituent un cas particulier de personnalisation que vous pouvez sauvegarder et restaurer. Assurez-vous que votre plan de sauvegarde et de récupération gère les scénarios suivants qui s’appliquent à votre environnement :

• Les flux de travail déclaratifs, tels que ceux que vous avez créés dans Microsoft SharePoint Designer 2010, sont stockés dans la base de données de contenu de la collection de sites sur laquelle ils sont déployés. La sauvegarde de la base de données de contenu protège ces flux de travail.

• Les actions de flux de travail déclaratifs personnalisés ont des composants aux trois emplacements suivants :

  1. Les assemblys Visual Studio pour les activités sont stockés dans le Global Assembly Cache.

  2. Les fichiers de définition XML (fichiers .ACTIONS) sont stockés dans le répertoire 14\TEMPLATE\{LCID}\Workflow.

  3. Une entrée XML marquant l’activité comme type autorisé est stockée dans le fichier web.config des applications Web dans lesquelles elle est utilisée.

  Si vos flux de travail de batterie utilisent des actions personnalisées, vous devez recourir à un système de sauvegarde de fichiers pour protéger ces fichiers et les entrées XML. S’apparentant à des fonctionnalités SharePoint Server telles que les composants WebPart et les récepteurs d’événements, ces fichiers doivent être réappliqués à la batterie selon les besoins après la récupération.

• Les flux de travail qui dépendent de code personnalisé, tels que ceux créés à l’aide de Visual Studio, sont stockés à deux emplacements. Les assemblys Visual Studio pour le flux de travail sont stockés dans le Global Assembly Cache et les fichiers de définition XML sont stockés dans le répertoire Features. Ceci est identique à d’autres types de fonctionnalités SharePoint Server telles que les composants WebPart et les récepteurs d’événements. Si le flux de travail a été installé dans le cadre d’un package de solution, la sauvegarde de la base de données de contenu protège ces flux de travail.

• Si vous créez un flux de travail personnalisé qui interagit avec une collection de sites autre que celle dans laquelle le flux de travail est déployé, vous devez sauvegarder les deux collections de sites afin de protéger le flux de travail. Cela comprend les flux de travail qui écrivent dans un historique ou autre liste personnalisée dans une autre collection de sites. Une sauvegarde de batterie suffit à sauvegarder toutes les collections de site de la batterie et tous les flux de travail qui y sont associés.

• Les flux de travail qui ne sont pas encore déployés doivent être sauvegardés et restaurés séparément, comme tout autre fichier de données. Lorsque vous développez un nouveau flux de travail et que vous ne l’avez pas encore déployé dans la batterie SharePoint Server, assurez-vous de sauvegarder le dossier dans lequel vous stockez vos fichiers de projet de flux de travail à l’aide de Sauvegarde Windows ou d’une autre application de sauvegarde de système de fichiers.

Protection des applications de services

Les applications de services dans un environnement SharePoint Server peuvent être composées de paramètres de services et, éventuellement, d’une ou plusieurs bases de données. Vous ne pouvez pas restaurer une application de service complète en restaurant la base de données uniquement. Toutefois, vous pouvez restaurer les bases de données pour une application de service, puis déployer celle-ci. Pour plus d’informations, voir Restaurer une application de service (SharePoint Server 2010).

Protection des bases de données SQL Server Reporting Services

La sauvegarde et la restauration SharePoint Server n’incluent pas les bases de données SQL Server Reporting Services. Vous devez utiliser les outils SQL Server. Pour plus d’informations, voir Opérations de sauvegarde et de restauration pour une installation Reporting Services (https://go.microsoft.com/fwlink/?linkid=186642&clcid=0x40C).

Choisir les outils de sauvegarde et de récupération SharePoint

Pour sélectionner les outils appropriés pour la sauvegarde et la récupération, vous devez déterminer si vous pouvez respecter les impératifs de continuité que vous avez définis pour votre entreprise dans le cadre de votre budget et de vos ressources.

Les éléments clés à prendre en considération lors de la sélection des outils incluent ce qui suit :

• Rapidité de la sauvegarde : l’outil peut-il s’exécuter pendant la période de maintenance de vos bases de données ? Vous devez tester tout système de sauvegarde afin de vous assurer qu’il répond à vos exigences sur votre matériel.

• Intégralité de la récupération.

• Granularité des objets récupérables.

• Type de la sauvegarde prise en charge (complète, différentielle ou incrémentielle).

• Complexité de la gestion de l’outil.

Le tableau suivant compare le type de sauvegarde et la taille de batterie pouvant être sauvegardée en l’espace de 6 heures avec les outils de sauvegarde et de récupération disponibles auprès de Microsoft.

1La taille de la sauvegarde a été déterminée par la sauvegarde d’un système qui totalise la taille spécifiée sur le matériel de test répertorié dans la section suivante.

Matériel de test

Le tableau suivant répertorie les composants matériels utilisés dans les tests qui déterminent la taille de la sauvegarde pouvant être réalisée en l’espace de six heures.

Pour plus d’informations sur les systèmes de sauvegarde et de restauration qui peuvent être utilisés avec Microsoft SharePoint Server, voir les ressources suivantes :

• Vue d’ensemble de la sauvegarde et de la récupération (SharePoint Server 2010)

• Sauvegarde et restauration de bases de données dans SQL Server (https://go.microsoft.com/fwlink/?linkid=186643&clcid=0x40C)

• Vue d’ensemble de Data Protection Manager 2010 (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=186655&clcid=0x40C) (éventuellement en anglais).

Déterminer les stratégies de sauvegarde et de récupération de SharePoint

Sur la base de vos impératifs d’entreprise, des besoins de récupération et des outils que vous avez sélectionnés, déterminez et documentez les stratégies de sauvegarde et de récupération de votre environnement.

Il est courant pour les départements informatiques qui prennent en charge les environnements SharePoint Server de décider d’utiliser plusieurs outils pour protéger l’environnement, quand ils déterminent les stratégies à utiliser.

Par exemple, dans un environnement comprenant des bases de données gérées par des administrateurs de bases de données, il est possible d’appliquer les stratégies de la liste suivante :

• Toutes les bases de données sont sauvegardées par SQL Server. L’intervalle de sauvegarde est défini selon les facteurs suivants :

  • L’importance du contenu ou service.

  • L’impact en termes de performances de la sauvegarde sur l’environnement.

• Les bases de données de contenu à évolution rapide et ayant un très fort impact professionnel sont en plus protégées par les captures instantanées de bases de données SQL Server qui sont stockées sur un disque physique distinct. Une seule capture instantanée est stockée par base de données, et les captures instantanées sont supprimées régulièrement, afin que l’effet sur les performances soit limité. L’intervalle de capture instantanée est défini pour chaque base de données selon :

  • L’importance du contenu ou service.

  • La fréquence de changement standard de la base de données.

  • L’impact en termes de performances de la capture instantanée sur l’environnement.

  • La quantité d’espace requise pour stocker la capture instantanée.

  La récupération à partir d’une capture instantanée est plus rapide qu’une récupération standard, car une capture instantanée et sa base de données sous-jacente peuvent être traitées par SharePoint Server comme une base de données non attachée. Toutefois, la création de captures instantanées peut entraîner une dégradation des performances de la base de données sous-jacente. Nous vous recommandons de tester l’impact des captures instantanées sur les performances du système avant de les implémenter, et de supprimer régulièrement les captures instantanées afin de réduire la quantité d’espace requise.

  Notes

  Si vous utilisez RBS et que le fournisseur RBS que vous utilisez ne prend pas en charge les captures instantanées, vous ne pouvez pas utiliser de captures instantanées pour la sauvegarde. Par exemple, le fournisseur FILESTREAM ne prend pas en charge les captures instantanées.

• La sauvegarde SharePoint Server permet de protéger les applications de service. L’intervalle de sauvegarde dépend des facteurs suivants :

  • L’importance du service.

  • La fréquence de changement standard de la base de données.

  • L’impact en termes de performances de la sauvegarde sur la base de données.

• Toutes les opérations de restauration sont effectuées via SharePoint Server. Le choix du système de restauration à utiliser est déterminé par le type de sauvegarde disponible et de l’objet restauré.

D’autres outils devraient faire partie de votre stratégie de continuité des activités de l’entreprise. Examinez la façon dont vous utiliserez les Corbeilles et la gestion des versions dans les collections de sites dans tout l’environnement. Pour plus d’informations, voir Planifier la gestion de la continuité des opérations (SharePoint Server 2010).

Planifier les performances lors de la conception de votre stratégie de sauvegarde et de récupération SharePoint

Lorsque vous planifiez votre stratégie de sauvegarde et de récupération, tenez compte des recommandations suivantes pour réduire l’effet de la sauvegarde et de la récupération sur les performances du système.

De par leur nature, la plupart des opérations de sauvegarde consomment autant de ressources d’E/S que possible pour terminer la tâche dans le temps disponible à des fins de maintenance. Par conséquent, il se peut que vous constatiez une mise en file d’attente sur le disque et un retour de toutes les demandes d’E/S plus lent que d’habitude. Ceci est normal et ne doit pas être considéré comme un problème.

Suivre les recommandations de configuration de SQL Server et du stockage

Suivez les recommandations générales relatives à la configuration de SQL Server et au stockage pour un environnement SharePoint Server. Pour plus d’informations, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010).

Réduire la latence entre SQL Server et l’emplacement de sauvegarde

En général, il est préférable d’utiliser un disque local, et non un lecteur réseau, pour les sauvegardes. Si vous sauvegardez plusieurs serveurs, vous pouvez recourir à un ordinateur directement connecté accessible en écriture par les deux serveurs. Les lecteurs réseau présentant une latence inférieure ou égale à 1 milliseconde entre eux-mêmes et les ordinateurs qui exécutent SQL Server se prêtent à ce dispositif. Si votre batterie comprend plusieurs serveurs (notamment l’ordinateur exécutant SQL Server), vous devez utiliser les chemins d’accès réseau UNC pour l’emplacement de sauvegarde de la batterie SharePoint.

Éviter les conflits de traitement

N’exécutez pas d’opérations de sauvegarde pendant les périodes au cours desquelles les utilisateurs doivent avoir accès au système.

Pour éviter les goulots d’étranglement d’E/S, effectuez dans un premier temps la sauvegarde principale sur un disque distinct, puis réalisez une copie sur bande.

Envisagez des sauvegardes échelonnées afin que toutes les bases de données ne soient pas sauvegardées en même temps.

Les sauvegardes SharePoint Server utilisent des sauvegardes SQL Server. Lorsque vous utilisez la compression avec vos sauvegardes, veillez à ne pas surcharger SQL Server. Par exemple, certains outils de sauvegarde tiers compressent les données pendant la sauvegarde, ce qui peut gêner les performances de SQL Server. Il existe des outils permettant de limiter les processus de compression et de contrôler l’impact sur SQL Server.

Suivre les recommandations permettant d’optimiser les sauvegardes et les restaurations SQL Server

Si vous exécutez SQL Server 2008 Enterprise, nous vous recommandons d’utiliser la compression de sauvegarde. Pour plus d’informations, voir Compression de sauvegardes (SQL Server) (https://go.microsoft.com/fwlink/?linkid=179525&clcid=0x40C).

Si vous utilisez des sauvegardes SQL Server, afin de réduire au minimum le temps de récupération, combinez des sauvegardes complètes, différentielles et des sauvegardes du journal des transactions pour le mode de récupération complète. Les sauvegardes différentielles de la base de données sont généralement plus rapides à créer que les sauvegardes complètes et réduisent la quantité de journal des transactions requise pour la récupération de la base de données.

Si vous utilisez le mode de récupération complète dans SQL Server 2008, il est recommandé d’utiliser l’option de troncation lors de la sauvegarde pour éviter les problèmes de maintenance.

Pour obtenir des recommandations détaillées sur la façon d’optimiser les performances de sauvegarde et de restauration dans SQL Server, voir Optimisation des performances de sauvegarde et de restauration dans SQL Server (https://go.microsoft.com/fwlink/?linkid=126630&clcid=0x40C).

Garantir des performances d’écriture suffisantes sur le lecteur de sauvegarde

Réfléchissez bien avant de décider s’il faut utiliser un dispositif RAID (Redundant Array of Independent Disks) sur votre unité de sauvegarde sur disque. Par exemple, un dispositif RAID 5 présente des performances d’écriture faibles, avec une vitesse approximativement identique à celle obtenue dans le cas d’un seul disque. (En effet, le niveau RAID 5 gère les informations de parité.) L’utilisation d’un dispositif RAID 10 pour une unité de sauvegarde peut procurer des sauvegardes plus rapides. Pour plus d’informations sur la façon d’utiliser la technologie RAID dans le cadre des sauvegardes, voir Configurer RAID afin d’optimiser les opérations d’écriture et de lecture SQL Server (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=126632&clcid=0x40C) (éventuellement en anglais).

Contenu connexe

See Also

Other Resources

Centre de ressources : conception de l’architecture de SharePoint Server 2010 (éventuellement en anglais)