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

Mit Backup und 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 Funktion der Sicherungs-/Wiederherstellungs-Appliance nutzen, um sowohl die Datenbank als auch die zugehörigen Logs mit einer einzigen Richtlinie zu sichern. Wenn sowohl die Datenbank als auch ihre Logs gesichert sind, kann die Appliance die Datenbank zu einem bestimmten Zeitpunkt wiederherstellen, indem sie die Logs ü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 zum Erstellen einer Sicherung stillgelegt wird, wird ein Snapshot ihrer Laufwerke erstellt und dann freigegeben. Bei Konsistenzgruppen und Datenbankinstanzen werden Mitglieder gemeinsam stillgelegt und freigegeben, um einen konsistenten Zeitpunkt für die Daten zu erhalten.

Wenn Sie eine SQL-Instanz sichern, werden die Datenbanken, die der Instanz hinzugefügt werden, automatisch in den Sicherungsvorgang von Backup und DR einbezogen. Das Sichern von Datenbanken in einer SQL-Instanz eignet sich für Umgebungen, in denen Datenbanken regelmäßig hinzugefügt und entfernt werden. Datenbanken, die als virtuelle Anwendungen in einer SQL-Instanz bereitgestellt werden, werden nicht mit den anderen Mitgliedern der Instanz geschützt. Virtuell bereitgestellte 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 häufig hinzugefügt oder entfernt werden.

Datenbank- und VM-Verwaltung im Vergleich

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 mithilfe von VMware APIs gesichert. Wenn Sie SQL-Datenbanken verwalten, die Teil einer gesamten geschützten VM sind, lesen Sie den Hilfeartikel [Compute Engine-Instanzen schützen und wiederherstellen](/backup-disaster-recovery/docs/quickstarts/gce-instances-backup-recovery).
Der Backup und DR-Agent koordiniert den VSS-Snapshot und führt die Protokollkürzung durch. Die VMware API koordiniert den VSS-Snapshot. Der Backup und DR-Agent muss für die Protokollkürzung auf der VM installiert sein.
Der Backup und DR-Agent verwendet die Änderungsblockverfolgung für benannte Dateien, was für große Datenbankdateien sehr effizient ist. Die VMware API bietet Change Block Tracking.
Transaktionslogs werden gesichert, wenn ein Sicherungsjob ausgeführt wird, wenn Sie in Details und 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 Logs einen Roll-forward durchführen. Roll-forward wird während der Wiederherstellung nicht unterstützt.

Gehen Sie nach der folgenden Anleitung vor, um einen Sicherungsplan zum Schutz einer Microsoft SQL Server-Datenbank anzuwenden.

  1. Rufen Sie in der Verwaltungskonsole der Backup und DR-Appliance App Manager > Anwendungen 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 wählen Sie rechts unten auf der Seite Sicherungsplan verwalten aus.

  3. Wählen Sie im Fenster Sicherungsplan verwalten eine Vorlage und ein Profil aus den Drop-down-Listen 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 Vorlage für Sicherungsplan verwalten die folgenden Änderungen vor, bevor Sie einen Sicherungsplan anwenden:

    • Anwendungseinstellungen: Spezifische Einstellungen für Microsoft SQL, z. B. Anwendungstyp, Hostname, Host-IP-Adresse, Pfad, Betriebssystem, Sicherungs-/Wiederherstellungs-Appliance und Appliance-IP-Adresse.

    • Richtlinienüberschreibungen. Bestimmte Richtlinieneinstellungen überschreiben, 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 Richtlinieneinstellungen überschrieben werden können.

  5. Klicken Sie unter Regel für die Aufnahme von Datenbanken auf Bearbeiten, um Datenbanken auszuwählen. Das Dialogfeld Mitgliedschaft verwalten wird geöffnet.

    • Wählen Sie im Dialogfeld Mitgliedschaft verwalten die Datenbanken aus, die gesichert werden sollen. Weisen Sie dazu eine Einschlussregel zu (Alle, Systemdatenbanken, Nutzerdatenbanken) und wählen Sie dann aus, ob die Regel Ausgewählte einschließen oder Ausgewählte ausschließen soll.

    • Klicken Sie auf Speichern. Das Dialogfeld Mitgliedschaft verwalten wird geschlossen.

  6. Klicken Sie auf Anwenden, um die Backup-Vorlage und das Ressourcenprofil anzuwenden. Es wird eine Erfolgsmeldung 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 in der Sicherungsvorlage definierten Betriebszeiten ausgeführt wird. Wenn Sie beispielsweise um 10:00 Uhr (UTC) eine Vorlage mit Betriebszeiten von 02:00 bis 05:00 Uhr (UTC) zuweisen, wird der erste Job erst gestartet, wenn die Appliance 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 der Empfehlung angezeigt, die Daten auf einer anderen Sicherungs-/Wiederherstellungs-Appliance zu sichern.

Datenbankprotokollschutz 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 Datenbanksicherungen erstellt werden, wird separat von 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. Die Häufigkeit, mit der Logs gesichert werden, darf die Häufigkeit, mit der die zugehörige Datenbank gesichert wird, nicht überschreiten. Wenn eine Datenbank beispielsweise alle 24 Stunden gesichert wird, muss die Sicherungshäufigkeit der Protokolldatei weniger als 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 den Logschutz über die erweiterten Einstellungen Datenbank-Logsicherung aktivieren in einer Snapshot-Richtlinie für den Sicherungsplan. Häufigkeit und Aufbewahrung werden in den Details und Einstellungen für eine Sicherungsplanrichtlinie definiert.

Der für die Logs einer Datenbank erforderliche Speicherplatz wird automatisch von der Appliance-Verwaltungskonsole verwaltet. Die Appliance-Verwaltungskonsole wertet typische Loggrößen und deren Aufbewahrungsdauer aus und fügt bei Bedarf Speicherplatz hinzu. Zur Verwaltung der Speicheranforderungen für die Logs einer Datenbank bieten Snapshot-Richtlinien die folgenden erweiterten Einstellungen:

  • Log Backup Retention Period (Aufbewahrungsdauer für Log-Sicherungen) Die Aufbewahrung von Logs wird separat von der Aufbewahrung der Snapshot-Richtlinie definiert. Mit einer separaten Aufbewahrungsdauer können Sie Logs 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 obligatorisch, wenn Log-Sicherungen aktiviert sind.

  • Logs replizieren: Sie können Datenbanklogs auf einer Remote-Sicherungs-/Wiederherstellungs-Appliance oder in einem OnVault-Pool replizieren und die Remote-Logs für jedes Datenbank-Image innerhalb des Aufbewahrungsbereichs der replizierten Logs verwenden. Bei der Logreplikation wird die StreamSnap-Technologie zwischen den lokalen und Remote-Appliances verwendet. Dabei werden die Daten direkt vom lokalen Snapshot-Pool an den Snapshot-Pool auf der Remote-Appliance übertragen. Dazu ist eine StreamSnap-Replikationsrichtlinie in der Vorlage erforderlich und es 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), damit die Sicherungs-/Wiederherstellungs-Appliance die Größe des Staging-Laufwerks, das zum Speichern von Logs erforderlich ist, besser berechnen kann. Diese Einstellung ist ein Prozentsatz. Gültige Werte sind 0 bis 100.

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

Erweiterte Einstellungen für das Überschreiben von Richtlinieneinstellungen konfigurieren

Klicken Sie im Fenster Sicherungsplan verwalten auf Richtlinienüberschreibungen, um das Dialogfeld Richtlinieneinstellungen überschreiben 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 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 Standardeinstellung zurückgesetzt werden, um alle Richtlinienüberschreibungen auf den Standardzustand zurückzusetzen.

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

  • Do Not Unmap (Zuordnung nicht aufheben). Staging-Laufwerke zwischen Jobs zugeordnet lassen: Wählen Sie diese Option aus, wenn Sie möchten, dass temporäre Staging-Laufwerke, die dem Host zugeordnet sind und während der Datenverschiebung verwendet werden, dem Host zugeordnet bleiben. LUNs werden während des ersten Jobs zugeordnet und alle nachfolgenden Jobs verwenden dieselbe zugeordnete LUN wieder. Diese Option ist standardmäßig ausgewählt. Staging-Laufwerke nach jedem Job trennen: Mit dieser Option wird das Staging-Laufwerk am Ende jedes Jobs vom Betriebssystem getrennt (Bereitstellungspunkte oder Laufwerksbuchstaben werden entfernt) und auch vollständig vom Host getrennt. Bei dieser Option muss der Host zu Beginn des nächsten Jobs einen Scan nach SCSI-LUNs durchführen, da die neu zugeordneten Staging-Laufwerke neu erkannt werden müssen, bevor sie wieder bereitgestellt werden können.

  • Truncate Log After Backup. Geben Sie an, ob die Logs nach jeder Sicherung gekürzt werden sollen. Wenn diese Option aktiviert ist, werden anwendungsbezogene Logs bis zur letzten oder aktuellen Sicherung gekürzt. Wenn Sie Logs kürzen, müssen Sie auch das Transaktionslog sichern, um eine Roll-Forward-Wiederherstellung zu ermöglichen.

  • Offline-Anwendungen 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 zusammen zu sichern und 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 fehlschlagen lassen, wenn Offline-Anwendungen gefunden werden
    • Offline-Anwendungen bei der Sicherung überspringen

  • Staging-Laufwerke allen ESX-Hosts in einem Cluster zuordnen. (Diese Option ist bei Verwendung von NFS-Datenspeichern nicht relevant.) Staging-Laufwerk nur für die VM dem ESX-Host zuordnen. Ordnen Sie das Staging-Laufwerk allen ESX-Hosts im Cluster zu. Staging-Laufwerk 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 (Application Awareness-Bereitstellung), können die gesicherten Nutzeranmeldungen optional in der SQL Server-Zielinstanz wiederhergestellt werden. So wird sichergestellt, dass die virtuelle Datenbank für dieselben Nutzer zugänglich ist, die Zugriff auf die ursprüngliche Quelldatenbank haben. Die Optionen sind Ja oder Nein.

  • Datenbank-Log-Sicherung aktivieren. Mit der Option 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 Sie Ja auswählen, werden die zugehörigen Optionen aktiviert.

  • RPO. Wenn Datenbank-Log-Sicherung aktivieren auf Ja gesetzt ist, definiert der RPO-Wert die Häufigkeit der Datenbank-Log-Sicherung. Die Häufigkeit wird in Minuten festgelegt und darf das Intervall für die Datenbanksicherung nicht überschreiten. Der kleinste Wert, der festgelegt werden kann, beträgt 15 Minuten.

  • Log Backup Retention Period (Aufbewahrungsdauer für Log-Sicherungen) Wenn Datenbank-Log-Sicherung aktivieren auf Ja gesetzt ist, wird die Logaufbewahrung separat von der Aufbewahrung der Snapshot-Richtlinie definiert. Mit einer separaten Aufbewahrungsdauer können Sie Logs in Verbindung mit Kopien der Datenbank verwenden, die im Snapshot-Pool gespeichert sind. Die Aufbewahrungsdauer für Logs ist eine obligatorische Einstellung.

  • Logs replizieren. (Verwendet StreamSnap-Technologie) Wenn Datenbankprotokollsicherung aktivieren auf Aktivieren gesetzt ist, können mit der erweiterten Einstellung Protokolle replizieren Microsoft SQL Server-Datenbanktransaktionsprotokolle auf eine Remote-Sicherungs-/Wiederherstellungs-Appliance repliziert werden. Damit ein Logreplikationsjob ausgeführt werden kann, muss in der Vorlage eine StreamSnap-Replikationsrichtlinie zusammen mit einem Ressourcenprofil vorhanden sein, das eine Remote-Sicherungs-/Wiederherstellungs-Appliance angibt. Außerdem muss zuerst mindestens eine erfolgreiche Replikation der Datenbank abgeschlossen werden. Sie können dann die Logs am Remote-Standort für jedes Datenbank-Image innerhalb des Aufbewahrungsbereichs 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 mit dieser Einstellung Microsoft SQL Server-Datenbanktransaktionslogs in einen OnVault-Pool repliziert werden. Damit ein Protokollreplikationsjob ausgeführt werden kann, muss die Vorlage eine OnVault-Richtlinie sowie ein Ressourcenprofil enthalten, das einen OnVault-Pool angibt. Außerdem muss mindestens eine Datenbank an den Pool gesendet werden. Sie können dann die Logs am Remotestandort für jedes Datenbank-Image innerhalb des Aufbewahrungszeitraums verwenden. Diese Funktion ist standardmäßig aktiviert.

  • Größe des Log-Staging-Laufwerks. Wenn Datenbank-Logsicherung aktivieren auf Ja gesetzt ist, definiert Größe des Laufwerkswachstums für Log-Staging das Wachstum, das beim automatischen Erweitern des Staging-Laufwerks, auf dem sich die Logs befinden, verwendet werden soll. Diese Einstellung liegt zwischen 5 und 100 %.

  • Geschätzte Änderungsrate. Wenn Datenbank-Log-Sicherung aktivieren auf Ja gesetzt ist, definiert diese Einstellung die tägliche Änderung (in Prozent). Dadurch kann die Sicherungs-/Wiederherstellungs-Appliance die Größe des Staging-Laufwerks besser berechnen, das zum Speichern von Logs erforderlich ist. Diese Einstellung liegt im Bereich von 0 bis 100.

  • Datenbankprotokollsicherung komprimieren. Wenn Datenbankprotokollsicherung aktivieren auf Ja gesetzt ist, wird die Quelldatenbank angewiesen, ihre Protokolle zu komprimieren, bevor sie von der Appliance-Verwaltungskonsole gesichert werden. Der Datenbankserver führt während der Protokollsicherung eine Protokollkomprimierung durch. Die Optionen sind Ja oder Nein. Wenn Sie Ja festlegen, ist die Option Datenbank-Log-Sicherung komprimieren aktiviert.

  • Zeitlimit für Script. Mit dem Backup und 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 Zeitlimits, die in einer Richtlinienvorlage angegeben sind, werden direkt den vier Phasen eines hostseitigen Skripts zugeordnet.

    • Zeitlimit für Scriptinitialisierung. Definiert, wie lange eine Richtlinie warten soll, bevor davon ausgegangen wird, dass hostseitige Skripts auf einem verwalteten Host initialisiert wurden. Der Standardwert ist 120 Sekunden. Der zulässige Bereich liegt zwischen 1 und 86.400 Sekunden (24 Stunden).
    • Zeitlimit für das Einfrieren von Scripts. Definiert, wie lange eine Richtlinie warten soll, bevor davon ausgegangen wird, dass die Anwendung eingefroren und für die Datensicherung bereit 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 Skripts. Definiert, 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 die Ausführung des Scripts. Definiert, wie lange eine Richtlinie warten soll, bis die Datensicherung abgeschlossen ist. Der Standardwert beträgt 60 Sekunden. Der zulässige Bereich liegt zwischen 1 und 86.400 Sekunden.
    • Zeitlimit für Skript 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.

Backup and DR Microsoft SQL Server DBA-Leitfaden

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: