Microsoft SQL Server-Instanzen und -Datenbanken in geräteverwalteten Sicherungen sichern

Mit Backup and DR können Sie Microsoft SQL Server sichern:

  • Instanzen

  • Primäre Datenbank einer Always On-Verfügbarkeitsgruppe

  • Datenbanken in VMs

  • Systemdatenbanken

  • Nutzerdatenbanken

  • Datenbanken und Supportdateien in einer Konsistenzgruppe

  • Einzelne Mitglieder einer Konsistenzgruppe

Hinweis

Bevor Sie Microsoft SQL Server-Datenbanken schützen:

Best Practices zum Schutz von Microsoft SQL Server-Datenbanken

Bei Microsoft SQL Server-Datenbanken, die das vollständige Wiederherstellungsmodell verwenden, können Sie die Möglichkeit der Sicherungs-/Wiederherstellungs-Appliance nutzen, sowohl die Datenbank als auch ihre Logs mit einer einzigen Richtlinie zu sichern. Wenn sowohl die Datenbank als auch ihre Protokolle gesichert werden, kann die Appliance die Datenbank zu einem bestimmten Zeitpunkt wiederherstellen, indem sie ihre Protokolle über die Benutzeroberfläche der Appliance vorwärts rollt. Die Sicherung der Datenbank und ihrer Logs wird über die erweiterten Einstellungen der Richtlinienvorlage aktiviert.

Datenbanken in einer Instanz im Vergleich zu einer Konsistenzgruppe sichern

Wenn eine Datenbank in den Ruhezustand versetzt wird, um ein Backup zu erstellen, wird ein Snapshot der zugehörigen Laufwerke erstellt und dann freigegeben. Bei Konsistenzgruppen und Datenbankinstanzen werden die Mitglieder gemeinsam in den Ruhezustand versetzt und freigegeben, um einen konsistenten Zeitpunkt für die Daten zu gewährleisten.

Wenn Sie eine SQL-Instanz sichern, werden Datenbanken, die der Instanz hinzugefügt werden, automatisch in den Backup und DR-Sicherungsvorgang einbezogen. Das Sichern von Datenbanken in einer SQL-Instanz eignet sich für Umgebungen, in denen regelmäßig Datenbanken hinzugefügt und entfernt werden. Datenbanken, die als virtuelle Anwendungen in eine SQL-Instanz eingebunden sind, werden nicht mit den anderen Mitgliedern der Instanz geschützt. Virtuell eingebundene Datenbanken müssen separat geschützt werden.

Die Mitgliedschaft in einer Konsistenzgruppe erfolgt manuell. Das Sichern von Datenbanken in einer Konsistenzgruppe eignet sich für Umgebungen, in denen Datenbanken nicht oft hinzugefügt oder entfernt werden.

Datenbank- im Vergleich zu VM-Verwaltung

Microsoft SQL-Server werden unterschiedlich geschützt, je nachdem, ob sie als Anwendung (Datenbank, Instanz oder Verfügbarkeitsgruppe) oder als Teil einer gesamten VM geschützt werden.

Als Anwendung geschützt, nicht als ESP Als Teil einer VM geschützt
Sicherungs-/Wiederherstellungs-Appliances schützen nur die Datenbankdateien. Gesamte VMware-VMs werden mit VMware-APIs gesichert. Wenn Sie SQL-Datenbanken verwalten, die Teil einer geschützten VM sind, lesen Sie den Abschnitt [Compute Engine-Instanzen schützen und wiederherstellen](/backup-disaster-recovery/docs/quickstarts/gce-instances-backup-recovery).
Der Backup and DR-Agent koordiniert den VSS-Snapshot und führt die Protokollkürzung durch. Die VMware API koordiniert den VSS-Snapshot. Der Backup and DR-Agent muss auf der VM installiert sein, damit Protokolle gekürzt werden können.
Der Backup and DR-Agent verwendet die Änderungsblockverfolgung für benannte Dateien. Das ist sehr effizient für große Datenbankdateien. Die VMware API bietet Change Block Tracking.
Transaktionsprotokolle werden bei der Ausführung eines Sicherungsjobs gesichert, wenn Sie in Details & Einstellungen die Option Protokoll nach der Sicherung kürzen auswählen (siehe [Erweiterte Einstellungen für Überschreibungen von Richtlinieneinstellungen konfigurieren](: #SetOverrides)). Transaktionslogs werden nicht gesichert.
Der Client kann mit Protokollen vorwärts rollen. Das Vorrollen wird während der Wiederherstellung nicht unterstützt.

Folgen Sie der Anleitung unten, um einen Sicherungsplan zum Schutz einer Microsoft SQL Server-Datenbank anzuwenden.

  1. Rufen Sie in der Verwaltungskonsole für Backup und DR-Appliances App Manager > Applications auf. Die Seite Anwendungen wird geöffnet.

  2. Wählen Sie die Microsoft SQL Server-Datenbank, ‑Instanz, ‑AG oder ‑Konsistenzgruppe aus, die Sie sichern möchten, und klicken Sie rechts unten auf der Seite auf Sicherungsplan verwalten.

  3. Wählen Sie im Fenster Sicherungsplan verwalten in den Drop-down-Listen eine Vorlage und ein Profil aus:

    • Vorlage: Eine vorhandene Sicherungsvorlage, die Richtlinien zur Definition von Snapshots und Replikation der Anwendungsdaten enthält.

    • Profil Ein vorhandenes Ressourcenprofil, in dem die Ressourcen definiert sind, die zum Speichern der Daten der Anwendung als Snapshot und replizierte Images verwendet werden.

  4. Nehmen Sie im Fenster Manage Backup Plan Template (Vorlage für Sicherungsplan verwalten) die folgenden Änderungen vor, bevor Sie einen Sicherungsplan anwenden:

    • Anwendungseinstellungen: Einstellungen speziell für Microsoft SQL, z. B. Anwendungstyp, Hostname, Host-IP-Adresse, Pfad, Betriebssystem, Sicherungs-/Wiederherstellungsgerät und Geräte-IP-Adresse.

    • Richtlinienüberschreibungen: Überschreiben Sie bestimmte Richtlinieneinstellungen, die zuvor in der ausgewählten Sicherungsvorlage konfiguriert wurden. Richtlinienüberschreibungen können unter bestimmten Umständen nützlich oder erforderlich sein. Sie können Richtlinieneinstellungen nur überschreiben, wenn die Vorlage der Richtlinie so konfiguriert wurde, dass Überschreibungen von Richtlinieneinstellungen zulässig sind.

  5. Wenn Sie Datenbanken auswählen möchten, klicken Sie unter Regel für die Einbeziehung von Datenbanken auf Bearbeiten. Das Dialogfeld Mitgliedschaft verwalten wird geöffnet.

    • Wählen Sie im Dialogfeld Mitgliedschaft verwalten die zu sichernden Datenbanken aus, indem Sie eine Einschlussregel (Alle, Systemdatenbanken, Nutzerdatenbanken) zuweisen. Wählen Sie dann aus, ob die Regel Ausgewählte einschließen oder Ausgewählte ausschließen soll.

    • Klicke auf Speichern. Das Dialogfeld Mitgliedschaft verwalten wird geschlossen.

  6. Klicken Sie auf Anwenden, um die Sicherungsvorlage und das Ressourcenprofil anzuwenden. Daraufhin wird das Erfolgsmeldungsfeld angezeigt.

    Wenn die ausgewählte Datenbank zum ersten Mal erkannt wird, wird so schnell wie möglich ein On-Demand-Job ausgeführt, um die Daten zu schützen. Danach werden neue Daten gesichert, wenn der geplante Job gemäß den im Sicherungstemplate definierten Betriebszeiten ausgeführt wird. Wenn Sie beispielsweise um 10:00 Uhr (UTC) eine Vorlage zuweisen, deren Öffnungszeiten von 02:00 bis 05:00 Uhr (UTC) sind, beginnt der erste Job erst, wenn das Gerät nach 02:00 Uhr (UTC) einen verfügbaren Job-Slot hat.

    Wenn Sie eine Arbeitslast auf einer Sicherungs-/Wiederherstellungs-Appliance sichern, die die empfohlene Speicherkapazität oder das Snapshot-Limit überschreitet, wird eine Benachrichtigung mit einer Empfehlung angezeigt, die Daten auf einer anderen Sicherungs-/Wiederherstellungs-Appliance zu sichern.

Schutz von Datenbankprotokollen in einer Sicherungsplanrichtlinie

Wenn Sie eine Snapshot-Richtlinie für eine Datenbank erstellen, können Sie auch die zugehörigen Logdateien sichern. Die Häufigkeit, mit der Datenbankprotokolle gesichert werden, wird separat von der Häufigkeit der Sicherung der Datenbank definiert. Beispielsweise kann eine Datenbank täglich und ihre Logs stündlich gesichert werden. Die Häufigkeit der Sicherung von Datenbanklogs wird in Minuten festgelegt und darf die Häufigkeit der Sicherung der zugehörigen Datenbank nicht überschreiten. Wenn eine Datenbank beispielsweise alle 24 Stunden gesichert wird, muss die Sicherungshäufigkeit der Protokolldatei weniger als alle 24 Stunden betragen.

Häufigkeit und Aufbewahrung werden in den Details und Einstellungen der Datenbank-Snapshot-Richtlinie definiert. Die Logsicherung erfolgt unabhängig davon, wann die zugehörige Datenbank gesichert wird.

Sie aktivieren Log Protection (Protokollschutz) über die erweiterten Einstellungen Enable Database Log Backup (Datenbankprotokollsicherung aktivieren) in einer Snapshot-Richtlinie für einen Sicherungsplan. Häufigkeit und Aufbewahrung werden in den Details und Einstellungen für eine Richtlinie für Sicherungspläne definiert.

Der Speicherplatz, der für die Logs einer Datenbank erforderlich ist, wird automatisch von der Appliance-Verwaltungskonsole verwaltet. In der Appliance-Verwaltungskonsole werden typische Loggrößen und ihr Aufbewahrungszeitraum ausgewertet und bei Bedarf Speicherplatz hinzugefügt. Snapshot-Richtlinien bieten die folgenden erweiterten Einstellungen, um die Speicheranforderungen für die Logs einer Datenbank zu verwalten:

  • Aufbewahrungsdauer für Log-Sicherungen Die Aufbewahrung von Logs wird separat von der Aufbewahrung der Snapshot-Richtlinie definiert. Durch einen separaten Aufbewahrungszeitraum können Sie Protokolle in Verbindung mit Kopien der Datenbank verwenden, die im Snapshot-Pool und optional in einem OnVault-Pool gespeichert sind. Die Aufbewahrungsdauer für Logs ist erforderlich, wenn Logsicherungen aktiviert sind.

  • Logs replizieren: Sie können Datenbanklogs auf eine Remote-Sicherungs-/Wiederherstellungs-Appliance oder in einen OnVault-Pool replizieren und die Remoteprotokolle für jedes Datenbankimage innerhalb des Aufbewahrungszeitraums der replizierten Protokolle verwenden. Bei der Protokollreplikation wird die StreamSnap-Technologie zwischen den lokalen und Remote-Appliances verwendet. Die Daten werden direkt vom lokalen Snapshot-Pool zum Snapshot-Pool auf der Remote-Appliance übertragen. Dazu ist eine StreamSnap-Replikationsrichtlinie in der Vorlage erforderlich. Außerdem muss mindestens eine erfolgreiche Replikation der Datenbank abgeschlossen sein.

  • Größe des Log-Staging-Laufwerks Definiert den Prozentsatz, um den das Staging-Laufwerk, auf dem sich die Logs befinden, automatisch vergrößert werden soll. Diese Einstellung ist ein Prozentsatz. Gültige Werte liegen zwischen 5 und 100.

  • Geschätzte Änderungsrate: Definiert die tägliche Änderung (in Prozent), die es der Sicherungs-/Wiederherstellungs-Appliance ermöglicht, die Größe des Staging-Laufwerks, das zum Speichern von Protokollen erforderlich ist, besser zu berechnen. Diese Einstellung ist ein Prozentsatz. Gültige Werte sind 0 bis 100.

  • Datenbanksicherungsprotokoll komprimieren: Weist die Quelldatenbank an, ihre Protokolle vor der Sicherung zu komprimieren. Der Datenbankserver führt die Protokollkomprimierung während der Protokollsicherung durch.

Erweiterte Einstellungen für Überschreibungen von Richtlinieneinstellungen konfigurieren

Klicken Sie im Fenster Sicherungsplan verwalten auf Richtlinienüberschreibungen, um das Dialogfeld Überschreibung der Richtlinieneinstellungen aufzurufen. Hier können Sie bestimmte Richtlinieneinstellungen überschreiben, die mit der ausgewählten Sicherungsvorlage verknüpft sind. Wenn Sie fertig sind, klicken Sie auf Änderungen speichern.

Wenn Sie eine Einstellung für die Richtlinienüberschreibung auf den Standardzustand zurücksetzen möchten, klicken Sie auf das Kästchen links neben der Auswahl. Wenn Sie alle Einstellungen für die Richtlinienüberschreibung auf den Standardzustand zurücksetzen möchten, klicken Sie auf Optionen auswählen, die auf die Standardeinstellungen zurückgesetzt werden.

In der folgenden Liste finden Sie Beschreibungen der Überschreibungen von Richtlinieneinstellungen, die für SQL Server-Instanzen, Verfügbarkeitsgruppen, Datenbanken und Konsistenzgruppen gültig sind.

  • Zuordnung nicht aufheben: Staging-Laufwerke zwischen Jobs zuordnen: Wählen Sie diese Option aus, wenn temporäre Staging-Laufwerke, die während der Datenübertragung verwendet werden, dem Host zugeordnet bleiben sollen. LUNs werden während des ersten Jobs zugeordnet und alle nachfolgenden Jobs verwenden dieselbe zugeordnete LUN. Diese Option ist standardmäßig ausgewählt. Staging-Laufwerke nach jedem Job trennen: Mit dieser Option wird das Staging-Laufwerk am Ende jedes Jobs sowohl vom Betriebssystem getrennt (Mount-Punkte oder Laufwerkbuchstaben werden entfernt) als auch vollständig vom Host getrennt. Bei dieser Option muss der Host zu Beginn des nächsten Jobs nach SCSI-LUNs suchen, da die neu zugeordneten Staging-Festplatten neu erkannt werden müssen, bevor sie wieder bereitgestellt werden können.

  • Log nach der Sicherung kürzen: Geben Sie an, ob die Protokolle nach jeder Sicherung gekürzt werden sollen. Wenn diese Option aktiviert ist, werden anwendungsbezogene Protokolle bis zum letzten oder aktuellen Backup gekürzt. Wenn Sie Protokolle kürzen, müssen Sie auch das Transaktionsprotokoll sichern, um eine Rollforward-Wiederherstellung zu ermöglichen.

  • Offlineanwendungen in der Konsistenzgruppe überspringen: (Nur für die Verwaltung von Konsistenzgruppen) Geben Sie an, ob nicht verfügbare Datenbanken, die Teil einer Konsistenzgruppe sind, ignoriert werden sollen. Sie erstellen eine Konsistenzgruppe, um mehrere Datenbanken gleichzeitig zu sichern und so die Konsistenz der Daten in den Datenbanken zu gewährleisten. Konsistenzgruppen sind Sammlungen von Datenbanken aus derselben Instanz oder Verfügbarkeitsgruppe.

    Folgende Optionen sind verfügbar:

    • Sicherung fehlgeschlagen, wenn Offlineanwendungen gefunden werden
    • Offlineanwendungen bei der Sicherung überspringen

  • Staging-Festplatten allen ESX-Hosts in einem Cluster zuordnen Diese Option ist nicht relevant, wenn Sie NFS-Datenspeicher verwenden. Stellen Sie eine Verbindung zwischen dem Staging-Laufwerk und dem ESX-Host für die VM her. Ordnen Sie das Staging-Laufwerk allen ESX-Hosts im Cluster zu. Weisen Sie die Staging-Festplatte zwei ESX-Hosts im Cluster zu.

  • SQL Server-Nutzeranmeldungen sichern Sichert die Anmeldedatensätze der SQL Server-Instanz für Konten, denen Zugriff auf die zu sichernden Datenbanken gewährt wurde. Wenn die Datenbank als virtuelle Anwendung bereitgestellt wird (anwendungsbezogene Bereitstellung), können die gesicherten Nutzeranmeldungen optional in der Ziel-SQL Server-Instanz wiederhergestellt werden. So wird sichergestellt, dass die virtuelle Datenbank von denselben Nutzern aufgerufen werden kann, die Zugriff auf die ursprüngliche Quelldatenbank haben. Die Optionen sind Ja oder Nein.

  • Datenbank-Log-Sicherung aktivieren Mit der Option Enable Database Log Backup (Datenbank-Log-Sicherung aktivieren) kann die Richtlinie des Sicherungsplans eine Oracle- oder Microsoft SQL Server-Datenbank und alle zugehörigen Transaktionslogdateien sichern. Die Logs werden gesichert, wenn der Job für Log-Snapshots ausgeführt wird. Die Optionen sind Ja oder Nein. Wenn Ja festgelegt ist, werden die zugehörigen Optionen aktiviert.

  • RPO Wenn Enable Database Log Backup auf Yes gesetzt ist, wird die Häufigkeit der Datenbank-Log-Sicherung durch den RPO-Wert definiert. Die Häufigkeit wird in Minuten festgelegt und darf das Intervall für die Datenbanksicherung nicht überschreiten. Der kleinste Wert, der festgelegt werden kann (in Minuten), ist 15.

  • Aufbewahrungsdauer für Log-Sicherungen Wenn Datenbank-Log-Sicherung aktivieren auf Ja festgelegt ist, wird die Log-Aufbewahrung separat von der Aufbewahrung der Snapshot-Richtlinie definiert. Durch einen separaten Aufbewahrungszeitraum können Sie Logs in Verbindung mit Kopien der Datenbank verwenden, die im Snapshot-Pool gespeichert sind. Die Aufbewahrungsdauer für Logs ist eine Pflichteinstellung.

  • Logs replizieren: (Verwendet StreamSnap-Technologie) Wenn Datenbank-Log-Sicherung aktivieren 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 Log-Replikationsjob ausgeführt werden kann, muss im Template eine StreamSnap-Replikationsrichtlinie zusammen mit einem Ressourcenprofil vorhanden sein, in dem eine Remote-Sicherungs-/Wiederherstellungs-Appliance angegeben ist. Außerdem muss mindestens eine erfolgreiche Replikation der Datenbank abgeschlossen sein. Sie können die Logs dann am Remote-Standort 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 an OnVault-Pool senden Wenn Datenbank-Log-Sicherung aktivieren auf Aktivieren gesetzt ist, können Microsoft SQL Server-Datenbanktransaktionslogs in einen OnVault-Pool repliziert werden. Damit ein Job zur Protokollreplikation ausgeführt werden kann, muss im Template eine OnVault-Richtlinie zusammen mit einem Ressourcenprofil enthalten sein, in dem ein OnVault-Pool angegeben ist. Außerdem muss mindestens eine Datenbank zuerst an den Pool gesendet werden. Sie können die Logs dann am Remote-Standort für jedes Datenbank-Image innerhalb des Aufbewahrungszeitraums verwenden. Diese Funktion ist standardmäßig aktiviert.

  • Größe des Log-Staging-Laufwerks. Wenn Enable Database Log Backup auf Yes gesetzt ist, wird mit Log Staging Disk Growth Size die Größe des Wachstums definiert, das beim automatischen Vergrößern des Staging-Laufwerks verwendet werden soll, auf dem sich die Logs befinden. Diese Einstellung liegt zwischen 5 und 100 %.

  • Geschätzte Änderungsrate: Wenn Enable Database Log Backup auf Yes gesetzt ist, wird mit dieser Einstellung die tägliche Änderung (in Prozent) definiert, damit die Sicherungs-/Wiederherstellungs-Appliance die Größe der Staging-Festplatte, die zum Speichern von Logs erforderlich ist, besser berechnen kann. Diese Einstellung liegt zwischen 0 und 100.

  • Datenbanksicherungsprotokoll komprimieren: Wenn Enable Database Log Backup auf Yes gesetzt ist, wird die Quelldatenbank durch diese Einstellung angewiesen, ihre Protokolle zu komprimieren, bevor sie von der Appliance-Verwaltungskonsole gesichert werden. Der Datenbankserver führt die Protokollkomprimierung während der Protokollsicherung durch. Die Optionen sind Ja oder Nein. Wenn Ja festgelegt ist, wird die Option Datenbank-Log-Sicherung komprimieren aktiviert.

  • Zeitlimit für Script Mit dem Backup and DR-Agenten können Sie hostseitige Skripts erstellen, die vor oder nach der Ausführung einer Richtlinie auf dem Host einer Anwendung ausgeführt werden. Die vier Zeitüberschreitungen in einer Richtlinienvorlage entsprechen direkt den vier Phasen eines hostseitigen Skripts.

    • Zeitlimit für die Initialisierung des Scripts Gibt an, wie lange eine Richtlinie warten soll, bevor davon ausgegangen wird, dass hostseitige Skripts auf einem verwalteten Host initialisiert wurden. Der Standardwert beträgt 120 Sekunden. Der zulässige Bereich liegt zwischen 1 und 86.400 Sekunden (24 Stunden).
    • Zeitlimit für das Einfrieren von Scripts Gibt an, wie lange eine Richtlinie warten soll, bevor davon ausgegangen wird, dass die Anwendung eingefroren und bereit für die Datensicherung ist. Der Standardwert beträgt 60 Sekunden. Der zulässige Bereich liegt zwischen 1 und 86.400 Sekunden.
    • Zeitlimit für das Aufheben des Einfrierens von Scripts: Gibt an, wie lange eine Richtlinie warten soll, bevor davon ausgegangen wird, dass die Anwendung nicht mehr eingefroren ist. Der Standardwert beträgt 60 Sekunden. Der zulässige Bereich liegt zwischen 1 und 86.400 Sekunden.
    • Zeitlimit für Script-Abschluss: Gibt an, wie lange eine Richtlinie warten soll, bevor die Datensicherung abgeschlossen ist. Der Standardwert beträgt 60 Sekunden. Der zulässige Bereich liegt zwischen 1 und 86.400 Sekunden.
    • Zeitlimit für Script nach der Replikation Definiert, wie lange eine Richtlinie warten soll, bis die Replikation abgeschlossen ist. Der Standardwert beträgt 60 Sekunden. Der zulässige Bereich liegt zwischen 1 und 86.400 Sekunden.

DBA-Leitfaden für 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: