Freigeben über

Datenbanken, Bereitstellungstopologien und Sicherung

  • Artikel

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

Sie können ihre Bereitstellung vor Datenverlust schützen, indem Sie einen regelmäßigen Zeitplan für Sicherungen für die Datenbanken erstellen, von denen Azure DevOps Server abhängt. Um Ihre Azure DevOps Server-Bereitstellung vollständig wiederherzustellen, sichern Sie zuerst alle Azure DevOps Server-Datenbanken.

Wenn Ihre Bereitstellung SQL Server Reporting Services enthält, müssen Sie auch die Datenbanken sichern, die Azure DevOps in diesen Komponenten verwendet. Um Synchronisierungsfehler oder Datenkonfliktfehler zu verhindern, müssen Sie alle Sicherungen mit demselben Zeitstempel synchronisieren. Die einfachste Möglichkeit, um eine erfolgreiche Synchronisierung sicherzustellen, besteht darin, markierte Transaktionen zu verwenden. Indem Sie verwandte Transaktionen in jeder Datenbank routinemäßig markieren, richten Sie eine Reihe allgemeiner Wiederherstellungspunkte in den Datenbanken ein. Eine schrittweise Anleitung zum Sichern einer Bereitstellung mit einem einzelnen Server, die Berichterstellung verwendet, finden Sie unter Erstellen eines Sicherungszeitplans und -plans.

Sichern von Datenbanken

Schützen Sie Ihre Azure DevOps-Bereitstellung vor Datenverlust, indem Sie Datenbanksicherungen erstellen. In der folgenden Tabelle und den zugehörigen Abbildungen wird gezeigt, welche Datenbanken gesichert werden sollen, und beispiele dafür, wie diese Datenbanken in einer Bereitstellung physisch verteilt werden können.

Datenbanktyp Produkt Erforderliche Komponente?
Konfigurationsdatenbank Azure DevOps Server Ja
Lagerdatenbank Azure DevOps Server Ja
Project-Auflistungsdatenbanken Azure DevOps Server Ja
Berichtsdatenbanken SQL Server Reporting Services No
Analysedatenbanken SQL Server Analysis Services No

Bereitstellungstopologien

Basierend auf Ihrer Bereitstellungskonfiguration können sich alle Datenbanken, die eine Sicherung erfordern, auf demselben physischen Server befinden, wie in dieser Beispieltopologie.

Hinweis

In diesem Beispiel sind keine Reporting Services oder SharePoint-Produkte enthalten, sodass Sie keine Datenbanken sichern müssen, die berichterstellungs-, analyse- oder SharePoint-Produkte zugeordnet sind.

Einfache Azure DevOps Server-Datenbankstruktur

Alternativ können die Datenbanken auf viele Server und Serverfarmen verteilt werden. In dieser Beispieltopologie müssen Sie die folgenden Datenbanken sichern, die auf sechs Server- oder Serverfarmen skaliert werden:

  • die Konfigurationsdatenbank

  • die Lagerdatenbank

  • die Projektsammlungsdatenbanken, die sich im SQL Server-Cluster befinden

  • die Sammlungsdatenbank, die sich auf dem eigenständigen Server befindet, auf dem SQL Server ausgeführt wird

  • die Datenbanken, die sich auf dem Server befinden, auf dem Reporting Services ausgeführt wird

  • die Datenbank, die sich auf dem Server befindet, auf dem Analysis Services ausgeführt wird

  • Die administrativen SharePoint-Produkte-Datenbanken und die Websitesammlungsdatenbanken für SharePoint-Webanwendungen

    Wenn Ihre SharePoint-Datenbanken auf mehreren Servern skaliert werden, können Sie das Feature "Geplante Sicherungen" nicht verwenden, um sie zu sichern. Sie müssen Sicherungen für diese Datenbanken manuell konfigurieren und sicherstellen, dass diese Sicherungen mit den Azure DevOps Server-Datenbanksicherungen synchronisiert werden. Weitere Informationen finden Sie unter Manuelles Sichern von Azure DevOps Server.

Komplexe Azure DevOps Server-Datenbankstruktur

In beiden Beispielen müssen Sie keine der Clients sichern, die eine Verbindung mit dem Server herstellen. Möglicherweise müssen Sie jedoch die Caches für Azure DevOps Server auf den Clientcomputern manuell löschen, bevor sie eine erneute Verbindung mit der wiederhergestellten Bereitstellung herstellen können.

Zu sichernde Datenbanken

In der folgenden Liste finden Sie weitere Details dazu, was Sie je nach Bereitstellungsressourcen sichern müssen.

Wichtig

Alle Datenbanken in der folgenden Liste sind SQL Server-Datenbanken. Obwohl Sie SQL Server Management Studio verwenden können, um einzelne Datenbanken jederzeit zu sichern, sollten Sie diese individuellen Sicherungen möglichst vermeiden. Möglicherweise treten unerwartete Ergebnisse auf, wenn Sie aus einzelnen Sicherungen wiederherstellen, da die von Azure DevOps genutzten Datenbanken alle miteinander verknüpft sind. Wenn Sie nur eine Datenbank sichern, werden die Daten in dieser Datenbank möglicherweise nicht mit den Daten in den anderen Datenbanken synchronisiert.

  • Datenbanken für Azure DevOps Server – Die logische Datenebene für Azure DevOps Server umfasst mehrere SQL Server-Datenbanken, darunter die Konfigurationsdatenbank, die Lagerdatenbank und eine Datenbank für jede Projektsammlung in der Bereitstellung. Diese Datenbanken befinden sich möglicherweise auf demselben Server, verteilt über mehrere Instanzen in derselben SQL Server-Bereitstellung oder verteilt auf mehrere Server. Unabhängig von ihrer physischen Verteilung müssen Sie alle Datenbanken auf den gleichen Zeitstempel sichern, um sicherzustellen, dass Datenverlust besteht. Sie können Datenbanksicherungen manuell oder automatisch ausführen, indem Sie Wartungspläne verwenden, die zu bestimmten Zeiten oder Intervallen ausgeführt werden.

    Wichtig

    Die Liste der Azure DevOps-Datenbanken ist nicht statisch. Jedes Mal, wenn Sie eine Sammlung erstellen, wird eine neue Datenbank erstellt. Stellen Sie beim Erstellen einer Sammlung sicher, dass Sie die Datenbank für diese Sammlung zu Ihrem Wartungsplan hinzufügen.

  • Datenbanken für Reporting Services und Analysis Services – Wenn Ihre Bereitstellung SQL Server Reporting Services oder SQL Server Analysis Services zum Generieren von Berichten für Azure DevOps Server verwendet, müssen Sie die Berichts- und Analysedatenbanken sichern. Sie müssen jedoch nach der Wiederherstellung noch bestimmte Datenbanken neu generieren, z. B. das Lager.
  • Verschlüsselungsschlüssel für den Berichtsserver – Der Berichtsserver verfügt über einen Verschlüsselungsschlüssel, den Sie sichern müssen. Dieser Schlüssel schützt vertrauliche Informationen, die in der Datenbank für den Berichtsserver gespeichert sind. Sie können diesen Schlüssel manuell sichern, indem Sie entweder das Reporting Services-Konfigurationstool oder ein Befehlszeilentool verwenden.

Erweiterte Vorbereitung auf Sicherungen

Wenn Sie Azure DevOps bereitstellen, sollten Sie einen Datensatz der Konten speichern, die Sie erstellen, sowie aller Computernamen, Kennwörter und Setupoptionen, die Sie angeben. Sie sollten auch eine Kopie aller Wiederherstellungsmaterialien, Dokumente und Datenbank- und Transaktionsprotokollsicherungen an einem sicheren Ort aufbewahren. Zum Schutz vor einer Katastrophe, z. B. einem Feuer oder Erdbeben, sollten Sie Duplikate Ihrer Serversicherungen an einem anderen Ort als dem Standort der Server aufbewahren. Diese Strategie schützt Sie vor dem Verlust kritischer Daten. Als bewährte Methode sollten Sie drei Kopien des Sicherungsmediums beibehalten, und Sie sollten mindestens eine Kopie außerhalb der Website in einer kontrollierten Umgebung beibehalten.

Wichtig

Führen Sie regelmäßig eine Testdatenwiederherstellung aus, um sicherzustellen, dass Ihre Dateien ordnungsgemäß gesichert sind. Eine Testwiederherstellung kann Hardwareprobleme erkennen, die nicht mit einer Nur-Software-Überprüfung angezeigt werden.

Wenn Sie eine Datenbank sichern und wiederherstellen, müssen Sie die Daten mit einer Netzwerkadresse sichern (z. B. Tapes und Datenträger, die als Netzlaufwerke freigegeben wurden). Ihr Sicherungsplan sollte Bestimmungen für die Verwaltung von Medien enthalten, z. B. die folgenden Taktiken:

  • Ein Tracking- und Managementplan zum Speichern und Recycling von Sicherungssätzen.
  • Ein Zeitplan zum Überschreiben von Sicherungsmedien.
  • In einer Umgebung mit mehreren Servern entscheidet sich die Verwendung von zentralisierten oder verteilten Sicherungen.
  • Eine Möglichkeit zum Nachverfolgen des Nutzens von Medien.
  • Ein Verfahren zur Minimierung der Auswirkungen des Verlusts eines Sicherungssatzes oder Sicherungsmediums (z. B. eines Bandes).
  • Eine Entscheidung zum Speichern von Sicherungssätzen vor Ort oder außerhalb der Website und eine Analyse, wie sich diese Entscheidung auf die Wiederherstellungszeit auswirken kann.

Da Azure DevOps-Daten in SQL Server-Datenbanken gespeichert sind, müssen Sie nicht die Computer sichern, auf denen Azure DevOps-Clients installiert sind. Wenn ein Medienfehler oder ein Notfall auftritt, bei dem diese Computer beteiligt waren, können Sie die Clientsoftware erneut installieren und die Verbindung mit dem Server erneut herstellen. Durch die erneute Installation der Clientsoftware haben Ihre Benutzer eine sauberere und zuverlässigere Alternative zum Wiederherstellen eines Clientcomputers aus einer Sicherung.

Sie können einen Server sichern, indem Sie die verfügbaren Features für geplante Sicherungen verwenden oder Wartungspläne in SQL Server manuell erstellen, um die Datenbanken zu sichern, die sich auf Ihre Azure DevOps-Bereitstellung beziehen. Die Azure DevOps-Datenbanken funktionieren in Beziehung zueinander, und wenn Sie einen manuellen Plan erstellen, sollten Sie sie sichern und gleichzeitig wiederherstellen. Weitere Informationen zu Strategien zum Sichern von Datenbanken finden Sie unter Sichern und Wiederherstellen von SQL Server-Datenbanken.

Sicherungsarten

Wenn Sie die verfügbaren Sicherungstypen verstehen, können Sie die besten Optionen für die Sicherung Ihrer Bereitstellung ermitteln. Wenn Sie z. B. mit einer großen Bereitstellung arbeiten und vor Datenverlust schützen möchten und gleichzeitig begrenzte Speicherressourcen verwenden, können Sie differenzielle Sicherungen sowie vollständige Datensicherungen konfigurieren. Wenn Sie SQL Server Always On verwenden, können Sie Sicherungen Ihrer sekundären Datenbank erstellen. Sie können auch versuchen, die Sicherungskomprimierung zu verwenden oder Sicherungen auf mehrere Dateien aufzuteilen. Hier sind kurze Beschreibungen Ihrer Sicherungsoptionen:

Vollständige Datensicherungen (Datenbanken)

Für die Wiederherstellbarkeit Ihrer Bereitstellung ist eine vollständige Datenbanksicherung erforderlich. Eine vollständige Sicherung enthält einen Teil des Transaktionsprotokolls, sodass Sie die vollständige Sicherung wiederherstellen können. Vollständige Sicherungen sind eigenständig, da sie die gesamte Datenbank so darstellen, wie sie vorhanden sind, wenn Sie sie gesichert haben. Weitere Informationen finden Sie unter Vollständige Datenbanksicherungen.

Differenzielle Datensicherungen (Datenbanken)

Eine differenzielle Datenbanksicherung zeichnet nur die Daten auf, die sich seit der letzten vollständigen Datenbanksicherung geändert haben, die als differenzielle Basis bezeichnet wird. Differenzielle Datenbanksicherungen sind kleiner und schneller als vollständige Datenbanksicherungen. Diese Option spart Backup-Zeit zu kosten erhöhter Komplexität. Bei großen Datenbanken können differenzielle Sicherungen in kürzeren Intervallen als Datenbanksicherungen auftreten, wodurch die Exposition bei Arbeitsverlusten reduziert wird. Weitere Informationen finden Sie unter Differenzielle Datenbanksicherungen.

Außerdem sollten Sie Ihre Transaktionsprotokolle regelmäßig sichern. Diese Sicherungen sind zum Wiederherstellen von Daten erforderlich, wenn Sie das vollständige Datenbanksicherungsmodell verwenden. Wenn Sie Transaktionsprotokolle sichern, können Sie die Datenbank zum Fehlerpunkt oder zu einem früheren Zeitpunkt wiederherstellen.

Transaktionsprotokollsicherungen

Das Transaktionsprotokoll ist ein serieller Datensatz aller Änderungen, die in einer Datenbank aufgetreten sind, zusätzlich zu der Transaktion, die jede Änderung ausgeführt hat. Das Transaktionsprotokoll zeichnet den Beginn jeder Transaktion, die Änderungen an den Daten auf, und gegebenenfalls genügend Informationen, um die während dieser Transaktion vorgenommenen Änderungen rückgängig zu machen. Das Protokoll wächst kontinuierlich, wenn protokollierte Vorgänge in der Datenbank auftreten.

Durch das Sichern von Transaktionsprotokollen können Sie die Datenbank zu einem früheren Zeitpunkt wiederherstellen. Sie können die Datenbank beispielsweise an einem Punkt wiederherstellen, bevor unerwünschte Daten eingegeben wurden oder ein Fehler aufgetreten ist. Neben Datenbanksicherungen müssen Transaktionsprotokollsicherungen Teil Ihrer Wiederherstellungsstrategie sein. Weitere Informationen finden Sie unter Transaktionsprotokollsicherungen (SQL Server).

Transaktionsprotokollsicherungen verwenden in der Regel weniger Ressourcen als vollständige Sicherungen. Daher können Sie häufiger Transaktionsprotokollsicherungen erstellen als vollständige Sicherungen, wodurch das Risiko des Verlusts von Daten reduziert wird. Manchmal ist eine Transaktionsprotokollsicherung jedoch größer als eine vollständige Sicherung. Beispielsweise führt eine Datenbank mit hoher Transaktionsrate dazu, dass das Transaktionsprotokoll schnell wächst. In diesem Fall sollten Sie häufiger Transaktionsprotokollsicherungen erstellen. Weitere Informationen finden Sie unter Problembehandlung bei vollen Transaktionsprotokollen (SQL Serverfehler 9002).

Sie können die folgenden Arten von Transaktionsprotokollsicherungen ausführen:

  • Eine reine Protokollsicherung enthält nur Transaktionsprotokolldatensätze für ein Intervall, ohne dass massenweise Änderungen vorgenommen werden.
  • Eine Massenprotokollsicherung enthält Protokoll- und Datenseiten, die durch Massenvorgänge geändert wurden. Die Zeitpunktwiederherstellung ist nicht zulässig.
  • Eine Tail-Log-Sicherung wird aus einer möglicherweise beschädigten Datenbank übernommen, um die noch nicht gesicherten Protokolldatensätze zu erfassen. Nach einem Ausfall des Arbeitsverlusts wird eine Tail-Log-Sicherung übernommen und kann entweder reine Protokoll- oder Massenprotokolldaten enthalten.

Da die Synchronisierung von Daten für eine erfolgreiche Wiederherstellung von Azure DevOps Server von entscheidender Bedeutung ist, sollten Sie markierte Transaktionen als Teil Ihrer Sicherungsstrategie verwenden, wenn Sie Sicherungen manuell konfigurieren. Weitere Informationen finden Sie unter Erstellen eines Sicherungszeitplans und -Plans und manuelles Sichern von Azure DevOps Server.

Sicherungen des Diensts auf Anwendungsebene

Die einzige Sicherung, die für die logische Anwendungsebene erforderlich ist, ist für den Verschlüsselungsschlüssel für Reporting Services erforderlich. Wenn Sie die Funktion "Geplante Sicherungen" verwenden, um Ihre Bereitstellung zu sichern, wird dieser Schlüssel für Sie als Teil des Plans gesichert. Sie können davon ausgehen, dass Sie Websites sichern müssen, die als Projektportale verwendet werden.

Obwohl Sie eine Anwendungsebene einfacher sichern können als eine Datenebene, gibt es noch mehrere Schritte zum Wiederherstellen einer Anwendungsebene. Sie müssen eine weitere Anwendungsebene für Azure DevOps Server installieren, Projektsammlungen umleiten, um die neue Anwendungsebene zu verwenden, und die Portalwebsites für Projekte umleiten.

Standarddatenbanknamen

Wenn Sie die Namen Ihrer Datenbanken nicht anpassen, können Sie die in Ihrer Bereitstellung von Azure DevOps Server verwendeten Datenbanken mithilfe der folgenden Tabelle identifizieren. Wie bereits erwähnt, verfügen nicht alle Bereitstellungen über alle diese Datenbanken. Wenn Sie beispielsweise Azure DevOps Server nicht mit Reporting Services konfiguriert haben, verfügen Sie nicht über die ReportServer- oder ReportServerTempDB-Datenbanken. Ebenso verfügen Sie nicht über die Datenbank für System Center Virtual Machine Manager (SCVMM), VirtualManagerDB, es sei denn, Sie konfigurieren Azure DevOps Server zur Unterstützung der Lab Management. Darüber hinaus werden die Datenbanken, die Azure DevOps Server verwendet, möglicherweise über mehrere Instanzen von SQL Server oder über mehrere Server verteilt.

Hinweis

Standardmäßig wird das Präfix TFS_ den Namen aller Datenbanken hinzugefügt, die beim Installieren von Azure DevOps Server oder während des Betriebs automatisch erstellt werden.

Datenbank Beschreibung
TFS_Configuration Die Konfigurationsdatenbank für Azure DevOps Server enthält die Katalog-, Servernamen und Konfigurationsdaten für die Bereitstellung. Der Name dieser Datenbank kann zusätzliche Zeichen zwischen TFS_ und Konfiguration enthalten, z. B. den Benutzernamen der Person, die Azure DevOps Server installiert hat. Beispielsweise kann der Name der Datenbank TFS_UserNameConfiguration
TFS_Warehouse Die Lagerdatenbank enthält die Daten zum Erstellen des Warehouses, das Reporting Services verwendet. Der Name dieser Datenbank kann zusätzliche Zeichen zwischen TFS_ und Warehouse enthalten, z. B. den Benutzernamen der Person, die Azure DevOps Server installiert hat. Beispielsweise kann der Name der Datenbank TFS_UserNameWarehouse werden.
TFS_CollectionName Die Datenbank für eine Projektsammlung enthält alle Daten für die Projekte in dieser Auflistung. Diese Daten umfassen Quellcode, Buildkonfigurationen und Laborverwaltungskonfigurationen. Die Anzahl der Auflistungsdatenbanken entspricht der Anzahl der Auflistungen. Wenn Sie beispielsweise drei Auflistungen in Ihrer Bereitstellung haben, müssen Sie diese drei Sammlungsdatenbanken sichern. Der Name jeder Datenbank kann zusätzliche Zeichen zwischen TFS_ und CollectionName enthalten, z. B. den Benutzernamen der Person, die die Sammlung erstellt hat. Beispielsweise kann der Name einer Sammlungsdatenbank TFS_UserNameCollectionName werden.
TFS_Analysis Die Datenbank für SQL Server Analysis Services enthält die Datenquellen und Cubes für Ihre Bereitstellung von Azure DevOps Server. Der Name dieser Datenbank kann zusätzliche Zeichen zwischen TFS_ und Analysis enthalten, z. B. den Benutzernamen der Person, die Analysis Services installiert hat. Beispielsweise kann der Name der Datenbank TFS_UserNameAnalysis werden.
Hinweis: Sie können diese Datenbank sichern, aber Sie müssen das Lager aus der wiederhergestellten TFS_Warehouse Datenbank neu erstellen.
ReportServer Die Datenbank für Reporting Services enthält die Berichte und Berichtseinstellungen für Ihre Bereitstellung von Azure DevOps Server.
Hinweis: Wenn Reporting Services auf einem separaten Server von Azure DevOps Server installiert ist, ist diese Datenbank möglicherweise nicht auf dem Datenebenenserver für Azure DevOps Server vorhanden. In diesem Fall müssen Sie sie separat von Azure DevOps Server konfigurieren, sichern und wiederherstellen. Sie sollten die Wartung der Datenbanken synchronisieren, um Synchronisierungsfehler zu vermeiden.
ReportServerTempDB Die temporäre Datenbank für Reporting Services speichert vorübergehend Informationen, wenn Sie bestimmte Berichte ausführen.
Hinweis: Wenn Reporting Services auf einem separaten Server als Azure DevOps Server installiert ist, ist diese Datenbank möglicherweise nicht auf dem Datenebenenserver für Azure DevOps Server vorhanden. In diesem Fall müssen Sie sie separat von Azure DevOps Server konfigurieren, sichern und wiederherstellen. Sie sollten jedoch die Wartung der Datenbanken synchronisieren, um Synchronisierungsfehler zu vermeiden.
VirtualManagerDB Die Verwaltungsdatenbank für SCVMM enthält die Informationen, die Sie in der SCVMM-Administratorkonsole anzeigen, z. B. virtuelle Computer, Hosts virtueller Computer, Bibliotheksserver und deren Eigenschaften.
Hinweis: Wenn SCVMM auf einem separaten Server als Azure DevOps Server installiert ist, ist diese Datenbank möglicherweise nicht auf dem Datenebenenserver für Azure DevOps Server vorhanden. In diesem Fall müssen Sie sie separat von Azure DevOps Server konfigurieren, sichern und wiederherstellen. Sie sollten jedoch markierte Transaktionen verwenden und die Wartung der Datenbanken synchronisieren, um Synchronisierungsfehler zu vermeiden.