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

SQL Server-Daten erfassen

Mit Backup and 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 and DR verschiebt und verwaltet die Microsoft SQL Server-Daten unabhängig davon, wo Microsoft SQL Server den primären Speicher schreibt.

Eine Sicherungs-/Wiederherstellungs-Appliance speichert Anwendungsdaten auf einem Staging-Laufwerk. Snapshots auf der Staging-Festplatte ermöglichen es der Sicherungs-/Wiederherstellungs-Appliance, Verlaufsdaten zu verwalten.

Sichern von Microsoft SQL Server-Daten vorbereiten

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

  1. Fügen Sie Server hinzu, auf denen Microsoft SQL Server-Datenbanken gehostet werden.

  2. VMs und Microsoft SQL Server-Datenbanken ermitteln

  3. Definieren Sie Backup- und DR-Richtlinienvorlagen und Ressourcenprofile entsprechend Ihren RPOs und RTOs.

    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 zu einem bestimmten Zeitpunkt wiederhergestellt werden, indem ihre Logs vorwärts gerollt werden.

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

Datenerfassung

Beachten Sie beim Erfassen von Daten Folgendes:

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

  • Eine erste vollständige Kopie wird auf dem Staging-Laufwerk erstellt. Nachfolgende Kopien bestehen nur aus geänderten Blöcken.

  • Das Staging-Laufwerk wurde 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. Damit können mit einer einzelnen Snapshot-Richtlinie Protokolle 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 separat von der der Datenbank definiert. Beispielsweise kann eine Datenbank jeden Tag und ihre Logs jede Stunde erfasst werden.

Die Häufigkeit der Sicherung von Datenbankprotokollen wird in Minuten festgelegt. Die Häufigkeit, mit der Protokolle erfasst werden, darf die Häufigkeit, mit der die zugehörige Datenbank erfasst wird, nicht überschreiten. Wenn die Erfassungshäufigkeit für die Datenbank beispielsweise alle 24 Stunden erfolgt, muss die Erfassungshäufigkeit für die Logdatei gleich oder kleiner als alle 24 Stunden sein.

Die Aufbewahrung von Logs wird auch separat von der zugehörigen Datenbank definiert. Durch separate Aufbewahrungszeiträume 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 lang und die OnVault-Daten sieben Tage lang aufbewahrt werden, können Sie die Protokollaufbewahrung für alle sieben Tage festlegen. In diesem Beispiel kann eine einzelne erfasste Datenbank ausgewählt und ihre Logs über den gesamten Zeitraum hinweg vorwärts gerollt werden.

Datenbanklogs werden auf einem einzelnen Staging-Laufwerk im Backup and DR-Snapshot-Pool 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 angeben, dass Transaktionslogs von Microsoft SQL Server-Datenbanken auf ein externes Sicherungs-/Wiederherstellungsgerät repliziert werden sollen. Sie können die Logs am Remote-Standort für jede Datenbank innerhalb des Aufbewahrungszeitraums der replizierten Logs verwenden.

Größe des Staging-Laufwerks für das Datenbanklog ändern

Der physische Speicherplatz, der für die Sicherung der Logs einer Datenbank erforderlich ist, wird automatisch von Backup and DR verwaltet. Dies wird als Log-Staging-Laufwerk bezeichnet und ist vom Speicher getrennt, der vom Quellserver verwaltet wird. Backup and DR bewertet mindestens die typischen Loggrößen und den Aufbewahrungszeitraum und verwendet bei Bedarf eine größere Festplatte.

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

  • Aufbewahrungsdauer für Logsicherungen: Die Aufbewahrung von Logs wird separat von der zugehörigen Datenbank definiert. Durch separate Aufbewahrungsraten können Sie genügend Protokollinformationen für alle Snapshot-Versionen einer Datenbank aufbewahren. Die Aufbewahrungsdauer für Logs ist eine Pflichteinstellung.

  • Log Staging Disk Size Growth (Wachstum der Größe des Staging-Laufwerks für Logs): Definiert den Prozentsatz, um den das Staging-Laufwerk, auf dem sich die Logs befinden, automatisch vergrößert werden soll.

  • Geschätzte Änderungsrate: Definiert die tägliche Änderung (in Prozent), damit die Sicherungs-/Wiederherstellungs-Appliance die Größe des Staging-Laufwerks, das zum Speichern von Protokollen benötigt wird, besser berechnen kann.

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

Optionen für die Datenerfassung in SQL Server

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

Instanzen, einzelne Datenbanken und Datenbankgruppen erfassen

Mit dem Backup and DR-Agent werden Instanzen, Nutzerdatenbanken, Systemdatenbanken und Gruppen von Datenbanken auf physischen und virtuellen Servern erfasst.

Beim Erfassen einer SQL Server-Instanz können Sie entweder die gesamte Instanz oder ausgewählte Datenbanken in der Instanz erfassen. Wenn Sie die gesamte Instanz schützen, werden Datenbanken, die der Instanz hinzugefügt werden, automatisch in den nächsten Backup und DR-Erfassungsjob aufgenommen. Datenbanken in einer Instanz werden in den Ruhezustand versetzt und mit einem einzigen Sicherungsplan erfasst.

Wenn Backup und DR-Datenbanken und ‑Logerfassung in der Richtlinie für den Sicherungsplan aktiviert sind, können alle Datenbanken in dieser Instanz zum selben Zeitpunkt wiederhergestellt werden. Die Wiederherstellung und das Vorwärtsrollen der Logs für alle oder einzelne Datenbanken in einer Instanz erfolgt über die Backup und DR-Benutzeroberfläche mit einer einzigen Aktion.

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

Konsistenzgruppen erfassen

Eine Konsistenzgruppe ist eine Gruppe von Datenbanken, die mit einer einzelnen Sicherungsplanrichtlinienvorlage und einem einzelnen Ressourcenprofil in einen inaktiven Zustand versetzt 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 die 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 Technologie zum Erfassen von Datenbanken und Protokollen von Backup and DR in der Richtlinie des Sicherungsplans aktiviert ist, können alle Datenbanken in dieser Gruppe zum selben Zeitpunkt wiederhergestellt werden. Die Wiederherstellung und das Vorrollen der Logs für alle oder einzelne Datenbanken in einer Konsistenzgruppe erfolgt über die Backup und DR-Benutzeroberfläche mit einer einzigen Aktion. 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 Mount-Punkte)

Auf einzelne Mitglieder einer Konsistenzgruppe kann über Mount-, Klon-, LiveClone- und Wiederherstellungsvorgänge zugegriffen werden.

Datenbanken in einer geclusterten Failover-Instanz müssen vom aktiven Knoten erkannt werden. Nachdem der Schutz aktiviert wurde, folgt GO dem aktiven SQL-Knoten in einem Cluster. Schutzaufträge werden auch bei einem Failover fortgesetzt. Konsistenzgruppen beschleunigen nicht nur die Erfassungs- und Zugriffsoperationen, sondern verbrauchen auch weniger Systemressourcen (VDisks) als der individuelle Schutz von Datenbanken.

Sie können die Integrität von Datenbanksicherungen regelmäßig prüfen, indem Sie eine Sicherung auf einem Server einbinden 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 den zugehörigen Datenbanken erfasst wird, kann ein Backup erstellt werden, das eine voll funktionsfähige Datenbank und VM enthält. Das Backup kann dann an einen neuen, dauerhaften Speicherort migriert werden.

SQL Server-Daten replizieren

Daten können auf eine zweite Sicherungs-/Wiederherstellungs-Appliance oder in die Cloud repliziert werden, um sie wiederherzustellen, im Rahmen der Notfallwiederherstellung oder für Test- oder Entwicklungszwecke zu verwenden. Die Datenreplikation ist seit Langem ein Hindernis für eine effiziente Datenverwaltung in einer geografisch verteilten Umgebung. Die Backup- und DR-Replikation behebt diese Probleme mit der Komprimierung durch:

  • Die Gesamtnetzwerknutzung wird reduziert.

  • Es ist kein dedizierter WAN-Beschleuniger oder ‑Optimierer mehr erforderlich.

  • Verschlüsselt Daten mit dem AES-256-Verschlüsselungsstandard. Die Authentifizierung zwischen Sicherungs- und Wiederherstellungsgeräten erfolgt mit 1024-Bit-Zertifikaten.

Die Replikation wird über Richtlinienvorlagenrichtlinien für Backup und DR gesteuert:

  • Die Richtlinien für Production to Mirror bieten mehrere Optionen zum Replizieren von Daten auf eine zweite Sicherungs-/Wiederherstellungs-Appliance.

  • Bei Production to OnVault-Richtlinien wird eine proprietäre Backup and DR-Engine verwendet, um Daten in den Objektspeicher zu übertragen.

Logs replizieren

Wenn für eine Richtlinie Enable Database Log Backup auf Enable gesetzt ist, können mit der erweiterten Einstellung Replicate Logs Microsoft SQL Server-Datenbanktransaktionslogs auf ein externes Sicherungs-/Wiederherstellungsgerät repliziert werden. Damit ein Job zur Protokollreplikation ausgeführt werden kann, muss im Template eine StreamSnap-Replikationsrichtlinie zusammen mit einem Ressourcenprofil enthalten sein, in dem ein Remote-Gerät für Sicherung und Wiederherstellung angegeben ist. Außerdem muss mindestens eine erfolgreiche Replikation der Datenbank abgeschlossen sein. Sie können die Logs dann am Remote-Standort für alle Datenbanksicherungen 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 Protokolle an jeden OnVault-Pool gesendet, der durch eine gültige OnVault-Richtlinie oder Ressourcenprofilkombination angegeben wird (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 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 and DR sofort eine Kopie der Datenbank bereitstellen, die bis zu einem bestimmten Zeitpunkt zurückgesetzt wurde. Der Rollforward-Vorgang wird in der Appliance-Verwaltungskonsole angegeben.

Bei Microsoft SQL Server-Datenbanken, die das einfache Wiederherstellungsmodell verwenden, kann Backup and DR jede Sicherung der Datenbank, deren Aufbewahrungszeitraum noch nicht abgelaufen ist, sofort bereitstellen.

Unabhängig vom verwendeten Microsoft SQL Server-Wiederherstellungsmodell kann auf Microsoft SQL Server-Daten über die iSCSI-Schnittstelle 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 und Ressourcen haben. Erfasste Daten können als vertraulich gekennzeichnet werden und Backup und DR-Nutzern kann Zugriff auf vertrauliche Daten gewährt werden.

Halterungen

Die Bereitstellungsfunktion von Backup and DR ermöglicht den sofortigen Zugriff auf Daten, ohne dass diese verschoben werden müssen. Erstellte Kopien von Datenbanken können über die Backup und DR-Benutzeroberfläche vorwärts gerollt und auf einem beliebigen Datenbankserver bereitgestellt werden. Backup and DR bietet zwei Möglichkeiten zum Einbinden einer Microsoft SQL Server-Datenbank:

  • Die Einbindung der virtuellen Anwendung stellt die erfassten Microsoft SQL Server-Daten auf einem Zielserver als Microsoft SQL Server-Datenbank zur Verfügung. So können Sie Kopien von Produktionsdatenbanken für die Verwendung in Nicht-Produktionsumgebungen erstellen und verwalten. Virtuelle Anwendungsbereitstellungen werden von der Sicherungs-/Wiederherstellungs-Appliance erstellt und erfordern keine manuellen Eingriffe durch Datenbank-, Server- oder Speicheradministratoren. Virtuelle Anwendungsbereitstellungen 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 einbinden und Datenbanken in SQL Always On-Verfügbarkeitsgruppen einbinden beschrieben.

  • Bei der Standardbereitstellung, auch als direkte Bereitstellung bezeichnet, werden die erfassten Microsoft SQL Server-Daten auf einem Zielserver als Dateisystem und nicht als Datenbank bereitgestellt. Das ist nützlich, wenn eine Datenbank beschädigt ist, verloren gegangen ist oder ein Datenbankserver ersetzt wird. In solchen Fällen können Sie die Datenbank nicht mit einem Wiederherstellungsvorgang wiederherstellen. Stattdessen können Sie eine Sicherung einbinden und die Datenbankdateien aus der eingebundenen Sicherung an ihren ursprünglichen Speicherort auf dem Datenbankserver kopieren. Weitere Informationen zu direkten Einbindungen finden Sie unter Erfasste Microsoft SQL-Daten einbinden.

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 Ort als die Quelle verschoben. Die Zeit, die für einen Klonvorgang benötigt wird, hängt von der Menge der beteiligten Daten 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 Wiederherstellungsvorgängen werden Daten tatsächlich verschoben. Wiederherstellungsvorgänge werden in der Regel nach einer massiven Datenbeschädigung durchgeführt. Wie lange ein Wiederherstellungsvorgang dauert, hängt von der Datenmenge ab.

Wenn Sie eine Datenbank wiederherstellen und dann Logs anwenden möchten, muss sich die wiederhergestellte Datenbank im Restoring Mode (Wiederherstellungsmodus) befinden. Sie können die Datenbank im Wiederherstellungsmodus wiederherstellen und die Logs dann bis zu einem bestimmten Zeitpunkt vorwärts rollen. Wenn Sie die Datenbank wiederherstellen, ohne Restore with no Recovery (Wiederherstellen ohne Wiederherstellung) anzugeben, wird die Datenbank wiederhergestellt und online geschaltet, ohne dass Protokolle angewendet werden. Details zur Wiederherstellung finden Sie unter SQL Server-Datenbanken wiederherstellen. Wenn Sie die Daten mit nahezu null Ausfallzeiten wiederherstellen möchten, stellen Sie sie zuerst bereit, 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. Workflows können Daten als direkte Einbindung oder als LiveClone präsentieren:

  • Direkte Bereitstellungen (Standard oder anwendungsbezogen) 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.

Durch die Kombination der automatischen Microsoft SQL Server-Datenerfassung und Zugriffssteuerung von Backup and DR mit Workflows und ihren optionalen Datenmaskierungsfunktionen 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 Backup-Vorlage erstellen, mit der Microsoft SQL Server-Daten nach einem bestimmten Zeitplan erfasst werden. Der Administrator kann die erfassten Produktionsdaten von Microsoft SQL Server als vertraulich kennzeichnen und nur Nutzern mit den entsprechenden Zugriffsrechten zugänglich machen.

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

  • Die erfassten Microsoft SQL Server-Daten werden als LiveClone oder als direkte Einbindung verfügbar gemacht.

  • Aktualisiert die LiveClone- oder bereitstellbaren Microsoft SQL Server-Daten nach Zeitplan oder auf Anfrage

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

Nach Abschluss des Workflows können Nutzer mit dem entsprechenden Zugriff ihre Umgebungen mit den LiveClone- oder mountable Microsoft SQL Server-Daten bereitstellen.

Backup and DR in Verbindung mit vorhandenen Sicherungsprodukten

Da immer mehr Unternehmen die Anwendungsentwicklung mithilfe von Produktionsdatenbanken beschleunigen möchten, ist es häufig erforderlich, dass Backup and DR mit Legacy-Sicherungsprodukten zusammenarbeitet, die auf denselben Produktionsdatenbankumgebungen basieren. Backup und DR können problemlos mit anderen Produkten koexistieren, die Daten aus Produktionsdatenbanken erfassen, wenn diese Best Practices eingehalten werden.

Backup and DR verwendet eine eigene Methode für das Change-Block-Tracking. Daher sind Sicherungslösungen, die SQL oder andere Methoden zum Abrufen der Sicherungen verwenden, nicht von geplanten Backup and DR-Datenerfassungsjobs betroffen.

Sicherungsjobs können sehr E/A-intensiv sein. Sie können lange dauern und sich während der Sicherungszeiträume auf die Leistung der Datenbank auswirken. Backup and 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 keine Ausführung von Jobs mit der alten Sicherungssoftware und mit Backup und DR, die sich zeitlich überschneiden.
Best Practice Planen Sie Backup und DR-Datenbankjobs so, dass sie zu einem Zeitpunkt beginnen, zu dem die alte Sicherungssoftware abgeschlossen sein sollte. Planen Sie die Ausführung der alten Sicherungssoftware nicht unmittelbar nach dem normalen Abschluss eines Backup und DR-Jobs.
Grund Wenn Legacy-Sicherungsjobs und Backup and DR-Jobs 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ühren kann.

Datenbanklogs werden verwendet, um einzelne Transaktionen in einer Datenbank zu erfassen und so die Wiederherstellung zu einem bestimmten Zeitpunkt zu ermöglichen. Die meisten Anwendungsfälle für Agilität drehen sich darum, 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 Nichtproduktionsinstanz in der Regel nicht auf einen bestimmten Zeitpunkt der Quelle (Produktion) zurücksetzen. Dadurch entfällt in der Regel die Notwendigkeit, Protokolle als Teil einer Backup und DR-Agilitätslösung zu erfassen und zu verwalten.

Anforderung Nur ein System kann Logs verwalten (erfassen oder kürzen (löschen)), entweder die alte Sicherungssoftware oder Backup and DR.
Best Practice Lassen Sie die gesamte Logverwaltung von der alten Sicherungssoftware durchführen und verwenden Sie Backup and DR nicht, um Logs in dieser Umgebung zu schützen.
Grund Wenn Ihr System so konfiguriert ist, dass Protokolle verwaltet (erfasst oder gekürzt/gelöscht) werden, und die alte Sicherungssoftware ebenfalls Protokolle erfasst und/oder kürzt/löscht, kann es sein, dass eines oder beide Systeme eine unvollständige Protokollkette aufweisen. Dies kann die Wiederherstellung der Datenbank zu einem bestimmten Zeitpunkt erschweren oder unmöglich machen.

Weitere Dokumentation zu Backup and DR for Microsoft SQL Server

Diese Seite ist eine von mehreren Seiten, die sich speziell mit dem Schutz und der Wiederherstellung von Microsoft SQL Server-Datenbanken mit Backup and DR befassen. Weitere Informationen finden Sie unter:

Weitere Informationen

SQL Server-Datenbanken für Backup and DR vorbereiten