News zu Microsoft SQL Server
Die Frage “Welches SQL Server Wiederherstellungsmodell ist das richtige für mich?” ist nicht immer so leicht zu beantworten, das erleben auch wir als Dienstleister bei unseren Kunden immer wieder. Falls du dir jetzt von diesem DBA Tipp eine einfache Antwort auf die Frage erhoffst und womöglich noch eine Pro- und Contra-Liste erwartest, solltest du vielleicht besser aufhören zu lesen. Denn – Spoiler Alarm: Es gibt kein pauschales “Besser” oder “Schlechter” der einzelnen Modelle.
Was es allerdings durchaus gibt, sind einige Überlegungen und Kernfragen, die du dir im Vorfeld unbedingt stellen solltest und die dir dabei helfen werden, künftig die richtige Wahl zu treffen. Also, falls du gewillt bist, etwas tiefer in die Materie der SQL Server Wiederherstellungsmodelle einzusteigen, um den Entscheidungsprozess künftig zu beschleunigen, ließ gern weiter.
Zu Beginn noch eine kurze Rekapitulation: Es heißt aus guten Grund “Wiederherstellungsmodell” und nicht etwa “Sicherungsmodell”. Schließlich legst du mit dem SQL Server Wiederherstellungsmodell fest, wie du im Falle einer Wiederherstellung von Tabellen und Zeilen vorgehen möchtest. Dieser Gedanke wird nicht selten vergessen, wenn man die Datensicherungsstrategie plant. Hinzu kommt, dass eine potentielle Wiederherstellung nicht erst nach Hardware-Ausfällen oder nach größeren Katastrophen notwendig wird, sondern auch (oder ganz besonders) aufgrund der “von innen ausgehenden Gefahren” (siehe Frage 5 im nächsten Abschnitt) durchgeführt werden muss.
Grundsätzlich unterscheidet man im Microsoft SQL Server Bereich drei Wiederherstellungsmodelle:
Um sich völlig zu vergegenwärtigen, wie sich die drei möglichen Modelle von einander unterscheiden, solltest du nicht nur die klassischen Indikatoren im Blick haben, sondern auch die “stressverursachenden” Einflüsse beachten. Hier einige Beispiele dafür:
Klassische Indikatoren
Stressverursachende Einflüsse
Darüber hinaus sind die folgenden 5 Überlegungen geradezu essenziell, wenn du vor der Frage des sinnvollsten SQL Server Wiederherstellungsmodells für deine Datenbank stehst:
Handelt es sich um eine ERP-Datenbank mit über 1000 Kunden und Lieferanten oder lediglich um ein Intranet mit mäßig brisanten Informationen?
Müssen ein Dutzend Fachanwender die verlorenen Daten erneut eingeben oder ist die Anwendung in der Lage, die fehlenden Daten aus dem alten Datenstand zur errechnen?
Stehen diverse produktionskritische Systeme und Anlagen still oder wird der Ausfall der Datenbank für bis zu 48 Stunden gar nicht bemerkt?
Handelt es sich um eine 24/7‑Datenbank, die immer unter Last steht oder erfolgen nur sporadische Änderungen?
Werden Datensätze gleichmäßig (also ohne erkennbare Pause) geändert oder erfolgt der hauptsächliche Schreibzugriff nur in der Kernarbeitszeit?
Sind die fehlenden Daten (nach einer Wiederherstellung) komplett verloren oder kann eine Fachanwendung eine geringe Menge an Daten erneut in die Datenbank einfügen?
Wie lange dauert eine komplette Wiederherstellung?
Ist die Dauer des Wiederherstellungsprozesses relevant für den Geschäftsbetrieb?
Wird ein Drittanbieterprodukt (wie beispielsweise Veeam) zur Datenbanksicherung verwendet oder kommen nur klassische SQL Server Agent Jobs zum Einsatz?
Wird der Host virtuell betrieben und per Snapshot gesichert? Wie oft werden die Snapshots angefertigt?
Kommt es ab und zu vor, dass die Programm-Updates der Fachanwendungen eine unangenehme Auswirkung auf die Datenbank haben?
Neigen Fachanwender dazu, Daten unbeabsichtigt zu löschen oder zu verändern?
Hast du dir nun ein Bild von der Relevanz deiner Datenbanken gemacht, so fällt es wesentlich leichter, die Wiederherstellungsmodelle (man könnte auch sagen “Strategien zur Wiederherstellung”) für jede einzelne Datenbank festzulegen.
Da die Unterschiede zwischen dem massenprotokollierten und dem vollständigen Modell zu vernachlässigen sind, fassen wir diese beiden Modelle in der weiteren Betrachtung zusammen. Damit unterscheiden wir im Folgenden lediglich zwischen dem einfachen und dem vollständigen Wiederherstellungsmodell:
Das einfache SQL Server Wiederherstellungsmodell
Das vollständige SQL Server Wiederherstellungsmodell
Auf die jeweils erste Eigenschaft kommt es bei der Entscheidung an. Denn während man unter Verwendung des einfachen Wiederherstellungsmodells eine Datenbank nur auf den Datenstand zum exakten Zeitpunkt der Komplettsicherung zurückspielen kann, ist bei Verwendung des vollständigen Wiederherstellungsmodells nahezu jeder Zeitpunkt nach der Komplettsicherung möglich. Und eben genau darauf sollte deine Überlegung abzielen: Der Anspruch an die gezielte Wiederherstellbarkeit einzelner Datensätze. Denn wenn die Änderungen einzelner Aktionen in den Tabellen “ungeschehen gemacht” werden sollen, dann scheidet das einfache Wiederherstellungsmodell aus.
Das SQL Server Wiederherstellungsmodell entscheidet maßgeblich darüber, wie granular eine Wiederherstellung durchgeführt werden kann.
Kannst du mit einem theoretischen Datenverlust leben, der sich vom Zeitpunkt des letzten Komplett-Backups bis zum Ausfall ergibt? Dann kann das einfache Wiederherstellungsmodell genügen.
Suchst du nach einem Weg, den theoretischen Datenverlust so weit wie möglich zu minimieren, indem du die Zeit zwischen zwei Komplett-Backups mit diversen kleineren Backups überbrückst? Dann bleibt nur das vollständige Wiederherstellungsmodell übrig.
Die Entscheidung für oder gegen ein bestimmtes Wiederherstellungsmodell wird also durch die maximal tolerierbare Menge an verlorenen Daten bestimmt. Als Faustregel gilt, dass mit steigender Anforderung an einen möglichst hohen/aktuellen Datenstand, die Entscheidung auf das vollständige Wiederherstellungsmodell hinausläuft. Bedenke jedoch, dass auch das vollständige Modell und sehr häufige Transaktionsprotokoll-Backups bei produktionskritischen Datenbanken kein Ersatz für eine Hochverfügbarkeitslösung darstellt.
Hier findest du weitere Infos zum Thema » Microsoft SQL Server aus unserem News & Insights Bereich.
Share this article