- Article
- 15 minutes de temps de lecture
Serveur Azure DevOps 2022 | Serveur Azure DevOps 2020 | Serveur Azure DevOps 2019 | TF 2018
Vous pouvez protéger votre implémentation contre la perte de données en créant une planification de sauvegarde régulière pour les bases de données dont dépend Azure DevOps Server. Pour récupérer complètement votre déploiement Azure DevOps Server, sauvegardez d'abord 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 utilisées par Azure DevOps dans ces composants. Pour éviter les erreurs de synchronisation ou les conflits de données, vous devez synchroniser toutes les sauvegardes avec le même horodatage. L'utilisation de transactions balisées est le moyen le plus simple d'assurer une synchronisation réussie. En balisant régulièrement les transactions associées dans chaque base de données, vous établissez un ensemble commun de points de récupération sur toutes les bases de données. Pour obtenir un guide étape par étape sur la sécurisation d'un déploiement à serveur unique qui utilise la création de rapports, consultezCréer un calendrier et un plan de sauvegarde.
Sauvegarde de la base de données
Protégez votre implémentation Azure DevOps contre la perte de données en créant des sauvegardes de base de données. Le tableau suivant et les figures qui l'accompagnent montrent les bases de données qui seront sauvegardées et fournissent des exemples de la manière dont ces bases de données peuvent être physiquement distribuées au sein d'un déploiement.
| type de base de données | produits | Composant requis ? |
|---|---|---|
| base de données de configuration | Serveur Azure DevOps | Oui |
| base de données de roulements | Serveur Azure DevOps | Oui |
| Bases de données de collection de projets | Serveur Azure DevOps | Oui |
| bases de données de rapports | SQLServerReportingServicesSQLServerReportingServices | Non |
| bases de données d'analyse | Services d'analyse SQL Server | Non |
topologies de déploiement
Selon la configuration de votre déploiement, toutes les bases de données à sauvegarder peuvent résider sur le même serveur physique, comme dans cet exemple de topologie.
Noix
Cet exemple n'inclut pas les produits Reporting Services ou SharePoint. Par conséquent, vous n'avez pas besoin de sauvegarder les bases de données associées aux rapports, aux analyses ou aux produits SharePoint.
Les bases de données peuvent également être réparties sur de nombreux serveurs et batteries de serveurs. Dans cet exemple de topologie, vous devez sauvegarder les bases de données mises à l'échelle suivantes sur six serveurs ou batteries :
la base de données de configuration
la base de données de l'entrepôt
Bases de données de collection de projets situées dans le cluster SQL Server
la base de données de collecte, située sur le serveur autonome exécutant SQL Server
Bases de données situées sur le serveur exécutant Reporting Services
la base de données située sur le serveur exécutant Analysis Services
Bases de données d'administration de produit SharePoint et bases de données de collection de sites pour les applications Web SharePoint
Si vos bases de données SharePoint sont mises à l'échelle sur plusieurs serveurs, vous ne pouvez pas utiliser la fonctionnalité de sauvegarde planifiée pour effectuer des sauvegardes. Vous devez configurer manuellement les sauvegardes de ces bases de données et vous assurer que ces sauvegardes sont synchronisées avec les sauvegardes de la base de données Azure DevOps Server. Pour plus d'informations, voirSauvegarde manuelle du serveur Azure DevOps.
Dans les deux exemples, vous ne devez pas protéger les clients qui se connectent au serveur. Cependant, vous devrez peut-être vider manuellement les caches du serveur Azure DevOps sur les machines clientes avant de vous reconnecter au déploiement restauré.
Bases de données pour la sauvegarde
La liste suivante fournit des détails supplémentaires sur ce que vous devez prendre en charge en fonction de vos capacités de déploiement.
Important
Toutes les bases de données de la liste suivante sont des bases de données SQL Server. Bien que vous puissiez toujours utiliser SQL Server Management Studio pour sauvegarder des bases de données individuelles, vous devez éviter ces sauvegardes individuelles dans la mesure du possible. Des résultats inattendus peuvent se produire lors de la 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 d'autres bases de données.
- Bases de données pour Azure DevOps Server- La couche de données logiques 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. Toutes ces bases de données peuvent être sur le même serveur, dans plusieurs instances dans la même implémentation SQL Server, ou réparties sur plusieurs serveurs. Quelle que soit votre distribution physique, vous devez sauvegarder toutes les bases de données avec un horodatage identique pour éviter la perte de données. Vous pouvez exécuter des sauvegardes de base de données manuellement ou automatiquement à l'aide de calendriers de maintenance qui s'exécutent à des heures ou à des intervalles spécifiques.
Important
La liste de 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. Lors de la création d'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 ServicesRemarque : 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 vos bases de données de rapports et d'analyse. Cependant, certaines bases de données doivent encore être recréées après la restauration, par ex. B. l'entrepôt.
- Clé de chiffrement pour le serveurServeur de rapports : le serveur de rapports possède une clé de chiffrement qu'il doit protéger. Cette clé protège les informations sensibles stockées dans la base de données du serveur de rapports. Vous pouvez sauvegarder cette clé manuellement à l'aide de l'outil de configuration de Reporting Services ou d'un outil de ligne de commande.
Préparation avancée pour les sauvegardes
Lors du déploiement d'Azure DevOps, vous devez enregistrer les comptes créés ainsi que les noms d'ordinateur, les mots de passe et les options de configuration fournis. Vous devez également conserver une copie de tous les supports de récupération, documents, bases de données et sauvegardes du journal des transactions dans un endroit sûr. Pour vous protéger contre un incident tel qu'un incendie ou un tremblement de terre, vous devez conserver des copies de vos sauvegardes de serveur dans un emplacement séparé de vos serveurs. Cette politique protège contre la perte de données critiques. Il est recommandé de conserver trois copies du support de sauvegarde et de conserver au moins une copie hors site dans un environnement contrôlé.
Important
Essayez de restaurer vos données régulièrement pour vérifier si vos fichiers ont été correctement sauvegardés. Une restauration d'évaluation peut révéler des problèmes matériels qui ne sont pas détectables avec une analyse logicielle uniquement.
Lors de la sauvegarde et de la restauration d'une base de données, vous devez sauvegarder les données sur un support doté d'une adresse réseau (comme une bande et des disques partagés en tant que lecteurs réseau). Votre plan de sauvegarde doit inclure la gestion des médias, notamment :
- un plan de surveillance et de gestion de la conservation et du recyclage des jeux de sauvegarde ;
- un programme de sauvegarde pour le support de sauvegarde ;
- dans un environnement multi-serveurs, la possibilité d'utiliser des sauvegardes centralisées ou distribuées ;
- un moyen de suivre la durée de vie utile des médias ;
- une méthode d'atténuation des effets de la perte d'un jeu de sauvegarde ou d'un support de sauvegarde (par exemple, bande) ;
- Stockage des jeux de sauvegarde sur site ou hors site et analyse de l'impact 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, les machines sur lesquelles des clients Azure DevOps sont installés n'ont pas besoin d'être sauvegardées. En cas de panne de support ou d'incident impliquant ces ordinateurs, 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 avecfonctionnalités de sauvegarde planifiéeêtre disponible ou créer manuellement des plans de maintenance dans SQL Server pour sauvegarder les bases de données liées au déploiement d'Azure DevOps. Les bases de données Azure DevOps fonctionnent ensemble 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 de base de données, consultezSauvegarde et restauration de la base de données SQL Server.
types de fusibles
Comprendre les types de sauvegarde disponibles peut vous aider à déterminer les meilleures options pour prendre en charge votre déploiement. Par exemple, si vous travaillez avec de grands déploiements et souhaitez vous protéger contre la perte de données tout en utilisant efficacement les ressources de stockage, vous pouvez configurer des sauvegardes différentielles et des sauvegardes complètes des données. Si vous utilisez SQL Server Always On, vous pouvez créer des sauvegardes de votre base de données secondaire. Vous pouvez également utiliser la compression de sauvegarde ou diviser les sauvegardes en plusieurs fichiers. Voici de brèves descriptions des options de sauvegarde disponibles :
Sauvegarde complète des données (bases de données)
Une sauvegarde complète de la base de données est requise pour restaurer votre déploiement. Une sauvegarde complète contient des parties du journal des transactions, de sorte que la sauvegarde complète peut être restaurée. Les sauvegardes complètes sont autonomes car elles représentent l'intégralité de la base de données telle qu'elle existait au moment de la création de la sauvegarde. Pour plus d'informations, voirSauvegardes complètes de la base de données.
Sauvegarde différentielle des données (bases de données)
Une sauvegarde différentielle de la base de données enregistre uniquement les données qui ont été modifiées depuis la dernière sauvegarde complète de la base de données, appelée base de données 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 détriment d'une complexité accrue. Pour les grandes bases de données, 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, voirSauvegardes différentielles de la base de données.
Vous devez également sauvegarder régulièrement vos journaux de transactions. Ces sauvegardes sont requises pour la récupération des données lors de l'utilisation du modèle de sauvegarde complète de la base de données. En sauvegardant les journaux de transactions, vous pouvez restaurer la base de données jusqu'au point de défaillance ou avant.
Sauvegardes du journal des transactions
Le journal des transactions est un enregistrement continu de toutes les modifications apportées à une base de données, ainsi que de la transaction qui a effectué chaque modification. Le journal des transactions enregistre le début de chaque transaction, les modifications de données et, si nécessaire, les informations nécessaires pour annuler les modifications apportées au cours de cette transaction. Le journal s'agrandit continuellement au fur et à mesure que les opérations consignées sont effectuées sur la base de données.
En sauvegardant les journaux de transactions, vous pouvez restaurer la base de données à une heure antérieure. Par exemple, vous pouvez restaurer la base de données à un moment antérieur à l'insertion de données indésirables ou à une erreur. Outre les sauvegardes de base de données, les sauvegardes du journal des transactions doivent faire partie de votre stratégie de récupération. Pour plus d'informations, voirSauvegardes du journal des transactions (SQL Server).
Les sauvegardes du journal des transactions utilisent généralement moins de ressources que les sauvegardes complètes. Par conséquent, vous pouvez créer des sauvegardes du journal des transactions plus fréquemment que des sauvegardes complètes, ce qui réduit le risque de perte de données. Cependant, une sauvegarde du journal des transactions est parfois plus volumineuse qu'une sauvegarde complète. Par exemple, une base de données avec un taux de transaction élevé entraînera une croissance rapide du journal des transactions. Dans ce cas, créez des sauvegardes du journal des transactions plus fréquemment. Pour plus d'informations, voirRéparez un journal de transactions complet (erreur SQL Server 9002).
Vous pouvez effectuer les types de sauvegardes de journaux de transactions suivants :
- Une sauvegarde du journal des transactions ponctuelle contient uniquement les enregistrements du journal des transactions pour un intervalle sans modifications en masse.
- Une sauvegarde du journal des transactions contient des pages de journal et des pages de données qui ont été modifiées par des opérations en bloc. La date et l'heure ne peuvent pas être restaurées.
- Une sauvegarde de fichier journal de basculement est restaurée à partir d'une base de données potentiellement corrompue pour conserver les journaux qui n'ont pas encore été sauvegardés. Une sauvegarde du fichier journal de basculement est effectuée après un échec pour éviter la perte de données et peut inclure des données provenant d'une sauvegarde ponctuelle ou d'une sauvegarde du journal des transactions.
Étant donné que la synchronisation des données est essentielle à la réussite de la récupération d'Azure DevOps Server, vous devez utiliser des transactions étiquetées dans le cadre de votre stratégie de sauvegarde lors de la configuration manuelle des sauvegardes. Pour plus d'informations, voirCréer un calendrier de sauvegarde et un calendrieretSauvegarder manuellement le serveur Azure DevOps.
Garanties de service au niveau de l'application
La seule sauvegarde requise pour le niveau de l'application logique est la clé de chiffrement Reporting Services. Si vous utilisez la fonctionnalité de sauvegardes planifiées pour sauvegarder votre déploiement, cette clé sera sauvegardée dans le cadre de la planification. Vous pouvez supposer que vous devez protéger les sites Web utilisés comme portails de projet.
Bien qu'il soit possible de sauvegarder un niveau application plus facilement qu'un niveau données, la restauration d'un niveau application nécessite toujours plusieurs étapes. Vous devez installer un autre niveau d'application pour Azure DevOps Server, rediriger les collections de projets pour utiliser le nouveau niveau d'application et rediriger les sites portail vers les projets.
Noms de base de données par défaut
Si vous ne personnalisez pas les noms de base de données, vous pouvez utiliser le tableau suivant pour identifier les bases de données utilisées dans votre déploiement Azure DevOps Server. Comme mentionné ci-dessus, toutes les implémentations n'incluent pas toutes ces bases de données. Par exemple, si vous n'avez pas Azure DevOps Server configuré avec Reporting Services, vous n'avez pas les bases de données ReportServer ou ReportServerTempDB. De même, à moins que vous ne configuriez Azure DevOps Server pour prendre en charge Lab Management, vous n'aurez pas la base de données pour System Center Virtual Machine Manager (SCVMM), VirtualManagerDB. De plus, les bases de données utilisées par Azure DevOps Server peuvent être réparties sur plusieurs instances SQL Server ou sur plusieurs serveurs.
Noix
Par défaut, le préfixeTFS_Il est ajouté aux noms des bases de données qui sont automatiquement créées lorsque vous installez Azure DevOps Server ou pendant son exécution.
| base de données | la description |
|---|---|
| Configuration_TFS | La base de données de configuration Azure DevOps Server contient le catalogue, le nom du serveur et les données de configuration pour le déploiement. Le nom de cette base de données peut contenir des caractères supplémentaires entreTFS_etLes paramètres, comme nom d'utilisateur de la personne qui a installé Azure DevOps Server. Par exemple, le nom de la base de données pourrait être TFS_UserNameConfiguration |
| TFS_Lager | La base de données d'entrepôt contient les données permettant de créer l'entrepôt utilisé par Reporting Services. Le nom de cette base de données peut contenir des caractères supplémentaires entreTFS_etstockage, comme 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_collection_name | 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, la configuration de build et les paramètres d'administration du laboratoire. Le nombre de bases de données de collection correspond 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 contenir des caractères supplémentairesTFS_etnom de la collection, comme 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_Analyse | La base de données SQL Server Analysis Services contient les sources de données et les cubes pour le déploiement Azure DevOps Server. Le nom de cette base de données peut contenir des caractères supplémentaires entreTFS_etAnalyser, comme 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. surveillanceRemarque : 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. |
| serveur de rapports | La base de données Reporting Services contient des rapports et des paramètres de rapport pour votre déploiement Azure DevOps Server. surveillanceRemarque : si Reporting Services est installé sur un serveur différent du serveur Azure DevOps, cette base de données peut ne pas exister sur le serveur de niveau données du serveur Azure DevOps. Dans ce cas, vous devez configurer, sauvegarder et restaurer séparément du serveur Azure DevOps. Vous devez synchroniser la maintenance de votre base de données pour éviter les erreurs de synchronisation. |
| ReportServerTempDB | La base de données temporaire de Reporting Services stocke temporairement des informations lorsque vous exécutez certains rapports. surveillanceRemarque : si Reporting Services est installé sur un serveur différent du serveur Azure DevOps, cette base de données peut ne pas exister sur le serveur de niveau données du serveur Azure DevOps. Dans ce cas, vous devez configurer, sauvegarder et restaurer séparément du serveur Azure DevOps. Cependant, vous devez synchroniser la maintenance de votre base de données pour éviter les erreurs de synchronisation. |
| VirtualManagerDB | La base de données de gestion SCVMM contient les informations que vous voyez dans la console de gestion SCVMM, telles que : B. machines virtuelles, hôtes de machines virtuelles, serveurs de bibliothèque de machines virtuelles et leurs propriétés. surveillanceRemarque : si SCVMM est installé sur un serveur différent du serveur Azure DevOps, cette base de données peut ne pas exister sur le serveur de niveau données pour le serveur Azure DevOps. Dans ce cas, vous devez configurer, sauvegarder et restaurer séparément du serveur Azure DevOps. Cependant, vous devez utiliser des transactions marquées et synchroniser la maintenance de la base de données pour éviter les erreurs de synchronisation. |
Articles Similaires
- Sauvegarde et restauration du serveur Azure DevOps
- Récupérer un déploiement sur un nouveau matériel