Sicherungs- und Notfallwiederherstellungsdienst für Microsoft SQL Server

SQL Server-Daten erfassen

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

Auf einem Sicherungs-/Wiederherstellungsgerät werden Anwendungsdaten auf einer Staging-Festplatte gespeichert. Snapshots auf der Staging-Festplatte ermöglichen es der Sicherungs-/Wiederherstellungs-Appliance, Verlaufsdaten zu speichern.

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 Logs 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.

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

  • Das Staging-Laufwerk ist vom Server getrennt.

  • Auf der Sicherungs-/Wiederherstellungs-Appliance wird ein Snapshot des Staging-Laufwerks erstellt.

SQL Server-Datenbanklogs erfassen

Die Erfassung von Datenbankprotokollen wird in den Details und Einstellungen einer Snapshot-Richtlinie festgelegt. Damit kann 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 und 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 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 ein einzelnes erfasstes Datenbankimage ausgewählt werden und seine Logs können für den gesamten Zeitraum 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 Microsoft SQL Server-Datenbanktransaktionslogs auf ein externes Sicherungs-/Wiederherstellungsgerät repliziert werden sollen. Sie können die Logs am Remote-Standort für jedes Datenbankimage innerhalb des Aufbewahrungszeitraums der replizierten Logs verwenden.

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

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 berücksichtigt mindestens die typischen Protokollgrößen und den Aufbewahrungszeitraum 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:

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

  • Log Staging Disk Size Growth (Wachstum der Staging-Laufwerksgröße 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 Datenbankgruppen auf physischen und virtuellen Servern erfasst.

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

Wenn die Sicherung und DR-Datenbank und die Protokollerfassung in der Sicherungsplanrichtlinie aktiviert sind, können alle Datenbanken in dieser Instanz zum selben Zeitpunkt wiederhergestellt werden. Die Wiederherstellung und das Vorrollen der Logs für alle oder einzelne Datenbanken in einer Instanz erfolgt über die Backup & DR-Benutzeroberfläche mit einer einzigen Aktion.

Auf einzelne Elemente 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 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 Technologie zum Erfassen von Datenbanken und Logs von Backup and DR in der Richtlinie für den Sicherungsplan 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 & 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 Bereitstellungspunkte)

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 im Failover-Fall weiter ausgeführt. 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 ein Sicherungsimage 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 den zugehörigen Datenbanken erfasst wird, kann ein Image erstellt werden, das eine voll funktionsfähige Datenbank und VM enthält. Das Bild kann dann an einen neuen, dauerhaften Speicherort migriert werden.

SQL Server-Daten replizieren

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

  • Die allgemeine Netzwerknutzung wird reduziert.

  • Es ist kein dedizierter WAN-Beschleuniger oder ‑Optimierer 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 durch Richtlinienvorlagenrichtlinien für Backup & DR gesteuert:

  • Die Richtlinien für Production to Mirror bieten mehrere Optionen zum Replizieren von Daten auf ein zweites Sicherungs-/Wiederherstellungsgerät.

  • 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 die Richtlinie Enable Database Log Backup auf Enable festgelegt ist, können mit der erweiterten Einstellung Replicate Logs Microsoft SQL Server-Datenbanktransaktionsprotokolle 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 externes Sicherungs-/Wiederherstellungsgerät angegeben ist. Außerdem muss mindestens eine erfolgreiche Replikation der Datenbank abgeschlossen sein. Sie können die Logs am Remote-Standort dann für jedes Datenbankimage 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 OnVault-Richtlinie oder Ressourcenprofilkombination angegeben wird (z.B. OnVault-Pool 1 ist in der Richtlinie ausgewählt und OnVault-Pool 1 ist im Ressourcenprofil angegeben. Die Log-Aufbewahrung im OnVault-Pool entspricht immer der Log-Aufbewahrung 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 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 ü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 & DR-Funktionen und Ressourcen haben. Erfasste Daten können als vertraulich gekennzeichnet werden und Backup & DR-Nutzern kann die Zugriffsberechtigung für vertrauliche Daten gewährt werden.

Mounts

Die Mount-Funktion von Backup and DR bietet sofortigen Zugriff auf Daten, ohne dass Daten verschoben werden müssen. Erstellte Kopien von Datenbanken können über die Backup & 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 AlwaysOn-Verfügbarkeitsgruppen einbinden beschrieben.

  • Beim Standard-Mount, auch als direkter Mount 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 ein Image einbinden und die Datenbankdateien aus dem eingebundenen Image an ihren ursprünglichen Speicherort auf dem Datenbankserver kopieren. Weitere Informationen zu Direct Mounts 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 Datenmenge ab. Details 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. Die Zeit, die für einen Wiederherstellungsvorgang benötigt wird, hängt von der Menge der beteiligten 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 die Logs dann bis zu einem bestimmten Zeitpunkt vorwärts verschieben. Wenn Sie die Datenbank wiederherstellen, ohne Restore with no Recovery anzugeben, wird die Datenbank wiederhergestellt und online geschaltet, ohne dass Protokolle angewendet werden. Wiederherstellungsvorgänge werden unter SQL Server-Datenbanken wiederherstellen beschrieben. Wenn Sie eine Wiederherstellung mit nahezu null Ausfallzeiten durchführen möchten, stellen Sie die Daten 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 Mounts (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 Produktionsdaten von Microsoft SQL Server, 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 automatisierten 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 Sicherungsvorlagenrichtlinie erstellen, mit der Microsoft SQL Server-Daten nach einem bestimmten Zeitplan erfasst werden. Der Administrator kann die erfassten Microsoft SQL Server-Produktionsdaten als vertraulich kennzeichnen, sodass nur Nutzer mit den entsprechenden Zugriffsrechten darauf zugreifen können.

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. Dies ist nützlich, um vertrauliche 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 Backup and DR häufig erforderlich, um mit Legacy-Sicherungsprodukten zusammenzuarbeiten, die auf denselben Produktionsdatenbankumgebungen basieren. Sicherung 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 eine Weile.

Anforderung Planen Sie keine Jobs für die alte Sicherungssoftware und Backup und DR so, dass es zu zeitlichen Überschneidungen kommt.
Best Practice Planen Sie Backup and 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 & DR-Jobs.
Grund Wenn alte Sicherungsjobs und Backup and DR-Jobs gleichzeitig ausgeführt werden, kann dies zu einer erheblichen Beeinträchtigung der Leistung des Datenbankservers 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. Bei den meisten Anwendungsfällen für Agilität geht es darum, regelmäßig Datenbank-Snapshots aus der Produktion zu erhalten. Die Häufigkeit variiert 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) ausrichten. 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. 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. In diesem Fall ist es schwierig oder unmöglich, die Datenbank zu einem bestimmten Zeitpunkt wiederherzustellen.

Weitere Dokumentation zu Backup and DR für 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 den Backup- und DR-Dienst vorbereiten