SQL Server Backup und Restore: den Ernstfall planen

Wie kommen Sie zum richtigen Datenstand?

SQL Server stellt für Backup und Restore leistungsfähige native Funktionen bereit. Ola Hallengrens Maintenance Solution automatisiert deren Einsatz. Ein belastbarer Betrieb verbindet diese Bausteine mit einem konkreten Wiederherstellungsziel, vollständigen Abhängigkeiten und wiederholbaren Proben.

Dieser Beitrag setzt Kenntnisse zu Full-, Diff- und Logbackups voraus; Teil 1 erklärt diese Grundlagen. Uhrzeiten und Betriebsziele in den Bildern sind schematische Beispiele, soweit sie nicht ausdrücklich als Labbeleg gekennzeichnet sind.

Typische Anlässe

Springen Sie direkt zu Ihrem Fall:

• Fehler 3136Nach einem zusätzlichen Fullbackup passt der geplante Diff-Restore nicht mehr.↓
• Fehler 4305Das einzuspielende Log beginnt für den aktuellen Restorestand zu spät.↓
• Ein bestimmter ZeitpunktGebraucht wird der Stand unmittelbar vor einer versehentlichen Änderung.↓
• Restore dauert zu langeTrotz kurzer Sicherungsintervalle dauert der Wiederanlauf zu lange.↓
• Ola läuft, aber …Ola läuft zuverlässig; unklar sind Abdeckung, Cleanup und Restoreproben.↓
• Verschlüsselung, AG, ObjektspeicherZusätzliche Bausteine erweitern die Sicherungsstrecke.↓

Unterwegs lösen wir vier verbreitete Fehlannahmen auf:

1. „Ein zusätzliches Full unterbricht die Logkette.“ Ein normales Full setzt die Differentialbasis neu. Die Logbackupfolge ist davon getrennt.

   aufgelöst in: Drei Beziehungen ↓

2. „Die neueste Datei ist die richtige.“ Ein Full nach dem Zielzeitpunkt lässt sich nicht zurückspulen.

   aufgelöst in: Restore auf einen Zeitpunkt ↓

3. „Sieben Tage aufbewahren heißt sieben Tage wiederherstellen.“ Die benötigte Full-Basis kann älter als sieben Tage sein.

   aufgelöst in: Retention ↓

4. „35 Minuten Restore passen in eine Stunde RTO.“ Nur wenn alle übrigen Phasen bis zur Freigabe in die Restzeit passen.

   aufgelöst in: RTO ↓

Eine Route hat drei verschiedene Beziehungen

Das Bild aus Teil 1 bleibt: Wir suchen einen Startpunkt, gegebenenfalls eine Abkürzung und weitere Abschnitte bis zum Ziel. Im Advanced-Fall unterscheiden wir dabei drei Dinge.

1. Die DifferentialbasisEin Differentialbackup gehört zu einer bestimmten Datenbasis. Ein normales Full setzt diese Basis neu. Ein älteres Full und ein Diff auf einer neueren Basis passen deshalb nicht zusammen.
2. Die LogabdeckungDie erforderlichen Logs müssen den benötigten Bereich lückenlos abdecken. Ein zusätzliches normales Full unterbricht die Logbackupkette nicht. Es kann lediglich einen weiteren Einstieg für andere Restorewege schaffen.
3. Die konkrete AuswahlFür den Zielzeitpunkt wählen wir eine tatsächlich verfügbare Kombination. Die neueste Datei kann zu spät liegen, zur falschen Basis gehören oder nur ein Teil eines Stripe-Sets sein.

SQL Server verwaltet dafür unter anderem Log Sequence Numbers, kurz LSNs, Basisinformationen und Recovery-Fork-Bezüge. Das sind technische Beziehungen und keine Uhrzeiten. Zur Inventur gehören die Backupheader, verfügbare Medienfamilien und bei Bedarf die Historie in msdb. Für einen Desasterfall muss die Dateiauswahl auch dann möglich sein, wenn die ursprüngliche msdb nicht erreichbar ist (Microsoft: Restore Sequences).

Eine praktische Inventur liefert pro Backupset: Datenbankidentität, Art, Beginn und Ende, Copy-only-Flag, relevante LSNs, Differentialbasis, Medienposition, sämtliche benötigten Dateien und Verschlüsselungsabhängigkeit. Namen und Dateidatum helfen bei der Orientierung. Die technische Zuordnung ersetzen sie nicht.

COPY_ONLY: zusätzliche Sicherungen ohne neue Differentialbasis

Ein Entwickler benötigt eine aktuelle Kopie. Der reguläre Plan verwendet ein Full vom Sonntag und tägliche Diffs. Wird am Dienstag ein zusätzliches normales Full erstellt, basieren spätere Diffs auf diesem neuen Full. Wer beim Restore weiter nur das Sonntags-Full berücksichtigt, kann scheitern.

Für die zusätzliche Kopie ist ein gezielt gewähltes COPY_ONLY-Full häufig sinnvoll:

BACKUP DATABASE [BackupDemo]
  TO DISK = N'D:\SQLBackup\BackupDemo_extra_copy_01.bak'
  WITH COPY_ONLY, CHECKSUM, COMPRESSION;

Dieses Full lässt die bestehende Differentialbasis unverändert. Es kann wie ein Full wiederhergestellt werden, wird aber selbst keine neue Differentialbasis. Ein danach entstandenes Diff lässt sich deshalb nicht allein deshalb auf diese Kopie anwenden, weil sie zeitlich kurz davor lag (Microsoft: Copy-only Backups).

Labfrage Ändert ein Copy-only-Full die Basis des nächsten Diff?

Aufbau Full F0 erstellen, Daten ändern, zusätzliches Copy-only-Full C0 erstellen, erneut ändern und Diff D2 sichern. Später folgen ein normales Full F1 und ein neues Diff D3.

Msg 3136, Level 16, State 1, Server …, Line 1
This differential backup cannot be restored because the database has not been restored to the correct earlier state.

Msg 3136, Level 16, State 1, Server …, Line 1
This differential backup cannot be restored because the database has not been restored to the correct earlier state.

Beobachtung Auf SQL Server 2022 und 2025 lässt sich F0 plus D2 wiederherstellen. C0 plus D2 wird mit Fehler 3136 zurückgewiesen. Nach einem späteren normalen Full F1 benötigt das neue Diff D3 die Basis F1; F0 plus D3 scheitert ebenfalls.

Folgerung Zusätzliche Sicherungen gehören in die Betriebsregeln. Benennen Sie ihren Zweck und entscheiden Sie bewusst, ob sie die Diff-Basis verändern sollen. Das ist eine andere Frage als die Fortsetzung der Logkette.

Wenn ein Logbackup fehlt

Full F0, Log L1, Log L2, Log L3: Für den vorgesehenen Restoreweg brauchen wir die nötige Abdeckung. Fehlt L2, kann L3 die darin fehlenden Logbereiche nicht einfach ersetzen. SQL Server kann den Restore mit Fehler 4305 zurückweisen.

Im Lab erzeugen wir genau diese Lücke, indem wir L2 beim Einspielen auslassen. Nach Bereitstellung und Anwendung des vorhandenen L2 lässt sich der Ablauf fortsetzen. Wir löschen im Versuch keine unbekannten Produktionsdateien und simulieren keinen vollständigen Serververlust.

Msg 4305, Level 16, State 1, Server …, Line 1
The log in this backup set begins at LSN 42000000053600001, which is too recent to apply to the database. An earlier log backup that includes LSN 42000000049600001 can be restored.

Für die Praxis bedeutet das: zuerst alle Speicherorte, Kopien und erzeugenden Jobs inventarisieren. Prüfen Sie, ob eine anderweitig vorhandene Datei die Lücke schließt oder eine andere geeignete Datenbasis einen neuen Restoreweg eröffnet.

Auch ein weiterer regulärer Logbackupjob kann relevant sein: Werden Logs auf einen anderen Speicher gesichert, liegen benötigte Abschnitte womöglich dort. Mehrere Werkzeuge müssen in einen gemeinsamen Plan passen. Copy-only-Logbackups haben andere Auswirkungen auf den regulären Archivierungspunkt und sind gezielt zu beurteilen.

@ChangeBackupType='Y' in Ola sucht bei fehlenden Voraussetzungen einen durchführbaren Sicherungstyp. Es repariert keine verlorene historische Datei. Der tatsächlich erzeugte Typ muss deshalb Teil der Überwachung sein.

Restore auf einen bestimmten Zeitpunkt

Ein versehentliches Löschen um 14:07 ist ein anderer Fall als ein Hardwareausfall, bei dem Sie den jüngsten erreichbaren Stand wollen. Für den Zustand unmittelbar vor dem Löschen brauchen Sie eine geeignete Datenbasis vor dem Ziel und die erforderlichen Logs bis zu diesem Zeitpunkt.

Ein Full, das erst nach dem gewünschten Zeitpunkt endet, lässt sich nicht rückwärts dorthin abspielen. Wählen Sie gegebenenfalls ein älteres Full. Ein Diff darf den gewünschten Zeitpunkt ebenfalls nicht bereits überschritten haben.

Ein schematischer Ablauf unter einem neuen Testnamen lautet:

DECLARE @TargetTime datetime = '2026-10-22T14:06:50';

RESTORE DATABASE [BackupDemo_PointTest]
  FROM DISK = N'D:\SQLBackup\BackupDemo_full_01.bak'
  WITH MOVE N'BackupDemo'
         TO N'D:\SQLData\BackupDemo_PointTest.mdf',
       MOVE N'BackupDemo_log'
         TO N'D:\SQLLog\BackupDemo_PointTest.ldf',
       NORECOVERY, CHECKSUM;

RESTORE LOG [BackupDemo_PointTest]
  FROM DISK = N'D:\SQLBackup\BackupDemo_log_01.trn'
  WITH NORECOVERY, CHECKSUM, STOPAT = @TargetTime;

RESTORE LOG [BackupDemo_PointTest]
  FROM DISK = N'D:\SQLBackup\BackupDemo_log_02.trn'
  WITH NORECOVERY, CHECKSUM, STOPAT = @TargetTime;

-- Erst nach Anwendung der erforderlichen Logs bis zum Ziel:
RESTORE DATABASE [BackupDemo_PointTest] WITH RECOVERY;

Dateien, logische Dateinamen und Zeitpunkt sind Beispiele. Die benötigte Logliste muss für die tatsächlichen Backupsets bestimmt werden. Microsoft empfiehlt, den gleichen Zielzeitpunkt in jedem Logrestore anzugeben. Prüfen Sie anschließend, dass der gewollte Datenstand erreicht wurde. Zeitzone, Serverzeit, Anwendungstimestamps und ein möglicher Sommerzeitwechsel gehören zur Zuordnung (Microsoft: Point-in-time Restore).

Im Lab Vor einer gezielten Löschung wird die SQL Server Zeit festgehalten. Der STOPAT-Restore enthält den zuvor vorhandenen Datensatz und nicht die danach eingefügte Änderung. Der Restore bis zum jüngsten Logstand enthält dagegen die spätere Änderung. Gezählt werden daher nicht nur Zeilen; wir prüfen die konkreten Marker.

Bei BULK_LOGGED kann ein Logbackup mit minimal protokollierten Änderungen keinen beliebigen STOPAT innerhalb dieses Backups liefern. Die Einschränkung betrifft diesen Abschnitt. Beziehen Sie geplante Massenoperationen in die Wiederherstellungsentscheidung ein.

Tail-log: noch nicht gesicherte Änderungen erfassen

Nach dem letzten regulären Logbackup können weitere Änderungen existieren. Wenn die nötigen Voraussetzungen bestehen, sichert ein Tail-log-Backup den noch nicht gesicherten Logrest. Das kann beim Wiederherstellen zum jüngsten möglichen Stand Datenverlust vermeiden.

Für eine noch online befindliche Datenbank zeigt das folgende Beispiel einen bewussten Wiederherstellungseingriff.

-- ACHTUNG: bewusster Wiederherstellungseingriff, kein Job.
-- NORECOVERY versetzt die Quelle in RESTORING; normale Nutzung ist danach unterbrochen.
-- Nur im abgestimmten Wiederherstellungsablauf ausführen.
BACKUP LOG [BackupDemo]
  TO DISK = N'D:\SQLBackup\BackupDemo_tail_01.trn'
  WITH NORECOVERY, CHECKSUM;

Im Lab wird eine nur im Tail vorhandene Änderung gesichert und auf einem separaten Ziel zusammen mit den vorherigen Backups wiederhergestellt. Bei einem echten Schaden hängt die Möglichkeit davon ab, welche Logdateien und Datenbankbestandteile noch brauchbar sind. Ein verlorenes oder unbrauchbares Log kann auch diesen Weg versperren (Microsoft: Tail-log Backups).

Für einen Zielzeitpunkt, der bereits von vorhandenen Sicherungen abgedeckt wird, ist ein Tail-log-Backup nicht zur Erreichung dieses älteren Stands erforderlich. Ob Sie den aktuellen Rest vor weiteren Eingriffen zusätzlich bewahren müssen, bleibt eine Frage des konkreten Falls.

Ola im Betrieb: Auswahl, Ausführung und Ergebnis auseinanderhalten

Eine robuste Einrichtung beschreibt vier Ebenen:

Für den nachvollziehbaren Einstieg sind explizite Optionen sinnvoll: @Checksum='Y', @Verify='Y', @LogToTable='Y', Kompression passend zu Edition und Last, Typwechsel bewusst festgelegt. @Execute='N' hilft bei der Prüfung erzeugter Befehle. Es erzeugt keinen Backup- oder Restorebeleg.

Ein kontrollierter Sonder-Full kann beispielsweise so vorbereitet werden:

DECLARE @ReturnCode int;
EXEC @ReturnCode = [DBA].dbo.DatabaseBackup
  @Databases = N'BackupDemo',
  @Directory = N'D:\SQLBackup',
  @BackupType = 'FULL',
  @CopyOnly = 'Y',
  @Compress = 'Y',
  @Checksum = 'Y',
  @Verify = 'Y',
  @ChangeBackupType = 'N',
  @CleanupTime = NULL,
  @LogToTable = 'Y',
  @Execute = 'N';
IF @ReturnCode <> 0
  THROW 50002, N'Sonderbackup fehlgeschlagen.', 1;

Vor Ausführung Auswahl und Ziel prüfen und anschließend @Execute='Y' verwenden. Auch hier ersetzt @Verify='Y' keinen vollständigen Restore.

Wichtig für die Überwachung: Datenbanken können wegen Recovery-Modell, Zustand, fehlender Basis oder AG-Präferenz übersprungen werden. Im Lab endet der LOG-Aufruf für eine SIMPLE-Datenbank erfolgreich, ohne ein Logbackup anzulegen. Ein Alarm nur auf fehlerhafte Jobs würde diese Abdeckungslücke nicht erkennen.

Msg 4208, Level 16, State 1, Server …, Line 1
The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE.

Vergleichen Sie deshalb das erwartete Datenbankinventar mit tatsächlich entstandenen Backupsets, erforderlichen Typen, deren Alter, Datei- und Kopierstatus. Führen Sie Restoretests als eigenen Nachweis. Ein CommandLog mit sechs erfolgreichen Befehlen beantwortet noch nicht, ob die siebte erwartete Datenbank gesichert wurde (Ola: Parameter und Verhalten, geprüfter Originalcode).

Retention: vom ältesten zugesagten Restorepunkt rückwärts denken

„Sieben Tage aufbewahren“ ist als Dateiregel mehrdeutig. Sollen alle Dateien nach sieben Tagen verschwinden? Oder muss jeder vereinbarte Zeitpunkt der vergangenen sieben Tage erreichbar sein? Für Letzteres kann die benötigte Full-Basis älter als sieben Tage sein.

Schematisches Beispiel: Das Restorefenster beginnt an einem Mittwochmittag. Das dafür benötigte Full stammt vom vorherigen Sonntag. Wenn Sie diese Basis rein nach Alter löschen, kann der älteste zugesagte Mittwoch trotz jüngerer Logs unerreichbar werden. Eine spätere Vollsicherung hilft nicht für ein früheres Ziel.

Planen Sie deshalb pro zugesagtem Zielbereich die vollständige Menge aus Basis, gegebenenfalls Diff, erforderlichen Logs, allen Stripes und Schlüsseln. Berücksichtigen Sie erfolgreiche externe Kopien und deren eigene Lifecycle-Regeln. Die Platzplanung braucht Reserve für eine neue Generation, bevor eine alte entfernt wird.

Olas @CleanupTime arbeitet in Stunden, nicht Tagen. @CleanupMode='AFTER_BACKUP' ist der Standard; die Lösung hat Schutzlogik für abhängige Sicherungen. Das ist hilfreich, aber keine Abnahme Ihres individuellen historischen Restorefensters. Eine Umstellung auf BEFORE_BACKUP nur wegen knappen Platzes kann gerade die noch vorhandene Absicherung verringern (Ola: CleanupTime).

Backupdateien löschen, msdb-Historie bereinigen und CommandLog pflegen sind getrennte Aufgaben. sp_delete_backuphistory entfernt Historie, keine Backupdateien. Für URL-Ziele unterstützt Ola kein entsprechendes Datei-Cleanup; die Speicher-Lifecycle-Regeln müssen gesondert zu den Restoreabhängigkeiten passen.

Die wirksamste Gegenprobe ist ein Test des ältesten zugesagten Wiederherstellungszeitpunkts. Wer immer nur das jüngste Full wiederherstellt, prüft die schwierige Kante des Aufbewahrungsfensters nicht.

RTO verbessern: den gesamten Ablauf messen

Die richtige Optimierung beginnt mit einer Zeitaufteilung: Bereitstellung, Zugriff auf Dateien und Schlüssel, Transfer, Full-, Diff- und Logrestore, Recovery, Konsistenzprüfung, Instanzobjekte und Anwendungsfreigabe.

Kompression kann Übertragungs- und I/O-Aufwand reduzieren, kostet jedoch CPU. Stripes können geeignete I/O-Ressourcen besser ausnutzen; auf demselben Engpass entsteht daraus kein zusätzlicher physischer Durchsatz. BUFFERCOUNT, MAXTRANSFERSIZE oder zusätzliche Parallelität sind gezielte Messvariablen, keine universellen Beschleunigungsrezepte.

Ein anderer Mix aus Full, Diff und Log kann die einzuspielende Dateimenge verändern. Ein kleineres Backup kann trotzdem langsamer entstehen, und ein schneller Backupjob kann einen aufwendigen Restorepfad hinterlassen. Vergleichen Sie daher das ganze Verfahren unter repräsentativer Last und Größe. Die kleinen synthetischen Labdaten in dieser Reihe erlauben keine allgemeine RTO- oder Durchsatzempfehlung.

Zur freigegebenen Anwendung gehören häufig mehr als Userdatenbanken: Logins und SIDs, Agentjobs, Credentials, Zertifikate, Schnittstellen und abgestimmte Stände mehrerer Datenbanken. Gleicher STOPAT-Zeitpunkt und fehlerfreies CHECKDB beweisen allein keine fachlich konsistente Gesamtanwendung. Für zusammengehörige Datenbanken können vorab geplante markierte Transaktionen Teil eines geeigneten Verfahrens sein (Microsoft: Related Databases Consistently Recover).

Best Practices für fortgeschrittenen Betrieb

1. Jeden Ausfallfall benennen. Versehentliche Änderung, Datenbankverlust, Serververlust und Verlust des Backupziels brauchen unterschiedliche Nachweise.
2. Restorepfade inventarisieren. Basis, Logabdeckung, Recovery Forks, Medienpositionen, Stripes und Schlüssel zusammenführen.
3. Zusatzbackups koordinieren. Normales Full, Copy-only-Full und zusätzliche Logjobs bewusst in den bestehenden Plan einordnen.
4. Das älteste Ziel testen. Retention nicht nur am neuesten erfolgreichen Backup beurteilen.
5. Schlüssel unabhängig prüfen. Frische Instanz aus gesichertem Material wiederherstellen; Zugriffe und Entschlüsselung tatsächlich testen.
6. Fehler bis zum Verantwortlichen transportieren. Prozedur, Scheduler, Job und Benachrichtigung gemeinsam prüfen; Überspringen über die Abdeckungsprüfung erkennen.
7. Typwechsel und Ausnahmen sichtbar halten. @ChangeBackupType, Mindestgrößen und -abstände sowie Replikatpräferenzen können die erwartete Menge ändern.
8. RTO vollständig messen. Ein Restorebefehl ist ein Abschnitt des Wiederanlaufs. Fachliche Freigabe und Abhängigkeiten mitmessen.
9. Updates kontrolliert übernehmen. Engine- und Ola-Version erfassen, Optionen vergleichen und Kernproben erneut durchführen.
10. Ein zweites Teammitglied einbeziehen. Ein dokumentierter, erfolgreich übergebener Ablauf ist belastbarer als ausschließliches Personenwissen.

To-do-Listen

Eine Liste für den laufenden Betrieb, eine für den konkreten Problemfall. Ihr Häkchenstand bleibt nur in Ihrem Browser.

Häufige Fragen

Prüfen Sie Ihr Verständnis

Zwei Fragen aus dem Alltag. Überlegen Sie kurz, dann drehen Sie die Karte um.

• Frage 1 · Diff-Basis

  Sie haben ein Full vom Sonntag, ein zusätzliches Copy-only-Full vom Dienstag und ein Diff vom Mittwoch. Auf welches Full gehört der Diff, sofern dazwischen kein weiteres normales Full entstanden ist?

  SoDiMi

  Auflösung

  Auf das Full vom Sonntag.

  Es ist die passende normale Full-Basis. Das Copy-only-Full hat sie nicht verändert und ist selbst keine Diff-Basis. Die tatsächliche Identität wird mit den Metadaten und dem Restore geprüft.

  Im Lab nachgestellt: Bild 2 ↑

• Frage 2 · RTO

  Alle Dateien sind vorhanden, der Restore dauert 35 Minuten. Ist ein RTO von einer Stunde damit eingehalten?

  35 minvon60 min

  Auflösung

  Noch nicht entschieden.

  Erst wenn die übrigen vereinbarten Phasen einschließlich Bereitstellung, Zugriff, Prüfungen und Anwendungsfreigabe innerhalb der verbleibenden Zeit abgeschlossen sind. Die einzelne SQL-Dauer genügt dafür nicht.

  Zum Phasen-Rechner: Bild 12 ↑

Herkunft und Dank

Die SQL Server Maintenance Solution von Ola Hallengren automatisiert Sicherungen mit den nativen Funktionen von SQL Server und protokolliert, was sie tut. Quellcode und Dokumentation sind frei verfügbar, unter MIT-Lizenz (Repository). Danke an Ola Hallengren und an die Community, die die Lösung einsetzt, prüft und weiterträgt.

Wo dieser Beitrag Grenzen beschreibt, sind es Einsatzgrenzen und keine Mängel: DatabaseBackup sichert und verifiziert, den Restoreplan, das Sollinventar und die Proben bauen Sie darum herum. Genau diese Aufgabenteilung macht die Lösung nachvollziehbar.

Dieser Beitrag ist eigener Text mit eigenen Labproben. Ola Hallengren hat ihn weder geprüft noch freigegeben; Schlussfolgerungen und eventuelle Fehler sind unsere. Für Parameter und Verhalten ist Olas eigene Dokumentation maßgeblich. Geprüft haben wir den Stand von Commit 41617578 (Quellzeitstempel 12.09.2026); neuere Fassungen können sich anders verhalten.

Methode und Grenzen

Faktenstand 22.10.2026. Ola-Originalcode auf Commit 41617578643e722b790ea4d57ef80f8de38ae747 eingefroren. Das eigene Lab prüft ausgewählte native Restorepfade und Ola-Aufrufe auf SQL Server 2022 und 2025 unter Linux.

Nicht geprüft: keine produktive Windows-Integration, kein Server- oder Standortverlust, keine Availability Group, kein Objektspeicher, kein echtes Retentionsfenster, kein Schlüsselverlustfall. Ebenfalls nur dokumentationsgestützt: BULK_LOGGED, Systemdatenbanken, Scheduler und vollständige Anwendungswiederherstellung. Dass ein normales Full die Logkette nicht unterbricht, belegt die Microsoft-Dokumentation; einen eigenen Versuch dazu gab es nicht. Die betroffenen Bilder tragen deshalb „Schema“ oder „Quellkonzept“.

Weiterlesen