SQL_Kurs

SQL Server Restore – Problemlösungen für den hängenden Recovery Mode

Wiederherstellung von Datenbanken, typische Fehler und was Sie tun können, wenn der Recovery Status nicht verschwindet

📌 Restore einer SQL Server Datenbank – die Grundlagen

Das Wiederherstellen einer Datenbank aus einem Backup ist eine der wichtigsten Aufgaben eines Datenbankadministrators. Der Befehl RESTORE DATABASE lädt die Sicherungsdatei und stellt die Datenbank in ihren ursprünglichen oder einen neuen Zustand wieder her. Meist läuft dies reibungslos – doch manchmal bleibt die Datenbank nach der Wiederherstellung im Status „In Recovery“ hängen. Dies bedeutet, dass SQL Server die Transaktionsprotokolle abarbeitet (Redo/Undo), um die Datenbank konsistent zu machen. Normalerweise dauert dies nur Sekunden bis Minuten. Wenn es jedoch länger anhält oder sogar stecken bleibt, ist schnelles Handeln gefragt.
💡 Wichtig: Ein Restore besteht aus zwei Phasen: Kopieren der Daten (Dateien werden aus dem Backup gelesen) und der Recovery-Phase (Transaktionen werden zurückgespielt oder rückgängig gemacht). Der hängende Recovery Mode tritt in der zweiten Phase auf.

🛠️ RESTORE DATABASE – der Standardbefehl

Ein typischer Restore einer Voll- und Differentialsicherung (mit Recovery) sieht wie folgt aus:
-- Vollständige Wiederherstellung (Datenbank wird nach dem Restore sofort verfügbar)
RESTORE DATABASE [MeineDatenbank] 
FROM DISK = N'D:\Backups\MeineDatenbank_Full.bak'
WITH REPLACE, RECOVERY;

-- Wenn Sie anschließend noch differenzielle oder Log-Backups einspielen wollen, verwenden Sie NORECOVERY
RESTORE DATABASE [MeineDatenbank] 
FROM DISK = N'D:\Backups\MeineDatenbank_Full.bak'
WITH NORECOVERY;

-- Danach Differenz-Backup
RESTORE DATABASE [MeineDatenbank] 
FROM DISK = N'D:\Backups\MeineDatenbank_Diff.bak'
WITH RECOVERY;
⚠️ Typische Fehlerquelle: Wenn Sie versehentlich WITH RECOVERY vergessen (oder es ist Standard) und dann ein weiteres Backup einspielen wollen, schlägt der nächste Restore fehl. Dann müssen Sie erneut mit NORECOVERY beginnen.

🔍 Ursachen für einen hängenden Recovery Mode

Folgende Situationen können dazu führen, dass eine Datenbank nach dem Restore nicht aus dem Status „In Recovery“ kommt:
  • Sehr große aktive Transaktionen im Backup: Lange Transaktionen müssen während der Recovery zurückgerollt werden – das kann Stunden dauern.
  • Defekte oder inkonsistente Backup-Datei: Beschädigte Sicherung kann den Recovery-Prozess blockieren.
  • Unzureichender Speicherplatz im Transaktionslog: Das Log kann während der Recovery wachsen (z. B. bei offenen Transaktionen).
  • Blockierende Systemprozesse: Andere Abfragen oder Hintergrundprozesse halten Sperren.
  • Datenbank im EMERGENCY-Modus bereits zuvor: Kombination mit REPAIR_ALLOW_DATA_LOSS kann zu Inkonsistenzen führen.
  • Fehlende Berechtigungen auf Dateiebene: SQL Server kann nicht auf die Log-Datei schreiben.
  • Ein Bug im SQL Server (sehr selten, aber bekannt).
💡 Erste Maßnahme: Prüfen Sie den Status mit SELECT name, state_desc FROM sys.databases. Bei RECOVERING läuft die Recovery noch. Bei RECOVERY_PENDING gibt es ein Problem.

📊 Fortschritt der Recovery verfolgen

Mit den folgenden DMVs und Befehlen sehen Sie, ob die Recovery noch aktiv ist und wie weit sie fortgeschritten ist.
-- Aktuelle Recovery-Prozesse anzeigen
SELECT 
  session_id,
  command,
  status,
  percent_complete,
  estimated_completion_time
FROM sys.dm_exec_requests
WHERE command = 'DB STARTUP' OR command LIKE '%RECOVERY%';

-- Allgemeinen Datenbankstatus
SELECT 
  name,
  state_desc,
  recovery_model_desc
FROM sys.databases
WHERE name = 'IhreDB';

-- Fehlerprotokoll auf Recovery-bezogene Meldungen durchsuchen
EXEC xp_readerrorlog 0, 1, 'recovery', NULL, NULL, NULL, 'DESC';
📌 Hinweis: Wenn percent_complete sich über längere Zeit nicht bewegt, liegt wahrscheinlich ein Problem vor.

⌛ Lösung 1: Geduld (bei sehr großen Transaktionen)

Wenn das Backup eine sehr lange, noch nicht abgeschlossene Transaktion enthält (z. B. eine Massenaktualisierung ohne COMMIT), muss SQL Server beim Recovery genau diese Transaktion zurücksetzen (Rollback). Das kann je nach Datenmenge und Serverleistung Stunden dauern. Der Fortschritt ist in sys.dm_exec_requests sichtbar. Greifen Sie nur dann ein, wenn der Prozess nach einem angemessenen Zeitraum keine Fortschritte mehr zeigt.
💡 Empfehlung: Lassen Sie den Prozess über Nacht laufen, bevor Sie drastische Maßnahmen ergreifen. Ein Rollback von 500 Millionen Zeilen kann durchaus 8–12 Stunden dauern.

🔄 Lösung 2: SQL Server Dienst neu starten

Ein Neustart des SQL Server-Dienstes kann eine blockierte Recovery oft lösen, weil der Startvorgang die Recovery neu initialisiert. Gehen Sie wie folgt vor:
  1. Stoppen Sie den SQL Server-Dienst über die Services-Konsole oder SSMS.
  2. Starten Sie den Dienst neu.
  3. Nach dem Start sollte die Datenbank normal online gehen – sofern keine Korruptur vorliegt.
Diese Methode ist risikoarm, da kein Datenverlust droht. Sie funktioniert oft bei hängenden Recovery-Prozessen durch unklare Blockierungen.
⚠️ Achtung: Bei sehr großen Transaktionen wird der Rollback nach einem Neustart nicht abgebrochen, sondern fortgesetzt. Der Neustart selbst kann also nicht den Rollback beschleunigen, beseitigt aber manchmal andere Blockaden.

🚑 Lösung 3: EMERGENCY Modus & DBCC CHECKDB

Wenn die Datenbank nach einem Neustart immer noch im Recovery Mode hängt (oder im Status RECOVERY_PENDING), können Sie versuchen, sie in den Notfallmodus zu versetzen und zu reparieren. Achtung: Dies kann zu Datenverlust führen!
-- 1. Datenbank in den EMERGENCY Modus versetzen (nur erfahrene DBAs!)
ALTER DATABASE [IhreDB] SET EMERGENCY;

-- 2. Auf Konsistenz prüfen (read-only)
DBCC CHECKDB ([IhreDB]) WITH NO_INFOMSGS, ALL_ERRORMSGS;

-- 3. Wenn Korrupturen gefunden werden: Reparatur (mit Datenverlust!)
DBCC CHECKDB ([IhreDB], REPAIR_ALLOW_DATA_LOSS);

-- 4. Nach erfolgreicher Reparatur: Datenbank wieder online schalten
ALTER DATABASE [IhreDB] SET ONLINE;
🚨 Warnung: REPAIR_ALLOW_DATA_LOSS kann Zeilen oder ganze Seiten löschen, um die Konsistenz wiederherzustellen. Nutzen Sie dies nur, wenn Sie keine andere Möglichkeit haben und ein aktuelles Backup fehlt. Idealerweise ersetzen Sie die Datenbank durch ein intaktes Backup.

⚡ Lösung 4: Manuelles Abbrechen der Recovery (nicht immer möglich)

In einigen Fällen können Sie den Recovery-Prozess durch Abbrechen des zugehörigen SPID (session_id) beenden – allerdings ist das nicht immer erlaubt. Sie können auch versuchen, die Datenbank offline zu setzen, um den Vorgang zu unterbrechen.
-- SPID der Recovery finden (siehe oben)
SELECT session_id, command 
FROM sys.dm_exec_requests 
WHERE command LIKE '%RECOVERY%';

-- Versuch, den Prozess zu beenden (Vorsicht!)
KILL ;

-- Alternativ: Datenbank offline erzwingen (unterbricht die Recovery und setzt sie beim nächsten Online-Schalten fort)
ALTER DATABASE [IhreDB] SET OFFLINE;
ALTER DATABASE [IhreDB] SET ONLINE;
⚠️ Hinweis: KILL funktioniert nicht immer, da Recovery-Prozesse oft als Systemprozesse laufen. Offline/Online kann ebenfalls die Recovery neu starten, aber nicht abbrechen.

🛡️ Präventive Maßnahmen

  • Regelmäßige Backups testen: Führen Sie regelmäßige Test-Restores auf einer separaten Umgebung durch.
  • Keine langen Transaktionen: Vermeiden Sie Transaktionen, die viele Stunden laufen. Unterteilen Sie große Updates in Batches.
  • Ausreichend Log-Speicherplatz: Die Recovery benötigt Platz im Transaktionslog – überwachen Sie diesen.
  • Verwenden Sie WITH CHECKSUM beim Backup: So wird die Backup-Integrität schon beim Erstellen geprüft.
  • Vermeiden Sie REPAIR_ALLOW_DATA_LOSS im Alltag.
  • Stellen Sie sicher, dass die SQL Server-Dienstkonten volle Schreibrechte auf die Zielverzeichnisse haben.
  • Nutzen Sie für kritische Datenbanken die Option RESTORE VERIFYONLY vor dem eigentlichen Restore.
-- Prüfung der Backup-Integrität vor dem Restore
RESTORE VERIFYONLY FROM DISK = N'D:\Backups\MeineDB.bak';

✅ Checkliste – Was tun, wenn die Datenbank im Recovery Mode hängt?

  1. Status prüfenSELECT state_desc FROM sys.databases WHERE name = '...'
  2. Fortschritt beobachtensys.dm_exec_requests mit command = 'DB STARTUP'
  3. Fehlerprotokoll lesenxp_readerrorlog nach 'recovery' durchsuchen
  4. Bei Fortschritt > 10 % und Bewegung: Geduld haben.
  5. Bei Stillstand > 30 Minuten: SQL Server Dienst neu starten.
  6. Wenn das nicht hilft: Datenbank in EMERGENCY versetzen und DBCC CHECKDB mit REPAIR_ALLOW_DATA_LOSS (letzte Option).
  7. Alternativ: Restore mit WITH REPLACE, RECOVERY wiederholen (falls Backup noch intakt).
🚀 Fazit: Ein hängender Recovery Mode ist meist harmlos, sondern deutet auf einen langen Rollback hin. Mit den richtigen Diagnose-Tools finden Sie schnell heraus, ob Sie eingreifen müssen. Im Zweifel ist ein Neustart des Dienstes oder die Wiederherstellung aus einem anderen Backup der sicherste Weg.
Nächster SQL Server – QUOTED_IDENTIFIER & ANSI_NULLS
Cookies user preferences
We use cookies to ensure you to get the best experience on our website. If you decline the use of cookies, this website may not function as expected.
Accept all
Decline all
Analytics
Tools used to analyze the data to measure the effectiveness of a website and to understand how it works.
Google Analytics
Advertisement
If you accept, the ads on the page will be adapted to your preferences.
Google Ad
Save