Ein SQL Server Backup testen heißt mehr, als eine erfolgreiche Meldung des Backup-Jobs zu kontrollieren. Erst wenn sich die Sicherung auf einer getrennten Instanz wiederherstellen lässt und die Datenbank anschließend geprüft wurde, weißt du, ob dein Wiederherstellungsweg funktioniert. Genau dafür ist ein regelmäßiger Restore-Probelauf da.

Diese Anleitung führt dich von der Auswahl der Backup-Datei bis zur Integritätsprüfung der wiederhergestellten Datenbank. Du erfährst auch, warum RESTORE VERIFYONLY allein nicht ausreicht und welche Fehler bei Dateipfaden, Berechtigungen, Verschlüsselung und Backup-Ketten häufig auftreten.

Warum solltest du ein SQL Server Backup testen?

Eine vorhandene .bak-Datei beantwortet noch nicht alle Fragen, die im Ernstfall wichtig werden: Kann der Zielserver die Datei lesen? Ist genügend Speicherplatz vorhanden? Kennst du die logischen Dateinamen für den Restore? Sind benötigte Zertifikate verfügbar? Und ist die Datenbank nach dem Wiederherstellen konsistent?

Ein Probelauf macht diese Fragen zu einem Zeitpunkt sichtbar, an dem die Produktivdatenbank noch läuft. Zugleich kannst du festhalten, wie lange die Wiederherstellung tatsächlich dauert. Dieser Wert hilft dir einzuschätzen, ob dein Wiederherstellungsziel im Störungsfall erreichbar ist.

Für weitere Themen rund um Datenbanken und SQL Server findest du Beiträge in unserer Datenbank-Rubrik.

Was der Restore-Probelauf abdeckt

In diesem Beispiel stellen wir eine vollständige Datenbanksicherung auf einer separaten Testinstanz unter dem Namen AppDB_RestoreTest wieder her. Anschließend prüfen wir den Datenbankstatus, führen DBCC CHECKDB aus und kontrollieren einige fachlich wichtige Daten.

Die Namen und Pfade in den SQL-Beispielen sind Beispiele. Ersetze sie vor der Ausführung durch die Werte deiner Umgebung. Wenn dein Backup aus mehreren Dateien besteht oder die Datenbank zusätzliche Datendateien enthält, musst du alle beteiligten Dateien berücksichtigen.

Schritt 1: Testumgebung vorbereiten

Verwende nach Möglichkeit eine Instanz, auf der keine produktiven Datenbanken laufen. Das senkt das Risiko einer Verwechslung und erlaubt dir, den Restore samt Integritätsprüfung ohne Last auf dem Produktivserver durchzuführen.

  • SQL-Server-Version: Die Testinstanz darf nicht älter sein als die Instanz, auf der das Backup erstellt wurde. Ein Backup aus einer neueren SQL-Server-Version lässt sich nicht auf einer älteren Version wiederherstellen.
  • Speicherplatz: Plane Platz für die wiederhergestellten Daten- und Logdateien sowie für die anschließende Prüfung ein. Die Größe einer komprimierten Backup-Datei ist dafür kein ausreichender Maßstab.
  • Dateizugriff: Das SQL-Server-Dienstkonto der Testinstanz muss die Backup-Datei lesen und in den Zielverzeichnissen Dateien anlegen können.
  • Verschlüsselung: Bei mit TDE oder Backup-Verschlüsselung geschützten Sicherungen müssen die passenden Zertifikate beziehungsweise Schlüssel auf der Zielinstanz verfügbar sein.
  • Datenschutz: Eine wiederhergestellte Produktivdatenbank enthält gegebenenfalls echte personenbezogene oder vertrauliche Daten. Schütze die Testinstanz entsprechend und begrenze den Zugriff.

Notiere vor dem Start, welches Backup du prüfst: Datenbankname, Erstellungszeit, Speicherort und gegebenenfalls die zugehörigen differenziellen und Transaktionslog-Sicherungen. Verwende im Probelauf genau die Dateien, die du auch für eine Wiederherstellung im Ernstfall benötigen würdest.

Schritt 2: Backup-Satz und Dateinamen prüfen

Verbinde dich mit der Testinstanz und führe die folgenden Befehle dort aus. RESTORE HEADERONLY zeigt die Backup-Sätze in der Datei. Das ist besonders wichtig, wenn mehrere Sicherungen in derselben Datei gespeichert wurden.

RESTORE HEADERONLY
FROM DISK = N'D:\Backups\AppDB_full.bak';

Achte im Ergebnis insbesondere auf die Position des gewünschten Backup-Satzes, den Sicherungstyp und das Erstellungsdatum. In den folgenden Beispielen wird FILE = 1 verwendet. Steht dein gewünschtes Backup an einer anderen Position, ersetze die 1 durch den passenden Wert.

Mit RESTORE FILELISTONLY erhältst du die logischen Namen der Daten- und Logdateien. Diese Namen brauchst du gleich für die MOVE-Anweisungen:

RESTORE FILELISTONLY
FROM DISK = N'D:\Backups\AppDB_full.bak'
WITH FILE = 1;

Im Beispiel nehmen wir an, dass die logischen Namen AppDB und AppDB_log lauten. Übernimm nicht blind diese Namen: Maßgeblich ist das Ergebnis deiner eigenen FILELISTONLY-Abfrage. Enthält die Sicherung weitere Dateien, benötigst du beim Restore für jede an einen neuen Ort verschobene Datei eine passende MOVE-Angabe.

Schritt 3: Backup-Datei vorab verifizieren

Als zusätzliche Vorprüfung kannst du RESTORE VERIFYONLY ausführen:

RESTORE VERIFYONLY
FROM DISK = N'D:\Backups\AppDB_full.bak'
WITH FILE = 1;

Der Befehl prüft unter anderem, ob der Backup-Satz vollständig und lesbar ist. Sind Backup-Prüfsummen vorhanden, können sie ebenfalls überprüft werden. Eine erfolgreiche Verifizierung ersetzt jedoch keinen echten Restore: Die Datenbank wird dabei nicht wiederhergestellt, und die Struktur der enthaltenen Daten wird nicht vollständig geprüft.

Wenn die Vorprüfung bereits scheitert, untersuche zuerst die Datei, den angegebenen Backup-Satz und den Zugriff der Testinstanz auf den Speicherort. Setze den Probelauf nicht mit einer anderen Datei fort, ohne den Fehler zu dokumentieren.

Schritt 4: Datenbank auf der Testinstanz wiederherstellen

Jetzt folgt der entscheidende Teil des Tests. Der folgende Befehl stellt das vollständige Backup als neue Datenbank AppDB_RestoreTest wieder her. Durch MOVE erhalten Daten- und Logdatei eigene Zielpfade. Die Verzeichnisse müssen bereits existieren und für das SQL-Server-Dienstkonto beschreibbar sein.

USE [master];
GO

RESTORE DATABASE [AppDB_RestoreTest]
FROM DISK = N'D:\Backups\AppDB_full.bak'
WITH
    FILE = 1,
    MOVE N'AppDB'
        TO N'D:\SQLData\AppDB_RestoreTest.mdf',
    MOVE N'AppDB_log'
        TO N'D:\SQLLogs\AppDB_RestoreTest_log.ldf',
    RECOVERY,
    STATS = 5;
GO

Prüfe vor dem Ausführen noch einmal, ob du mit der richtigen Instanz verbunden bist und ob AppDB_RestoreTest dort nicht bereits existiert. Das Beispiel verwendet bewusst weder den Namen der Produktivdatenbank noch WITH REPLACE.

RECOVERY schließt die Wiederherstellung ab und macht die Datenbank benutzbar. Das ist richtig, wenn du nur dieses vollständige Backup einspielen willst. Möchtest du danach noch ein differenzielles Backup oder Transaktionslog-Backups anwenden, muss die Wiederherstellung zunächst mit NORECOVERY offenbleiben.

Schritt 5: Status und Datenbankintegrität kontrollieren

Prüfe zunächst, ob die Datenbank online ist:

SELECT
    name,
    state_desc,
    compatibility_level
FROM sys.databases
WHERE name = N'AppDB_RestoreTest';

Anschließend führst du auf der Testinstanz eine vollständige Integritätsprüfung aus:

DBCC CHECKDB (N'AppDB_RestoreTest')
WITH NO_INFOMSGS, ALL_ERRORMSGS;

Bei einem fehlerfreien Durchlauf meldet DBCC CHECKDB keine Konsistenzfehler. Je nach Größe der Datenbank kann die Prüfung längere Zeit dauern und zusätzliche Ressourcen beanspruchen. Plane sie deshalb als festen Teil des Probelaufs ein und erfasse ihre Dauer getrennt von der reinen Restore-Zeit.

Eine technische Integritätsprüfung beantwortet noch nicht jede fachliche Frage. Öffne zusätzlich wichtige Tabellen oder Ansichten, prüfe erwartete Datensätze und führe einige typische Leseabfragen deiner Anwendung aus. Wenn du die Anwendung auf die Testdatenbank verbinden kannst, teste außerdem einen ungefährlichen Kernablauf. Dokumentiere, welche Prüfungen du durchgeführt hast und welche nicht.

Auch die Backup-Kette testen: Full Backup und Transaktionslogs

Wenn deine Wiederherstellungsstrategie auf einem vollständigen Backup und anschließenden Transaktionslog-Backups beruht, reicht ein Test des Full Backups allein nicht aus. Du musst die benötigte Kette in der richtigen Reihenfolge einspielen. Dabei bleibt die Datenbank bis zum letzten Restore im Zustand RESTORING.

Das folgende vereinfachte Muster zeigt ein vollständiges Backup und danach ein Log-Backup. Passe Dateinamen, Positionen und logische Namen an deine Sicherungen an:

USE [master];
GO

RESTORE DATABASE [AppDB_RestoreTest]
FROM DISK = N'D:\Backups\AppDB_full.bak'
WITH
    FILE = 1,
    MOVE N'AppDB'
        TO N'D:\SQLData\AppDB_RestoreTest.mdf',
    MOVE N'AppDB_log'
        TO N'D:\SQLLogs\AppDB_RestoreTest_log.ldf',
    NORECOVERY,
    STATS = 5;
GO

RESTORE LOG [AppDB_RestoreTest]
FROM DISK = N'D:\Backups\AppDB_log_01.trn'
WITH
    FILE = 1,
    RECOVERY,
    STATS = 5;
GO

Bei mehreren Log-Backups stellst du sie lückenlos in der richtigen Reihenfolge wieder her. Verwende für alle Zwischenstufen NORECOVERY und erst beim letzten Backup RECOVERY. Wenn ein differenzielles Backup zu deiner Strategie gehört, wird es nach dem passenden vollständigen Backup und vor den darauf folgenden Log-Backups eingespielt.

Ein Probelauf mit vollständiger Kette zeigt nicht nur, ob die Dateien lesbar sind. Er zeigt auch, ob du die richtigen Sicherungen findest, ihre Reihenfolge kennst und den gewünschten Wiederherstellungszeitpunkt tatsächlich erreichen kannst.

Typische Fehler beim SQL-Server-Restore

„Access is denied“ oder „Operating system error 5“

Der Restore läuft im Kontext des SQL-Server-Dienstes. Dass du die Datei im Windows-Explorer öffnen kannst, bedeutet nicht, dass das Dienstkonto der Testinstanz ebenfalls Zugriff hat. Prüfe Leserechte für den Backup-Speicherort und Schreibrechte für die Zielverzeichnisse der Daten- und Logdateien.

Die logischen Dateinamen stimmen nicht

Die Namen hinter MOVE sind die logischen Namen aus dem Backup, nicht frei gewählte Dateinamen. Führe RESTORE FILELISTONLY aus und übernimm die Werte aus der Spalte LogicalName. Prüfe auch, ob mehr als eine Datendatei vorhanden ist.

Es fehlt Speicherplatz

Orientiere dich nicht nur an der Größe der .bak-Datei. Besonders komprimierte Sicherungen können beim Restore erheblich mehr Platz benötigen. Prüfe die Größenangaben aus RESTORE FILELISTONLY und den freien Speicherplatz auf den Zielvolumes.

Die SQL-Server-Version ist zu alt

Ein Backup aus einer neueren SQL-Server-Version lässt sich nicht auf einer älteren Instanz wiederherstellen. Prüfe deshalb die Version der Quell- und Testinstanz. Für einen aussagekräftigen Notfalltest sollte die Zielumgebung zu deiner geplanten Wiederherstellungsumgebung passen.

Ein Zertifikat oder Schlüssel fehlt

Bei TDE-geschützten Datenbanken und verschlüsselten Backups kann die Sicherung ohne das passende Zertifikat beziehungsweise den benötigten Schlüssel nicht auf einer anderen Instanz wiederhergestellt werden. Sichere diese Bestandteile getrennt und teste auch ihre Bereitstellung auf dem Zielserver.

Die Log-Kette lässt sich nicht vollständig einspielen

Prüfe, ob alle benötigten Log-Backups vorhanden sind und zum gewählten vollständigen beziehungsweise differenziellen Backup gehören. Ein fehlendes Log-Backup kann verhindern, dass du den gewünschten Zeitpunkt erreichst. Halte beim Probelauf fest, welche Dateien tatsächlich verwendet wurden.

Was du nach dem Test dokumentieren solltest

Ein knappes Protokoll macht aus einem einmaligen Versuch eine wiederholbare Wiederherstellungsanleitung. Halte mindestens diese Punkte fest:

  • Datum des Tests und verwendete SQL-Server-Versionen
  • Name, Erstellungszeit und Speicherort aller verwendeten Backup-Dateien
  • Zielinstanz sowie Pfade für Daten- und Logdateien
  • Dauer des Restores und der Integritätsprüfung
  • Ergebnis von DBCC CHECKDB und der fachlichen Stichproben
  • Aufgetretene Fehler und ihre Lösungen
  • Benötigte Zertifikate, Schlüssel und weitere Abhängigkeiten

Wiederhole den Restore-Probelauf regelmäßig und nach wichtigen Änderungen an Backup-Strategie, SQL-Server-Version oder Speicherort. Entscheidend ist nicht nur, dass irgendwann einmal ein Restore gelungen ist. Entscheidend ist, ob deine aktuelle Sicherungskette mit deiner aktuellen Infrastruktur wiederherstellbar bleibt.

Fazit

Ein SQL Server Backup testen bedeutet, den Wiederherstellungsweg vollständig durchzugehen: Backup-Satz identifizieren, Dateinamen prüfen, Sicherung auf einer getrennten Instanz wiederherstellen und die Datenbank anschließend technisch und fachlich kontrollieren. RESTORE VERIFYONLY ist eine nützliche Vorprüfung, ersetzt diesen Probelauf aber nicht.

Wenn du außerdem die benötigten differenziellen und Transaktionslog-Backups einspielst, kennst du nicht nur den Zustand eines einzelnen Backups. Du weißt auch, ob deine Sicherungskette den vorgesehenen Wiederherstellungszeitpunkt erreicht.

Weiterführende Microsoft-Dokumentation