Meilleures pratiques pour la sauvegarde et la récupération (SharePoint Server 2010)

S’applique à : SharePoint Foundation 2010, SharePoint Server 2010

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

Cet article décrit les meilleures pratiques qui vous permettent de mener à bien des opérations de sauvegarde et de récupération dans Microsoft SharePoint Server 2010 et de protéger l’environnement contre les pertes de données ou les interruptions de la continuité des opérations. Les meilleures pratiques présentées dans cet article concernent les performances, l’assurance qualité, la sécurité et le fonctionnement optimal.

Dans cet article :

• Meilleures pratiques pour les performances

• Meilleures pratiques pour l’assurance qualité

• Meilleures pratiques pour les procédures

Meilleures pratiques pour les performances

Les opérations de sauvegarde et de restauration peuvent consommer des ressources des serveurs et limiter les performances de ceux-ci pendant qu’elles sont en cours d’exécution. En suivant ces meilleures pratiques, vous pouvez réduire l’utilisation des ressources et augmenter les performances des serveurs et de l’opération de sauvegarde ou de restauration.

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

En général, il est conseillé d’utiliser un disque local sur le serveur de bases de données, pas un lecteur réseau, pour les sauvegardes, puis de copier les données sur un dossier partagé sur le réseau. Les lecteurs réseau présentant une latence inférieure ou égale à 1 milliseconde entre eux-mêmes et le serveur de bases de données se prêtent à ce dispositif.

Pour éviter les goulots d’étranglement d’E/S, effectuez la sauvegarde principale sur un disque distinct du disque exécutant SQL Server 2008 avec SP1 et mise à jour cumulative 2.

De par leur nature, la plupart des travaux de sauvegarde consomment toutes les ressources d’E/S disponibles. Par conséquent, il se peut que vous constatiez une mise en file d’attente sur le disque, avec à la clé une latence des requêtes d’E/S supérieure à la normale. Cela est typique et ne doit pas être considéré comme un problème.

Éviter les conflits de traitement

N’exécutez pas d’opérations de sauvegarde pendant les périodes au cours desquelles les utilisateurs ont besoin d’accéder au système. Envisagez des sauvegardes échelonnées afin que toutes les bases de données ne soient pas sauvegardées en même temps.

Limiter la taille des bases de données pour réduire le temps nécessaire à la récupération

Limitez la taille des bases de données pour accélérer la sauvegarde et la récupération. Pour ce faire, vous pouvez utiliser plusieurs bases de données de contenu pour une application Web au lieu d’une seule base de données de contenu volumineuse.

Utiliser des sauvegardes incrémentielles pour les bases de données volumineuses

Utilisez des sauvegardes incrémentielles pour une base de données volumineuse, telles que celles disponibles avec DPM 2010. Les sauvegardes incrémentielles peuvent être restaurées plus rapidement et plus efficacement que les sauvegardes complètes pour les bases de données plus volumineuses. Pour plus d’informations sur les types de sauvegarde, voir Vue d’ensemble de la sauvegarde (SQL Server) (https://go.microsoft.com/fwlink/?linkid=203863&clcid=0x40C).

Utiliser la compression pendant la sauvegarde

Dans certaines circonstances, vous pouvez utiliser la compression pour réduire la taille des sauvegardes (30 %) et leurs durées (25 %). La compression de la sauvegarde a été introduite dans SQL Server 2008 Enterprise. Pour plus d’informations sur l’impact de la compression des sauvegardes sur les performances dans SQL Server, voir Compression de sauvegardes (SQL Server) (https://go.microsoft.com/fwlink/?linkid=129381&clcid=0x40C).

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

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 du journal des transactions (pour le mode de récupération complète ou utilisant les journaux de transactions). 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é du 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, il est recommandé de tronquer régulièrement les fichiers journaux de transactions pour éviter les problèmes de maintenance.

Pour obtenir des recommandations détaillées sur l’optimisation des 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).

Utiliser un dispositif RAID 10 si le recours à la technologie RAID est envisagé

Réfléchissez bien avant de décider s’il faut utiliser un dispositif RAID (Redundant Array of Independent Disks) sur l’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 doit gérer 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).

Configurer les paramètres SharePoint afin d’améliorer les performances de sauvegarde ou de restauration

Vous pouvez configurer les paramètres de l’Administration centrale et de Windows PowerShell de manière à améliorer l’efficacité et les performances des sauvegardes ou des restaurations.

Si vous utilisez l’applet de commande Windows PowerShell Export-SPWeb, vous pouvez recourir au paramètre NoFileCompression. Par défaut, SharePoint Server 2010 utilise la compression de fichier lors de l’exportation des applications Web, de la collection de sites, des listes ou des bibliothèques de documents. Ce paramètre vous permet de désactiver la compression de fichiers lors de l’exportation et de l’importation. La compression de fichier peut utiliser jusqu’à 30 % de ressources supplémentaires, mais le fichier exporté utilise approximativement 25 % d’espace disque en moins. Si vous utilisez le paramètre NoFileCompression lors de l’exportation, vous devez également y recourir lors de l’importation du même contenu.

Vous pouvez également utiliser le paramètre NoLogFile. Par défaut, SharePoint Server 2010 crée systématiquement un fichier journal lorsque vous exportez du contenu. Ce paramètre vous permet de désactiver la création du fichier journal afin de limiter la consommation de ressources. Toutefois, il est recommandé de créer des journaux systématiquement. En effet, ceux-ci peuvent s’avérer utiles pour la résolution de problèmes. En outre, la création des journaux n’utilise pas beaucoup de ressources.

Si vous utilisez l’applet de commande Backup-SPFarm, vous pouvez recourir au paramètre BackupThreads pour spécifier le nombre de threads que SharePoint Server 2010 utilisera pendant le processus de sauvegarde. Plus le nombre de threads spécifié est élevé, plus l’opération de sauvegarde consomme de ressources, mais plus vite elle est accomplie, sous réserve que les ressources disponibles soient suffisantes. Toutefois, chaque thread étant mentionné séparément dans les fichiers journaux, l’utilisation d’un nombre réduit de threads facilite l’interprétation des fichiers journaux. Par défaut, trois threads sont utilisés. Le nombre maximal de threads disponibles est 10.

Tenir compte de la taille de la collection de sites lors de la détermination des outils à utiliser

S’il est nécessaire d’effectuer des sauvegardes de la collection de sites, en plus des sauvegardes au niveau de la batterie de serveurs ou au niveau de la base de données, sélectionnez les outils à utiliser en fonction de la taille de la collection de sites.

• Inférieure à 15 gigaoctets (Go) : utilisez la commande Windows PowerShell Backup-SPSite. Pour plus d’informations, voir Sauvegarder une collection de sites (SharePoint Server 2010).

• Comprise entre 15 et 100 Go : utilisez un outil des produits et technologies SharePoint, un outil SQL Server ou un autre outil de sauvegarde de base de données pour protéger la base de données de contenu dans laquelle se trouve la collection de sites. Pour plus d’informations, voir Sauvegarder une collection de sites (SharePoint Server 2010).

• Supérieure à 100 Go : utilisez une solution de sauvegarde différentielle, telle que Microsoft SQL Server 2005 ou DPM 2010, au lieu des outils de sauvegarde et de récupération intégrés.

Meilleures pratiques pour l’assurance qualité

Vous pouvez suivre ces meilleures pratiques pour garantir la qualité des sauvegardes de l’environnement de la batterie de serveurs et réduire les risques de perte de données.

S’assurer que l’espace de stockage est suffisant

Assurez-vous que le système dispose de suffisamment d’espace disque pour prendre en charge la sauvegarde.

Tester régulièrement la qualité de la sauvegarde

Testez régulièrement les sauvegardes et validez leur cohérence. Exécutez des opérations de récupération pratiques pour valider le contenu de la sauvegarde et pour vous assurer que vous pouvez restaurer la totalité de l’environnement. Dans le cas des environnements répartis sur plusieurs zones géographiques, préparez-vous à une récupération d’urgence en configurant une batterie de serveurs distante. Ensuite, vous pouvez restaurer l’environnement à l’aide de la commande d’attachement de base de données pour télécharger une copie de la base de données vers la batterie de serveurs distante et rediriger les utilisateurs. Effectuez régulièrement un essai de récupération de données pour vérifier que les fichiers sont correctement sauvegardés. Un essai de restauration peut révéler des problèmes matériels non détectés lors des vérifications logicielles.

Sauvegarder les journaux de suivi ULS

Les outils SharePoint Server 2010 ne sauvegardent pas les journaux de suivi ULS. Les données de ces journaux peuvent s’avérer utiles pour l’analyse des performances, le dépannage, la surveillance de la conformité aux contrats de niveau de service et pour des raisons légales, réglementaires ou professionnelles. Par conséquent, protégez ces données dans le cadre de la maintenance de routine. Pour plus d’informations sur la sauvegarde des journaux ULS, voir Journaux de sauvegarde ou d’archive (SharePoint Server 2010).

Stocker une copie des fichiers de sauvegarde hors site

Pour prévenir les pertes provoquées par une catastrophe, telle qu’un incendie ou un tremblement de terre, conservez des copies en double des sauvegardes ailleurs que sur les serveurs. Procéder ainsi peut vous éviter la perte de données critiques. Une pratique recommandée est de conserver trois copies du support de sauvegarde et de conserver au moins une copie hors site dans un environnement contrôlé. Cela doit inclure la totalité des supports et documents de sauvegarde et de récupération, des sauvegardes des journaux de base de données et de transactions et des sauvegardes des journaux d’utilisation et de suivi.

Meilleures pratiques pour les procédures

Vous pouvez utiliser ces meilleures pratiques pour planifier et réaliser les opérations de sauvegarde et de restauration avec une meilleure documentation, davantage d’aisance et une plus grande assurance.

Utiliser des noms de serveur complets (FQDN)

Lorsque vous faites référence à des serveurs dans un autre domaine, utilisez systématiquement des noms de domaine complets (FQDN).

Garder une trace précise des informations

Lorsque vous déployez SharePoint Server 2010, notez les comptes que vous créez, ainsi que les noms d’ordinateurs, les mots de passe et les options de configuration retenues. Conservez ces informations en lieu sûr.

Configurer un environnement de récupération opérationnel

Préparez le test de la restauration et une récupération d’urgence en configurant une batterie de serveurs distante. Ensuite, vous pouvez restaurer l’environnement à l’aide de la commande d’attachement de base de données pour télécharger une copie de la base de données vers la batterie de serveurs distante et rediriger les utilisateurs. De même, vous pouvez configurer un environnement de secours exécutant la même version du logiciel que l’environnement de production afin de restaurer les bases de données et de récupérer les documents rapidement.

Planifier les opérations de sauvegarde

Si vous voulez planifier des sauvegardes, vous pouvez utiliser le Planificateur de tâches de Windows pour les exécuter à l’aide d’un fichier de script Windows PowerShell (*.ps1).

Utiliser le fournisseur SQL FILESTREAM avec un stockage BLOB

Si vous utilisez un stockage BLOB à l’aide du fournisseur SQL FILESTREAM et que vous sauvegardez la base de données de contenu alors que ce magasin d’objets blob distant est défini, ce dernier et la base de données de contenu sont sauvegardés et restaurés lorsque vous utilisez des outils SharePoint ou des outils SQL Server. Il est déconseillé d’utiliser le magasin d’objets blob distant avec d’autres méthodes de restauration.