Imagebackup als Sicherung

Achtung:
Die meisten Sicherungen, die auf einem Festplattenimage basieren (Online oder Offline) sind keine geeigneten Exchange Datensicherungen. Nur eine Sicherung per API oder VSS ist eine gültige Sicherung.

Achtung: Imagebackup und Domaincontroller
Sie können einen DC per ImageBackup kopieren, aber eine Sicherung ist dies nicht, da beim Restore ein "USN.Rollback" passiert. Nur wenn Sie genau einen DC haben, ist so ein Restore möglich:
Tipp: machen Sie vor dem Image ein Systemstate-Backup mit Windows Backup auf die Festplatte. Nach einem Restore können sie ebenfalls wieder dieses Backup mit NTBACKUP restaurieren und wie gewohnt arbeiten.

Auf dieser Seite möchte ich ihnen neue Möglichkeiten einer schnellen Wiederherstellung von Servern erläutern, die direkt mit Exchange nichts zu tun hat. Da aber auch Exchange Server ausfallen können, und dann eine schnelle Rücksicherung erwünscht wird, ist diese Option doch wieder interessant.

Verwechseln Sie ein Image nicht mit einem "richtigen" Exchange Backup. Sie sollten folgende Dokumente ebenfalls lesen:

Das Problem heute

Jeder verantwortungsbewusste Administrator sichert seine Server heute regelmäßig. Unter Windows gibt es dazu NTBACKUP als auch Drittsoftware. Mit den passenden Exchange Funktionen wird auch Exchange "korrekt" online gesichert, d.h. die Datenbank wird auf Konsistenz geprüft und die Transaktionsprotokolle werden abgeschnitten.

Damit ist ein schnelles Restore der Exchange Datenbank möglich. Seit Exchange 2003 erleichtern die neuen Speichergruppen zur Wiederherstellung die Rücksicherung einzelner Postfächer. Aber damit dies funktioniert, muss Das Betriebssystem und die Exchange Installation funktionstüchtig sein.

Sehr viel häufiger ist aber der Fall, dass andere Schäden die Funktion behindern, z.B.:

  • Ein fehlgeschlagenes Servicepack
  • Eine frisch installierte Zusatzsoftware
  • Ein Festplattendefekt, der das Betriebssystem unbrauchbar gemacht hat
  • Fälschlicherweise gelöschte Dateien (Menschlicher Fehler oder Virus)
  • Virusbefall
  • Treiberupdate
  • und vieles mehr

Es gibt also viele Fälle, wann das Betriebssystem nicht mehr funktioniert oder die Datensicherung keine Wiederherstellung mehr fahren kann.

In all diesen Fällen können Sie versuchen, das System wieder zu reparieren, indem Sie die Software nachinstallieren, deinstallieren oder mit der Recovery Console die Treiberfehler korrigieren. Im schlimmsten Fall müssen Sie das Betriebssystem neu installieren. Dieser Fall bedeutet aber auch, dass sie in den meisten Fällen folgende Schritte durchführen müssen:

  • Installation des Betriebssystem per CD oder RIS
  • Einspielen der Treiber
  • Installieren der Datensicherungssoftware
  • Wiederherstellung des Systemstatus und Programme (und damit der originalen Betriebssysteminstallation
  • Neustart
  • Wiederherstellung der Exchange Datenbanken.

Das kann alles sehr zeitaufwändig sein. Wenn Sie gut vorgesorgt haben und z.B.: das Betriebssystem und die Software von den Nutzdaten (hier die Exchange Datenbanken) getrennt haben, dann können Sie sich mit einer Imaginglösung helfen.

Imaging als Sicherung

Ein "Image" einer Festplatte ist eine Sicherung von Blöcken eines Speichermediums ohne Rücksicht auf Daten, Strukturen und Abhängigkeiten. Ein Image kann daher nur einen Schnappschuss einer Festplatte darstellen und löscht z.B. keine Exchange Transaktionsprotokolle. Ein Image sollte immer in Verbindung mit einer klassischen Sicherung eingesetzt werden, auch wenn mittlerweile Programme auch einzelne Dateien aus einem Image extrahieren können.

Das Thema Imaging ist schon sehr lange praktisch im Einsatz. Programme wie Ghost, Driveimage etc. haben es schon immer erlaubt, Partitionen oder komplette Festplatten von einem System auf ein anderes zu übertragen (Stichwort: Klonen von Betriebssystemen). Dabei waren die entsprechenden Betriebssysteme jedoch offline, d.h. nicht aktiv.

Seit einiger Zeit gibt es aber auch Programme, die unter Windows eine Partition im laufenden Betrieb als Image kopieren können. Dazu bedienen Sie sich einer Funktion, die ähnlich der Funktion der Schattenkopien ist. Die Software klinkt sich in das Windows Speichersubsystem ein und analysiert die Festplatte. Zu einem bestimmten Zeitpunkt ein Schnappschuss durchgeführt und die belegen Blöcke dann als Datei weggesichert. Versucht nun das Betriebssystem einen Block zu ändern, der noch nicht weg geschrieben wurde, dann kopier die Software den Block schnell weg, ehe Windows die Daten überschreibt. Diese Verfahren ist schon seit längerem bekannt durch so genannte "Open File Manager"-Agenten für Datensicherungen, um offene Dateien zu sichern. Nur dass hier auf Blocklevel operiert wird.

Die Wiederherstellung ist der eigentlich wichtige Schritt, da meist über eine DOS-Diskette und den Zugriff auf das Image der Server sehr schnell installiert werden kann. Die Installation eines gesonderten "Recoverysystems" ist nicht erforderlich. Das Image enthält meist auch direkt das Backupprogramm, so dass auch die Nutzdaten (z.B.: Exchange Datenbanken) online restauriert werden können. Bei getrennten Festplatten kann es sogar sein, dass die alte unbeschädigte Datenbank einfach weiter genutzt werden kann. Damit ist ein Ausfall der BetriebssystemUmgebung in kurzer Zeit repariert werden.

Grenzen und Risiken eines Imagebackups

Der Inhalt des Image entspricht daher im wesentlichen dem Stand der Festplatte, als wenn der Server hart ausgeschaltet worden wäre. Dies ist auch das größte Problem dieser Imagesicherungen. Zuverlässig funktionieren diese Sicherungen nur mit Daten, die transaktionsorientiert abgespeichert werden. Ein Image von einer Access Datenbank ist nur bedingt brauchbar, da der Treiber nicht erkennen kann, ob gerade ein Schreibprozess aktiv ist, der für den Erfolg mehrere Blöcke schreiben müsste. Das Image aber genau "dazwischen" aufsetzt.

Exchange, das Active Directory, NTFS selbst und SQL sind transaktionsorientiert, so dass diese System quasi immer wieder starten können. Aber selbst hier gibt es manche Dinge die schief gehen können.

Sie können zwar einen Domänencontroller als Image sichern, aber Sie dürfen ihn niemals wieder restaurieren !!!. Dies würde zu einem USN Rollback  führen, der nicht erkannt wird und ihre DCs "out of Sync" laufen lässt. Die einzige legitime Art einen DC zu restaurieren ist eine Wiederherstellung des Systemstate.
875495 How to detect and recover from a USN rollback in Windows Server 2003
885875 How to detect and recover from a USN rollback in Windows 2000 Server

Stellen Sie sich dazu vor, sie haben ein Netzwerk mit zwei DCs, die sauber synchron sind.

  • Nun machen Sie eine Imagesicherung der DCs.
  • Danach legen Sie einen Benutzer auf DC1 an, welcher natürlich auf den DC2 repliziert wird.

  • Danach fällt der DC nach einiger Zeit komplett aus
  • Er ist natürlich schnell mit einem Restore des Images von   wieder online gebracht. Nur hat er natürlich nun noch nicht den Benutzer, der nach dem Backup angelegt wurde.

Sie irren aber nun, wenn Sie glauben, dass diese Änderung vom DC2 wieder auf den DC1 zurück repliziert wird. Warum sollte das passieren ?. Das Objekt wurde auf DC2 nicht geändert und es kam ja ursprünglich von DC1. Daher geht DC2 aus, dass das Objekt auf DC1 ist. Nur bei einem Restore des Systemstate auf dem DC1 wird die erwünschte Replikation durchgeführt.

Ein Imagebackup ist aber sicherlich gut geeignet, um einen Dateiserver zu sichern, auf dem tausende von Officedokumente liegen und das Risiko sehr gering ist, eine offene Datei in einem inkonsistenten Status zu sichern. Da die meisten Programme auch einen Zugriff auf einzelne Dateien in dem Image erlauben, ist damit auch eine Wiederherstellung einer einzelnen Datei denkbar.

Es kann aber wohl  funktionieren, wenn Sie Imagerestore und Systemstate Restore kombinieren. für ein Restore des SystemState muss auf dem Zielsystem zuerst einmal Windows laufen. Dieses Windows muss man natürlich nicht von Hand installieren. Es kann ein kleines Windows durch ein Image oder per Remote Installation Services installiert sein. Denkbar ist auch ein Restore eines Imagebackups des gesamten Server. Sie sollten aber immer ein SystemState danach restaurieren.

Hier noch ein Auszug aus der Acronis FAQ http://www.acronis.de/enterprise/products/ATISWin/faq.html#19

Auf meinem Server laufen komplexe Anwendungen, wie z.B. Microsoft SQL Server, Oracle oder Microsoft Exchange. Ich möchte ein Image erstellen, bin aber nicht sicher ob diese Anwendungen auch während des Sicherungsprozesses laufen dürfen. Was sollte ich tun?
Obwohl Acronis True Image Server 8.0 für Windows sich per Snapshot Technologie um die Konsistenz auf Festplatten- und Dateisystem-Ebene kümmert, garantiert es jedoch keine Konsistenz in der Anwendungs-Ebene. Wir empfehlen komplexe Server-Anwendungen wie Microsoft SQL, Oracle oder Microsoft Exchange zu suspendieren, bevor die Schaltfläche Fertigstellen auf der letzten Seite des Acronis TrueImage Assistenten geklickt wird oder bevor ein geplanter Task ausgeführt wird. Sobald die Sicherung gestartet wurde, können alle Server-Operationen fortgeführt werden. Es ist nicht notwendig die Anwendung für die ganze Dauer der Sicherung zu suspendieren.

Kleiner Hinweis. Wenn Sie einen Domain Controller restaurieren, dann sollten Sie eine Eventlogmeldung der folgenden Form auf den anderen DCs finden:

reignistyp:         Informationen
Ereignisquelle:         NTDS Replication
Ereigniskategorie: Replikation
Ereigniskennung: 1587
Datum:         14.06.2006
Zeit:         20:53:13
Benutzer: MSXFAQ\SRV01$
Computer:         SERV01
Beschreibung:
Dieser Domänencontroller wurde wiederhergestellt, oder er wurde als Host für eine Anwendungspartition konfiguriert. Als Folge dessen hat sich seine Replikationsidentität geändert. Ein Partner hat ReplikationsÄnderungen angefordert und dabei die alte Identität verwendet. Die Anfangssequenznummer wurde angepasst.
Der Zieldomänencontroller, der der folgenden Objekt-GUID entspricht, hat Änderungen angefordert, die bei einer Aktualisierungssequenznumer beginnen sollen, die vor der Aktualisierungssequenznummer liegen, bei der der lokale Domänencontroller vom Sicherungsmedium wiederhergestellt wurde.
 
Objekt-GUID:
5e804b9e-7db7-b853-4f78-527d08dbcc28
Aktualisierungssequenznummer zur Zeit der Wiederherstellung: 11203
 
Als Folge dessen wurde der Aktualitätsvektor des Zieldomänencontrollers mit den folgenden Einstellungen konfiguriert.
 
Vorherige Datenbank-GUID: d07dcc90-d75b-4900-be7a-e55fa15622e2
Vorherige Objekt-Aktualisierungssequenznummer: 11305
Vorherige Eigenschafts-Aktualisierungssequenznummer: 11305
Neue Datenbank-GUID: 96f9eea1-8d5b-4e1b-beb7-17651d635f9d
Neue Objekt-Aktualisierungssequenznummer: 11203
Neue Eigenschafts-Aktualisierungssequenznummer: 11203

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter
http://go.microsoft.com/fwlink/events.asp.

Man sieht sehr deutlich, dass die Datenbank eine neue GUID erhält und damit der Server "neu" ist. Nur dann werden auch die Änderungen zurück repliziert.

Imaging und Tape-Backup

Für das Image muss aber irgendwo auch ausreichend Platz für das Image sein. Die meisten Imaging-Programme können ihre Daten auf lokale-, USB- oder Firewire-Festplatten, Netzwerklaufwerke oder CD/DVD-Brenner schreiben. Ein direktes Schreiben auf Bänder ist meist nicht möglich.

Für den regelmäßigen Einsatz als Sicherungsmedium des Betriebssystems eignen sich Netzwerklaufwerke am besten, da lokale Festplatten bei einem Ausfall ebenso defekt sein können und andere Medien einen manuellen Eingriff erfordern. Die Sicherung eines Image auf eine versteckte lokale Partition ist jedoch als "Ad-Hoc"-Sicherung brauchbar, wenn vor einem größeren update der aktuelle Stand außerhalb eines Zeitplans gesichert werden soll.

Ideal ist es, wenn es einen zentralen Sicherungsserver gibt, an dem auch die Bandlaufwerke angeschlossen sind. So können alle Server nahezu gleichzeitig ihr Image über das Netzwerk auf die lokalen Festplatten des Servers sichern. Dieser kann dann die wichtigen Daten zu bestimmten Zeiten auf Band auslagern. Durch die Verfügbarkeit des Images auf der Festplatte sind auch schnelle Restore-Zeiten realisierbar, ohne erst auf Bänder zu warten.

Der Ansatz eines zentralen Sicherungsservers mit ausreichend Festplattenkapazität hat auch den Vorteil, dass auch normale Sicherungen ebenfalls erst auf Festplatte als Image oder COPY erfolgen können. Die meisten Sicherungsprogramme erlauben nicht das gleichzeitige Schreiben mehrerer Quellen auf ein Bandlaufwerk.

Desaster mit RIS optimiert

Wird eine Wiederherstellung erforderlich, so stehen Sie als Administrator erst mal vor einem Server ohne Betriebssystem. Ehe Sie nun lange nach DOS-Disketten suchen oder bootfähige CDs bauen, sollten Sie den Windows RIS-Server genauer betrachten. Der RIS-Server kann nicht nur "Windows" installieren, sondern nahezu jedes beliebige System starten. Es lohnt sich daher schon, eine Bootdiskette mit Netzwerktreibern und passender AuTOEXEC.BAT entsprechend vorgefertigt auf dem Server zu hinterlegen. Die Wiederherstellung erfolgt dann sehr schnell, da die meisten Server heute schon "PXE-tauglich" sind, d.h. F12-Taste drücken, anmelden, Imagerestore starten, das Image auswählen und warten.

Je nach Größe des Image und der Leistung der beteiligten Komponenten ist ein Betriebssystem nach wenigen Minuten schon wieder funktionstüchtig.

Weitere Informationen über RIS finden Sie hier:

Weitere Links

Achten Sie bei der Auswahl ihres Produkte darauf, dass das Image "online" erfolgt. Ich denke nicht, dass Sie häufig ihren Server herunterfahren möchten, um die Partition zu sichern. Zudem sollte das Produkt Windows Server unterstützen und eine Rücksicherung unter DOS möglich sein.