SQL Server Backup und Restore: die Grundlagen

Ihre Backups laufen. Können Sie daraus auch wiederherstellen?

Ein Backup-Job meldet Erfolg. Auf dem Laufwerk liegen Dateien. Das ist ein guter Anfang. Ob Sie nach einem Ausfall weiterarbeiten können, zeigt erst der nächste Schritt: Lassen sich die benötigten Sicherungen erreichen, in der richtigen Reihenfolge einspielen und fachlich prüfen?

SQL Server bringt die dafür nötigen Sicherungs- und Wiederherstellungsfunktionen mit. Ola Hallengrens Maintenance Solution hilft, ihre Ausführung zu automatisieren. In diesem Beitrag bauen wir das Grundmodell auf, führen einen ersten Restore durch und zeigen, wie aus einzelnen Befehlen ein brauchbarer Betriebsablauf wird.

Die kurze Antwort: Eine vollständige Sicherung kann die Grundlage eines Restores bilden. Differenzielle Sicherungen ergänzen die dazugehörige Vollsicherung. Transaktionslogsicherungen führen den Datenstand in FULL oder BULK_LOGGED entlang des verfügbaren Logverlaufs weiter. Ob dieser Weg zu Ihrem Ziel führt, prüfen Sie mit einem echten Restore.

Das lohnt sich besonders, wenn Sie eine dieser Situationen kennen:

• „Die Sicherung läuft seit Jahren. Wiederhergestellt haben wir zuletzt bei der Installation.“
• „Wir haben .bak-Dateien, wissen aber nicht genau, welche zusammengehören.“
• „Der Job ist grün, trotzdem fehlen Sicherungen einer neuen Datenbank.“
• „Wir wollen Ola einsetzen und brauchen einen verständlichen Einstieg.“

Zuerst klären: Wie viel darf fehlen, wie lange darf es dauern?

Bevor Sie einen Zeitplan einrichten, brauchen Sie zwei fachliche Ziele.

Recovery Point Objective, kurz RPO: Welcher Datenverlust ist für den betrachteten Ausfallfall höchstens akzeptabel? Wenn höchstens 15 Minuten fehlen dürfen, muss das Verfahren einen hinreichend aktuellen wiederherstellbaren Stand bereitstellen. Ein Logbackup alle 15 Minuten ist eine mögliche technische Grundlage. Fehlgeschlagene Sicherungen oder noch nicht übertragene Dateien können das tatsächlich erreichbare Ergebnis verschlechtern.

Recovery Time Objective, kurz RTO: Innerhalb welcher Zeit soll die vereinbarte Leistung wieder verfügbar sein? Zur Wiederherstellung gehören häufig Ersatzsystem, Dateitransfer, Restore, Prüfungen und Freigabe der Anwendung. Die vom SQL-Befehl gemeldete Restorezeit deckt nur einen Teil davon ab.

Ein kleines Beispiel zur Planung, keine Labmessung: Die Fachabteilung akzeptiert höchstens 15 Minuten fehlende Änderungen und zwei Stunden Unterbrechung. Dann reicht die Aussage „Wir sichern nachts“ nicht aus. Sie benötigen einen Weg zu einem ausreichend aktuellen Datenstand und einen nachgewiesenen Wiederanlauf innerhalb dieses Zeitbudgets. Die Ziele müssen zum konkreten Ausfallfall passen: Ein gelöschter Datensatz stellt andere Anforderungen als der Verlust des gesamten Standorts.

Drei Sicherungsarten, ein gemeinsamer Weg

Stellen Sie sich den Restore als Route vor. Eine Vollsicherung ist ein möglicher Startpunkt. Eine passende differenzielle Sicherung verkürzt den Weg zu einem späteren Stand. Logsicherungen führen von dort aus weiter. Manche Abschnitte sind austauschbar, andere müssen lückenlos verfügbar sein.

F0FullD1DifferentialL1LogZielgewünschter Datenstand

Full: eine vollständige Datenbanksicherung

Ein normales Fullbackup sichert die Datenbank und genügend Transaktionslog, um aus dem Backup einen konsistenten Datenbankstand wiederherzustellen. SQL Server kann währenddessen weiterarbeiten; eine Vollsicherung ist keine bloße Dateikopie einer stillgelegten Datenbank.

Ein Fullbackup allein liefert einen wiederherstellbaren Stand aus dieser Sicherung. Änderungen danach brauchen weitere passende Sicherungen. Außerdem setzt ein normales Fullbackup die Basis für spätere differenzielle Sicherungen neu. Es unterbricht eine bestehende Logbackupkette nicht. Diesen Unterschied brauchen wir in Teil 2.

Log: den verfügbaren Verlauf weiterführen

In FULL und BULK_LOGGED können Transaktionslogsicherungen den für die Wiederherstellung benötigten Verlauf sichern. Für einen Restore benötigen Sie die Sicherungen, die den Bereich ab dem gewählten Datenstand bis zum Ziel lückenlos abdecken. Dateien allein nach Änderungsdatum zu sortieren ist dafür zu wenig.

Eine Logsicherung ist kein Backup der gesamten .ldf-Datei. Sie verkleinert diese Datei auch nicht automatisch. Sie kann Voraussetzungen für die Wiederverwendung nicht mehr benötigter Logbereiche schaffen; andere Rückhaltegründe können trotzdem bestehen. Ein großes Log ist deshalb nicht automatisch durch ein einmaliges Logbackup oder regelmäßiges Shrink gelöst.

Wie das zusammenspielt, zeigt der Routenplaner. Wählen Sie einen Zielstand und sehen Sie, welche Dateien Sie dafür brauchen.

SIMPLE, FULL und BULK_LOGGED sind Betriebsentscheidungen

Das Recovery-Modell bestimmt mit, welche Wiederherstellungswege überhaupt verfügbar sind.

Wählen Sie das Recovery-Modell nach den Wiederherstellungszielen. Ein Wechsel auf SIMPLE, nur um ein wachsendes Log loszuwerden, kann einen benötigten Wiederherstellungsweg zerstören. Im Routenplaner sehen Sie den Unterschied mit dem Umschalter „Recovery SIMPLE“ (Microsoft: Recovery Models).

Der erste native Backup- und Restore-Test

Wir verwenden eine eigene Übungsdatenbank BackupDemo und einen neuen Zielnamen BackupDemo_RestoreTest. Der Pfad ist ein Windows-Beispiel auf dem SQL Server. Unter Linux oder bei anderen Verzeichnissen ändern Sie ihn passend. Der SQL Server Dienst benötigt Zugriff auf das Ziel; ein auf Ihrem Arbeitsplatz sichtbares Laufwerk ist nicht automatisch für ihn erreichbar.

Die Übungsdatenbank muss vorab angelegt sein und Testdaten enthalten. Verwenden Sie für eigene Sicherungsläufe jeweils einen neuen Dateinamen.

-- Übungsdatenbank BackupDemo; Windows-Beispielpfad auf dem SQL Server
BACKUP DATABASE [BackupDemo]
  TO DISK = N'D:\SQLBackup\BackupDemo_full_01.bak'
  WITH CHECKSUM, COMPRESSION, STATS = 10;

CHECKSUM aktiviert Sicherungsprüfsummen und die vorgesehenen Prüfungen vorhandener Seitenprüfsummen. COMPRESSION kann Dateigröße und I/O reduzieren, beansprucht aber CPU und muss von Ihrer Version und Edition unterstützt werden. STATS zeigt Fortschritt. Keine dieser Optionen ersetzt den Restoretest.

Erst die Datei kennenlernen

-- Liest nur die Sicherungsdatei, ändert keine Datenbank
RESTORE HEADERONLY
  FROM DISK = N'D:\SQLBackup\BackupDemo_full_01.bak';

RESTORE FILELISTONLY
  FROM DISK = N'D:\SQLBackup\BackupDemo_full_01.bak';

RESTORE VERIFYONLY
  FROM DISK = N'D:\SQLBackup\BackupDemo_full_01.bak'
  WITH CHECKSUM;

HEADERONLY zeigt Sicherungsinformationen, FILELISTONLY die Datenbankdateien. VERIFYONLY prüft unter anderem Lesbarkeit und Vollständigkeit der Sicherung und bei vorhandenen Backupprüfsummen die entsprechende Integrität. Es führt keinen vollständigen Restore mit anschließender Struktur- oder Anwendungsprüfung durch (Microsoft: RESTORE VERIFYONLY).

Danach wirklich wiederherstellen

Die logischen Namen für MOVE müssen aus FILELISTONLY stammen. Hier heißen sie im Beispiel BackupDemo und BackupDemo_log; andere Datenbanken können mehrere weitere Dateien haben. Jede benötigte Datei braucht einen passenden Zielpfad. Die Verzeichnisse müssen existieren, der neue Datenbankname muss frei sein.

-- ACHTUNG: nur auf einem Testziel und unter NEUEM Datenbanknamen ausführen,
-- nie über die laufende Datenbank. Kein WITH REPLACE.
-- Logische Namen aus RESTORE FILELISTONLY übernehmen.
RESTORE DATABASE [BackupDemo_RestoreTest]
  FROM DISK = N'D:\SQLBackup\BackupDemo_full_01.bak'
  WITH MOVE N'BackupDemo'
         TO N'D:\SQLData\BackupDemo_RestoreTest.mdf',
       MOVE N'BackupDemo_log'
         TO N'D:\SQLLog\BackupDemo_RestoreTest.ldf',
       RECOVERY, CHECKSUM, STATS = 10;

DBCC CHECKDB ([BackupDemo_RestoreTest]) WITH NO_INFOMSGS;

Hier beendet RECOVERY den Restoreablauf und macht die Datenbank nutzbar. Für weitere Diffs oder Logs muss der Ablauf vorher mit NORECOVERY offenbleiben. Ein überhastetes RECOVERY kann daher einen neuen Durchlauf erforderlich machen. Probieren Sie es aus:

Prüfen Sie anschließend die erwarteten Testdatensätze und einen fachlichen Vorgang. Eine technisch konsistente Datenbank kann immer noch den falschen Zeitpunkt enthalten. Für einen vollständigen Anwendungstest können zusätzlich Logins, Jobs, Zertifikate oder weitere Datenbanken nötig sein.

Was beweist welche Prüfung?

Datei vorhanden, Datei geprüft, Datenbank wiederhergestellt, Ergebnis kontrolliert: Im Alltag verschwimmen diese vier Nachweise leicht. Jede Stufe beantwortet aber eine andere Frage. VERIFYONLY, Wiederherstellung, CHECKDB und fachliche Tests liefern unterschiedliche Nachweise.

Ergebnis des Grundlagenversuchs: Ein Diff lässt sich mit VERIFYONLY erfolgreich prüfen, obwohl es sich allein noch nicht als neue Datenbank wiederherstellen lässt. Im eigenen Lab auf SQL Server 2022 und 2025 gelingt der Restore mit der passenden Full-Basis. Dateiprüfung und vollständiger Wiederherstellungsweg beantworten unterschiedliche Fragen.

Full, Differential und Log sinnvoll kombinieren

Ein mögliches Schema lautet: regelmäßig Full, dazwischen Differential, in FULL zusätzlich häufige Logbackups. Das ist ein Beispielmuster, kein vorgegebener Standard für jede Datenbank.

Ein schematischer Tagesablauf: Full um 00:00, Diff um 12:00, Logs alle 15 Minuten. Für einen Zielstand am Nachmittag wählen Sie den geeigneten Startpunkt und die danach nötigen Logs. Für einen Zeitpunkt vor dem Mittags-Diff können Sie diesen späteren Diff nicht verwenden. Genau dieses Schema steckt im Routenplaner (Bild 3) ↑: Schieben Sie das Ziel einmal vor und einmal hinter 12:00.

Die richtige Häufigkeit hängt von Änderungsvolumen, Datenbankgröße, Backupfenster, erreichbarem Ziel, gewünschtem Datenverlust und getesteter Restorezeit ab. Eine Kette aus vielen kleinen Logs kann wenig Datenverlust erlauben und trotzdem einen langen Wiederanlauf verursachen. Der Zeitplan muss beide Ziele berücksichtigen.

Ola Hallengren: gute Automatisierung für native Sicherungen

Ola Hallengrens SQL Server Maintenance Solution stellt unter anderem die Prozedur DatabaseBackup bereit. Sie wählt Datenbanken aus, erzeugt native Backupbefehle, organisiert Verzeichnisse und Dateinamen und kann anschließend RESTORE VERIFYONLY ausführen. Mit CommandLog werden ausgeführte Befehle und Ergebnisse nachvollziehbar.

Das ist wertvolle Community-Arbeit. Gerade bei mehreren Datenbanken hilft ein gepflegtes gemeinsames Verfahren, statt viele handgestrickte Einzeljobs zu betreiben. Ola definiert damit aber weder Ihre RPO- und RTO-Ziele noch einen kompletten Restoreplan. Die Maintenance Solution enthält keine allgemeine Prozedur, die aus beliebigen Dateien automatisch Ihre Datenbank zum gewünschten Zeitpunkt wiederherstellt (offizielle Maintenance Solution, DatabaseBackup).

Ein überschaubarer Einstieg

1. Laden Sie die Lösung aus der offiziellen Quelle. Halten Sie Version und Prüfsumme fest und prüfen Sie Änderungen vor einem Update.
2. Wählen Sie eine eigene Administrationsdatenbank und lesen Sie die Installationsoptionen. Das Gesamtskript kann mehr Objekte und Jobs anlegen, als Sie für den ersten Versuch brauchen.
3. Stellen Sie den Zugriff des SQL Server Dienstes auf das Backupziel sicher. Jobowner und Dateizugriffsidentität sind unterschiedliche Fragen.
4. Beginnen Sie mit einer einzelnen Testdatenbank und einem dedizierten Verzeichnis.
5. Lassen Sie zunächst Befehle mit @Execute = 'N' anzeigen. Prüfen Sie Auswahl, Pfade und Optionen; dieser Vorschauaufruf beweist noch keinen erfolgreichen Dateizugriff oder Restore.
6. Führen Sie den Test wirklich aus, prüfen Sie die entstandenen Sicherungen und stellen Sie diese mit nativen Befehlen wieder her.

Ein Beispiel nach Installation in der Administrationsdatenbank DBA:

-- Vorschau: @Execute = 'N' zeigt die Befehle nur an.
-- Erst nach Prüfung der Ausgabe @Execute = 'Y' setzen.
DECLARE @ReturnCode int;

EXEC @ReturnCode = [DBA].dbo.DatabaseBackup
  @Databases   = N'BackupDemo',
  @Directory   = N'D:\SQLBackup',
  @BackupType  = 'FULL',
  @Compress    = 'Y',
  @Checksum    = 'Y',
  @Verify      = 'Y',
  @CleanupTime = NULL,
  @LogToTable  = 'Y',
  @Execute     = 'N';

IF @ReturnCode <> 0
  THROW 50001, N'DatabaseBackup meldet einen Fehler.', 1;

Nach Prüfung der Ausgabe wird für die tatsächliche Sicherung @Execute = 'Y' gesetzt. Für passende Diff- und Logläufe wird @BackupType auf DIFF beziehungsweise LOG gesetzt. Werten Sie einen LOG-Job nicht einfach für jede Datenbank als Erfolg: In SIMPLE ist diese Sicherungsart nicht verfügbar.

@CleanupTime = NULL verzichtet hier bewusst auf automatisches Löschen. Erst wenn Ihr Aufbewahrungs- und Restoreweg feststeht, konfigurieren Sie Cleanup. Das ist eine Einstiegseinstellung, keine Empfehlung für unbegrenzte Aufbewahrung.

Im Lab geprüft: Ola erzeugt Full-, Diff- und Logbackups mit Prüfsummen und anschließender Verifikation. Diese Dateien lassen sich mit nativen RESTORE-Befehlen wiederherstellen. Ebenfalls geprüft: Der LOG-Aufruf für eine SIMPLE-Datenbank kann mit Rückgabewert 0 enden, ohne eine Logsicherung anzulegen. Deshalb prüfen wir neben dem Rückgabewert auch die erwarteten Backupsets je Datenbank (Originalcode im geprüften Stand).

Best Practices für den Einstieg

• Ziele vor Zeitplan. Datenverlust und Wiederanlaufzeit fachlich benennen, dann Sicherungsarten und Intervalle auswählen.
• Neu angelegte Datenbanken erfassen. Ein erfolgreich laufender alter Job kann neue Datenbanken übersehen. Inventar und tatsächliche Abdeckung vergleichen.
• Eindeutige Dateien verwenden. Überschreiben, Medienanhängen und Sicherungspositionen verstehen. Für den Einstieg neue Dateinamen statt unklarer Sammeldateien verwenden.
• Prüfsummen und echte Restoreproben kombinieren. Verifikation, Wiederherstellung, CHECKDB und fachliche Tests liefern unterschiedliche Nachweise.
• Sicherungen aus dem Ausfallbereich bringen. Eine weitere Datei auf demselben Server schützt nicht vor dessen vollständigem Verlust. Getrennte Kopien und Zugriffsrechte vorsehen.
• Schlüssel mitdenken. Verschlüsselte Sicherungen benötigen passende Schlüssel und Zertifikate. Diese müssen auch nach Verlust des Ursprungsservers verfügbar sein.
• Zuständigkeit sichtbar machen. Wer erhält einen Alarm, wer bewertet ihn, wer prüft den erfolgreichen Nachlauf?
• Änderungen erneut testen. Nach Versionswechsel, neuen Pfaden, geändertem Dienstkonto oder neuer Backupsoftware den Wiederherstellungsweg erneut prüfen.

Ihre To-do-Liste für einen ersten belastbaren Stand

Haken Sie ab, was erledigt ist. Der Stand bleibt nur in diesem Browser gespeichert.

• Alle produktiv benötigten Datenbanken und ihre Recovery-Modelle auflisten.
• Pro Anwendung RPO, RTO und betrachteten Ausfallfall festhalten.
• Letzte erfolgreiche und am Restoreziel erreichbare Full-, Diff- und Logbackups je Datenbank bestimmen.
• Ein isoliertes Restoreziel mit ausreichendem Platz und passender Engine bereitstellen.
• Einen vollständigen Testrestore unter neuem Namen durchführen.
• CHECKDB, erwartete Datensätze und mindestens einen fachlichen Vorgang prüfen.
• Benötigte Zertifikate, Schlüssel und Instanzobjekte in die Wiederherstellungsunterlagen aufnehmen.
• Zeit für Bereitstellung, Dateizugriff, Restore und Freigabe getrennt erfassen.
• Bei Ola Version, Parameter, Zeitpläne und tatsächliche Datenbankabdeckung dokumentieren.
• Verantwortlichen, Alarmweg und Datum der nächsten Probe festhalten.

Häufige Fragen

Prüfen Sie Ihr Verständnis

Herkunft und Dank

Die SQL Server Maintenance Solution stammt von Ola Hallengren und steht unter der MIT-Lizenz (ola.hallengren.com). Gerade bei mehreren Datenbanken ersetzt sie viele handgestrickte Einzeljobs durch ein gepflegtes gemeinsames Verfahren. Danke an Ola Hallengren für diese Arbeit und an die Community, die die Lösung einsetzt, prüft und weiterträgt.

Dieser Beitrag ist eine eigene Darstellung mit eigenen Worten, Beispielen und Labproben. Ola Hallengren hat ihn weder geprüft noch freigegeben; Schlussfolgerungen und eventuelle Fehler sind unsere. Geprüft haben wir den Stand Commit 41617578. Neuere Fassungen können Parameter und Verhalten verändern; maßgeblich ist die Dokumentation von DatabaseBackup.

Methode und Grenzen

Faktenstand 22.10.2026. Native Funktionsproben und Ola-Aufrufe auf SQL Server 2022 und 2025 in einem isolierten Linux-Lab, ausschließlich mit synthetischen Daten. Keine Produktionsabnahme, keine allgemeine Leistungsquote und kein vollständiger Plattformtest. Die Windows-Pfade im Text sind erläuterte Beispiele; im Lab liefen dieselben Befehle mit Linux-Pfaden.

Nicht im Lab geprüft, dokumentationsgestützt erläutert: Zeitsteuerung mit Agent oder Task Scheduler, Systemdatenbanken, Verschlüsselung, BULK_LOGGED, Availability Groups, Windows-Pfade und eine vollständige Anwendungswiederherstellung. Die Laufzeiten der kleinen Proben sind keine Leistungs- oder RTO-Messungen und werden hier nicht verwendet.

Quellen: Microsoft: Backup and Restore · Recovery Models · Differential Backups · RESTORE VERIFYONLY · Ola Hallengren: DatabaseBackup.

Weiterlesen

Weiter mit Teil 2: Wiederherstellungswege, Zeitpunkte und Betrieb. Dort prüfen wir COPY_ONLY, fehlende Logs, Tail-Log, Retention und die Grenzen automatischer Abläufe.