Meilleures pratiques de sauvegarde et de restauration dans SharePoint Server

S’APPLIQUE À :2013 2016 2019 Édition d’abonnement SharePoint dans Microsoft 365

Les meilleures pratiques pour la sauvegarde et la restauration permettent de s'assurer que les opérations de sauvegarde et de restauration dans SharePoint Server ont réussi et que l'environnement est protégé contre la perte de données ou les failles de continuité.

Meilleures pratiques de performances pour les opérations de sauvegarde et de restauration SharePoint

Les opérations de sauvegarde et de restauration consomment des ressources serveur et limitent les performances pendant l’exécution des opérations. Respectez ces pratiques recommandées pour réduire l'utilisation des ressources et améliorer les performances des serveurs et de la tâche de sauvegarde ou de restauration.

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

En règle générale, il est plus efficace d'effectuer une sauvegarde sur un disque local sur le serveur de base de données plutôt que sur un lecteur réseau. Vous pourrez ensuite copier les données ultérieurement dans un dossier partagé sur le réseau. Les lecteurs réseau avec une latence entre eux et le serveur de base de données inférieure ou égale à 1 milliseconde fonctionnent bien.

Pour éviter les goulots d’étranglement d’E/S, effectuez la sauvegarde principale sur un disque distinct du disque exécutant SQL Server 2017 RTM, 2016, 2014, 2012 ou 2008 R2 avec Service Pack 1 (SP1). Pour plus d'informations, reportez-vous à l'article Définir une unité de sauvegarde logique pour un fichier de disque (SQL Server).

En raison de leur conception, la plupart des travaux de sauvegarde utilisent toutes les ressources d'E/S disponibles. Vous pouvez ainsi assister à une mise en file d'attente sur le disque, ce qui peut entraîner une latence plus élevée que d'habitude pour les demandes d'E/S. Cela est normal et ne doit pas être considéré comme un problème. Pour plus d'informations, voir Surveiller l'utilisation du disque.

Éviter les conflits de traitement

N’exécutez aucun travail de sauvegarde lorsque les utilisateurs ont besoin d’accéder au système. Généralement, les systèmes fonctionnent 24 heures sur 24, 7 jours sur 7. La meilleure pratique consiste à toujours exécuter des sauvegardes incrémentielles pour se protéger des erreurs serveur. Envisagez des sauvegardes échelonnées afin que toutes les bases de données ne soient pas sauvegardées en même temps.

Maintenir des bases de données de petite taille pour optimiser les temps de récupération

Les bases de données doivent rester de petite taille pour accélérer à la fois la sauvegarde et la restauration. Par exemple, utilisez plusieurs bases de données de contenu pour une application Web plutôt qu'une seule base de données volumineuse. Pour plus d'informations, voir Types et descriptions des bases de données dans SharePoint Server.

Pour obtenir une vue d’ensemble graphique des bases de données qui prennent en charge SharePoint Server 2016, voir Guide de référence rapide : Bases de données SharePoint Server 2016 et 2019.

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

Utilisez des sauvegardes incrémentielles pour les bases de données volumineuses car elles sont rapides et maintiennent les performances de l’environnement. Bien que la restauration des sauvegardes complètes puisse être effectuée plus rapidement que pour les sauvegardes complètes, des sauvegardes incrémentielles continues minimisent la perte de données. Pour plus d'informations sur les types de sauvegardes, voir Vue d'ensemble de la sauvegarde (SQL Server).

Utiliser la compression pendant la sauvegarde

Dans certains cas, vous pouvez utiliser la compression pour réduire la taille des sauvegardes et le temps de réalisation de chaque sauvegarde. La compression des sauvegardes a été introduite dans SQL Server 2008 Enterprise. La compression des sauvegardes augmente l'utilisation de l'UC et cela peut avoir des conséquences sur les opérations SQL Server simultanées.

Pour connaître les conséquences de la compression de sauvegardes sur les performances dans SQL Server, reportez-vous à Compression de sauvegardes (SQL Server).

Suivre les recommandations d'optimisation de la sauvegarde et de la restauration SQL Server

Les sauvegardes SQL Server utilisent une combinaison 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) pour minimiser le temps de récupération. 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 le nombre de journaux des transactions requis pour la récupération de la base de données.

Si vous utilisez le mode de récupération complète, nous vous recommandons de tronquer régulièrement les fichiers journaux des transactions 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, reportez-vous à Optimisation des performances de sauvegarde et de restauration dans SQL Server.

Utiliser RAID 10 (si vous utilisez RAID)

Réfléchissez soigneusement à l’utilisation d’un tableau redondant de disques indépendants (RAID) sur l’appareil sur lequel vous sauvegardez les données. Par exemple, RAID 5 a des performances d’écriture lentes, à peu près la même vitesse que pour un seul disque. Cela est dû au fait que RAID 5 doit conserver les informations de parité. RAID 10 peut fournir des sauvegardes plus rapides, car il n’a pas besoin de gérer la parité. Par conséquent, il lit et écrit les données plus rapidement. Pour plus d’informations sur l’utilisation de RAID avec des sauvegardes, consultez Configurer RAID pour un débit d’E/S maximal SQL Server et niveaux RAID et SQL Server.

Configurer les paramètres SharePoint pour améliorer les performances de sauvegarde ou de restauration

Vous ne pouvez configurer que les paramètres de compression des fichiers et de fichiers journaux dans PowerShell. Vous pouvez configurer les threads de sauvegarde et de restauration à la fois dans le le site Web Administration centrale de SharePoint et dans PowerShell pour augmenter l'efficacité et les performances de sauvegarde ou de restauration.

Si vous utilisez l’applet de Export-SPWeb commande PowerShell, vous pouvez utiliser le NoFileCompression paramètre . Par défaut, SharePoint Server utilise la compression des fichiers lors de l'exportation des applications Web, des collections de sites, des listes ou des bibliothèques de documents. Vous pouvez utiliser ce paramètre pour supprimer la compression des fichiers pendant l'exportation et l'importation. La compression des fichiers peut utiliser jusqu'à 30 % de ressources en plus. Toutefois, le fichier exporté utilise environ 25 % d'espace disque en moins. Si vous utilisez le NoFileCompression paramètre lors de l’exportation, vous devez également l’utiliser lorsque vous importez le même contenu.

Vous pouvez également utiliser le NoLogFile paramètre . Par défaut, SharePoint Server crée toujours un fichier journal lorsque vous exportez du contenu. Bien que vous puissiez utiliser ce paramètre pour supprimer la création de fichiers journaux pour économiser des ressources, nous vous recommandons de continuer à créer des journaux. Les journaux sont importants pour le dépannage et leur création n'utilise que peu de ressources telles que l'UC ou la mémoire.

Lorsque vous utilisez l’applet Backup-SPFarm de commande, vous pouvez également utiliser le paramètre pour spécifier le BackupThreads nombre de threads que SharePoint Server utilisera pendant le processus de sauvegarde. Plus le nombre de threads utilisés est élevé, plus la consommation de ressources est grande pendant la sauvegarde. En revanche, l'utilisation d'un plus grand nombre de threads réduit la durée totale de la sauvegarde. Étant donné que chaque thread est enregistré dans les fichiers journaux, le nombre de threads n'a aucun impact sur leur interprétation. Par défaut, trois threads sont utilisés. Le nombre maximal de threads disponibles est de 10.

Prendre en compte la taille des collections de sites lors du choix des outils à utiliser

Si votre activité exige des sauvegardes des collections de sites en plus des sauvegardes au niveau de la batterie de serveurs ou de la base de données, sélectionnez un outil de sauvegarde en fonction de la taille de la collection de sites.

• 15-100 Go : utilisez , Backup-SPSiteun outil SharePoint Server, 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 qui contient la collection de sites. Pour plus d'informations, reportez-vous à Sauvegarder une collection de sites dans SharePoint Server.

• Plus de 100 Go: utilisez une solution de sauvegarde différentielle, telle que SQL Server ou System Center Data Protection Manager R2, plutôt que les outils de sauvegarde et de récupération intégrés.

Meilleures pratiques d’assurance qualité pour sauvegarder une batterie de serveurs SharePoint

Respectez ces meilleures pratiques pour garantir la qualité des sauvegardes de l’environnement de la batterie de serveurs et réduire les probabilités de perte de données.

S’assurer que l’espace de stockage disponible est suffisant

Assurez-vous que l'espace disque du système est suffisant pour contenir la sauvegarde. Configurez un travail de sauvegarde dans l'Administration centrale pour vérifier l'espace disque requis.

Tester la qualité des sauvegardes régulièrement

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 vous assurer que vous pouvez restaurer la totalité de l'environnement. Pour se préparer à la récupération d'urgence d'environnements géographiquement dispersés, configurez une batterie de serveurs distante. Vous pouvez ensuite restaurer l'environnement en utilisant la méthode 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 des données pour vérifier que le processus sauvegarde correctement les fichiers. Un essai de restauration peut révéler des problèmes matériels qui ne surviennent pas lors des vérifications logicielles et permet également de s’assurer que les objectifs de temps de récupération (RTO) sont atteints.

Sauvegarder les journaux de suivi ULS

Le processus de sauvegarde SharePoint Server ne sauvegarde pas les journaux de suivi ULS (Unified Logging Service). Les données contenues dans ces journaux peuvent être utiles pour l'analyse des performances, le dépannage et l'analyse de la conformité aux contrats de niveau de service. Par conséquent, la protection de ces données fait partie de la maintenance de routine.

Par défaut, les fichiers journaux SharePoint se trouvent dans C:\Program files\Common Files\Microsoft Shared\Web Server Extensions\<16 ou 15>\Logs. Le nom des fichiers est composé du nom du serveur suivi de la date et l'horodatage. Les journaux de suivi SharePoint sont créés à intervalles définis et lorsque vous utilisez la commande IISRESET.

Stocker une copie des fichiers de sauvegarde hors site

Pour vous protéger contre les pertes dues à une catastrophe naturelle qui détruirait le centre de données principal, conservez des copies des sauvegardes à des emplacements distincts de ceux des serveurs. Les copies peuvent vous éviter de perdre des données importantes. Dans le cadre des meilleures pratiques, conservez trois copies du support de sauvegarde et au moins une copie hors site dans un environnement contrôlé. Cette copie doit contenir l'intégralité des supports de sauvegarde et de récupération, des documents, des sauvegardes de bases de données et de journaux des transactions et des sauvegardes de journaux de suivi et d'utilisation.

Meilleures pratiques de procédures pour sauvegarder et restaurer SharePoint Server

Utilisez les meilleures pratiques de procédures suivantes pour planifier et effectuer des opérations de sauvegarde et de restauration.

Utiliser des noms de serveurs FQDN

Lorsque vous faites référence aux serveurs d’un autre domaine, utilisez toujours des noms de domaine complets (FQDN).

Conserver des enregistrements précis

Lorsque vous déployez SharePoint Server, notez les comptes que vous créez, les noms des ordinateurs, les mots de passe et les options de configuration. Conservez ces informations dans un endroit sûr. Si possible, conservez plusieurs enregistrements pour vous assurer que ces informations sont toujours disponibles.

Disposer d’un environnement de récupération prêt

Utilisez une batterie de serveurs dans un emplacement secondaire pour valider la réussite des opérations de restauration dans le cadre de votre stratégie de récupération d’urgence. Pour plus d'informations, reportez-vous à Choisir une stratégie de récupération d'urgence pour SharePoint Server. Dans le cas d'une récupération d'urgence, vous pouvez restaurer l'environnement à l'aide de la méthode 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. Pour plus d'informations, consultez et suivez les étapes de la procédure Restaurer des batteries de serveurs dans SharePoint Server. De même, pour une solution de haute disponibilité, vous pouvez configurer un environnement de secours qui exécute la même version de logiciel que l'environnement de production pour que vous puissiez rapidement restaurer les bases de données et récupérer des documents. Pour plus d’informations, reportez-vous à Description de la haute disponibilité.

Planifier des opérations de sauvegarde

Utilisez les applets de commande de sauvegarde et de récupération PowerShell pour créer un fichier de script (*.ps1), puis planifiez son exécution avec le Planificateur de tâches Windows. Vous vous assurez ainsi que toutes les opérations de sauvegarde sont exécutées au meilleur moment, lorsque le système est le moins occupé et que les utilisateurs n'y accèdent pas. Pour plus d'informations, voir les articles suivants :

• Exécution de scripts

• Backup and recovery cmdlets in SharePoint Server 2016

Utiliser le fournisseur SQL FILESTREAM avec le stockage BLOB

Le stockage BLOB distant est pris en charge dans une batterie de serveurs SharePoint Server. L'utilisation du stockage BLOB distant dans SharePoint Server a des avantages et des inconvénients. L'une des limites de l'utilisation du stockage BLOB distant avec une batterie de serveurs SharePoint est que System Center Data Protection Manager ne peut pas utiliser le fournisseur FILESTREAM pour le sauvegarder ou le restaurer. SharePoint Server prend en charge le fournisseur FILESTREAM pour les opérations de sauvegarde et de restauration. L'un des avantages du stockage BLOB distant avec une batterie de serveurs SharePoint est que vous pouvez utiliser soit des outils SharePoint soit des outils SQL Server pour sauvegarder et restaurer la base de données de contenu pour laquelle le stockage BLOB distant est défini. Cette opération sauvegarde et restaure à la fois le stockage BLOB distant et la base de données de contenu. Nous vous recommandons de ne pas utiliser le stockage BLOB distant avec d'autres méthodes de restauration. Pour plus d'informations sur les avantages et les limites de l'utilisation du stockage BLOB distant, voir Utiliser le stockage BLOB distant (RBS) dans SharePoint Server. Téléchargez Microsoft SQL Server 2014 Feature Packqui inclut RBS.

Voir aussi

Concepts

Vue d'ensemble de la sauvegarde et de la récupération dans SharePoint Server

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

Préparer la sauvegarde et la restauration de batteries de serveurs dans SharePoint Server

Autres ressources

Chiffrement transparent des données