Warum muss eine Datenbank zum Backup konsistent sein?

Aus einer Diskussion: Ein Berater ist der Ansicht, ein sog. “Hot Backup” einer relationalen Datenbank wie SQL Server, Oracle oder Exchange sei kein Problem, wenn man sie mit einem SAN-Snapshot herstellt. Die Gefahr einer Inkonsistenz der Datenbank sei zu vernachlässigen, weil sehr unwahrscheinlich. Das Argument, dass “Hot Backups” vom Datenbankhersteller nicht supportet seien, ziehe nicht, denn es gehe um die Praxis.

Warum irrt er?

Zum einen: für mich ist "kein Herstellersupport" ein schlagendes Sachargument, denn ich habe schon zahlreiche Situationen erlebt, in denen man ohne den Hersteller das jeweilige System hätte einstampfen können.

Zum anderen aber – technisch argumentiert: Eine Datenbank wie SQL Server (aber auch alle anderen) arbeitet nach dem "Lazy Writer"-Prinzip. Das bedeutet folgenden Ablauf (schematisch vereinfacht):

1. Eine Applikation fordert eine Änderung von Daten an (UPDATE oder INSERT usw.).
2. SQL Server lädt die betreffenden Datenbankseiten in den Cache (=RAM) bzw. lokalisiert sie dort.
3. SQL Server schreibt die Änderung ins Transaktionsprotokoll.
4. SQL Server ändert die Seiten im Cache (=RAM).
5. SQL Server sendet der Applikation ein Acknowledge über die Änderung.
6. Erst beim nächsten Intervall schreibt SQL Server die Daten in die Datenbankdatei, aber im Regelfall nicht sofort. (Steigert Performance, weil es Random Writes einspart.)

Wenn nun nach Schritt 5 der Strom weg ist – oder man eben einen Snapshot macht -, entsprechen die Daten auf der Platte nicht dem Stand, der an die Applikation berichtet wurde. Nun könnte man argumentieren: Kein Problem, dafür hat man ja das Transaktionsprotokoll. Richtig, hat man auch, und genau dafür ist es da. Das setzt aber voraus, dass das Protokoll auch nutzbar ist – und sich auf exakt demselben Stand (hier also Schritt 3) befindet. Nun liegt das Log aber i.d.R. auf einer anderen LUN als die Datenbank. Ist es also im Falle des "Hot Backups" per Snapshot (oder wie immer) auf demselben Stand? Das wage ich energisch zu bezweifeln.

Selbst in einem normalen Strom-weg-Szenario ohne Snapshot bleibt hier ein Risiko, denn es kann ja sein, dass das Transaktionsprotokoll beschädigt ist. Wenn man hier noch ein Risiko in seinem Backup hat, macht das aus meiner Sicht ein bisschen viel Risiko für einen sensiblen Bereich.

Man kann das auch variieren: Eine Datenbank kann ja auch selbst auf mehrere LUNs verteilt sein – gerade bei großen Datenbanken gibt es mehrere Gründe dafür. Nun betrifft ein Update beispielsweise mehrere Tabellen, die in Datenbankdateien auf mehreren LUNs liegen. Es muss hierbei schon mit schwarzer Magie zugehen, wenn man erwartet, dieses Szenario in einem "Hot Backup" konsistent hinzubekommen. Wir reden ja u.U. von High-Performance-Datenbanken, in der tausende Transaktionen in einer Sekunde verarbeitet werden.

Das muss man aber gar nicht so weit führen. Auch eine Transaktion in einer “ganz normalen” Datenbank, die nicht über mehrere LUNs verteilt ist, kann Datenbankseiten auf ganz unterschiedlichen Plattenbereichen betreffen. Natürlich müssen diese Änderungen alle gemeinsam geschrieben werden (oder eben gar nicht). Ein “Hot Backup” wie ein Snapshot kann aber nicht wissen, wann eine Transaktion abgeschlossen ist und “fotografiert” einfach mitten rein. Hier kann ein weiteres Problem auftreten: Eine Datenbankseite wird gar nicht vollständig geschrieben (“Torn Page”). Ein solches Problem wird u.U. nicht beim anschließenden Durchlauf der Transaktionsprotokolle beim Neustart der Datenbank behoben und bleibt unentdeckt. Je nach Konfiguration der Datenbank hat man also das Risiko unbrauchbarer Daten – oder die Datenbank hält an, weil sie das Problem bemerkt hat (“Torn Page Detection”) und fordert zum Restore aus einem Backup auf. Dumm, wenn das Restore gerade der Grund für das Problem war.

Auch der manchmal vorgeschlagene “Ausweg”, Datenbank- und Transaktionsprotokolldateien auf dieselbe LUN zu legen, um mit einem einzigen Snapshot arbeiten zu können, ist also kein echter Ausweg. Zumal man dies bei belasteten Datenbanken schon deshalb nicht machen wird, weil ein Transaktionsprotokoll auch mal plötzlich sehr stark anwachsen kann und auf einer separaten LUN besser aufgehoben ist.

Und das Argument mit "unwahrscheinlich" wird schon von der Praxis widerlegt, denn im Support gibt es ständig Anwenderprobleme, die auf Inkonsistenzen durch falsche Datenbanksicherungen zurückzuführen sind. Das hat z.B. überhaupt nichts mit der Dauer zu tun, die ein Snapshot zum Erzeugen braucht, sondern liegt einfach in der Art, wie relationale Datenbanken ihre Daten ablegen.

Schließlich bleibt das Nutzenargument: SQL Server hat etwa mit der VSS-Schnittstelle eine eingebaute (und supportete) Möglichkeit, für Backupzwecke eine Konsistenz zu erzeugen. Warum darauf verzichten und ein noch so kleines Risiko eingehen?