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

Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018-TFS 2013

Notes

Azure DevOps Server a été précédemment nommé Visual Studio Team Foundation Server.

Vous pouvez contribuer à 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, sauvegardez d’abord toutes les bases de données Azure DevOps Server.

Si votre déploiement comprend SQL Server Reporting Services, vous devez également sauvegarder les bases de données qu’Azure DevOps utilise au sein de 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 communs dans les bases de données. Pour obtenir des instructions pas à pas sur la sauvegarde d’un déploiement de serveur unique qui utilise la création de rapports, consultez créer une planification et un plan de sauvegarde.

Si votre déploiement comprend SQL Server Reporting Services ou des produits SharePoint, vous devez également sauvegarder les bases de données qu’Azure DevOps utilise au sein de 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 communs dans les bases de données. Pour obtenir des instructions pas à pas sur la sauvegarde d’un déploiement sur un serveur unique qui utilise SharePoint Foundation et 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 distribuées physiquement 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 la collection de projets Azure DevOps Server Oui
Bases de données Reporting SQL Server Reporting Services Non
Bases de données Analysis SQL Server Analysis Services Non
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 la collection de projets Azure DevOps Server Oui
Bases de données Reporting SQL Server Reporting Services Non
Bases de données Analysis SQL Server Analysis Services Non
Bases de données de produits SharePoint Produits SharePoint 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 à 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 Azure DevOps Server simple

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

  • bases de données de la collection de projets situées 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 Azure DevOps Server complexe

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 pour 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 dans la mesure du possible. Vous pouvez constater des résultats inattendus si vous effectuez une restauration à partir de sauvegardes individuelles, car les bases de données utilisées par Azure DevOps sont toutes liées. Si vous sauvegardez 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 : la couche de données logique pour Azure DevOps Server inclut plusieurs bases de données SQL Server, y compris la base de données de configuration, la base de données de l’entrepôt et une base de données pour chaque collection de projets dans le déploiement. Ces bases de données peuvent toutes être sur le même serveur, distribuées sur plusieurs instances dans le même déploiement SQL Server ou distribuées 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 a 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.
  • Bases de données pour les produits SharePoint : Si votre déploiement utilise des produits SharePoint pour héberger des portails de projet, vous devez sauvegarder plusieurs bases de données. Ces bases de données incluent la base de données d’administration pour chaque application Web SharePoint que votre déploiement utilise et les bases de données de collection de sites qui hébergent les portails de projet. De préférence, votre déploiement a été configuré pour utiliser une collection de sites distincte pour chaque collection de projets de votre déploiement. Tout comme les collections de projets peuvent être sauvegardées et restaurées en tant qu’unité dans Azure DevOps Server, les collections de sites peuvent être sauvegardées et restaurées dans les produits SharePoint. Si une ou plusieurs collections de votre déploiement utilisent des sites ou des sous-sites au lieu de collections de sites comme site racine, il est possible que vous ne puissiez pas sauvegarder et restaurer la totalité des collections. Pour plus d’informations, consultez organiser votre serveur avec des collections de projets.

    Notes

    Vous pouvez supposer que vous devez sauvegarder les bases de données et les sites Web pour les pages du portail du projet. Toutefois, les produits SharePoint génèrent dynamiquement les sites Web à partir des bases de données. Ainsi, lorsque vous sauvegardez les bases de données, vous sauvegardez également les sections du projet qui s’affichent en tant que sites Web. Si vous avez créé des collections de sites, des modèles de site ou des composants WebPart personnalisés dans les produits SharePoint, mais en dehors de Azure DevOps Server, vous devez les sauvegarder séparément. Pour plus d’informations, consultez sauvegarde (SharePoint Foundation).

Préparation avancée pour les sauvegardes

Lorsque vous déployez Azure DevOps, vous devez conserver un enregistrement des comptes que vous créez et de tous les noms d’ordinateurs, mots de passe et 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 des bases de données SQL Server, vous n’êtes pas obligé de sauvegarder les ordinateurs sur lesquels les clients Azure DevOps sont installés. Si une panne de support ou un incident qui impliquait 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 disposent d’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 qui se rapportent à votre déploiement Azure DevOps. Les bases de données Azure DevOps fonctionnent avec une 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 des bases de données SQL Server.

Types de sauvegardes

La compréhension des types de sauvegardes disponibles vous aide à déterminer les meilleures options de sauvegarde de 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 AlwaysOn, 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 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 complètes de base de données.

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

Une sauvegarde de base de données différentielle enregistre uniquement les données qui ont été modifiées depuis la dernière sauvegarde complète de base de données, 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 base 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 séquentiel 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 antérieur à la saisie de données indésirables ou une défaillance s’est produite. 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 augmentation 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 saturé (SQL Server l’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 une 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 de sauvegarde et planifier et sauvegarder manuellement Azure DevOps Server.

Sauvegardes du service de la couche application

La seule sauvegarde nécessaire pour la couche application logique concerne 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 du projet.

Si vous avez intégré les produits SharePoint dans le cadre de votre déploiement Azure DevOps Server, les portails sont sauvegardés dans le cadre de la sauvegarde des bases de données pour les produits Azure DevOps Server et SharePoint. Toutefois, si vous avez spécifié un site Web qui n'a pas été créé à l'aide d'une application Web intégrée, vous devez sauvegarder et restaurer ces sites manuellement. En outre, si vous avez des personnalisations pour des produits SharePoint ou des services, vous devez également les sauvegarder ou les enregistrer pour qu’ils puissent être reproduits sur un nouveau serveur.

Bien que vous puissiez sauvegarder une couche application plus facilement 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 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 ne disposez pas des bases de données ReportServer ou ReportServerTempDB. De même, vous ne disposerez pas de 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 instances de SQL Server ou sur plusieurs serveurs.

Notes

Par défaut, le préfixe TFS_ est ajouté aux noms de toutes les bases de données qui sont créées automatiquement lorsque vous installez Azure DevOps Server ou pendant qu’il fonctionne.

Base de données Description
TFS_Configuration La base de données de configuration de Azure DevOps Server contient le catalogue, les noms des serveurs et les données de configuration pour le déploiement. Le nom de cette base de données peut inclure des caractères supplémentaires entre TFS_ et la configuration, tels que le nom d’utilisateur de la personne qui a installé Azure DevOps Server. Par exemple, le nom de la base de données peut être TFS_UserNameConfiguration
TFS_Warehouse La base de données de l'entrepôt contient les données pour la génération de l'entrepôt que Reporting Services utilise. Le nom de cette base de données peut inclure des caractères supplémentaires entre TFS_ et l' entrepôt, tels que le nom d’utilisateur de la personne qui a installé Azure DevOps Server. Par exemple, le nom de la base de données peut être TFS_UserNameWarehouse.
TFS_CollectionName La base de données d’une collection de projets contient toutes les données des projets de cette collection. Ces données incluent le code source, les configurations de build et les configurations Lab Management. Le nombre de bases de données de collection sera égal au nombre de collections. Par exemple, si vous avez trois collections dans votre déploiement, vous devez sauvegarder ces trois bases de données de collection. Le nom de chaque base de données peut inclure des caractères supplémentaires entre TFS_ et CollectionName, tels que le nom d’utilisateur de la personne qui a créé la collection. Par exemple, le nom d’une base de données de collection peut être TFS_UserNameCollectionName.
TFS_Analysis La base de données de SQL Server Analysis Services contient les sources de données et les cubes pour votre déploiement de Azure DevOps Server. Le nom de cette base de données peut inclure des caractères supplémentaires entre les TFS_ et l' analyse, tels que le nom d’utilisateur de la personne qui a installé Analysis Services. Par exemple, le nom de la base de données peut être TFS_UserNameAnalysis.
Remarque: vous pouvez sauvegarder cette base de données, mais vous devez reconstruire l’entrepôt à partir de la base de données TFS_Warehouse restaurée.
ReportServer La base de données de Reporting Services contient les rapports et les paramètres de rapport pour votre déploiement de Azure DevOps Server.
Remarque: Si Reporting Services est installé sur un serveur distinct de Azure DevOps Server, cette base de données peut ne pas être présente sur le serveur de couche données pour Azure DevOps Server. Dans ce cas, vous devez configurer, sauvegarder et restaurer séparément à partir de Azure DevOps Server. Vous devez synchroniser la maintenance des bases de données pour éviter les erreurs de synchronisation.
ReportServerTempDB La base de données temporaire pour Reporting Services stocke temporairement des informations lorsque vous exécutez des rapports spécifiques.
Remarque: Si Reporting Services est installé sur un serveur distinct de Azure DevOps Server, cette base de données peut ne pas être présente sur le serveur de couche données pour Azure DevOps Server. Dans ce cas, vous devez configurer, sauvegarder et restaurer séparément à partir de Azure DevOps Server. Toutefois, vous devez synchroniser la maintenance des bases de données pour éviter des erreurs de synchronisation.
VirtualManagerDB La base de données d'administration de SCVMM contient les informations que vous affichez dans la Console Administration SCVMM, telles que les ordinateurs virtuels, les hôtes d'ordinateur virtuel, les serveurs de bibliothèque d'ordinateur virtuel et leurs propriétés.
Remarque: si SCVMM est installé sur un serveur distinct de Azure DevOps Server, cette base de données peut ne pas être présente sur le serveur de couche données pour Azure DevOps Server. Dans ce cas, vous devez configurer, sauvegarder et restaurer séparément à partir de Azure DevOps Server. Toutefois, vous devez utiliser des transactions marquées et synchroniser la maintenance des bases de données pour éviter des erreurs de synchronisation.

Noms de base de données par défaut des produits SharePoint

Notes

Vous ne devez pas utiliser de transactions marquées si vous sauvegardez ou restaurez manuellement les bases de données utilisées par les produits SharePoint. Toutefois, pour éviter les erreurs de synchronisation, vous devez essayer de synchroniser vos planifications de sauvegarde et de restauration pour les produits et les Azure DevOps Server SharePoint. Pour plus d’informations, consultez créer un plan de sauvegarde pour SharePoint Foundation.

Base de données Description
WSS_Config La base de données de configuration pour les produits SharePoint contient une liste de tous les sites, tels que les bases de données de contenu, les modèles de site, les composants WebPart personnalisés et d’autres paramètres de l’administration centrale de SharePoint.
WSS_Content La base de données de contenu pour les produits SharePoint contient le contenu réel dans les portails de projet.
Remarque: le nom de cette base de données varie selon la version des produits SharePoint installée et si la personne qui l’a installée a personnalisé le nom.
WSS_AdminContent La base de données d’administration pour les produits SharePoint contient les informations de sécurité pour les utilisateurs, les rôles et les bases de données.