Das Recovery-Model bezeichnet in Datenbankverwaltungssystemen, insbesondere bei Microsoft SQL Server, die Strategie zur Protokollierung von Transaktionen und zur Wiederherstellung von Daten. Es steuert, wie Änderungen aufgezeichnet, wie Transaktionsprotokolle verwaltet und welche Wiederherstellungsziele erreicht werden können. Je nach gewähltem Modell unterscheiden sich Aufwand, Leistung, Protokollgröße und die Möglichkeit zur Wiederherstellung bis zu einem bestimmten Zeitpunkt.
Definition
Ein Recovery-Model legt fest, in welchem Umfang Transaktionen detailliert protokolliert, wann Protokolle abgeschnitten und welche Sicherungstypen unterstützt werden. Es bestimmt somit, ob neben Voll- und differenziellen Sicherungen auch Transaktionsprotokollsicherungen möglich sind und ob eine Punkt-in-Time-Wiederherstellung erreichbar ist. Ziel ist, bei einem Fehler oder Datenverlust die Integrität und Konsistenz der Datenbank mit vertretbarem Aufwand wiederherstellen zu können.
Arten von Recovery-Modellen
Die Auswahl des Modells hängt von Wiederherstellungszielen, Lastprofil und Wartungsfenstern ab und wird häufig an den praktischen Anforderungen der Datenrettung und -wiederherstellung ausgerichtet. Typische Modelle sind:
- Simple Recovery-Model: Änderungen werden bis zum nächsten Checkpoint protokolliert, das Transaktionslog wird automatisch abgeschnitten. Es sind keine Transaktionsprotokollsicherungen und keine Punkt-in-Time-Wiederherstellung möglich. Verwaltung ist einfach, die Protokollgröße bleibt meist klein, jedoch mit eingeschränkten Wiederherstellungsoptionen.
- Full Recovery-Model: Alle Transaktionen werden vollständig protokolliert. In Verbindung mit regelmäßigen Transaktionsprotokollsicherungen ist eine Punkt-in-Time-Wiederherstellung möglich. Das Log kann stark anwachsen, wenn keine Protokollsicherungen erfolgen; die Verwaltung ist aufwendiger, bietet aber den weitreichendsten Schutz vor Datenverlust logisch bedingter Art.
- Bulk-Logged Recovery-Model: Grundsätzlich wie Full, jedoch werden bestimmte Massenoperationen (z. B. große Bulk-Inserts oder Indexvorgänge) minimal protokolliert. Das verbessert Leistung und begrenzt die Loggröße während dieser Vorgänge. Innerhalb eines Log-Backups, das minimal protokollierte Operationen enthält, ist allerdings keine Wiederherstellung auf einen beliebigen Zeitpunkt möglich, sondern nur bis zum Ende dieses Log-Backups.
Unabhängig vom Modell gilt: Nur vollständige und konsistente Sicherungsketten (Voll-, differenzielle und bei Bedarf Protokollsicherungen) ermöglichen belastbare Wiederherstellungspfade.
Funktionsweise und technische Bedeutung
Das Transaktionsprotokoll erfasst Datenänderungen sequenziell. Beim Wiederanlaufen nach einem Absturz werden abgeschlossene Transaktionen vorwärts nachgerollt und unvollständige zurückgerollt, bis ein konsistenter Zustand erreicht ist. Im Full- und Bulk-Logged-Modell lässt sich mit Protokollsicherungen eine lückenlose Wiederherstellungskette aufbauen. Im Simple-Modell werden Logeinträge regelmäßig abgeschnitten, wodurch die Wiederherstellung auf Zwischenzeitpunkte nicht möglich ist.
Transaktionsprotokolle und Datenrettung
Transaktionsprotokolle sind ein zentrales Werkzeug für die Wiederherstellung nach logischen Fehlern, etwa versehentlichen Löschungen oder fehlerhaften Updates. Sie erlauben es, Änderungen nachzuvollziehen und die Datenbank gezielt auf einen Zeitpunkt vor dem schädlichen Ereignis zu bringen, sofern das Recovery-Model und die Sicherungsstrategie dies unterstützen. Regelmäßige Sicherungen und ein passendes Recovery-Model senken das Risiko von Datenverlust und erhöhen die Chance auf eine präzise Wiederherstellung. Bei physischen Schäden am Speichersystem kann zusätzlich spezialisierte Datenrettung erforderlich sein, um die Datenbankdateien überhaupt wieder zugänglich zu machen.
Auswahl und typische Einsatzszenarien
- Simple: Entwicklungs-, Test- oder Analysesysteme, bei denen ein gewisser Datenverlust zwischen zwei Sicherungen akzeptabel ist und Verwaltung möglichst schlank bleiben soll.
- Full: Produktivsysteme mit strengen Wiederherstellungszielen, die eine Punkt-in-Time-Wiederherstellung und eine lückenlose Sicherungskette benötigen.
- Bulk-Logged: Zeitlich begrenzte Phasen mit massiven Lade- oder Indexoperationen, in denen Leistung und reduzierte Lognutzung im Vordergrund stehen, ohne dauerhaft auf die Vorteile des Full-Modells zu verzichten.
Wechsel des Recovery-Models
Ein Wechsel ist grundsätzlich möglich, hat aber direkte Auswirkungen auf die Sicherungskette. Nach einem Wechsel von Full oder Bulk-Logged auf Simple gehen die bisherigen Protokollketteneigenschaften verloren; für erneute Protokollsicherungen ist nach Rückkehr zu Full ein neues Vollbackup erforderlich. Planen Sie Modellwechsel außerhalb kritischer Betriebsphasen und stellen Sie sicher, dass Sicherungs- und Wiederherstellungsziele weiterhin erfüllt werden.
Praxisbeispiel
Wird in einer produktiven Datenbank versehentlich ein großer Datenbestand gelöscht, kann im Full-Modell mit vorhandenen Protokollsicherungen auf einen Zeitpunkt kurz vor dem Löschvorgang wiederhergestellt werden. Bei einem geplanten nächtlichen Massendatenimport kann vorübergehend auf Bulk-Logged umgestellt werden, um Protokollvolumen und Laufzeit zu reduzieren; anschließend wird zurück auf Full gewechselt und ein neues Vollbackup erstellt, um die Sicherungskette sauber fortzuführen.
Recovery-Model – einfach erklärt:
Ein Recovery-Model ist die Einstellung in einem Datenbankmanagementsystem, die bestimmt, wie Transaktionen protokolliert und Sicherungen organisiert werden und welche Wiederherstellungsoptionen daraus entstehen. Je nach Modell sind Leistungsbedarf, Loggröße und die Möglichkeit zur Wiederherstellung bis zu einem bestimmten Zeitpunkt unterschiedlich.
Häufige Fragen und Antworten
Welches Recovery-Model erlaubt eine Punkt-in-Time-Wiederherstellung?
Das Full Recovery-Model ermöglicht eine Punkt-in-Time-Wiederherstellung, sofern regelmäßige Transaktionsprotokollsicherungen vorliegen. Im Bulk-Logged-Modell ist dies grundsätzlich möglich, jedoch nicht innerhalb eines Log-Backups, das minimal protokollierte Massenoperationen enthält. Im Simple-Modell ist eine Wiederherstellung nur bis zum Zeitpunkt der letzten Sicherung möglich.
Wann ist das Bulk-Logged Recovery-Model sinnvoll?
Bulk-Logged eignet sich für Phasen mit großen Bulk-Inserts, Indexerstellungen oder Datenladeprozessen, bei denen Protokollvolumen und Laufzeit reduziert werden sollen. Danach wird häufig wieder auf Full umgestellt, um die volle Flexibilität der Punkt-in-Time-Wiederherstellung sicherzustellen. Beachten Sie, dass während minimal protokollierter Vorgänge keine Wiederherstellung auf einen beliebigen Zeitpunkt innerhalb des betreffenden Log-Backups möglich ist.
Kann ich das Recovery-Model im laufenden Betrieb wechseln?
Ein Wechsel ist möglich, sollte jedoch geplant erfolgen. Der Wechsel von Full oder Bulk-Logged auf Simple unterbricht die bestehende Log-Sicherungskette; für weitere Protokollsicherungen ist nach Rückkehr zu Full ein neues Vollbackup erforderlich. Prüfen Sie vorab, ob laufende Transaktionen, Wartungsfenster und Wiederherstellungsziele den Wechsel zulassen.
Wie beeinflusst das Recovery-Model die Größe des Transaktionsprotokolls?
Im Full-Modell wächst das Protokoll, bis es durch Protokollsicherungen abgeschnitten werden kann; ohne regelmäßige Sicherungen kann es stark anwachsen. Im Simple-Modell wird das Protokoll nach Checkpoints automatisch bereinigt, wodurch es meist kleiner bleibt. Bulk-Logged reduziert die Lognutzung während bestimmter Massenoperationen, kann aber je nach Arbeitslast dennoch zu deutlichem Wachstum führen.
