Backup und DR für Microsoft SQL Server auf einer Sicherungs-/Wiederherstellungs-Appliance

SQL Server-Daten erfassen

Mit Backup und DR 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

Backup und DR verschiebt und verwaltet die Microsoft SQL Server-Daten getrennt von dem Ort, an dem Microsoft SQL Server seinen primären Speicher schreibt.

Eine Sicherungs-/Wiederherstellungs-Appliance speichert Anwendungsdaten auf einem Staging-Laufwerk. Mithilfe von Snapshots auf dem Staging-Laufwerk kann die Sicherungs-/Wiederherstellungs-Appliance Verlaufsdaten verwalten.

Sicherung von Microsoft SQL Server-Daten vorbereiten

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

  1. Fügen Sie Server hinzu, die Microsoft SQL Server-Datenbanken hosten.

  2. VMs und Microsoft SQL Server-Datenbanken erkennen.

  3. Definieren Sie Vorlagen für Backup und DR-Richtlinien sowie Ressourcenprofile gemäß Ihren RPOs und RTOs.

    Datenbanken, die das vollständige Wiederherstellungsmodell von Microsoft SQL Server verwenden, können sowohl die Datenbank als auch ihre Logs erfassen. Daher kann eine erfasste Datenbank durch das Vorwärtsrollen ihrer Logs zu einem bestimmten Zeitpunkt wiederhergestellt werden.

  4. Weisen Sie Microsoft SQL Server-Datenbanken Vorlagen für Backup und DR-Richtlinien sowie Ressourcenprofile zu.

Datenerfassung

Beachten Sie beim Erfassen von Daten Folgendes:

  • Ein Staging-Laufwerk wird automatisch erstellt und auf einem Server bereitgestellt.

  • Auf dem Staging-Laufwerk wird eine erste vollständige Kopie erstellt. 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-Datenbanklogs erfassen

Die Erfassung von Datenbanklogs wird in den Details und Einstellungen einer Snapshot-Richtlinie festgelegt. Mit einer einzigen Snapshot-Richtlinie können Logs für Microsoft SQL Server-Datenbanken und Konsistenzgruppen, die Microsoft SQL Server-Datenbanken enthalten, erfasst werden.

Die Häufigkeit, mit der Datenbanklogs erfasst werden, wird getrennt von der Datenbank definiert. Beispielsweise kann eine Datenbank jeden Tag und ihre Logs jede Stunde erfasst werden.

Die Häufigkeit der Sicherung von Datenbanklogs wird in Minuten festgelegt. Die Häufigkeit, mit der Logs erfasst werden, darf die Häufigkeit, mit der die zugehörige Datenbank erfasst wird, nicht überschreiten. Wenn die Datenbankerfassungshäufigkeit beispielsweise alle 24 Stunden beträgt, muss die Erfassungshäufigkeit der Logdatei kleiner oder gleich 24 Stunden sein.

Die Logaufbewahrung wird ebenfalls separat von der zugehörigen Datenbank definiert. Durch separate Aufbewahrungsdauern können Sie genügend Loginformationen aufbewahren, um alle Snapshot- und OnVault-Versionen einer Datenbank abzudecken. Wenn beispielsweise die Snapshot-Daten einer Datenbank drei Tage lang und die OnVault-Daten sieben Tage lang aufbewahrt werden, können Sie die Logaufbewahrung auf alle sieben Tage festlegen. In diesem Beispiel kann eine einzelne erfasste Datenbank ausgewählt und ihre Logs können über den gesamten Zeitraum hinweg vorwärtsgerollt werden.

Datenbanklogs werden auf einem einzelnen Staging-Laufwerk im Snapshot-Pool von Backup und DR bereitgestellt. Um Speicherplatz im Snapshot-Pool zu sparen, können Sie eine erweiterte Einstellung verwenden, um die Datenbank anzuweisen, ihre Logs zu komprimieren.

Sie können festlegen, dass Microsoft SQL Server-Datenbanktransaktionslogs auf einer Remote-Sicherungs-/Wiederherstellungs-Appliance repliziert werden. Sie können die Logs am Remote-Standort für jede Datenbank innerhalb des Aufbewahrungszeitraums der replizierten Logs verwenden.

Größe des Staging-Laufwerks des Datenbanklogs anpassen

Der physische Speicherplatz, der für die Sicherung der Logs einer Datenbank erforderlich ist, wird automatisch von Backup und DR verwaltet. Dies wird als Log-Staging-Laufwerk bezeichnet und ist vom Speicher getrennt, der vom Quellserver verwaltet wird. Backup und DR wertet mindestens die typischen Protokollgrößen und deren Aufbewahrungsdauer aus und verwendet bei Bedarf ein größeres Laufwerk.

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

  • Aufbewahrungsdauer für Log-Sicherungen: Die Aufbewahrungsdauer für Logs wird separat von der zugehörigen Datenbank definiert. Durch separate Aufbewahrungsraten können Sie genügend Loginformationen aufbewahren, um alle Snapshot-Versionen einer Datenbank abzudecken. Die Aufbewahrungsdauer für Logs ist eine obligatorische Einstellung.

  • Log Staging Disk Size Growth: Definiert den Prozentsatz, um den das Staging-Laufwerk, auf dem sich die Logs befinden, automatisch vergrößert wird.

  • Geschätzte Änderungsrate: Definiert die tägliche Änderung (Prozent), sodass die Sicherungs-/Wiederherstellungs-Appliance die Größe des Staging-Laufwerks, das zum Speichern von Logs erforderlich ist, besser berechnen kann.

  • Datenbankprotokollsicherung komprimieren: Weist die Quelldatenbank an, ihre Protokolle vor der Erfassung auf der Sicherungs-/Wiederherstellungs-Appliance zu komprimieren. Der Datenbankserver führt während der Protokollsicherung eine Protokollkomprimierung durch (Standardeinstellung ist Aktiviert).

Optionen für die SQL Server-Datenerfassung

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

Instanzen, einzelne Datenbanken und Datenbankgruppen erfassen

Der Backup und DR-Agent wird verwendet, um Instanzen, Nutzerdatenbanken, Systemdatenbanken und Datenbankgruppen auf physischen und virtuellen Servern zu erfassen.

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 der Instanz hinzugefügte Datenbanken automatisch in den nächsten Backup und DR-Erfassungsjob einbezogen. Datenbanken in einer Instanz werden stillgelegt und zusammen mit einem einzigen Sicherungsplan erfasst.

Wenn die Datenbank- und Logerfassung von Backup und DR in der Sicherungsplanrichtlinie aktiviert ist, können alle Datenbanken in dieser Instanz auf denselben Zeitpunkt wiederhergestellt werden. Die Wiederherstellung und das Rollforward der Logs für alle oder einzelne Datenbanken in einer Instanz werden über die Benutzeroberfläche von Backup und DR mit einer einzigen Aktion durchgeführt.

Auf einzelne Mitglieder einer Instanz kann nach Bedarf über Bereitstellungs-, Klon-, LiveClone- und Wiederherstellungsvorgänge zugegriffen werden.

Konsistenzgruppen erfassen

Eine Konsistenzgruppe ist eine Gruppe von Datenbanken, die zusammen mit einer einzigen Sicherungsplan-Richtlinienvorlage und einem Ressourcenprofil stillgelegt und erfasst werden. Die Mitgliedschaft in einer Konsistenzgruppe wird manuell zugewiesen und eignet sich für Datenbankgruppen, deren Mitglieder sich nicht sehr oft ändern. Wenn Sie neue Mitglieder einer Gruppe von Datenbanken 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 über mehrere Datenbanken hinweg. Wenn die Datenbank- und Logerfassungstechnologie von Backup und DR in der Sicherungsplanrichtlinie aktiviert ist, können alle Datenbanken in dieser Gruppe auf denselben Zeitpunkt wiederhergestellt werden. Die Wiederherstellung und das Rollforward der Logs für alle oder einzelne Datenbanken in einer Konsistenzgruppe werden über die Benutzeroberfläche von Backup und DR mit einer einzigen Aktion durchgeführt. Mitglieder einer Konsistenzgruppe müssen sich in derselben Instanz befinden.

Eine Konsistenzgruppe kann aus Folgendem 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 Bereitstellungs-, Klon-, LiveClone- und Wiederherstellungsvorgänge zugegriffen werden.

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

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

Datenbanken und Boot-Volume einer VM erfassen

Wenn Sie Datenbanken auf VMs erfassen, können Sie auch das Boot-Volume der VM erfassen. Wenn das Boot-Volume einer VM zusammen mit ihren Datenbanken erfasst wird, kann eine Sicherung erstellt werden, die eine voll funktionsfähige Datenbank und VM ist. Die Sicherung kann dann an einen neuen, dauerhaften Speicherort migriert werden.

SQL Server-Daten replizieren

Daten können zu Wiederherstellungs-, Notfallwiederherstellungs- oder Test- oder Entwicklungszwecken auf eine zweite Sicherungs-/Wiederherstellungs-Appliance oder in die Cloud repliziert werden. Die Datenreplikation ist seit Langem ein Hindernis für eine effiziente Datenverwaltung in einer geografisch verteilten Umgebung. Die Backup- und DR-Replikation löst diese Probleme durch eine Komprimierung, die:

  • Senkt die allgemeine Netzwerknutzung.

  • Ein dedizierter WAN-Beschleuniger oder -Optimierer ist nicht mehr erforderlich.

  • Verschlüsselt Daten mit dem AES-256-Verschlüsselungsstandard. Die Authentifizierung zwischen Sicherungs-/Wiederherstellungs-Appliances erfolgt über 1024-Bit-Zertifikate.

Die Replikation wird durch Richtlinien in der Backup- und DR-Richtlinienvorlage gesteuert:

  • Produktion zu Spiegelung-Richtlinien bieten mehrere Optionen zum Replizieren von Daten auf eine zweite Sicherungs-/Wiederherstellungs-Appliance.

  • Production to OnVault-Richtlinien verwenden eine proprietäre Backup und DR-Engine, um Daten in den Objektspeicher zu übertragen.

Logs replizieren

Wenn die Option Datenbank-Log-Sicherung aktivieren einer Richtlinie auf Aktivieren gesetzt ist, können mit der erweiterten Einstellung Logs replizieren Microsoft SQL Server-Datenbanktransaktionslogs auf eine Remote-Sicherungs-/Wiederherstellungs-Appliance repliziert werden. Damit ein Protokollreplikationsjob ausgeführt werden kann, muss die Vorlage eine StreamSnap-Replikationsrichtlinie sowie ein Ressourcenprofil enthalten, das eine Remote-Sicherungs-/Wiederherstellungs-Appliance angibt. Außerdem muss zuerst mindestens eine erfolgreiche Replikation der Datenbank abgeschlossen werden. Sie können die Logs am Remote-Standort dann für jede Datenbanksicherung innerhalb des Aufbewahrungszeitraums der replizierten Logs verwenden. Diese Funktion ist standardmäßig aktiviert.

Bei der Logreplikation wird die StreamSnap-Technologie verwendet, um die Replikation zwischen den lokalen und Remote-Sicherungs-/Wiederherstellungs-Appliances durchzuführen. Die Logreplikation erfolgt direkt vom lokalen Snapshot-Pool zum Snapshot-Pool auf der Remote-Appliance.

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

Auf SQL Server-Daten zugreifen

Für Microsoft SQL Server-Datenbanken, die das vollständige Wiederherstellungsmodell verwenden, kann Backup und DR sofort eine Kopie der Datenbank bereitstellen, die auf einen bestimmten Zeitpunkt zurückgesetzt wurde. Der Roll-Forward-Vorgang wird in der Appliance-Verwaltungskonsole angegeben.

Für Microsoft SQL Server-Datenbanken, die das grundlegende Wiederherstellungsmodell verwenden, kann Backup und DR jede Sicherung der Datenbank, deren Aufbewahrungsdauer noch nicht abgelaufen ist, sofort bereitstellen.

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 auf Daten auch über einen NFS-Datenspeicher zugegriffen werden, der dem ESXi-Host präsentiert wird.

Rollenbasierte Zugriffssteuerung

Sie können festlegen, welche Nutzer Zugriff auf Daten, Backup und DR-Funktionen sowie Ressourcen haben. Erfasste Daten können als sensibel gekennzeichnet werden und Backup und DR-Nutzern kann die Zugriffsberechtigung für sensible Daten gewährt werden.

Halterungen

Die Bereitstellungsfunktion von Backup und DR bietet sofortigen Zugriff auf Daten, ohne dass diese verschoben werden müssen. Erfasste Kopien von Datenbanken können über die Benutzeroberfläche von Backup und DR aktualisiert und auf einem beliebigen Datenbankserver bereitgestellt werden. Backup und DR bietet zwei Möglichkeiten, eine Microsoft SQL Server-Datenbank bereitzustellen:

  • Die Bereitstellung der virtuellen Anwendung stellt die erfassten Microsoft SQL Server-Daten einem Zielserver als Microsoft SQL Server-Datenbank zur Verfügung. So können Sie Kopien von Produktionsdatenbanken für die Verwendung außerhalb der Produktion erstellen und verwalten. Virtuelle Anwendungseinbindungen werden von der Sicherungs-/Wiederherstellungs-Appliance erstellt und erfordern kein manuelles Eingreifen von Datenbank-, Server- oder Speicheradministratoren. Virtuelle Anwendungsmounts können für Datenbankberichte, Analysen, Integritätstests sowie Tests und Entwicklung verwendet werden. Virtuelle Datenbanken werden unter SQL Server-Datenbank als neue virtuelle Datenbank bereitstellen und Datenbanken in SQL AlwaysOn-Verfügbarkeitsgruppen bereitstellen ausführlich beschrieben.

  • Bei der Standardbereitstellung, auch als direkte Bereitstellung bezeichnet, werden die erfassten Microsoft SQL Server-Daten einem Zielserver als Dateisystem und nicht als Datenbank zur Verfügung gestellt. Das ist nützlich, wenn eine Datenbank beschädigt ist oder verloren geht oder wenn ein Datenbankserver ersetzt wird. In solchen Fällen können Sie die Datenbank nicht mit einem Wiederherstellungsvorgang wiederherstellen. Stattdessen können Sie eine Sicherung bereitstellen und die Datenbankdateien aus der bereitgestellten Sicherung an ihren ursprünglichen Speicherort auf dem Datenbankserver kopieren. Direkte Bereitstellungen werden unter Erfasste 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. Die Zeit, die für einen Klonvorgang benötigt wird, hängt von der Menge der beteiligten Daten ab. Klone werden unter SQL Server-Datenbanken klonen ausführlich beschrieben.

Wiederherstellungen

Bei einer Wiederherstellung werden die Produktionsdaten auf einen bestimmten Zeitpunkt zurückgesetzt. Bei Wiederherstellungsvorgängen werden Daten tatsächlich verschoben. Wiederherstellungsvorgänge werden in der Regel nach einer massiven Datenbeschädigung durchgeführt. Die für einen Wiederherstellungsvorgang erforderliche Zeit hängt von der Menge der betroffenen Daten ab.

Wenn Sie eine Datenbank wiederherstellen und dann Logs anwenden möchten, muss sich die wiederhergestellte Datenbank im Wiederherstellungsmodus befinden. Sie können die Datenbank im Wiederherstellungsmodus wiederherstellen und dann die Logs bis zu einem bestimmten Zeitpunkt vorwärts rollen. Wenn Sie die Datenbank wiederherstellen, ohne Restore with no Recovery anzugeben, wird die Datenbank wiederhergestellt und online geschaltet, ohne dass Logs angewendet werden. Wiederherstellungen werden unter SQL Server-Datenbanken wiederherstellen beschrieben. Für eine Wiederherstellung mit nahezu null Ausfallzeit stellen Sie die Daten zuerst bereit, wie unter SQL-Daten bereitstellen und migrieren beschrieben.

Workflows zur Automatisierung des Zugriffs auf SQL Server-Daten

Workflows automatisieren den Zugriff auf die erfassten Microsoft SQL Server-Daten. Workflows können Daten als direkte Bereitstellung oder als LiveClone darstellen:

  • Direkte Bereitstellungen (Standard oder anwendungsspezifisch) eignen sich gut für Microsoft SQL Server-Daten, die vor der Präsentation nicht maskiert werden müssen. Eine bereitgestellte Kopie von Daten 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 Microsoft SQL Server-Produktionsdaten, die manuell oder nach einem Zeitplan aktualisiert werden kann. Sie können sensible Daten in einem LiveClone maskieren, bevor Sie ihn Nutzern zur Verfügung stellen.

Wenn Sie die automatisierte Microsoft SQL Server-Datenerfassung und Zugriffssteuerung von Backup und DR mit Workflows und ihren optionalen Datenmaskierungsfunktionen kombinieren, können Sie Umgebungen mit automatischer Bereitstellung erstellen. Nutzer können ihre eigenen Umgebungen fast sofort bereitstellen.

Ein Backup- und DR-Administrator kann beispielsweise eine Richtlinie für eine Sicherungsvorlage erstellen, die Microsoft SQL Server-Daten nach einem bestimmten Zeitplan erfasst. Der Administrator kann die erfassten Microsoft SQL Server-Produktionsdaten als vertraulich kennzeichnen und nur für Nutzer mit den entsprechenden Zugriffsrechten zugänglich machen.

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

  • Stellt die erfassten Microsoft SQL Server-Daten als LiveClone oder als direkte Bereitstellung zur Verfügung.

  • Aktualisiert die LiveClone- oder bereitstellbaren Microsoft SQL Server-Daten nach einem Zeitplan oder bei Bedarf

  • Optional werden Skripts nach jeder Aktualisierung automatisch auf die Microsoft SQL Server-Daten des LiveClone angewendet. Dies ist nützlich, um sensible Microsoft SQL Server-Daten zu maskieren.

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

Backup und DR in Kombination mit vorhandenen Sicherungsprodukten

Da immer mehr Unternehmen die Anwendungsentwicklung mithilfe von Produktionsdatenbanken beschleunigen möchten, muss Backup und DR häufig mit Legacy-Sicherungsprodukten koexistieren, die in denselben Produktionsdatenbankumgebungen arbeiten. Backup und DR können problemlos mit anderen Produkten koexistieren, die Daten aus Produktionsdatenbanken erfassen, wenn diese Best Practices befolgt werden.

Backup und DR verfügt über eine proprietäre Methode zur Änderungsblockverfolgung, sodass Sicherungslösungen, die SQL oder andere Methoden zum Abrufen der Sicherungen verwenden, nicht von geplanten Backup und DR-Datenerfassungsjobs betroffen sind.

Sicherungsjobs können sehr E/A-intensiv sein. Sie können lange dauern und sich während der Sicherungsfenster auf die Leistung der Datenbank auswirken. Backup und DR minimiert die Auswirkungen während der Jobs, aber selbst ein inkrementelles Update auf Blockebene muss einige E/A-Vorgänge generieren und dauert etwas.

Anforderung Planen Sie die Ausführung von Jobs mit älterer Sicherungssoftware und Backup und DR nicht so, dass es zu zeitlichen Überschneidungen kommt.
Best Practice Planen Sie Backup- und DR-Datenbankjobs so, dass sie zu einem Zeitpunkt beginnen, zu dem die Legacy-Sicherungssoftware fertig sein sollte. Planen Sie die Ausführung der Legacy-Sicherungssoftware nicht unmittelbar nach dem normalen Abschluss eines Backup und DR-Jobs.
Grund Wenn Legacy-Sicherungsjobs und Backup und DR-Jobs gleichzeitig ausgeführt werden, kann dies die Leistung des Datenbankservers erheblich beeinträchtigen und zu Instabilität und möglicherweise zu einem Ausfall führen.

Datenbanklogs werden verwendet, um einzelne Transaktionen in einer Datenbank zu erfassen, was die Wiederherstellung zu einem bestimmten Zeitpunkt ermöglicht. Die meisten Agilitätsanwendungsfälle konzentrieren sich darauf, regelmäßig Datenbank-Snapshots aus der Produktion zu erhalten. Die Häufigkeit reicht je nach Anwendungsfall von täglich bis wöchentlich oder alle zwei Wochen. Daher müssen Anwendungsentwickler ihre Nicht-Produktionsinstanz in der Regel nicht auf einen bestimmten Zeitpunkt aus der Quelle (Produktion) zurücksetzen. Dadurch ist es in der Regel nicht mehr erforderlich, Logs im Rahmen einer agilen Backup- und DR-Lösung zu erfassen und zu verwalten.

Anforderung Nur ein System kann Logs verwalten (erfassen oder kürzen (löschen)), entweder die Legacy-Sicherungssoftware oder Backup und DR.
Best Practice Lassen Sie weiterhin die gesamte Logverwaltung von der Legacy-Sicherungssoftware ausführen und verwenden Sie Backup und DR nicht, um Logs in dieser Umgebung zu schützen.
Grund Wenn Ihr System so konfiguriert ist, dass Logs verwaltet (erfasst oder gekürzt/gelöscht) werden, und die Legacy-Sicherungssoftware ebenfalls Logs erfasst und/oder kürzt/löscht, kann es sein, dass eines oder beide Systeme eine unvollständige Logkette haben. Dadurch wird es schwierig oder unmöglich, die Datenbank zu einem bestimmten Zeitpunkt wiederherzustellen.

Weitere Dokumentation zu Backup und DR für Microsoft SQL Server

Diese Seite gehört zu einer Reihe von Seiten, die sich mit dem Schutz und der Wiederherstellung von Microsoft SQL Server-Datenbanken mit Backup und DR befassen. Weitere Informationen finden Sie unter:

Weitere Informationen

SQL Server-Datenbanken für Backup und DR vorbereiten