Aktuell gibt es viele Desaster-Recovery-(DR)-Technologien in der Industrie, einschließlich Datenbank-Spiegelung, Clustering und Replikationslösungen. Log Shipping ist jedoch eine einfachere, leichter zu konfigurierende und zu wartende Methode. In diesem Artikel werden die Schritte zum Desaster-Recovery bei SQL Server mit Log Shipping erläutert.
Disaster-Recovery-Lösung mit Protokollweiterleitung
Die Protokollweiterleitung hält in erster Linie Sicherungskopien auf einem sekundären Server und übernimmt bei Bedarf den primären Server, um die Verfügbarkeit der Gesamt-Datenbank zu verbessern. Mit anderen Worten: Wenn die primäre Datenbank aufgrund einer Katastrophe nicht verfügbar ist, können Sie die sekundäre Datenbank manuell online schalten, um den Dienst fortzusetzen.
Um das Log Shipping für eine Datenbank zu konfigurieren, erstellt SQL Server die folgenden drei Agent-Aufträge, um Backup-, Kopier- und Wiederherstellungsvorgänge zu automatisieren:
Der erste Auftrag wird auf der Primärinstanz ausgeführt. Er sichert das Transaktionsprotokoll auf der Primärdatenbank.
Der zweite Job wird auf dem sekundären Server ausgeführt. Er kopiert die Protokoll-Sicherungen vom primären auf den sekundären Server.
Der dritte Job wird ebenfalls auf dem sekundären Server ausgeführt. Er stellt die Protokollsicherungen wieder her und aktualisiert die Protokolleinträge in der sekundären Datenbank.
Überlegungen vor der Konfiguration des Log Shippings in SQL Server
Obwohl die Konfiguration von Log Shipping nicht schwierig ist, müssen vor der Implementierung mehrere Überlegungen angestellt werden:
Schutz auf Datenbankebene: Wenn Sie nur eine kleine Anzahl von Datenbanken im Fall einer Katastrophe schützen müssen, ist diese Ebene ausreichend. Wenn Sie jedoch mehrere Datenbanken auf der Ebene der SQL Server-Instanz beibehalten möchten, ist eine eigenständige Lösung mit Protokollversand unzureichend.
Manueller Failover auf dem sekundären Server: Ein reines Log Shipping kann nicht automatisch zum sekundären Server ausweichen. Sie müssen die sekundäre Datenbank manuell online schalten.
Manuelle Konfiguration der SQL-Anmeldung: SQL-Anmeldungen werden nicht automatisch vom primären Server zum sekundären Server übertragen. Sie müssen die Anmeldeinformationen vom primären Server auf den sekundären Server übertragen, um die Anmeldungen zu synchronisieren. Zusätzlich müssen Sie häufig verschiedene Wartungspläne, verknüpfte Server sowie SSIS (SQL Server Integration Services)-Pakete manuell auf dem sekundären Server erstellen.
Datenverlustgefahr: Üblicherweise kann bei Ausfall der primären Datenbank nur das letzte Transaktionsprotokoll-Backup wiederhergestellt werden. Das bedeutet, dass alle nach dem letzten Protokoll-Backup auf dem sekundären Server stattgefundenen Transaktionen verloren gehen. Wenn beispielsweise der primäre Server um 9:00 Uhr ausfällt und das letzte auf die sekundäre Serverinstanz B kopierte Backup um 8:45 Uhr erstellt wurde, gehen alle Daten von 8:45 Uhr bis 9:00 Uhr verloren.
Reverse Log Shipping: Dies ist nützlich, wenn Sie Serverrollen wechseln, ohne eine vollständige Datenbanksicherung durchzuführen. Beispielsweise, wenn Sie eine große Sicherung haben und Daten vom sekundären Server zu einem entfernten primären Server übertragen müssen. Das Kopieren der gesamten Sicherung könnte sehr lange dauern.
So konfigurieren und verwenden Sie das Protokollversand?
In der Regel lässt sich der Prozess der Konfiguration des Protokollversands in zwei klare Schritte unterteilen:
Schritt 1 – Initialisieren der Datenbank auf dem sekundären Server
Angenommen, wir haben zwei Datenbanken auf der primären Serverinstanz, und wir müssen die Protokolle für TestDB1 zu einem sekundären Server replizieren, der ursprünglich über keine Datenbanken verfügt. Es ist wichtig zu beachten, dass die Datenbank sich im FULL- oder BULK-LOGGED-Wiederherstellungsmodus befinden muss, um das Protokollreplizieren einzurichten. Wenn sich die Datenbank im SIMPLE-Wiederherstellungsmodus befindet, tritt bei der Protokollreplikation ein Fehler auf, da Sicherungen des Transaktionsprotokolls nicht verwendet werden können.
1. Zuerst müssen wir eine vollständige Datenbanksicherung und eine Transaktionsprotokollsicherung durchführen. Sie können die folgenden T-SQL-Abfragen ausführen, um „vollständige“ und „Transaktionsprotokoll“-Sicherungen zu erstellen:
backup database TestDB1 to disk = 'c:\backup\TestDB1.bak'
backup log TestDB1 to disk = 'c:\backup\TestDB1.bak'
2. Stellen Sie als Nächstes die Sicherung auf dem sekundären Server wieder her.
3. Wählen Sie in der Schnittstelle Restore Database die Option Device als Datenquelle aus und klicken Sie auf das entsprechende Symbol.
4. Klicken Sie im Dialogfeld Select backup devices auf Add.
5. Wählen Sie die Sicherungsdatei zum Wiederherstellen aus und klicken Sie auf OK.
6. Führen Sie die Wiederherstellung für das TestDB1-Backup aus.
7. Klicken Sie auf Select a page und gehen Sie zu Files, um die physischen Datenbankdateipfade ggf. zu ändern.
8. Klicken Sie anschließend auf der linken Seite auf Options. Wählen Sie auf der Seite Options aus der Dropdown-Liste Recovery State die Einstellung RESTORE WITH STANDBY aus. Beachten Sie, dass die Auswahl von RESTORE WITH STANDBY sicherstellt, dass die Datenbank im schreibgeschützten Modus bleibt. Falls Sie RESTORE WITH NORECOVERY auswählen, ist die Datenbank nicht zugänglich.
9. Klicken Sie nach der Auswahl des entsprechenden Wiederherstellungszustands auf OK, um eine erfolgreiche Wiederherstellung sicherzustellen. Dadurch wird TestDB1 im Standby-Modus (schreibgeschützt) auf der sekundären Serverinstanz wiederhergestellt.
An diesem Punkt wurde die Datenbank auf dem sekundären Server erfolgreich initialisiert.
Schritt 2 – Aktivieren der primären Datenbank
1. Klicken Sie mit der rechten Maustaste auf TestDB1 auf der primären Serverinstanz und klicken Sie auf Properties.
2. Wählen Sie Enable this as the primary database in the log shipping configuration.
Standardmäßig wird das Transaktionsprotokoll alle 15 Minuten gesichert. In einigen Fällen kann das Transaktionsprotokoll jedoch zu groß werden, um innerhalb des vorgegebenen Zeitlimits kopiert und wiederhergestellt zu werden. Um dies zu beheben, müssen Sie zusätzliche Protokollsicherungen planen. Klicken Sie auf Sicherungseinstellungen, geben Sie den Speicherort der Sicherungsdatei im Bereich „Transaktionsprotokoll-Sicherungseinstellungen“ an, klicken Sie anschließend auf „Zeitplan“, und ändern Sie die Sicherungshäufigkeit so, dass sie alle 1–2 Minuten ausgeführt wird.
3. Klicken Sie auf Add, um die sekundäre Datenbank einzurichten. Das System fordert Sie daraufhin auf, eine Verbindung mit der sekundären Serverinstanz herzustellen.
4. Wie in Schritt 1 konfiguriert, im Interface Secondary Database Settings die Option No, the secondary database is initialized. auswählen.
5. Fahren Sie fort, indem Sie den Speicherort des Sicherungsordners des sekundären Servers angeben, die Sicherungshäufigkeit festlegen und auf OK klicken.
6. Setzen Sie im Interface Restore Transaction Log den Datenbankstatus auf Standby mode und aktivieren Sie die Option Disconnect users in the database when restoring backups. Stellen Sie das Backup-Intervall ein und klicken Sie anschließend auf OK.
7. Um die sekundäre Serverinstanz und Datenbank hinzuzufügen, klicken Sie auf OK , um SQL Server-Agent-Aufträge zu erstellen.
Im SQL Server-Agent auf dem Primärserver finden Sie den Wartungsauftrag für die Transaktionsprotokollsicherung.
Unter dem SQL Server-Agent auf dem sekundären Server finden Sie zwei neu erstellte Aufträge: einen, der Sicherungen des Transaktionsprotokolls von der primären Datenbank kopiert, und einen weiteren, der die Sicherungen des Transaktionsprotokolls auf der sekundären Datenbank wiederherstellt.
8. An dieser Stelle ist die Lösung für die Wiederherstellung nach einer Katastrophe mit Protokollversand vollständig konfiguriert. Falls die primäre Datenbank ausfällt, können Sie die sekundäre Datenbank sofort online schalten. Sie können auch die folgende Abfrage ausführen, um zu überprüfen, ob die sekundäre Datenbank den Bereitschaftsmodus verlassen hat:
Select * from Products
RESTORE DATABASE TestDB1 WITH RECOVERY
9. Durch das Aktualisieren der Datenbank sehen Sie, dass TestDB1 auf dem sekundären Server jetzt online ist.
Weitreichende Datenschutzstrategie für SQL Server
Bei der Implementierung von Lösungen zur Wiederherstellung nach Katastrophen, wie z.B. Log Shipping, benötigen Unternehmen häufig eine umfassendere und effizientere Datenschutzstrategie. Vinchin Backup & Recovery bietet eine automatisierte Backup- und Wiederherstellungslösung, die speziell für virtuelle Maschinen und Datenbanken wie SQL Server entwickelt wurde. Sie unterstützt Voll-, Inkremental- und Differenz-Backups. Dank integrierter Technologien zur Daten-Deduplizierung und Kompression wird der Speicherbedarf sowie die Backup-Zeit erheblich reduziert.
Zusätzlich entfällt bei Vinchins Backup-Lösung der Bedarf für komplexe manuelle Eingriffe, wodurch ein automatischer Schutz von Datenbanken ermöglicht und gleichzeitig die Migration zwischen verschiedenen Plattformen sowie die Speicherung in der Cloud unterstützt wird. Falls ein SQL-Server ausfällt, hilft Vinchin Administratoren dabei, Datenbanken schnell wiederherzustellen, verhindert dadurch Datenverluste und langanhaltende Ausfallzeiten und bietet somit einen umfassenderen Schutz bei der Wiederherstellung nach Katastrophen.
Um Sicherungsaufträge für SQL Server-Datenbanken zu erstellen, gehen Sie bitte zur Seite Physische Sicherung > Datenbanksicherung > Sicherung:
1. Wählen Sie die Datenbanken aus, die gesichert werden müssen.
2. Wählen Sie einen Sicherungsknoten aus, auf dem die Sicherungsdaten verarbeitet und gespeichert werden sollen.
3. Konfigurieren Sie Sicherungsstrategien entsprechend Ihren Anforderungen.
4. Prüfen und bestätigen Sie die Einstellungen.
Klicken Sie auf die untenstehende Schaltfläche, um die 60-tägige kostenlose Testversion von Vinchin auszuprobieren und eine effiziente und zuverlässige Lösung für Datensicherung und Wiederherstellung kennenzulernen!
SQL-Server-Desasterwiederherstellung – Häufig gestellte Fragen
1. Welcher Unterschied besteht zwischen Hochverfügbarkeit (HA) und Desasterwiederherstellung (DR)?
HA gewährleistet mithilfe von Failover-Clustering, Always On-Verfügbarkeitsgruppen oder Datenbankspiegelung minimale Ausfallzeiten, während sich DR darauf konzentriert, den Service nach katastrophalen Ausfällen wiederherzustellen, häufig unter Verwendung von Offsite-Backups oder sekundären Rechenzentren.
2. Was ist eine SQL Server-Failoverclusterinstanz (FCI) und wie unterstützt sie die Katastrophenwiederherstellung (DR)?
Eine FCI ist eine Hochverfügbarkeitslösung, die Windows Server-Failovercluster (WSFC) verwendet, um auf Ebene der SQL Server-Instanz automatisches Failover bereitzustellen. Sie erfordert gemeinsam genutzten Speicher (SAN, Storage Spaces Direct oder cloud-basierte Lösungen). Sie ist ideal für die lokale Hochverfügbarkeit, allein aber keine DR-Lösung, da sie keinen Schutz vor ausfallsbedingten Problemen auf der gesamten Site bietet.
Schlussfolgerung
Log Shipping ist eine wirtschaftliche, effiziente und einfache Lösung für die Wiederherstellung nach Katastrophen für SQL Server. Sie ist eine ideale Wahl für die Wiederherstellung auf Datenbankebene. Für die Wiederherstellung auf Instanzebene sollten jedoch andere DR-Techniken wie Datenbank-Mirroring oder Failover-Clustering in Betracht gezogen werden. Außerdem kann Log Shipping zu Datenverlusten führen. Falls Sie gelöschte oder nicht zugängliche Daten aus einer beschädigten SQL-Datenbank wiederherstellen müssen, erwägen Sie die Verwendung eines professionellen SQL-Wiederherstellungstools.
