Bases de données, topologies de déploiement et sauvegarde

Article
03/25/2024

Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019

Vous pouvez protéger votre déploiement contre la perte de données en créant une planification régulière des sauvegardes pour les bases de données dont dépend Azure DevOps Server. Pour restaurer complètement votre déploiement Azure DevOps Server, commencez par sauvegarder toutes les bases de données Azure DevOps Server.

Si votre déploiement inclut SQL Server Reporting Services, vous devez également sauvegarder les bases de données qu’Azure DevOps utilise dans ces composants. Pour éviter les erreurs de synchronisation ou d'incompatibilité des données, vous devez synchroniser toutes les sauvegardes à un horodatage identique. L'utilisation de transactions marquées est la méthode la plus facile pour garantir une synchronisation réussie. En marquant régulièrement les transactions associées dans chaque base de données, vous établissez une série de points de récupération courants dans les bases de données. Pour obtenir des instructions pas à pas sur la sauvegarde d’un déploiement à serveur unique qui utilise la création de rapports, consultez Créer une planification et un plan de sauvegarde.

Sauvegarde de bases de données

Protégez votre déploiement Azure DevOps contre la perte de données en créant des sauvegardes de base de données. Le tableau suivant et les illustrations associées indiquent les bases de données à sauvegarder et fournissent des exemples de la façon dont ces bases de données peuvent être physiquement distribuées dans un déploiement.

Type de base de données	Produit	Composant requis ?
Base de données de configuration	Azure DevOps Server	Oui
Base de données de l'entrepôt	Azure DevOps Server	Oui
Bases de données de collection de projets	Azure DevOps Server	Oui
Bases de données Reporting	SQL Server Reporting Services	No
Bases de données Analysis	SQL Server Analysis Services	Non

Topologies de déploiement

Selon la configuration de votre déploiement, toutes les bases de données devant être sauvegardées peuvent se trouver sur le même serveur physique, comme dans cet exemple de topologie.

Notes

Cet exemple n’inclut pas les produits Reporting Services ou SharePoint. Vous n’avez donc pas besoin de sauvegarder les bases de données associées à la création de rapports, à l’analyse ou aux produits SharePoint.

Structure de base de données simple Azure DevOps Server

Les bases de données peuvent également être distribuées sur de nombreux serveurs et batteries de serveurs. Dans cet exemple de topologie, vous devez sauvegarder les bases de données suivantes, mises à l'échelle sur six serveurs ou batteries de serveurs :

la base de données de configuration
la base de données d'entrepôt
les bases de données de collection de projets qui se trouvent sur le cluster SQL Server
la base de données de collection qui se trouve sur le serveur autonome qui exécute SQL Server
les bases de données qui se trouvent sur le serveur qui exécute Reporting Services
la base de données qui se trouve sur le serveur qui exécute Analysis Services
les bases de données d’administration des produits SharePoint et les bases de données de collection de sites pour les deux applications web SharePoint

Si vos bases de données SharePoint sont mises à l’échelle sur plusieurs serveurs, vous ne pouvez pas utiliser la fonctionnalité Sauvegardes planifiées pour les sauvegarder. Vous devez configurer manuellement les sauvegardes pour ces bases de données et vous assurer que ces sauvegardes sont synchronisées avec les sauvegardes de base de données Azure DevOps Server. Pour plus d’informations, consultez Sauvegarder manuellement Azure DevOps Server.

Structure de base de données complexe Azure DevOps Server

Dans ces deux exemples, vous ne devez pas sauvegarder les clients qui se connectent au serveur. Toutefois, vous devrez peut-être effacer manuellement les caches des Azure DevOps Server sur les ordinateurs clients avant qu’ils puissent se reconnecter au déploiement restauré.

Bases de données à sauvegarder

La liste suivante fournit des détails supplémentaires sur ce que vous devez sauvegarder, en fonction de vos ressources de déploiement.

Important

Toutes les bases de données de la liste suivante sont SQL Server bases de données. Bien que vous puissiez utiliser SQL Server Management Studio pour sauvegarder des bases de données individuelles à tout moment, vous devez éviter d’utiliser ces sauvegardes individuelles lorsque cela est possible. Vous pouvez rencontrer des résultats inattendus si vous restaurez à partir de sauvegardes individuelles, car les bases de données qu’Azure DevOps utilise sont toutes liées. Si vous ne sauvegardez qu’une seule base de données, les données de cette base de données peuvent ne pas être synchronisées avec les données des autres bases de données.

Bases de données pour Azure DevOps Server : le niveau de données logique pour Azure DevOps Server comprend plusieurs bases de données SQL Server, y compris la base de données de configuration, la base de données d’entrepôt et une base de données pour chaque collection de projets dans le déploiement. Ces bases de données peuvent toutes se trouver sur le même serveur, réparties sur plusieurs instances dans le même déploiement SQL Server ou réparties sur plusieurs serveurs. Indépendamment de leur distribution physique, vous devez sauvegarder toutes les bases de données à un horodatage identique pour prévenir les pertes de données. Vous pouvez effectuer les sauvegardes de bases de données manuellement ou automatiquement en utilisant des plans de maintenance qui s'exécutent à des horaires ou des intervalles spécifiques.

Important

La liste des bases de données Azure DevOps n’est pas statique. Une base de données est créée chaque fois que vous créez une collection. Lorsque vous créez une collection, veillez à ajouter la base de données de cette collection à votre plan de maintenance.
Bases de données pour Reporting Services et Analysis Services : si votre déploiement utilise SQL Server Reporting Services ou SQL Server Analysis Services pour générer des rapports pour Azure DevOps Server, vous devez sauvegarder les bases de données de création de rapports et d’analyse. Cependant, vous devez continuer à régénérer certaines bases de données après la restauration, comme par exemple l'entrepôt.
Clé de chiffrement pour le serveur de rapports : le serveur de rapports dispose d’une clé de chiffrement que vous devez sauvegarder. Cette clé protège des informations sensibles stockées dans la base de données pour le serveur de rapports. Vous pouvez sauvegarder manuellement cette clé à l'aide de l'outil de configuration de Reporting Services ou un outil en ligne de commande.

Préparation avancée pour les sauvegardes

Lorsque vous déployez Azure DevOps, vous devez conserver un enregistrement des comptes que vous créez, ainsi que des noms d’ordinateurs, des mots de passe et des options d’installation que vous spécifiez. Vous devez également garder une copie de tous les matériels de récupération, documents, bases de données et sauvegardes des journaux des transactions dans un emplacement sécurisé. Pour se protéger contre un incident, tel qu'un incendie ou un tremblement de terre, vous devez conserver des doubles de vos sauvegardes de serveurs dans un emplacement différent de celui des serveurs. Cette stratégie permet de se protéger contre la perte de données critiques. Il est recommandé de garder trois copies du support de sauvegarde et de conserver au moins une copie en dehors du site, dans un environnement contrôlé.

Important

Effectuez périodiquement une tentative de restauration des données pour vérifier que vos fichiers sont correctement sauvegardés. Une restauration d’essai peut révéler des problèmes matériels qui n’apparaissent pas avec une vérification logicielle uniquement.

Lorsque vous sauvegardez et restaurez une base de données, vous devez sauvegarder les données sur un support disposant d'une adresse réseau (par exemple, des bandes et des disques ayant été partagés comme lecteurs réseau). Votre plan de sauvegarde doit prévoir la gestion des médias, notamment :

un plan de suivi et de gestion pour stocker et recycler des jeux de sauvegarde ;
un calendrier de remplacement des supports de sauvegarde ;
dans un environnement multi-serveur, le choix d'utiliser des sauvegardes centralisées ou distribuées ;
un moyen de suivi de la durée de vie des médias ;
une procédure permettant de réduire les effets de la perte d'un jeu de sauvegardes ou d'un support de sauvegarde (une bande, par exemple) ;
le stockage des jeux de sauvegardes sur place ou hors site, et une analyse de la répercussion de ce choix sur le temps de récupération.

Étant donné que les données Azure DevOps sont stockées dans SQL Server bases de données, vous n’avez pas besoin de sauvegarder les ordinateurs sur lesquels les clients d’Azure DevOps sont installés. Si une défaillance ou un sinistre multimédia impliquant ces ordinateurs devait se produire, vous pouvez réinstaller le logiciel client et vous reconnecter au serveur. En réinstallant le logiciel client, vos utilisateurs auront une alternative plus propre et plus fiable à la restauration d’un ordinateur client à partir d’une sauvegarde.

Vous pouvez sauvegarder un serveur à l’aide des fonctionnalités de sauvegardes planifiées disponibles ou en créant manuellement des plans de maintenance dans SQL Server pour sauvegarder les bases de données liées à votre déploiement Azure DevOps. Les bases de données Azure DevOps fonctionnent en relation entre elles et, si vous créez un plan manuel, vous devez les sauvegarder et les restaurer en même temps. Pour plus d’informations sur les stratégies de sauvegarde des bases de données, consultez Sauvegarder et restaurer SQL Server bases de données.

Types de sauvegardes

La compréhension des types de sauvegardes disponibles vous aide à déterminer les meilleures options pour sauvegarder votre déploiement. Par exemple, si vous travaillez avec de grands déploiements et que vous souhaitez vous protéger contre la perte de données tout en étant efficaces dans l'utilisation des ressources de stockage limitées, vous pouvez configurer des sauvegardes différentielles ainsi que des sauvegardes de données complètes. Si vous utilisez SQL Server Always On, vous pouvez effectuer des sauvegardes de votre base de données secondaire. Vous pouvez également utiliser la compression des sauvegardes ou fractionner les sauvegardes sur plusieurs fichiers. Voici de brèves descriptions des options de sauvegarde disponibles :

Sauvegardes de données complètes (bases de données)

Une sauvegarde complète de la base de données est nécessaire pour la récupération de votre déploiement. Une sauvegarde complète inclut des portions du journal des transactions afin que la sauvegarde complète puisse être récupérée. Les sauvegardes complètes sont autonomes, car elles représentent l'intégralité de la base de données telle qu'elle existait lorsque vous l'avez sauvegardée. Pour plus d’informations, consultez Sauvegardes de base de données complètes.

Sauvegardes de données différentielles (bases de données)

Une sauvegarde de base de données différentielle enregistre uniquement les données qui ont changé depuis la dernière sauvegarde de base de données complète, appelée base différentielle. Les sauvegardes de base de données différentielles sont plus petites et plus rapides que les sauvegardes complètes. Cette option réduit le temps de sauvegarde au prix d'une complexité accrue. Pour les bases de données importantes, les sauvegardes différentielles peuvent être effectuées à des intervalles plus courts que les sauvegardes de base de données, ce qui réduit le risque de perte de données. Pour plus d’informations, consultez Sauvegardes différentielles de bases de données.

Vous devez également sauvegarder régulièrement vos journaux des transactions. Ces sauvegardes sont nécessaires pour la récupération de données lorsque vous utilisez le modèle de sauvegarde complète de la base de données. Si vous sauvegardez les journaux des transactions, vous pouvez récupérer la base de données jusqu’au point de défaillance ou à un point antérieur dans le temps.

Sauvegardes des journaux de transactions

Le journal des transactions est un enregistrement en série de toutes les modifications qui se sont produites dans une base de données en plus de la transaction qui a effectué chaque modification. Le journal des transactions enregistre le démarrage de chaque transaction, les modifications de données et, au besoin, les informations nécessaires pour annuler les modifications effectuées pendant cette transaction. Le journal grandit continuellement au fur et à mesure que les opérations enregistrées se produisent dans la base de données.

La sauvegarde des journaux des transactions permet de récupérer la base de données à un point antérieur dans le temps. Par exemple, vous pouvez restaurer la base de données à un point avant l’entrée de données indésirables ou une défaillance. Outre les sauvegardes de la base, les sauvegardes des journaux de transactions doivent faire partie de votre stratégie de récupération. Pour plus d’informations, consultez Sauvegardes du journal des transactions (SQL Server).

Les sauvegardes des journaux de transactions utilisent généralement moins de ressources que les sauvegardes complètes. Par conséquent, vous pouvez créer des sauvegardes de journaux des transactions plus fréquemment que les sauvegardes complètes, ce qui permet de réduire le risque de perte de données. Toutefois, il arrive qu'une sauvegarde des journaux de transactions soit plus grande qu'une sauvegarde complète. Par exemple, une base de données avec un taux de transactions élevé entraîne une croissance rapide du journal des transactions. Dans ce cas, créez des sauvegardes des journaux des transactions plus fréquemment. Pour plus d’informations, consultez Résoudre les problèmes liés à un journal des transactions complet (SQL Server Erreur 9002).

Vous pouvez effectuer les types de sauvegardes de journaux des transactions suivants :

Une sauvegarde ponctuelle d'un journal de transactions contient uniquement les enregistrements des journaux de transactions pour un intervalle sans les modifications en bloc.
Une sauvegarde des journaux de transactions contient les pages de journaux et les pages de données modifiées par les opérations en bloc. La récupération jusqu'à une date et heure n'est pas possible.
Une sauvegarde de fichier journal après défaillance est récupérée à partir d'une base de données peut-être endommagée afin de conserver les enregistrements du journal qui n'ont pas encore été sauvegardés. Une sauvegarde de fichier journal après défaillance est effectuée après une défaillance pour éviter toute perte de données et peut contenir les données d'une sauvegarde ponctuelle ou d'une sauvegarde de journaux de transactions.

Étant donné que la synchronisation des données est essentielle pour la restauration réussie des Azure DevOps Server, vous devez utiliser des transactions marquées dans le cadre de votre stratégie de sauvegarde si vous configurez les sauvegardes manuellement. Pour plus d’informations, consultez Créer une planification et un plan de sauvegarde et Sauvegarder manuellement Azure DevOps Server.

Sauvegardes de service de la couche Application

La seule sauvegarde nécessaire pour la couche Application logique est pour la clé de chiffrement pour Reporting Services. Si vous utilisez la fonctionnalité Sauvegardes planifiées pour sauvegarder votre déploiement, cette clé est sauvegardée pour vous dans le cadre du plan. Vous pouvez supposer que vous devez sauvegarder les sites web utilisés comme portails de projet.

Bien que vous puissiez sauvegarder plus facilement une couche Application qu’une couche Données, il existe toujours plusieurs étapes pour restaurer une couche Application. Vous devez installer une autre couche Application pour Azure DevOps Server, rediriger les collections de projets pour utiliser la nouvelle couche Application et rediriger les sites du portail pour les projets.

Noms de bases de données par défaut

Si vous ne personnalisez pas les noms de vos bases de données, vous pouvez utiliser le tableau suivant pour identifier les bases de données utilisées dans votre déploiement de Azure DevOps Server. Comme mentionné précédemment, les déploiements ne comportent pas tous l'ensemble de ces bases de données. Par exemple, si vous n’avez pas configuré Azure DevOps Server avec Reporting Services, vous n’aurez pas les bases de données ReportServer ou ReportServerTempDB. De même, vous n’aurez pas la base de données pour System Center Virtual Machine Manager (SCVMM), VirtualManagerDB, sauf si vous configurez Azure DevOps Server pour prendre en charge Lab Management. En outre, les bases de données que Azure DevOps Server utilise peuvent être distribuées sur plusieurs instance de SQL Server ou sur plusieurs serveurs.