Zuletzt aktualisiert: 21. Dezember 2010
Images sind sehr beliebt. Die Technik, eine ganze Festplatte oder Partition sektorweise zu kopieren, ist schon recht alt und hat sich in vielen Fällen bewährt: Ein Image von einer Workstation lässt sich gut nutzen, um den Rechner zu „klonen“ und so zahlreiche gleich aufgebaute PCs zu erhalten. Viele Anwender nutzen Images auch, um ihren PC zu sichern – sollte etwas mit der Maschine sein, so lässt sich das letzte „gute“ Image einfach wieder zurückspielen, und das Problem ist verschwunden. Da liegt es doch nahe, diese 1:1-Technik auch für die Datensicherung von Servern einzusetzen. Oder?
Darauf gibt es nur eine klare Antwort: Nein. Ein Image ist fast nie zur Datensicherung eines Servers geeignet. In nahezu allen Situationen ist eine Wiederherstellung mit einem Image Ursache für schwer lösbare Probleme. Dasselbe gilt übrigens auch für „Snapshots“ von Servern auf Basis von SAN-Techniken oder auf Basis virtueller Maschinen. Warum ist dies so?
Was ein Image ist
Ein Image konserviert einen bestimmten historischen Zustand einer Maschine: Die Daten auf der Platte werden genau so „eingefroren“, wie sie im Moment des Image sind (mit „Image“ sind im Folgenden auch alle verwandten Techniken gemeint wie SAN-Snapshots, VMware-Snapshots oder ähnliche). Darin sehen viele Anwender einen unschätzbaren Vorteil, weil sich so ja eben dieser historische Zustand problemlos wiederherstellen lasse – vorausgesetzt, die Image-Software arbeitet sauber, könne es ja gar keine Probleme geben, denn der Zustand nach der Wiederherstellung sei ja derselbe, als würde der Server einfach an der „eingeforenen“ Stelle weiterarbeiten. Dass dies für die meisten Serversysteme nicht ohne Weiteres zutrifft, liegt an der Komplexität moderner Serveranwendungen. Einige der zahlreichen Stolperstellen werden im Folgenden beleuchtet. Zur besseren Verständlichkeit werden einige Zusammenhänge dabei vereinfacht.
Transaktionen und offene Dateien
Eine Datensicherung muss sicherstellen, dass die gesicherten Daten konsistent sind. Online-Image-Techniken laufen Gefahr, an offenen Dateien oder an Transaktionen zu scheitern: Komplexe Applikationen, aber auch normale Dateioperationen umfassen mehr als nur die Daten auf der Festplatte. Oft stehen zusätzliche Daten im Arbeitsspeicher oder im Cache des Plattencontrollers. Wird hier ein einfaches Image angelegt, können diese Daten fehlen und eine scheinbar „gesicherte“ Applikation bei der „Wiederherstellung“ beschädigen. Zwar setzen moderne Image-Programme hier einige Techniken ein, um dieses Problem zu umgehen, das Risiko besteht aber trotzdem – insbesondere bei Online-Images.
Datenverteilung über mehrere Orte
Viele Anwendungen, vor allem Datenbanken, verteilen ihre Daten auf mehrere Speicherorte, die oft auf verschiedenen Partitionen oder sogar auf verschiedenen Servern liegen. In solchen Fällen kann die Wiederherstellung einer Partition per Image direkte Schäden hervorrufen, wenn die Zustände aller beteiligten Speicherorte nicht exakt gleich sind: Befindet sich etwa Partition 1 mit der Datenbank auf dem Stand von 11:01 Uhr, Partition 2 mit den Transaktionsprotokollen aber auf dem Stand von 11:12 Uhr, so sind Inkonsistenzen sehr wahrscheinlich. Abhilfe kann hier, wenn überhaupt, nur bei Einzelservern durch ein Offline-Image geschaffen werden (also: der Server wird heruntergefahren und das Image dann mit einem separaten Betriebssystem erzeugt). Ein solcher Ansatz taugt aber in der Regel nicht für eine laufende Datensicherung. Zwar arbeiten manche Image-Programme mit Applikationsschnittstellen zusammen, die die Konsistenz der Daten sicherstellen sollen (z. B. Windows VSS), doch stehen solche Schnittstellen nicht für alle Applikationen bereit.
Computerkennwörter
Relativ unbekannt ist die Tatsache, dass ein Computer in einer Windows-Domäne über ein Anmeldekonto verfügt, das praktisch einem Benutzerkonto entspricht. Daraus folgt, dass auch ein Computer sich mit einem Kennwort an die Domäne anmelden muss. Dieses Kennwort wird zwischen dem Computer und dem Domänencontroller ausgehandelt und in bestimmten Zeitabständen erneuert. Wann dies geschieht, ist nicht ohne Weiteres nachvollziehbar. Genau hieraus erwächst aber ein Problem: Ein Image sichert natürlich auch das gerade aktuelle Kennwort des Computers mit. Es ist nun leicht möglich, dass nach dem Herstellen des Images das Computerkennwort neu gesetzt wird. Wenn die Maschine durch das Image auf den alten Stand zurückgebracht wird, kann sich der Computer nicht mehr an die Domäne anmelden. Die Lösungsmöglichkeit, den Computer aus der Domäne zu nehmen und neu hinzuzufügen, dürfte bei einer Workstation noch tolerabel sein, bei einem Server aber in der Regel nicht: Macht ein einfacher Terminalserver dies meist noch mit, werden ein Exchange-Server oder gar ein Domänencontroller das schon ganz anders sehen.
Diese Problematik ist nicht auf Windows-Rechner beschränkt, denn das Prinzip von lokal gespeicherten Kennwörtern, die ohne direkten Benutzereingriff geändert werden, gibt es plattformübergreifend in vielen Applikationen.
Domänencontroller: USN-Rollback
Eine Serverklasse, bei der vollständig vom Einsatz von Image-Techniken jeder Art abzuraten ist, sind Domänencontroller. Der Grund liegt in der Komplexität des sehr leistungsfähigen Replikationssystems: Alle Domänencontroller einer Domäne verfügen durch die Replikation über denselben Datenbestand. Dabei verwaltet jeder einzelne Domänencontroller seine Daten selbst und gleicht sie mit seinen Replikationspartnern ab. Damit die Replikation leistungsfähig und robust ist, wissen die Domänencontroller sehr viel über ihre Partner: So werden etwa die Seriennummern einzelner Objektänderungen gespeichert und den Replikationspartnern übermittelt, damit jeder Server zweifelsfrei feststellen kann, ob er auf dem aktuellen Stand ist oder noch Daten ändern muss. Genau an dieser Stelle wirkt eine Image-Wiederherstellung oft fatal. Warum das so ist, beleuchtet das folgende (vereinfachte) Beispiel:
- Die Domäne contoso.com wird von drei Domänencontrollern gehostet. Sie umfasst die drei Objekte Benutzer1, Benutzer2 und Benutzer3. Alle Domänencontroller sind ordnungsgemäß repliziert: DC01 hat die letzte Seriennummer (USN, Update Sequence Number) 4711, DC02 die letzte USN 3981, und DC03 hat die 5099.
- Der Domänencontroller DC01 wird um 12:11 per Image gesichert.
- Um 13:24 wird auf DC01 ein neues Benutzerkonto angelegt: Benutzer4. Zusammen mit einigen anderen Datenänderungen hat DC01 nun die letzte USN 4923.
- Um 14:00 fällt DC01 aus irgendeinem Grund aus und wird mit dem Image von 12:11 wiederhergestellt.
- DC01 wähnt sich nun auf dem Stand von 12:11: Er kennt nur die Benutzer 1 bis 3 und plant als nächstes die Vergabe von USN 4712.
- Wer nun glaubt, Benutzer4 würde von DC02 oder DC03 auf den Domänencontroller DC01 repliziert, irrt: DC02 und DC03 gehen davon aus, dass DC01 dieses Objekt bereits hat, denn sie haben es ja von ihm erhalten. DC01 wird also das Objekt Benutzer4 nicht bekommen.
- Bei der nächsten Änderung auf DC01 wird dieser seine USNs weiterzählen. In der Replikation wird er seinen Partnern also Objekte mit Seriennummern ab 4712 anbieten. Seine Partner können diese aber nicht akzeptieren, weil sie ja bereits vor einiger Zeit Änderungen mit genau diesen Nummern erhalten haben und davon ausgehen, dass von DC01 nur Daten mit USNs ab 4924 neu sein können.
- Irgendwann in dieser Zeitspanne wird DC01 feststellen, dass er ein Problem hat. Er wird daher seine Anmeldedienste einstellen und den Administrator im Ereignisprotokoll zur Problembehandlung auffordern.
- Die Problembehandlung kann aber schwierig sein: Im günstigen Fall ist DC01 zum Mitgliedsserver herabzustufen und wieder neu einzurichten. Es ist aber nicht zweifelsfrei auszuschließen, dass das USN Rollback (so der Ausdruck für das skizzierte Problem) Folgeschäden in der Umgebung verursacht hat, sodass eine eingehende Analyse notwendig ist: Ist das AD insgesamt noch konsistent? Sind vielleicht SIDs (Scurity IDs, Sicherheitskennungen für Benutzer und Gruppen) doppelt vergeben worden? Haben andere Applikationen aufgrund der inkonsistenten Daten Probleme verursacht?
Die Datensicherung und Wiederherstellung des Active Directory kann nur über den System State erfolgen. Mehr dazu:
Hinweis Es gibt eine Methode, einen DC, der mit einem Image wiederhergestellt wurde, zur ordentlichen Replikation mit seinen Partnern zu bewegen. Der Ansatz erzwingt das Erzeugen einer neuen „Invocation ID“, mit der die AD-Datenbank von den Replikationspartnern identifiziert wird. Diese Technik wird angeblich auch von einigen moderneren Imaging-Programmen verwendet (wohlgemerkt: Nur von wenigen – und die Nutzung von VSS hat damit nichts zu tun. Vor allem aber wird die Technik nicht von Snapshots à la VMware oder SAN genutzt).
Hebelt dies nun meine Argumentation aus? Nein, das tut es nicht:
- Das Verfahren setzt zwingend voraus, dass der per Image restaurierte DC nicht normal startet, sondern als erstes in den Modus „Verzeichnisdienste wiederherstellen“ gebootet wird. Dort wird dann die Registry manipuliert. Durch diesen Umstand verliert das Image-Verfahren einen (großen) Teil seines scheinbaren Zeitvorsprungs gegenüber einer „ordentlichen“ Methode. Zudem ist genaue Kenntnis des Vorgangs und sehr koordiniertes Handeln erforderlich. In der Praxis wird es aber genau daran scheitern – und wenn der DC auch nur einmal „unbehandelt“ hochfährt, kann es bereits zu spät sein, und das Kind ist in den Brunnen gefallen.
- Will man dieses Verfahren ernsthaft einsetzen, kann man es eigentlich nur mit Offline-Images nutzen, denn ein Online-Image würde nach der Wiederherstellung im „Normalbetrieb“ des AD ansetzen – zu spät für das Verfahren. Wer will aber seinen DC zur Datensicherung regelmäßig herunterfahren? Die Alternative wäre Netzwerkkabel-Akrobatik – das würde ich einem normalen Backup/Restore nicht vorziehen.
- Das Verfahren kann einen USN Rollback nicht aushebeln oder reparieren, sondern ihn bestenfalls verhindern – wenn es denn korrekt und rechtzeitig angewandt wird. In der Stresssituation einer Serverwiederherstellung ist letzteres aber leider keine Selbstverständlichkeit.
- Das Problem der Computerkennwörter lässt sich mit Images nicht lösen.
- Imaging ignoriert, dass die meisten Schadensfälle gar nichts mit einem Serverausfall zu tun haben – viel häufiger sind fehlerhafte Anwenderaktionen. Ein Image setzt die gesamte Maschine auf einen historischen Stand zurück. Wer auf Imaging setzt, hat also keine Möglichkeit, gezielt bestimmte Objekte wiederherzustellen. Das geht nur über die „ordentlichen“ Backup-Methoden.
- Der oft genannte Vorteil eines Image – die schnelle Wiederherstellung – ist in den meisten Umgebungen bei Domänencontrollern zu vernachlässigen. Ein verantwortungsbewusster Netzwerkaufbau sorgt durch Standardisierung und Dokumentation dafür, dass ein Domänencontroller sehr schnell neu installiert ist.
Aus diesen Gründen bleibe ich dabei, Images von Domänencontrollern abzulehnen.
Hier übrigens einige erhellende Artikel:
Das Directory-Service-Team bei Microsoft meint:
Acronis, Hersteller eines der beliebtesten Imaging-Programme, sagt zu dem Thema:
Claus Greck stellt die Problematik ausführlich dar:
Backup-Schnittstellen
Viele komplexe Anwendungen bieten eigene Schnittstellen für die Datensicherung an, z. B. Exchange Server oder SQL Server. Wenn diese Schnittstelle von einem Datensicherungsprogramm angesprochen wird, werden oft zusätzliche Vorgänge ausgeführt, etwa eine Prüfung der Datenbanken oder eine Defragmentierung. Werden solche Prozesse nicht ausgeführt, weil statt eines „ordentlichen“ Backups nur Images hergestellt werden, kann dies Beschädigungen der Datenbestände zur Folge haben, die unter Umständen erst bemerkt werden, wenn es viel zu spät ist und bereits zusätzliche Probleme entstanden sind. Ein klassisches Beispiel für dieses Problem ist der gefürchtete „-1018“-Fehler in Exchange (vgl. http://www.msxfaq.net/notfall/-1018.htm).
Es gibt noch zahlreiche weitere Gründe, die gegen den Einsatz von Images oder Computer-Snapshots als „Sicherungsstrategie“ sprechen. Daher die Empfehlung: Finger weg von Images! Server müssen mit einer ordentlichen Online-Datensicherung gesichert und mit einem herstellerunterstützten Verfahren wiederhergestellt werden.
Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=503
Kategorie: 
Translate EN
