Diese Seite wurde von der Cloud Translation API übersetzt.

Sicherungs- und Notfallwiederherstellungsdienst für Microsoft SQL Server

SQL Server-Daten erfassen

Mit dem Sicherungs- und Notfallwiederherstellungsdienst können Sie die folgenden Arten von Microsoft SQL Server-Anwendungen erfassen:

Instanzen
Datenbanken in Always On-Verfügbarkeitsgruppen
Konsistenzgruppen von Datenbanken
Einzelne Datenbanken
Systemdatenbanken
Nutzerdatenbanken
Datenbanken in VMs

Bei der Sicherung und Notfallwiederherstellung werden die Microsoft SQL Server-Daten getrennt von dem Speicherort verschoben und verwaltet, an dem Microsoft SQL Server seinen primären Speicher schreibt.

Eine Sicherungs-/Wiederherstellungsanwendung speichert Anwendungsdaten auf einem Staging-Laufwerk. Mit Snapshots auf dem Staging-Laufwerk kann die Sicherungs-/Wiederherstellungsanwendung Verlaufsdaten verwalten.

Microsoft SQL Server-Daten sichern

Die Vorbereitung der Sicherung von Microsoft SQL Server-Daten umfasst vier Schritte:

Fügen Sie Server hinzu, auf denen Microsoft SQL Server-Datenbanken gehostet werden.
VMs und Microsoft SQL Server-Datenbanken finden
Definieren Sie Vorlagen für Sicherungs- und Notfallwiederherstellungsrichtlinien und Ressourcenprofile gemäß Ihren RPO- und RTO-Werten.

Bei Datenbanken, die das vollständige Wiederherstellungsmodell von Microsoft SQL Server verwenden, können sowohl die Datenbank als auch ihre Protokolle erfasst werden. Daher kann eine erfasste Datenbank durch Vorspulen der Logs auf einen bestimmten Zeitpunkt wiederhergestellt werden.
Microsoft SQL Server-Datenbanken Sicherungs- und Notfallwiederherstellungsrichtlinienvorlagen und Ressourcenprofile zuweisen.

Datenerfassung

Beachten Sie beim Erfassen von Daten Folgendes:

Ein Staging-Laufwerk wird automatisch erstellt und auf einem Server bereitgestellt.
Es wird eine erste vollständige Kopie auf das Staging-Laufwerk kopiert. Nachfolgende Kopien bestehen nur aus geänderten Blöcken.
Das Staging-Laufwerk wird vom Server getrennt.
Auf der Sicherungs-/Wiederherstellungs-Appliance wird ein Snapshot des Staging-Laufwerks erstellt.

SQL Server-Datenbankprotokolle erfassen

Die Datenbankprotokollerfassung wird unter Details und Einstellungen einer Snapshot-Richtlinie festgelegt. So können mit einer einzigen Snapshot-Richtlinie Protokolle für Microsoft SQL Server-Datenbanken und ‑Konsistenzgruppen erfasst werden, die Microsoft SQL Server-Datenbanken enthalten.

Die Häufigkeit, mit der Datenbankprotokolle erfasst werden, wird unabhängig von der Datenbank definiert. Beispielsweise kann eine Datenbank jeden Tag und die zugehörigen Protokolle jede Stunde erfasst werden.

Die Häufigkeit der Datenbankprotokollsicherung wird in Minuten festgelegt. Die Häufigkeit, mit der Protokolle erfasst werden, darf nicht höher sein als die Häufigkeit, mit der die zugehörige Datenbank erfasst wird. Wenn die Erfassungshäufigkeit einer Datenbank beispielsweise alle 24 Stunden erfolgt, muss die Erfassungshäufigkeit der Protokolldatei maximal alle 24 Stunden betragen.

Die Aufbewahrungsdauer von Protokollen wird ebenfalls unabhängig von der zugehörigen Datenbank definiert. Mit separaten Aufbewahrungszeiträumen können Sie genügend Protokollinformationen für alle Snapshot- und OnVault-Versionen einer Datenbank aufbewahren. Wenn die Snapshot-Daten einer Datenbank beispielsweise drei Tage und die OnVault-Daten sieben Tage lang aufbewahrt werden, können Sie die Logaufbewahrung auf alle sieben Tage festlegen. In diesem Beispiel kann ein einzelnes erfasstes Datenbank-Image ausgewählt und seine Protokolle über den gesamten Zeitraum vor- und zurückgerollt werden.

Datenbankprotokolle werden auf einem einzigen Staging-Laufwerk im Snapshot-Pool für Sicherung und Notfallwiederherstellung bereitgestellt. Um Speicherplatz im Snapshot-Pool zu sparen, können Sie die Datenbank mit einer erweiterten Einstellung anweisen, ihre Protokolle zu komprimieren.

Sie können angeben, dass Microsoft SQL Server-Datenbanktransaktionsprotokolle auf einer Remote-Sicherungs-/Wiederherstellungs-Appliance repliziert werden sollen. Sie können die Protokolle am Remotestandort für jedes Datenbank-Image innerhalb des Aufbewahrungszeitraums der replizierten Protokolle verwenden.

Größe des Staging-Laufwerks für das Datenbankprotokoll anpassen

Der physische Speicherplatz, der für Sicherungen der Protokolle einer Datenbank erforderlich ist, wird automatisch von der Sicherung und Notfallwiederherstellung verwaltet. Dieser wird als Protokoll-Staging-Laufwerk bezeichnet und ist vom Speicherplatz getrennt, der vom Quellserver verwaltet wird. Bei der Sicherung und Notfallwiederherstellung werden mindestens die typischen Protokollgrößen und ihre Aufbewahrungsdauer bewertet und bei Bedarf ein größeres Laufwerk verwendet.

Um die Speicheranforderungen für die Protokolle einer Datenbank effizienter und effektiver zu verwalten, bieten Snapshot-Richtlinien die folgenden erweiterten Einstellungen:

Aufbewahrungsdauer für Protokollsicherungen: Die Aufbewahrungsdauer von Protokollen wird unabhängig von der zugehörigen Datenbank definiert. Mit separaten Aufbewahrungsraten können Sie genügend Protokollinformationen für alle Snapshot-Versionen einer Datenbank aufbewahren. Die Aufbewahrungsdauer von Protokollen ist eine obligatorische Einstellung.
Log-Staging-Laufwerk – automatisches Größenwachstum: Hiermit wird der Prozentsatz festgelegt, um den das Staging-Laufwerk, auf dem sich die Protokolle befinden, automatisch erweitert werden soll.
Geschätzte Änderungsrate: Hiermit wird die tägliche Änderung (in Prozent) definiert. So kann die Sicherungs-/Wiederherstellungs-Appliance die Größe des Staging-Laufwerks, das zum Speichern von Protokollen erforderlich ist, besser berechnen.
Datenbankprotokollsicherung komprimieren: Die Quelldatenbank wird angewiesen, ihre Protokolle vor der Erfassung auf der Sicherungs-/Wiederherstellungs-Appliance zu komprimieren. Der Datenbankserver führt während der Protokollsicherung eine Protokollkomprimierung durch (standardmäßig Aktiviert).

Optionen für die SQL Server-Datenerfassung

In den folgenden Abschnitten werden die Optionen für die Datenerfassung in SQL Server beschrieben.

Instanzen, einzelne Datenbanken und Datenbankgruppen erfassen

Mit dem Sicherungs- und Notfallwiederherstellungs-Agenten können Instanzen, Nutzerdatenbanken, Systemdatenbanken und Datenbankgruppen auf physischen und virtuellen Servern erfasst werden.

Beim Erfassen einer SQL Server-Instanz haben Sie die Möglichkeit, die gesamte Instanz oder ausgewählte Datenbanken innerhalb der Instanz zu erfassen. Wenn Sie die gesamte Instanz schützen, werden neue Datenbanken, die der Instanz hinzugefügt werden, automatisch in den nächsten Sicherungs- und Notfallwiederherstellungs-Auftrag aufgenommen. Datenbanken in einer Instanz werden angehalten und mit einem einzigen Sicherungsplan erfasst.

Wenn die Datenbank- und Protokollerfassung für die Sicherung und Notfallwiederherstellung in der Richtlinie für den Sicherungsplan aktiviert ist, können alle Datenbanken in dieser Instanz zum selben Zeitpunkt wiederhergestellt werden. Die Wiederherstellung und Fortschreibung der Protokolle für alle oder einzelne Datenbanken in einer Instanz erfolgt über die Benutzeroberfläche für Sicherung und Notfallwiederherstellung mit einer einzigen Aktion.

Auf einzelne Mitglieder einer Instanz kann nach Bedarf über die Vorgänge „mount“, „clone“, „LiveClone“ und „restore“ zugegriffen werden.

Konsistenzgruppen erfassen

Eine Konsistenzgruppe ist eine Gruppe von Datenbanken, die zusammen mit einer einzelnen Vorlage für die Sicherungsrichtlinie und einem Ressourcenprofil inaktiviert und erfasst werden. Die Mitgliedschaft in einer Konsistenzgruppe wird manuell zugewiesen und eignet sich für Gruppen von Datenbanken, deren Mitglieder sich nicht sehr oft ändern. Wenn Sie neue Mitglieder einer Datenbankgruppe automatisch schützen möchten, erstellen und schützen Sie diese Datenbanken stattdessen in einer SQL Server-Instanz.

Wie der Name schon sagt, sorgen Konsistenzgruppen für eine konsistente Erfassung und Wiederherstellung zu einem bestimmten Zeitpunkt in mehreren Datenbanken. Wenn die Datenbank- und Protokollerfassungstechnologie von Backup und Notfallwiederherstellung in der Richtlinie für den Sicherungsplan aktiviert ist, können alle Datenbanken in dieser Gruppe zum selben Zeitpunkt wiederhergestellt werden. Die Wiederherstellung und Fortschreibung der Protokolle für alle oder einzelne Datenbanken in einer Konsistenzgruppe erfolgt über die Benutzeroberfläche für Sicherung und Notfallwiederherstellung mit einer einzigen Aktion. Mitglieder einer Konsistenzgruppe müssen sich in derselben Instanz befinden.

Eine Konsistenzgruppe kann aus folgenden Elementen bestehen:

Eine oder mehrere Systemdatenbanken
Eine oder mehrere Nutzerdatenbanken
System- oder Nutzerdatenbanken zusammen
Null oder mehr Dateisysteme (Laufwerkbuchstaben oder Bereitstellungspunkte)

Auf einzelne Mitglieder einer Konsistenzgruppe kann über die Vorgänge „Bereitstellen“, „Klonen“, „LiveClone“ und „Wiederherstellen“ zugegriffen werden.

Datenbanken in einer clusterbasierten Failover-Instanz müssen vom aktiven Knoten erkannt werden. Nach der Sicherung folgt GO dem aktiven SQL-Knoten in einem Cluster. Schutzjobs werden auch bei einem Failover ausgeführt. Konsistenzgruppen beschleunigen nicht nur die Erfassungs- und Zugriffsvorgänge, sondern verbrauchen auch weniger Systemressourcen (V-Disks) als der individuelle Schutz von Datenbanken.

Sie können die Integrität der Datenbanksicherung regelmäßig prüfen, indem Sie ein Sicherungs-Image auf einem Server bereitstellen und eine Datenbankkonsistenzprüfung ausführen. Mit der Workflow-Funktion können Sie den Validierungsprozess automatisieren.

Datenbanken und Boot-Volume einer VM erfassen

Wenn Sie Datenbanken auf VMs erfassen, können Sie auch das Bootvolume der VM erfassen. Wenn das Bootvolume einer VM zusammen mit ihren Datenbanken erfasst wird, kann ein Image erstellt werden, das eine voll funktionsfähige Datenbank und VM enthält. Das Image kann dann an einen neuen, dauerhaften Speicherort migriert werden.

SQL Server-Daten replizieren

Daten können zur Wiederherstellung, Notfallwiederherstellung oder zu Test- oder Entwicklungszwecken auf einer zweiten Sicherungs-/Wiederherstellungs-Appliance oder in der Cloud repliziert werden. Die Datenreplikation ist seit langem ein Hindernis für die effiziente Datenverwaltung in einer geografisch verteilten Umgebung. Bei der Sicherung und Notfallwiederherstellung werden diese Probleme durch Komprimierung behoben, die:

Die Gesamtnutzung des Netzwerks wird reduziert.
Es ist kein spezieller WAN-Beschleuniger oder -Optimierer erforderlich.
Verschlüsselt Daten mit dem AES-256-Verschlüsselungsstandard. Die Authentifizierung zwischen Sicherungs-/Wiederherstellungsgeräten erfolgt mit 1.024-Bit-Zertifikaten.

Die Replikation wird durch die Vorlagenrichtlinien für Sicherungs- und Notfallwiederherstellungsrichtlinien gesteuert:

Bei Produktion zu Spiegel-Richtlinien gibt es mehrere Möglichkeiten, Daten auf einer zweiten Sicherungs-/Wiederherstellungs-Appliance zu replizieren.
Bei Produktion zu OnVault-Richtlinien werden Daten mithilfe einer proprietären Sicherungs- und Notfallwiederherstellungs-Engine in den Objektspeicher übertragen.

Protokolle replizieren

Wenn die Option Datenbankprotokollsicherung aktivieren einer Richtlinie auf Aktivieren gesetzt ist, können mit der erweiterten Einstellung Protokolle replizieren Microsoft SQL Server-Transaktionsprotokolle auf eine Remote-Sicherungs-/Wiederherstellungs-Appliance repliziert werden. Damit ein Job zur Protokollreplikation ausgeführt werden kann, muss die Vorlage eine StreamSnap-Replikationsrichtlinie sowie ein Ressourcenprofil mit einer Remote-Sicherungs-/Wiederherstellungsanwendung enthalten. Außerdem muss mindestens eine erfolgreiche Replikation der Datenbank durchgeführt worden sein. Sie können die Protokolle dann an der Remote-Site für jedes Datenbank-Image innerhalb des Aufbewahrungszeitraums der replizierten Protokolle verwenden. Diese Funktion ist standardmäßig aktiviert.

Bei der Protokollreplikation wird die Replikation zwischen der lokalen und der Remote-Sicherungs-/Wiederherstellungs-Appliance mit der StreamSnap-Technologie durchgeführt. Die Protokollreplikation erfolgt direkt vom lokalen Snapshot-Pool zum Snapshot-Pool auf der Remote-Appliance.

Protokolle können auch in einem OnVault-Pool repliziert werden. Wenn diese Option aktiviert ist (nicht standardmäßig), werden Protokolle an jeden OnVault-Pool gesendet, der durch eine gültige Kombination aus OnVault-Richtlinie oder Ressourcenprofil angegeben ist (z.B. OnVault-Pool 1, der in der Richtlinie ausgewählt ist, und OnVault-Pool 1, der im Ressourcenprofil angegeben ist. Die Logaufbewahrung im OnVault-Pool stimmt immer mit der Logaufbewahrung im Snapshot-Pool überein.

Auf SQL Server-Daten zugreifen

Bei Microsoft SQL Server-Datenbanken, die das vollständige Wiederherstellungsmodell verwenden, können Sie mithilfe von Sicherung und Notfallwiederherstellung sofort eine Kopie der Datenbank abrufen, die zu einem bestimmten Zeitpunkt vorwärtsgerollt wurde. Der Vorgang zum Vorwärtsrollen wird in der Verwaltungskonsole angegeben.

Bei Microsoft SQL Server-Datenbanken, die das einfache Wiederherstellungsmodell verwenden, können Sicherungen und Notfallwiederherstellungen sofort eine Sicherung der Datenbank bereitstellen, deren Aufbewahrungsdauer noch nicht abgelaufen ist.

Unabhängig vom verwendeten Microsoft SQL Server-Wiederherstellungsmodell kann über die iSCSI-Schnittstelle auf Microsoft SQL Server-Daten zugegriffen werden. Wenn Sie VMware (GCVE) verwenden, kann auch über einen NFS-Datenspeicher auf den ESXi-Host zugegriffen werden.

Rollenbasierte Zugriffssteuerung

Sie können festlegen, welche Nutzer Zugriff auf Daten, Sicherungs- und Notfallwiederherstellungsfunktionen sowie Ressourcen haben. Erfasste Daten können als vertraulich gekennzeichnet und Nutzern der Sicherung und Notfallwiederherstellung Zugriffsberechtigungen für vertrauliche Daten gewährt werden.

Halterungen

Die Bereitstellungsfunktion für Sicherung und Notfallwiederherstellung bietet sofortigen Zugriff auf Daten, ohne dass Daten verschoben werden müssen. Erfasste Kopien von Datenbanken können über die Benutzeroberfläche für Sicherung und Notfallwiederherstellung fortgeschrieben und auf einem beliebigen Datenbankserver bereitgestellt werden. Mit dem Sicherungs- und Notfallwiederherstellungsdienst gibt es zwei Möglichkeiten, eine Microsoft SQL Server-Datenbank bereitzustellen:

Über das virtuelle Anwendungs-Mount werden die erfassten Microsoft SQL Server-Daten einem Zielserver als Microsoft SQL Server-Datenbank zur Verfügung gestellt. So können Sie Kopien von Produktionsdatenbanken für die nicht kommerzielle Nutzung erstellen und verwalten. Virtuelle Anwendungs-Mounts werden von der Sicherungs-/Wiederherstellungs-Appliance erstellt und erfordern keine manuellen Eingriffe durch Datenbank-, Server- oder Speicheradministratoren. Virtuelle Anwendungs-Mounts können für Datenbankberichte, Analysen, Integritätsprüfungen sowie für Tests und Entwicklung verwendet werden. Weitere Informationen zu virtuellen Datenbanken finden Sie unter SQL Server-Datenbank als neue virtuelle Datenbank bereitstellen und Datenbanken in SQL AlwaysOn-Verfügbarkeitsgruppen bereitstellen.
Bei der Standardbindung, auch als direkte Bindung bezeichnet, werden die erfassten Microsoft SQL Server-Daten einem Zielserver als Dateisystem und nicht als Datenbank präsentiert und zur Verfügung gestellt. Das ist hilfreich, wenn eine Datenbank beschädigt oder verloren gegangen ist oder ein Datenbankserver ersetzt wird. In solchen Fällen können Sie die Datenbank nicht mithilfe einer Wiederherstellung wiederherstellen. Stattdessen können Sie ein Image bereitstellen und die Datenbankdateien aus dem bereitgestellten Image an ihren ursprünglichen Speicherort auf dem Datenbankserver kopieren. Direkte Bereitstellungen werden unter Aufgenommene Microsoft SQL-Daten bereitstellen beschrieben.

LiveClones

Ein LiveClone ist eine unabhängige Kopie von Microsoft SQL Server-Daten, die aktualisiert und maskiert werden kann, bevor sie Nutzern zur Verfügung gestellt wird. So können Entwicklungs- und Testteams mit den neuesten Daten arbeiten, ohne die Daten manuell verwalten oder die Produktionsumgebung beeinträchtigen zu müssen.

Clones

Mit der Klonfunktion wird eine Kopie der Produktionsdaten an einen anderen Speicherort als die Quelle verschoben. Wie lange ein Klonvorgang dauert, hängt von der Datenmenge ab. Weitere Informationen zu Klonen finden Sie unter SQL Server-Datenbanken klonen.

Wiederherstellungen

Bei einer Wiederherstellung werden die Produktionsdaten auf einen bestimmten Zeitpunkt zurückgesetzt. Bei der Wiederherstellung werden Daten tatsächlich verschoben. Wiederherstellungsvorgänge werden in der Regel nach einer massiven Datenbeschädigung durchgeführt. Wie lange die Wiederherstellung dauert, hängt von der Datenmenge ab.

Wenn Sie eine Datenbank wiederherstellen und dann Protokolle anwenden möchten, muss sich die wiederhergestellte Datenbank im Wiederherstellungsmodus befinden. Sie können die Datenbank im Wiederherstellungsmodus wiederherstellen und dann die Protokolle bis zu einem bestimmten Zeitpunkt vorspulen. Wenn Sie die Datenbank wiederherstellen, ohne Ohne Wiederherstellung wiederherstellen anzugeben, wird die Datenbank wiederhergestellt und ohne Anwenden von Protokollen online geschaltet. Weitere Informationen zur Wiederherstellung finden Sie unter SQL Server-Datenbanken wiederherstellen. Wenn Sie eine Wiederherstellung mit nahezu null Ausfallzeit durchführen möchten, müssen Sie die Daten zuerst bereitstellen, wie unter SQL-Daten bereitstellen und migrieren beschrieben.

Workflows zum Automatisieren des Zugriffs auf SQL Server-Daten

Workflows automatisieren den Zugriff auf die erfassten Microsoft SQL Server-Daten. In Workflows können Daten als direkte Bereitstellung oder als Live-Klon dargestellt werden:

Direkte Bereitstellungen (standard- oder anwendungsabhängig) eignen sich gut für Microsoft SQL Server-Daten, die vor der Präsentation nicht maskiert werden müssen. Eine bereitgestellte Datenkopie kann manuell oder automatisch nach einem Zeitplan aktualisiert werden. Mit direkten Bereitstellungen können Sie sofort auf erfasste Microsoft SQL Server-Daten zugreifen, ohne die Daten tatsächlich zu verschieben.
Ein LiveClone ist eine Kopie Ihrer Produktionsdaten aus Microsoft SQL Server, die manuell oder geplant aktualisiert werden kann. Sie können sensible Daten in einem LiveClone maskieren, bevor Sie sie Nutzern zur Verfügung stellen.

Durch die Kombination der automatisierten Microsoft SQL Server-Datenerfassung und Zugriffssteuerung von Sicherung und Notfallwiederherstellung mit Workflows und ihren optionalen Datenmaskierungsfunktionen können Sie Umgebungen zur Selbstbereitstellung erstellen. Nutzer können ihre eigenen Umgebungen fast sofort bereitstellen.

Ein Administrator für Sicherung und Notfallwiederherstellung kann beispielsweise eine Sicherungsvorlage erstellen, mit der Microsoft SQL Server-Daten gemäß einem bestimmten Zeitplan erfasst werden. Der Administrator kann die erfassten Produktionsdaten von Microsoft SQL Server als vertraulich kennzeichnen und nur für Nutzer mit den entsprechenden Zugriffsrechten zugänglich machen.

Nachdem die Zugriffsrechte definiert und Daten erfasst wurden, kann der Administrator einen Workflow erstellen, der Folgendes ermöglicht:

Stellt die erfassten Microsoft SQL Server-Daten als Live-Klon oder als direktes Laufwerk bereit.
Aktualisiert die LiveClone- oder speicherbaren Microsoft SQL Server-Daten geplant oder auf Abruf
Optional werden nach jeder Aktualisierung automatisch Scripts auf die Microsoft SQL Server-Daten des LiveClones angewendet. Das ist nützlich, um vertrauliche Microsoft SQL Server-Daten zu maskieren.

Sobald der Workflow abgeschlossen ist, können Nutzer mit den entsprechenden Zugriffsrechten ihre Umgebungen mit dem LiveClone oder den speicherbaren Microsoft SQL Server-Daten bereitstellen.

Sicherung und Notfallwiederherstellung mit vorhandenen Sicherungsprodukten

Da immer mehr Unternehmen die Anwendungsentwicklung mit Produktionsdatenbanken beschleunigen möchten, müssen Sicherung und Notfallwiederherstellung häufig mit älteren Sicherungsprodukten zusammenarbeiten, die in denselben Produktionsdatenbanken ausgeführt werden. Sicherung und Notfallwiederherstellung können problemlos mit anderen Produkten koexistieren, die Daten aus Produktionsdatenbanken erfassen, wenn diese Best Practices befolgt werden.

Für die Sicherung und Notfallwiederherstellung gibt es eine proprietäre Methode zum Blockänderungs-Tracking, sodass Sicherungslösungen, die SQL oder andere Methoden zur Sicherung verwenden, nicht von geplanten Jobs zur Datenerfassung für die Sicherung und Notfallwiederherstellung betroffen sind.

Sicherungsjobs können sehr datenintensiv sein. Sie können lange dauern und sich während der Sicherungszeiträume auf die Leistung der Datenbank auswirken. Durch Sicherung und Notfallwiederherstellung werden die Auswirkungen während der Jobs minimiert. Aber selbst ein inkrementelles Update auf Blockebene muss einige E/A-Vorgänge generieren und etwas Zeit in Anspruch nehmen.

Anforderung	Planen Sie keine Jobs für die bisherige Sicherungssoftware und für die Sicherung und Notfallwiederherstellung so, dass es zu Überschneidungen kommt.
Best Practice	Planen Sie Sicherungs- und Notfallwiederherstellungs-Datenbankjobs so, dass sie zu einer Zeit beginnen, zu der die bisherige Sicherungssoftware fertig sein sollte. Planen Sie die Ausführung der alten Sicherungssoftware nicht direkt nach Abschluss eines Sicherungs- und Notfallwiederherstellungsjobs.
Grund	Wenn alte Sicherungsjobs und Sicherungs- und Notfallwiederherstellungsjobs gleichzeitig ausgeführt werden, kann dies zu erheblichen Leistungseinbußen auf dem Datenbankserver führen, was zu Instabilität und möglicherweise zu einem Ausfall führt.

Mit Datenbankprotokollen werden einzelne Transaktionen in einer Datenbank erfasst, was eine Wiederherstellung zu einem bestimmten Zeitpunkt ermöglicht. Die meisten Anwendungsfälle für Agilität drehen sich darum, regelmäßig Datenbank-Snapshots aus der Produktion abzurufen. Die Häufigkeit variiert je nach Anwendungsfall von täglich bis wöchentlich oder alle zwei Wochen. Daher müssen Entwickler ihre nicht produktionsreife Instanz in der Regel nicht auf einen bestimmten Zeitpunkt aus der Quelle (Produktion) zurücksetzen. In der Regel müssen Sie dann keine Protokolle mehr erfassen und verwalten, um eine Lösung für die Agilität von Sicherung und Notfallwiederherstellung zu implementieren.

Anforderung	Logs können nur von einem System verwaltet (aufgenommen oder gekürzt) werden, entweder von der alten Sicherungssoftware oder vom Sicherungs- und Notfallwiederherstellungsdienst.
Best Practice	Lassen Sie die gesamte Protokollverwaltung weiterhin von der alten Sicherungssoftware ausführen und verwenden Sie keine Sicherungen und Notfallwiederherstellungen, um Protokolle in dieser Umgebung zu schützen.
Grund	Wenn Ihr System zum Verwalten von Protokollen (Erfassen oder Kürzen/Löschen) konfiguriert ist und die alte Sicherungssoftware auch Protokolle erfasst und/oder kürzt/löscht, kann es in einem oder beiden Systemen zu einer unvollständigen Protokollkette kommen, was die Wiederherstellung der Datenbank zu einem bestimmten Zeitpunkt erschwert oder unmöglich macht.

Weitere Informationen

SQL Server-Datenbanken für den Sicherungs- und Notfallwiederherstellungsdienst vorbereiten

Weitere Dokumentation zu Sicherung und Notfallwiederherstellung für Microsoft SQL Server

Diese Seite ist eine von mehreren Seiten zum Schutz und zur Wiederherstellung von Microsoft SQL Server-Datenbanken, Binärdateien und Supportdateien mithilfe von Sicherung und Notfallwiederherstellung.

Weitere Informationen finden Sie hier: