Wiederherstellung einer SQL Express Datenbank

von Philipp Stiefel, ursprünglich veröffentlicht am 9. März 2017

Basierend auf einem Foto von russ101, hier verwendet unter CC0 Lizensierung

Dieser dritte und letzte Artikel über Sicherung deiner Microsoft SQL Server Express Datenbanken schließt das Thema ab. Ich erkläre hier, wie du deine Datenbank aus einem Backup, das du zuvor erstellt hast, wiederherstellst.

Die vorhergehenden Artikel haben die Grundlagen von SQL Server Backups und die Implementierung von automatischen Backups mit SQL Express. Du solltest zumindest mit den Grundlagen der SQL Server Datensicherung vertraut sein, bevor du hier zur Wiederherstellung weiterliest.

Der Inhalt dieses Textes hier, ist grundsätzlich für alle SQL Server Editionen gültig. Da der Schwerpunkt dieser Serie allerdings auf der SQL Express Edition liegt, werde ich nur behandeln wie du eine komplette Datenbank aus einer vollständigen oder differentiellen Sicherung wiederherstellst.  Wenn du für eine „große“ Datenbank auf einer der „größeren“ Editionen von SQL Server verantwortlich bist, solltest du zusätzlich mit der Wiederherstellung von einzelnen Dateien und Dateigruppen und Wiederherstellung des Transaktionsprotokolls vertraut sein. - Dies geht jedoch über den Rahmen dieses Artikels hinaus.

Jeder will Wiederherstellung!

Lass uns mit einem alten Sysadmin-Sprichwort in das Thema einsteigen: “Nobody wants backup, everybody wants restore!” (“Niemand will Backups, jeder will Wiederherstellung!”) – Dahinter steht eine essenzielle Weisheit. Backups, allein für sich gesehen, sind absolut nichts wert. Du musst dir sicher sein, dass es auch tatsächlich möglich, ist die Daten aus dem Backup auch zu einem funktionierenden Zustand wiederherzustellen. Außerdem solltest du genau wissen, wie du das machst.

Wenn dein Backup richtig erstellt wurde, ist die eigentliche Wiederherstellung kein großes Problem. Üblicherweise ist eine Wiederstellungsoperation nichts, das man automatisieren wird. Du startest einfach SQL Server Management Studio und stellst die Datenbank manuell wieder her.

Es gibt zwei verschiedene, gängige Szenarien in es erfordern das du ein Restore deiner Datenbank machst.

Hardware-Ausfall

Hier ist das erste Szenario, das wir uns genauer anschauen werden. Stell dir vor, die Hardware, am wahrscheinlichsten die Festplatten, des Servers sind ausgefallen und die Datenbank wurde beschädigt oder ist komplett verloren gegangen. - Die Datenbanken des Servers auf einem RAID zu speichern reduziert das Risiko, dass so etwas passiert dramatisch. Dennoch, ich hatte tatsächlich mal eine Situation in der die zweite Festplatte eines RAID innerhalb von 48 Stunden nach der Ersten ausgefallen ist und natürlich bevor die Erste durch eine neue ersetzt wurde. - Katastrophen passieren manchmal.

Um dieses Beispiels willen, nehmen wir an, der Rechner auf dem dein SQL Server lief, ist ausgefallen und kann die Datenbankdateien können nicht gerettet werden. Weiterhin nehmen wir an, dass du für diesen Fall vorgesorgt hast und deine Backups an einen anderen Speicherort kopiert hast. Es sind also aktuelle Backups für eine Wiederherstellung vorhanden.

Als erstes musst du natürlich einen anderen SQL Server finden, auf dem du deine Datenbank, zumindest vorübergehend, betreiben kannst. Auf diesem Server muss die gleiche oder eine neuere Version SQL Server laufen. Es ist nicht möglich eine Datenbank auf einem anderen Server wiederherzustellen, auf dem eine ältere Version von SQL Server läuft. Wenn kein anderer SQL Server verfügbar ist, musst du SQL Server auf einem anderen Computer installieren.

Als nächstes kopierst du das aktuellste Backup auf den neuen (Ersatz)-Server. Starte dann SQL Server Management Studio (SSMS) und verbinde dich zu der SQL Server Instanz mit einen Account der entweder in der sysadmin oder dbcreator Server Rolle ist.

Im SSMS wählst du den Datenbanken Ordner in der Baumstruktur des Objekt Explorers aus und rufst Datenbank Wiederherstellen aus dem Kontextmenü auf. Dann, ausgehend vom dem Wiederherstellen Dialog, führst du die folgenden Schritte aus.

1. Die Datenbank, die du wiederherstellen möchtest, existiert auf dem Ersatzserver noch nicht. Ändere also die Quelle auf Medium.
2. Klick auf den …-Button in der Medium-Zeile um den Sicherung Angeben Dialog zu öffnen.
3. In dem Sicherung Angeben Dialog klicke den Hinzufügen Button, um den Sicherungsdatei suchen Dialog zu öffnen.
4. Wähle die Sicherungsdatei aus, die das aktuellste Backup der Datenbank enthält.
5. Bestätige den Sicherungsdatei suchen Dialog mit OK.
6. Bestätige den Sicherung Angeben Dialog mit OK.
7. Schreibe den Datenbanknamen in das Feld Ziel … Datenbank.
8. (Nicht im Screenshot) Bestätige den Datenbank Wiederherstellen Dialog mit OK, um den Wiederherstellungsprozess zu starten.

Nachdem die Wiederherstellung abgeschlossen ist, befindet sich deine Datenbank im gleichen Zustand wie zum Zeitpunkt des letzten Backups. - Jegliche Daten, die nach dem letzten Backup erfasst/geändert wurden sind verloren.

Was du jetzt wahrscheinlich noch machen musst, ist die entsprechenden Berechtigungen für die Benutzer deiner Datenbank zu konfigurieren. Beachte, dass in deiner Datenbank möglicherweise Benutzer existieren, die die gleichen Namen haben wie die auf dem neuen Server, aber die andere Prinzipal SIDs haben. Diese Benutzer sind also nicht dieselben, auch wenn sie dieselben Namen haben. Du musst dann die alten Benutzer löschen und neue anlegen, die auf die richtigen SIDs zeigen.

Der letzte Schritt um die wiederhegestellte Datenbank wieder in Betrieb zu nehmen ist, deine Frontend Anwendung(en) mit dem Ersatzserver zu verbinden. Wenn der neue Server den alten dauerhaft ersetzen wird und er zuvor noch nicht für andere Anwendungen verwendet wurde, ist die einfachste Lösung den neuen Server exakt genauso wie den alten zu benennen.

Wenn diese Lösung nicht in Frage kommt, hast du hier noch ein Problem zu lösen. Du musst die Konfiguration all deiner Client-Anwendungen ändern, so dass sie den neuen Server anstelle des Alten verwenden.

Ich habe üblicherweise eine Update-Script für meine Anwendung auf jedem Client-Computer installiert, das bei jeder Neu-Anmeldung eines Benutzers am Client-Rechner einen zentralen Speicherort auf Updates der Anwendung prüft und gegebenenfalls die Anwendung aktualisiert. - Vielleicht schreibe ich zu einem anderen Zeitpunkt mal mehr darüber, aber jetzt würde das den Rahmen dieses Artikels sprengen.

Unbeabsichtigte Fehlbedienung durch einen Benutzer

Jetzt zum zweiten, gängigen Szenario, das eine Datenbankwiederherstellung erfordert. Diese Szenario könnte eintreten, wenn jemand unbeabsichtigter Weise eine größere Menge an Daten in der Datenbank verändert oder löscht. - Gutes Anwendungsdesign sollte diese Art der Fehlbedienung verhindern, aber lass uns einfach einmal annehmen, es ist trotzdem passiert.

Der Serverrechner und die Datenbank sind im technischen Sinne unbeschädigt und voll funktionsfähig. Allerdings fehlen Daten in der DB, die dringend benötigt werden. - Sei dir bewusst, diese Angelegenheit kann jetzt ziemlich unschön werden.  

Es gibt verschiedene Aspekte des Sachverhalts, die du jetzt bewerten musst. - Schnell!

1. Wie schnell wurde der Benutzerfehler, der zum Datenverlust geführt hat, bemerkt? Hat der Benutzer direkt angerufen, nachdem er aus Versehen die Datenbank korrumpiert hat, oder ist es tage- oder wochenlang unbemerkt geblieben?
2. Wie schwerwiegend wären die Auswirkungen, wenn die Datenbank für einige Zeit offline/unerreichbar wäre? Würde das nur die User leicht stören, oder würde es missionskritische Abläufe in deiner Firma zum kompletten Stillstand bringend?
3. Besteht ein Risiko, dass die ID-Werte der gelöschten Datensätze erneut verwendet werden? Sind davon nur applikationsinterne IDs betroffen oder auch öffentliche IDs? Es ist schlimm genug, wenn es nur interne IDs sind. Das macht deine Arbeit bei der Wiederherstellung komplizierter. Wenn es aber öffentliche IDs, wie Kunden- oder Rechnungsnummern, sind, die bereits wirklichen Kunden mitgeteilt wurden, dann hast du jetzt wirklich ein Problem. Du musst dann auf jeden Fall das weitere Vorgehen mit den fachlichen Verantwortlichen der Anwendung abstimmen.

Wenn die akute Gefahr besteht, dass bereits verwendete IDs der gelöschten Datensätze bei Neueingaben wiederverwendet werden, musst du schnell handeln und die Datenbank in einen Zustand bringen, der Neueingaben verhindert. Die Datenbank in einen zugriffsbeschränkten Zustand zu bringen, wäre eine Möglichkeit, das zu erreichen.

Dafür wähle die Datenbank im Objekt Explorer des SSMS aus und klicke Eigenschaften im Kontextmenü. In dem Dialog Datenbankeigenschaften wechsle auf den Tab Optionen und scrolle runter zu der Option Zugriff Beschränken. Ändere diese Option auf RESTRICTED_USER. Das wird alle bestehenden Verbindungen zur Datenbank trennen und danach den Zugriff nur noch für Mitglieder der db_owner Rolle zulassen. - Die Benutzer deiner Anwendung sind nicht Mitglieder der Rolle db_owner, oder? - Dieses Szenario unterstreicht einmal mehr, dass das keine gute Idee ist.

Denk daran, die obige Eigenschaft der Datenbank wieder zurück auf MULTI_USER zu setzen, wenn du mit der manuellen Wiederherstellung fertig bist.

Dieses Datenverlust-Szenario kann nicht durch eine Wiederherstellung allein gelöst werden. Du wirst die gelöschten Daten manuell retten/neu-erstellen müssen.

Um das zu tun, stelle dein aktuellstes Backup wieder her, das vor dem Datenverlust erstellt wurde. Aber überschreibe dabei nicht die aktuelle, produktive Datenbank. Stattdessen stelle das Backup auf dem gleichen Server, aber in einer neuen Datenbank mit einem anderen Namen, wie z.B. DeineDatenbank_Recovery wieder her.

Die einzelnen Schritte, um die Datenbank wiederherzustellen, sind die gleichen wie in dem obigen Szenario zum Hardware-Ausfall. Denke nur jetzt daran, dass du einen anderen Datenbanknamen als den der Produktiv-Datenbank als Wiederherstellungsziel angibst.

Es ist sicherlich eine gute Idee, eine zusätzliche Kopiesicherung der Produktiv-Datenbank zu machen, bevor du die manuelle Wiederherstellung der Daten beginnst. Nur für den Fall, dass währenddessen etwas gründlich schief geht.

Nach dem reinen Sicherungs-Wiederherstellungsvorgang, musst du jetzt natürlich noch die einzelnen gelöschten Datensätze von der „Recovery“-Datenbank in die echte, produktive Datenbank kopieren. Die genaue Vorgehensweise dabei hängt gänzlich von der Struktur deiner Datenbank und der betroffen Tabellen ab. Daher kann ich dazu keine detaillierten Hinweise geben.

Jegliche Daten, die erst nach der oben wiederhergestellten Sicherung erstmalig erfasst und direkt anschließend auch irrtümlich gelöschten wurde, sind unwiederbringlich verloren.

Bereite dich auf ein Desaster vor!

Ich empfehle dir dringend, dass du einen Probelauf deines Wiederherstellungsprozesses unter realen Bedingungen durchführst. Tu einfach so, als wäre dein normales „Rechenzentrum“ grade abgebrannt und du musst diene Sicherungen auf einem komplett anderen Server anderswo wiederherstellen. – Nimm das erst, nicht schummeln! – Wenn dir irgendetwas essenzielles fehlt, das du noch zusätzlich von dem produktiven Server auf den Ersatz-Sever kopieren musst, um deine Datenbank dort einsatzbereit zu bekommen, dann ist deine Backup-Strategie gescheitert und muss überarbeitet und ergänzt werden.

Du warst erfolgreich und alles hat funktioniert wie geplant? Sehr gut! – Jetzt schreibe alle Schritte auf, die erforderlich waren, um das Backup wieder zum Laufen zu bekommen. – Ich meine das ernst,  schreib . es . auf! – Wenn eine kritische, produktive Datenbank mitten im Betrieb ausfällt, ist das eine stressige Situation. Dein Posteingang füllt sich mit Emails, die das Problem melden, dein Telefon klingelt ununterbrochen und dein Chef könnte hysterisch schreiend in deinem Büro auftauchen. In diesem Durcheinander wirst du sehr, sehr dankbar dafür sein, wenn du eine vollständige Schritt-für-Schritt-Anleitung dafür hast die Datenbank wiederherzustellen. – Glaub mir, ich war dort. Dank der Beharrlichkeit meines damaligen Projektmanagers hatte ich diese Anleitung. Ich bin nicht sicher, ob ich es ohne sie hinbekommen hätte.

Erledigt? - Gratuliere. Jetzt bist du wirklich gut auf jede Katastrophe, die mit deiner Datenbank passieren könnte vorbereitet.

Ich hoffe dir hat diese kleine Artikelserie gefallen. Abonniere doch meinen Newsletter, wenn du zukünftig über neue Artikel auf codekabinett.com informiert werden möchtest.

Share this article: