Sicherungspläne für Microsoft SQL Server-Instanzen und ‑Datenbanken konfigurieren

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

Hinweise

Bevor Sie Microsoft SQL Server-Datenbanken schützen:

Best Practices für den 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 auf einen bestimmten Zeitpunkt zurücksetzen, indem sie ihre Protokolle über die Benutzeroberfläche der Appliance vorwärts rollt. Das Sichern 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 eine Sicherung 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 die Backup and DR-Sicherung aufgenommen. 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- und 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 gesamten geschützten VM sind, lesen Sie [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.
Transaktionslogs werden bei der Ausführung eines Sicherungsjobs gesichert, wenn Sie unter Details & Einstellungen die Option Log nach 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 Rollforward wird während der Wiederherstellung nicht unterstützt.

Gehen Sie folgendermaßen vor, um einen Sicherungsplan zum Schutz einer Microsoft SQL Server-Datenbank anzuwenden.

  1. Gehen Sie in der Managementkonsole zu App Manager > Applications (App-Manager > Apps). 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 Manage Backup Plan (Sicherungsplan verwalten) in den Drop-down-Listen eine Vorlage und ein Profil aus:

    • Vorlage Eine vorhandene Sicherungsvorlage, die Richtlinien zum Definieren des Snapshots und der Replikation der Anwendungsdaten enthält.

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

  4. Nehmen Sie im Fenster Manage Backup Plan Template (Sicherungsplanvorlage 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, Backup-/Wiederherstellungs-Appliance und Appliance-IP-Adresse.

    • Richtlinien-Overrides: Ü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 Datenbankeinbeziehung 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 zuweisen (Alle, Systemdatenbanken, Nutzerdatenbanken). Wählen Sie dann aus, ob die Regel Ausgewählte einschließen oder Ausgewählte ausschließen sein 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, die Betriebszeiten von 02:00 bis 05:00 Uhr (UTC) hat, 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 Richtlinie für Sicherungspläne

Wenn Sie eine Snapshot-Richtlinie für eine Datenbank erstellen, können Sie auch die zugehörigen Logdateien sichern. Die Häufigkeit, mit der Datenbanklogs gesichert werden, wird separat von der Häufigkeit der Sicherung der Datenbank definiert. Eine Datenbank kann beispielsweise täglich und ihre Protokolle stündlich gesichert werden. Die Häufigkeit der Sicherung von Datenbankprotokollen 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 Häufigkeit der Sicherung der Logdatei weniger als alle 24 Stunden betragen.

Häufigkeit und Aufbewahrung werden in den Details und Einstellungen der Richtlinie für Datenbank-Snapshots definiert. Die Sicherung von Protokollen erfolgt unabhängig davon, wann die zugehörige Datenbank gesichert wird.

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

Der Speicherplatz, der für die Logs einer Datenbank erforderlich ist, wird automatisch von der Verwaltungskonsole verwaltet. Die Managementkonsole bewertet die typischen Loggrößen und den Aufbewahrungszeitraum und fügt bei Bedarf Speicherplatz hinzu. Snapshot-Richtlinien bieten die folgenden erweiterten Einstellungen, um die Speicheranforderungen für die Logs einer Datenbank zu verwalten:

  • Aufbewahrungsdauer für Logsicherungen: 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. Der Zeitraum für die Logaufbewahrung ist erforderlich, wenn Logsicherungen aktiviert sind.

  • Logs replizieren: Sie können Datenbankprotokolle auf eine Remote-Appliance für Sicherung/Wiederherstellung oder in einen OnVault-Pool replizieren und die Remote-Protokolle 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 Backup-/Wiederherstellungs-Appliance ermöglicht, die Größe des Staging-Laufwerks, das zum Speichern von Logs benötigt wird, besser zu berechnen. Diese Einstellung ist ein Prozentsatz. Gültige Werte sind 0 bis 100.

  • Datenbank-Logsicherung 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. Klicken Sie anschließend 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. Klicken Sie auf Optionen auswählen, die auf die Standardeinstellungen zurückgesetzt werden, um alle Einstellungen für die Richtlinienüberschreibung auf den Standardzustand zurückzusetzen.

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 nach Abschluss jedes Jobs sowohl vom Betriebssystem getrennt (Entfernen von Mount-Punkten oder Laufwerkbuchstaben) als auch vom Host getrennt. Bei dieser Option muss der Host zu Beginn des nächsten Jobs nach SCSI-LUNs suchen, da die neu zugeordneten Staging-Laufwerke 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 wahren. 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-Laufwerke allen ESX-Hosts in einem Cluster zuordnen Diese Option ist nicht relevant, wenn Sie NFS-Datenspeicher verwenden. Ordnen Sie das Staging-Laufwerk nur dem ESX-Host für die VM zu. Ordnen Sie das Staging-Laufwerk allen ESX-Hosts im Cluster zu. Staging-Festplatte zwei ESX-Hosts im Cluster zuordnen.

  • 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 und Nein.

  • Datenbank-Log-Sicherung aktivieren Mit der Option Enable Database Log Backup (Datenbank-Log-Sicherung aktivieren) kann die Sicherungsplanrichtlinie eine Oracle- oder Microsoft SQL Server-Datenbank und alle zugehörigen Transaktionslogdateien sichern. Die Logs werden gesichert, wenn der Log-Snapshot-Job 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 Sicherung von Datenbanklogs 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 Logsicherungen: Wenn Enable Database Log Backup auf Yes gesetzt ist, wird die Aufbewahrung von Protokollen 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 Enable Database Log Backup auf Enable festgelegt ist, können mit der erweiterten Einstellung Replicate Logs Microsoft SQL Server-Datenbanktransaktionslogs auf ein externes Sicherungs-/Wiederherstellungsgerät repliziert werden. Damit ein Log-Replikationsjob ausgeführt werden kann, muss im Template eine StreamSnap-Replikationsrichtlinie zusammen mit einem Ressourcenprofil vorhanden sein, in dem ein Remote-Sicherungs-/Wiederherstellungsgerät angegeben ist. Außerdem muss mindestens eine erfolgreiche Replikation der Datenbank abgeschlossen sein. Sie können die Logs am Remotestandort 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 an OnVault-Pool senden: Wenn Enable Database Log Backup auf Enable festgelegt 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 Protokolle dann am Remote-Standort für jedes Datenbankimage innerhalb des Aufbewahrungszeitraums verwenden. Diese Funktion ist standardmäßig aktiviert.

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

  • Geschätzte Änderungsrate. Wenn Enable Database Log Backup auf Yes festgelegt ist, wird mit dieser Einstellung die tägliche Änderung (in Prozent) definiert, mit der 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.

  • Datenbank-Logsicherung 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 Verwaltungskonsole gesichert werden. Der Datenbankserver führt die Protokollkomprimierung während der Protokollsicherung durch. Die Optionen sind Ja oder Nein. Wenn Ja ausgewählt ist, ist die Option Compress Database Log Backup (Datenbank-Log-Sicherung komprimieren) aktiviert.

  • Zeitlimit für Script Mit dem Backup and DR-Agent 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 Definiert, 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).
    • Zeitüberschreitung beim Einfrieren von Scripts: Definiert, 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: Gibt an, 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 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: