Datenbanken, Bereitstellungstopologien und Sicherung

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 Sicherungszeitplan für die Datenbanken erstellen, von denen Azure DevOps Server abhängig ist. Um Ihre Azure DevOps Server Bereitstellung vollständig wiederherzustellen, sichern Sie zunächst 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 nicht übereinstimmenden Daten zu vermeiden, müssen Sie alle Sicherungen mit dem gleichen Zeitstempel synchronisieren. Die einfachste Art zum Sicherstellen einer erfolgreichen Synchronisierung, besteht in der Verwendung markierter Transaktionen. Indem Sie routinemäßig verwandte Transaktionen in jeder Datenbank markieren, richten Sie eine Reihe allgemeiner Wiederherstellungspunkte in den Datenbanken ein. Eine schrittweise Anleitung zum Sichern einer Einzelserverbereitstellung mit Berichterstellung finden Sie unter Erstellen eines Sicherungszeitplans und -plans.

Sichern von Datenbanken

Schützen Sie Ihre Azure DevOps-Bereitstellung vor Datenverlust, indem Sie Datenbanksicherungen erstellen. Die folgende Tabelle und die zugehörigen Abbildungen zeigen, welche Datenbanken gesichert werden sollen, und bieten Beispiele dafür, wie diese Datenbanken in einer Bereitstellung physisch verteilt werden können.

Datenbanktyp Produkt Erforderliche Komponente?
Konfigurationsdatenbank Azure DevOps Server Ja
Warehouse-Datenbank Azure DevOps Server Ja
Projektsammlungsdatenbanken Azure DevOps Server Ja
Berichtsdatenbanken SQL Server Reporting Services No
Analysedatenbanken SQL Server Analysis Services Nein

Bereitstellungstopologien

Auf Grundlage der Bereitstellungskonfiguration können sich alle Datenbanken, die gesichert werden müssen, auf dem gleichen physischen Server befinden, wie in dieser Beispieltopologie dargestellt.

Hinweis

Dieses Beispiel enthält keine Reporting Services- oder SharePoint-Produkte, sodass Sie keine Datenbanken sichern müssen, die der Berichterstellung, Analyse oder SharePoint-Produkte zugeordnet sind.

Einfache Azure DevOps Server Datenbankstruktur

Die Datenbanken können alternativ jedoch auch auf verschiedenen Servern oder Serverfarmen verteilt sein. In dieser Beispieltopologie müssen Sie die folgenden Datenbanken sichern, die über sechs Server oder Serverfarmen skaliert sind:

  • Konfigurationsdatenbank

  • Warehouse-Datenbank

  • die Projektsammlungsdatenbanken, die sich auf dem SQL Server Cluster befinden

  • die Sammlungsdatenbank, die sich auf dem eigenständigen Server befindet, auf dem SQL Server

  • Datenbanken auf dem Server, der Reporting Services ausführt

  • Datenbank auf dem Server, der Analysis Services ausführt

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

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

Komplexe Azure DevOps Server Datenbankstruktur

In diesen 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 sich wieder mit der wiederhergestellten Bereitstellung verbinden können.

Zu sichernde Datenbanken

Die folgende Liste enthält zusätzliche Details zu den Zusicherungen, je nach Ihren Bereitstellungsressourcen.

Wichtig

Alle Datenbanken in der folgenden Liste sind SQL Server Datenbanken. Sie können zwar SQL Server Management Studio verwenden, um einzelne Datenbanken jederzeit zu sichern, sollten Sie jedoch nach Möglichkeit auf die Verwendung dieser einzelnen Sicherungen verzichten. Bei der Wiederherstellung aus einzelnen Sicherungen können unerwartete Ergebnisse auftreten, 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, einschließlich der Konfigurationsdatenbank, der Warehousedatenbank und einer Datenbank für jede Projektsammlung in der Bereitstellung. Diese Datenbanken können sich alle auf demselben Server befinden, auf mehrere Instanzen in derselben SQL Server Bereitstellung verteilt oder auf mehrere Server verteilt sein. Unabhängig von ihrer physischen Verteilung müssen Sie alle Datenbanken mit dem gleichen Zeitstempel sichern, damit ein ausreichender Schutz vor Datenverlust gegeben ist. Sie können Datenbanksicherungen manuell oder automatisch mithilfe von Wartungsplänen durchführen, die zu bestimmten Zeiten oder in bestimmten Intervallen ausgeführt werden.

    Wichtig

    Die Liste der Azure DevOps-Datenbanken ist nicht statisch. Eine neue Datenbank wird jedes Mal erstellt, wenn Sie eine Auflistung erstellen. Wenn Sie eine Auflistung erstellen, stellen Sie sicher, dass Sie dem Wartungsplan die Datenbank für diese Auflistung hinzufügen.

  • Datenbanken für Reporting Services und Analysis Services: Wenn Ihre Bereitstellung SQL Server Reporting Services oder SQL Server Analysis Services verwendet, um Berichte für Azure DevOps Server, müssen Sie die Berichts- und Analysedatenbanken sichern. Sie müssen jedoch weiterhin bestimmte Datenbanken nach der Wiederherstellung erneut generieren, z. B. das Warehouse.
  • 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 Berichtsserverdatenbank gespeichert sind. Sie können diesen Schlüssel manuell sichern, indem Sie entweder das Reporting Services-Konfigurationstool oder ein Befehlszeilentool verwenden.

Erweiterte Vorbereitung für Sicherungen

Wenn Sie Azure DevOps bereitstellen, sollten Sie die von Ihnen erstellten Konten und alle von Ihnen angegebenen Computernamen, Kennwörter und Setupoptionen aufzeichnen. Bewahren Sie außerdem stets eine Kopie aller Wiederherstellungsmaterialien, Dokumente und Datenbanken- sowie Transaktionsprotokollsicherungen an einem sicheren Ort auf. Um auch für Unglücksfälle aller Art gerüstet zu sein, z. B. für Feuer oder Naturkatastrophen, bewahren Sie Duplikate Ihrer Serversicherungen an einem anderen Ort als dem Serverstandort auf. Dies hilft Ihnen, sich vor dem Verlust wichtiger Daten zu schützen. Am besten ist es, jeweils drei Kopien der Sicherungsmedien aufzubewahren, davon mindestens eine extern in einer sorgfältig kontrollierten Umgebung.

Wichtig

Führen Sie regelmäßig eine Testdatenwiederherstellung aus, um sicherzustellen, dass die Dateien korrekt gesichert wurden. Eine Testwiederherstellung kann Hardwareprobleme aufdecken, die bei einer reinen Softwareüberprüfung nicht auftreten.

Wenn Sie eine Datenbank sichern und wiederherstellen, müssen Sie die Daten auf Medien mit einer Netzwerkadresse sichern (z. B. auf Bänder und Datenträger, die als Netzlaufwerke freigegeben wurden). Der Sicherungsplan sollte Vorschriften für die Verwaltung von Medien enthalten, wie z. B. folgende Vorgehensweisen:

  • Einen Verfolgungs- und Verwaltungsplan für die Aufbewahrung und den Wiedereinsatz von Sicherungssätzen
  • Einen Plan für das Überschreiben von Sicherungsmedien
  • Bei Multiserverumgebungen die Festlegung, ob zentralisierte oder verteilte Sicherungen zu verwenden sind
  • Eine Möglichkeit, die Haltbarkeit von Medien zu verfolgen
  • Ein Verfahren, um die Auswirkungen beim Verlust eines Sicherungssatzes oder Sicherungsmediums, z. B. eines Bands, möglichst gering zu halten
  • Eine Entscheidung, ob Sicherungssätze vor Ort oder an einem anderen Ort zu lagern sind und eine Analyse über deren mögliche Auswirkungen auf die Wiederherstellungszeit

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

Sie können einen Server mithilfe der verfügbaren Features für geplante Sicherungen sichern oder manuell Wartungspläne in SQL Server erstellen, um die Datenbanken zu sichern, die sich auf Ihre Azure DevOps-Bereitstellung beziehen. Die Azure DevOps-Datenbanken funktionieren in Beziehung zueinander. Wenn Sie einen manuellen Plan erstellen, sollten Sie sie gleichzeitig sichern und wiederherstellen. Weitere Informationen zu Strategien zum Sichern von Datenbanken finden Sie unter Sichern und Wiederherstellen 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 beispielsweise mit einer großen Bereitstellung arbeiten und sich gegen Datenverluste schützen und gleichzeitig begrenzte Speicherressourcen effizient nutzen möchten, 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. Außerdem können Sie versuchen, eine Backup-Komprimierung zu verwenden oder Sicherungen auf mehrere Dateien aufzuteilen. Nachstehend finden Sie kurze Beschreibungen der Sicherungsoptionen:

Vollständige Datensicherungen (Datenbanken)

Eine vollständige Datenbanksicherung ist für die Wiederherstellbarkeit Ihrer Bereitstellung erforderlich. Eine vollständige Sicherung schließt einen Teil des Transaktionsprotokolls ein, sodass die vollständige Sicherung wiederhergestellt werden kann. Vollständige Sicherungen sind darin in sich abgeschlossen, dass sie die gesamte Datenbank in dem Zustand darstellen, in dem sie sich zum Zeitpunkt der Sicherung befand. 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 benötigt weniger Zeit für die Sicherung, büßt dabei aber eine größere Komplexität ein. Für große Datenbanken können differenzielle Sicherungen in kürzeren Intervallen auftreten als Datenbanksicherungen, die die Gefahr des Datenverlusts reduzieren. Weitere Informationen finden Sie unter Differenzielle Datenbanksicherungen.

Sie sollten die Transaktionsprotokolle ebenfalls regelmäßig sichern. Diese Sicherungen sind für das Wiederherstellen von Daten notwendig, wenn Sie das Vollständige Datenbanksicherungsmodell verwenden. Wenn Sie Transaktionsprotokolle sichern, können Sie die Datenbank bis zum Fehlerpunkt oder zu einem früheren Zeitpunkt wiederherstellen.

Transaktionsprotokollsicherungen

Das Transaktionsprotokoll ist ein serieller Datensatz aller Änderungen, die zusätzlich zu der Transaktion, die jede Änderung ausgeführt hat, in einer Datenbank vorgenommen wurden. Das Transaktionsprotokoll zeichnet den Beginn jeder Transaktion, die Änderungen an den Daten und ggf. ausreichende Informationen auf, um die während der Transaktion durchgeführten Änderungen rückgängig zu machen. Die Protokollgröße nimmt kontinuierlich in dem Maße zu, wie protokollierte Vorgänge in der Datenbank auftreten.

Wenn Sie Transaktionsprotokolle sichern, können Sie die Datenbank so wiederherstellen, wie sie zu einem früheren Zeitpunkt war. Beispielsweise können Sie die Datenbank bis zu einem Punkt wiederherstellen, bevor unerwünschte Daten eingegeben wurden oder ein Fehler aufgetreten ist. Neben Datenbanksicherungen muss Ihre Wiederherstellungsstrategie auch Transaktionsprotokollsicherungen umfassen. Weitere Informationen finden Sie unter Transaktionsprotokollsicherungen (SQL Server).

Transaktionsprotokollsicherungen benötigen im Allgemeinen weniger Ressourcen als vollständige Sicherungen. Aus diesem Grund können Sie Transaktionsprotokollsicherungen häufiger als vollständige Sicherungen erstellen und so das Risiko eines Datenverlusts verringern. Dennoch können Transaktionsprotokollsicherungen mitunter größer als vollständige Sicherungen sein. Beispielsweise bewirkt eine Datenbank mit einer hohen Transaktionsrate, dass das Transaktionsprotokoll schnell anwächst. In diesem Fall sollten Sie häufiger Transaktionsprotokollsicherungen erstellen. Weitere Informationen finden Sie unter Problembehandlung für ein vollständiges Transaktionsprotokoll (SQL Server Fehler 9002).

Es stehen die folgenden Sicherungstypen für Transaktionsprotokolle zur Verfügung:

  • Eine reine Protokollsicherung enthält nur Transaktionsprotokolldatensätze für ein Intervall, keine Massenänderungen.
  • Eine Massenprotokollsicherung schließt Protokoll- und Datenseiten ein, die durch Massenvorgänge geändert wurden. Die Zeitpunktwiederherstellung ist nicht zulässig.
  • Eine Sicherung des Protokollfragments wird von einer möglicherweise beschädigten Datenbank erstellt, um die noch nicht gesicherten Protokolldatensätze zu erfassen. Sicherungen des Protokollfragments werden nach Auftreten eines Fehlers erstellt, um den Verlust von Daten zu verhindern, und können entweder reine Protokoll- oder Massenprotokolldaten enthalten.

Da die Synchronisierung von Daten für eine erfolgreiche Wiederherstellung von Azure DevOps Server entscheidend 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 undManuelles Sichern Azure DevOps Server.

Dienstsicherungen auf Anwendungsebene

Die einzige sicherung, die für die logische Anwendungsebene erforderlich ist, ist der Verschlüsselungsschlüssel für Reporting Services. Wenn Sie die Bereitstellung mit der Funktion für geplante Sicherungen sichern, wird dieser Schlüssel als Teil des Plans für Sie gesichert. Sie können davon ausgehen, dass Sie Websites sichern müssen, die als Projektportale verwendet werden.

Obwohl Sie eine Anwendungsebene einfacher als eine Datenebene sichern können, gibt es noch mehrere Schritte zum Wiederherstellen einer Anwendungsebene. Sie müssen eine andere Anwendungsebene für Azure DevOps Server installieren, Projektsammlungen zur Verwendung der neuen Anwendungsebene umleiten und die Portalwebsites für Projekte umleiten.

Standardmäßige Datenbanknamen

Wenn Sie die Namen Ihrer Datenbanken nicht anpassen, können Sie anhand der folgenden Tabelle die Datenbanken identifizieren, die in Ihrer Bereitstellung von Azure DevOps Server verwendet werden. 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 von Lab Management. Darüber hinaus können die von Azure DevOps Server verwendeten Datenbanken auf mehrere instance SQL Server oder auf mehrere Server verteilt sein.

Hinweis

Standardmäßig wird das Präfix TFS_ den Namen aller Datenbanken hinzugefügt, die automatisch erstellt werden, wenn Sie Azure DevOps Server installieren oder während sie ausgeführt wird.

Datenbank BESCHREIBUNG
TFS_Configuration Die Konfigurationsdatenbank für Azure DevOps Server enthält den Katalog, die Servernamen und die 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 Warehouse-Datenbank enthält die Daten zur Erstellung des Warehouses, das von Reporting Services verwendet wird. 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 sein.
TFS_CollectionName Die Datenbank für eine Projektauflistung enthält alle Daten für die Projekte in dieser Auflistung. Diese Daten enthalten den Quellcode, die Buildkonfigurationen und Lab Management-Konfigurationen. Die Anzahl der Auflistungsdatenbanken entspricht der Anzahl der Auflistungen. Wenn Sie beispielsweise drei Sammlungen 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. der Benutzername der Person, die die Sammlung erstellt hat. Beispielsweise kann der Name einer Sammlungsdatenbank TFS_UserNameCollectionName sein.
TFS_Analysis Die Datenbank für SQL Server Analysis Services enthält die Datenquellen und Cubes für Die 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 sein.
Hinweis: Sie können diese Datenbank sichern, aber Sie müssen das Warehouse 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 anderen 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 die Wartung der Datenbanken synchronisieren, um Synchronisierungsfehler zu vermeiden.
ReportServerTempDB Die temporäre Datenbank für Reporting Services speichert Informationen vorübergehend, 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, virtuelle Computerhosts, virtuelle Computerbibliotheksserver und ihre 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.