In der letzten Woche wurde ich von einem jungen Kollegen auf den Volume-Shadow-Copy-Service von Windows-Betriebssystemen angesprochen und die Funktion, die diese „Schattenkopien“ im Backupvorgang \u00fcbernehmen k\u00f6nnen. Er meinte VSS w\u00fcrde f\u00fcr ein konsistentes Backup sorgen. Dieser Aussage musste ich widersprechen. Diese Meinung ist jedoch verbreitet und daher soll dieser Artikel etwas zur Aufkl\u00e4rung beitragen.<\/p>\n
Eine Volumen-Schattenkopie friert den Zustand eines Volumes, also einer Festplattenpartition oder, einfacher ausgedr\u00fcckt, eines Windows-Laufwerks quasi ein. Ein Programm kann damit auf diesen eingefrorenen Zustand zugreifen w\u00e4hrend andere Programme weiter das Laufwerk bearbeiten und die Daten auf dem Laufwerk ver\u00e4ndern: Der eingefrorene Zustand bleibt erhalten.<\/p>\n
Beim Einfrieren werden alle Programme, die es interessiert und die sich vorher beim VSS, dem Volume-Shadow-Copy-Service, registriert haben, informiert und bekommen die M\u00f6glichkeit, noch Daten fertig zu schreiben. Auf diese Weise sind die Daten in einer Schattenkopie in einem definierten Zustand, also in einer Form, die die schreibenden Programme veranlasst haben.<\/p>\n
Backups haben ein prinzipielles Problem: sie dauern Zeit. Je nachdem wie gro\u00df die Datenmengen sind, vergehen vom Start bis zum Ende des Backups Sekunden, Minuten oder viele Stunden. Wird in dieser Zeit von Programmen weiter gearbeitet, so werden auch Daten ver\u00e4ndert. Es kann also sein, dass das Backup bei den Daten vorne schon fertig ist, dann jedoch Daten ver\u00e4ndert werden und dann erst das Ende gesichert wird. Bei einem Text ist vielleicht st\u00f6rend aber harmlos, bei Datenbanken jedoch ein gro\u00dfes Problem: Stellen Sie sich eine \u00dcberweisung vor: Geld wird in einem Schritt von einem Konto weggenommen und in einem zweiten Schritt auf ein anderes Konto aufgebucht. Beide Schritte d\u00fcrfen nur gemeinsam oder gar nicht ausgef\u00fchrt werden, sonst wird Geld erfunden oder vernichtet. Steht nun das zweite Konto vorne in unserer Datenbank, dann ist diese Konto vielleicht schon auf Band gesichert, wenn es bebucht wird, das erste Konto, das hinten steht wird aber noch beschrieben und landet dann ver\u00e4ndert in unserem Backup. Wird nun das Backup zur\u00fcckgespielt, passen die Konten nicht zusammen. Und dieses Problem besteht prinzipiell bei allen Daten, die auf Systemen gespeichert und gesichert werden.<\/p>\n
Dadurch, dass der VSS den Programmen vor dem Backup eine Nachricht zukommen l\u00e4sst, k\u00f6nnen die Programme sicherstellen, dass Daten auf den Plattenspeichern konsistent sind. Unser Bankprogramm kann also beide Kontenbewegungen schreiben und dann dem VSS mitteilen, dass die Daten nun konsistent sind.<\/p>\n
Die Grenzen bei Volumen-Schattenkopien liegen dort, wo die Programme mitspielen m\u00fcssen: Es reicht eben nicht aus, dass das Betriebssystem die Festplatte zu einem Zeitpunkt einfriert: Es k\u00f6nnte ja sein, dass bisher nur eine der beiden Kontenbewegungen geschrieben wurden. Das Betriebssystem darf eben erst dann die Daten einfrieren, wenn die Programme einen konsistenten Zustand hergestellt haben.<\/p>\n
Und wie ein konsistenter Zustand definiert ist, ist letztendlich Entscheidung des Programms. Gerade komplexe Datenbanksysteme arbeiten mit mehrstufigen Verfahren: Daten werden, wenn Sie ge\u00e4ndert werden, nicht direkt auf der Festplatte ge\u00e4ndert sondern erst im sehr viel schnelleren Hauptspeicher (RAM). Und werden komplexe Daten wie in unserem Beispiel ge\u00e4ndert, so werden die auch die Zwischenschritte in sogenannten Transaktionsprotokollen z.B. als Vorher-Nachher-Zustand gespeichert. F\u00fcr den Administrator bedeutet das, dass bei einem Backup einer Datenbankdatei ggf. die Datenbankdatei selbst trotz des Einsatzes von VSS in einem inkonsistenten Zustand sein kann. Nur in Verbindung mit der Ber\u00fccksichtigung der Transaktionsprotokolle kann die Datei dann in einen konsistenten Zustand gebracht werden. Bei einem R\u00fcckspielen eines Backups ist es also h\u00e4ufig nicht mit dem reinen R\u00fcckspielen der Daten getan, vielmehr m\u00fcssen vielfach weitere Schritte seitens des Administrators unternommen werden, um ein funktionsf\u00e4higes und konsistentes System zu gew\u00e4hrleisten.<\/p>\n
Extrem komplex wird eine Backupsituation dann, wenn ganze Serversysteme gesichert werden m\u00fcssen, bei denen Daten ggf. \u00fcber mehrere Server verteilt liegen. Denn hier ist das Problem der Inkonsistenz nicht auf einen Server beschr\u00e4nkt, sondern verteilt sich auf viele Systeme an vielen Standorten. Unter Umst\u00e4nden m\u00fcssen ja s\u00e4mtliche Systeme gleichzeitig „eingefroren“ werden. Sie merken: Ein Backup ist nicht „mal eben“ gemacht, sondern muss durchdacht und geplant werden.
\n