Exchange Server 2003-Dienste für Datensicherung und Volumeschattenkopie

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 822896 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel ist eine ?ersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
822896 Exchange Server 2003 data backup and Volume Shadow Copy services
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Mithilfe des Volumeschattenkopie-Dienstes in Microsoft Windows Server 2003 können Sie Anwendungen erstellen, mit denen Microsoft Exchange Server 2003 gesichert und wiederhergestellt werden kann. Der Windows Volumeschattenkopie-Dienst stellt eine Infrastruktur bereit, die es Speicherverwaltungs- und Geschäftsprogrammen von Fremdanbietern sowie Hardwareanbietern ermöglicht, bei der Erstellung und Verwaltung von Schattenkopien zusammenzuarbeiten. Lösungen auf dieser Grundlage können mithilfe von Schattenkopien (oder Spiegelungen) eine oder mehrere Exchange Server 2003-Datenbanken sichern und wiederherstellen.

Der Volumeschattenkopie-Dienst koordiniert die Kommunikation zwischen Requestors (Sicherungsanwendungen), Writers (Anwendungen in Windows-Diensten wie Exchange Server 2003 und SQL Server 2000) und Providern (System-, Software- oder Hardwarekomponenten, die die Schattenkopien erstellen). Das Sicherungsprogramm muss einen Volumeschattenkopiedienst-Requestor enthalten, der Exchange Server 2003 erkennt, um den Volumeschattenkopie-Dienst zum Sichern von Exchange Server 2003 nutzen zu können. Da das in Windows Server enthaltene Sicherungsprogramm keinen solchen Requestor enthält, müssen Organisationen Sicherungsanwendungen von Fremdanbietern verwenden.

Auf dem Volumeschattenkopie-Dienst (VSS) basierende Sicherungsanwendungen müssen, um mit Exchange Server 2003 kompatibel zu sein, drei grundlegende Voraussetzungen erfüllen, um die Integrität und Wiederherstellbarkeit von Schattenkopiesicherungen zu gewährleisten. Wenn diese Voraussetzungen nicht erfüllt sind, erachtet Microsoft Product Support Services (PSS) die Sicherungslösung als außerhalb des Exchange VSS-Frameworks und kann dann keine Probleme im Zusammenhang mit der Sicherung und Wiederherstellung beheben. Kunden sollten sich bei den Herstellern ihrer Sicherungsanwendung informieren, ob diese die im vorliegenden Knowledge Base-Artikel aufgelisteten Voraussetzungen für die Kompatibilität mit Exchange erfüllt. Einzelheiten zu den Exchange VSS-Voraussetzungen finden Sie im Abschnitt "Weitere Informationen" in diesem Artikel.

Wie bei jeder Fremdanbieterlösung ist der Hersteller Ihrer Sicherungsanwendung der primäre Supportanbieter bei Sicherungs- und Wiederherstellungsproblemen. PSS kann Ihnen zwar helfen, Probleme mit den verfügbaren Datenbank- und Transaktionsprotokolldateien zu diagnostizieren und zu analysieren, Microsoft stellt jedoch für Fremdanbieterprodukte keine Problembehandlungs- oder Debugprozeduren bereit. Die Unterstützung durch PSS ist auf Ratschläge beschränkt, wie bei der Wiederherstellung der verfügbaren Datenbank- und Transaktionsprotokolldateien am besten vorzugehen ist.

Weitere Informationen dazu, wie VSS-basierte Lösungen durch PSS unterstützt werden, finden Sie in folgendem Artikel der Microsoft Knowledge Base:
841696 Übersicht der Microsoft-Speichersoftwarelösungen dritten unterstützen Richtlinie

Weitere Informationen

Im Folgenden wird der Sicherungsvorgang für Exchange Server 2003 mit dem Volumeschattenkopie-Dienst beschrieben:

  1. Das Sicherungsprogramm (oder der Agent) führt einen geplanten Auftrag aus.
  2. Der Requestor des Volumeschattenkopie-Dienstes im Sicherungsprogramm sendet dem Volumeschattenkopie-Dienst den Befehl, eine Schattenkopie der ausgewählten Exchange Server 2003-Speichergruppen zu erstellen.
  3. Der Volumeschattenkopie-Dienst kommuniziert mit dem Exchange Server 2003-Writer, um eine Snapshotsicherung vorzubereiten.
  4. Der Volumeschattenkopie-Dienst fordert den entsprechenden Provider auf, eine Schattenkopie des/der Speichervolumes zu erstellen, welche die Exchange Server 2003-Speichergruppe(n) enthalten.
  5. Der Volumeschattenkopie-Dienst gibt Exchange Server 2003 wieder für den normalen Betrieb frei.
  6. Der Volumeschattenkopiedienst-Requestor überprüft die Integrität des Sicherungssatzes, bevor er Exchange informiert, dass die Sicherung erfolgreich war.
Wenn z. B. der Volumeschattenkopie-Dienst von einem Exchange 2003-Sicherungsprogramm, das diesen Dienst unterstützt (d. h. einen Requestor enthält), die Aufforderung zur Erstellung einer Schattenkopie erhält, kommuniziert der Dienst mit dem Exchange Server 2003-Writer, um den Snapshot vorzubereiten. An diesem Punkt untersagt Exchange Server 2003 administrative Aktionen für die Speichergruppe, überprüft Volumeabhängigkeiten und setzt alle Schreibvorgänge in Datenbank- und Transaktionsprotokolldateien aus, sodass nur Lesezugriff gewährt wird. Daraufhin fordert der Volumeschattenkopie-Dienst den entsprechenden Storage Provider auf, die Schattenkopie für die Datenträgervolumes zu erstellen, in denen die Exchange Server 2003-Daten enthalten sind. Die Erstellung der Schattenkopie dauert gewöhnlich einige Sekunden. Diese Zeitdauer wird vom Endbenutzer praktisch nicht wahrgenommen. Wenn der Vorgang beendet ist, teilt der Volumeschattenkopie-Dienst dem Exchange Server 2003-Writer mit, dass Exchange wieder den normalen Betrieb aufnehmen kann. Das Sicherungsprogramm überprüft die Integrität der Schattenkopie und informiert dann Exchange, dass die Sicherung erfolgreich war. Nach Abschluss einer erfolgreichen Sicherung löscht Exchange die Protokolle und zeichnet den Zeitpunkt der letzten Sicherung für die Datenbank(en) auf.

Weitere Informationen zu Exchange Server 2003-Sicherungen mit Volumeschattenkopie-Diensten finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:
842066 Technet Support WebCast: Datenträger-Schattenkopie für Exchange Server 2003

Im Folgenden werden die Exchange Server 2003-Voraussetzungen beschrieben, die Schattenkopie-Sicherungsanwendungen erfüllen müssen, um die Integrität und Wiederherstellbarkeit von Exchange-Datenbanken zu gewährleisten:

Die nachfolgende Liste enthält die speziellen Anwendungs-Ereignisprotokolle, die verdeutlichen, dass die Exchange-Voraussetzungen erfüllt werden. Sicherungsanwendungen und der Exchange-Server können auch andere Ereignisse im Zusammenhang mit dem Sicherungs- und Wiederherstellungsprozess protokollieren. Die Protokollierung der folgenden Ereignisse während der Sicherung und Wiederherstellung dient als Bestätigung, dass die Exchange VSS-Voraussetzungen erfüllt sind. Derzeit gibt es kein Zertifizierungsprogramm für Fremdanbieter-Softwarelösungen, die auf Exchange ausgeführt werden. Die Kompatibilität stellt die Integrität und Wiederherstellbarkeit der Schattenkopie-Sicherungen sicher, bietet aber keine Gewähr für die Leistung oder Zuverlässigkeit der Fremdanbieterlösung.
  1. Datenbank-, Transaktionsprotokoll- und Prüfpunktdateien von Exchange dürfen ausschließlich über den Exchange Writer gesichert werden:

    Die folgenden Anwendungsereignisse werden protokolliert, wenn der Exchange Writer während Schattenkopie-Sicherungen gestartet wird.

    Typ: Informationen
    Quelle: ESE
    Kategorie: ShadowCopy
    Ereigniskennung: 2005
    Datum: 17.06.2004
    Uhrzeit: 11:40:41 Uhr
    Benutzer: Nicht zutreffend
    Computer: EXCHSERVER
    Beschreibung: Information Store (2180) Shadow copy instance 3 starting. This will be a "Backup Type"* shadow copy. (Informationsspeicher [2180] Schattenkopie-Instanz 3 wird gestartet. Es handelt sich dabei um eine "Sicherungstyp"-Schattenkopie.)

    * Dabei ist "Sicherungstyp" der Typ der durchgeführten Sicherung (Vollständig, Kopie, Inkrementell oder Differenziell).

    Typ: Informationen
    Quelle: MSExchangeIS
    Kategorie: Exchange VSS Writer
    Ereigniskennung: 9608
    Datum: 17.06.2004
    Uhrzeit: 11:40:42 Uhr
    Benutzer: Nicht zutreffend
    Computer: EXCHSERVER
    Beschreibung: Exchange VSS Snapshot hat die Vorbereitungen für den Snapshot erfolgreich abgeschlossen.

    Typ: Informationen
    Quelle: MSExchangeIS
    Kategorie: Exchange VSS Writer
    Ereigniskennung: 9610
    Datum: 17.06.2004
    Uhrzeit: 11:40:43 Uhr
    Benutzer: Nicht zutreffend
    Computer: EXCHSERVER
    Beschreibung: Exchange VSS Snapshot hat die Speichergruppen erfolgreich fixiert.

    Typ: Informationen
    Quelle: MSExchangeIS
    Kategorie: Exchange VSS Writer
    Ereigniskennung: 9612
    Datum: 17.06.2004
    Uhrzeit: 11:40:44 Uhr
    Benutzer: Nicht zutreffend
    Computer: EXCHSERVER
    Beschreibung: Exchange VSS Snapshot hat die Fixierung der Speichergruppen erfolgreich aufgehoben.

  2. Die Sicherungsanwendung muss die Integrität des Schattenkopie-Sicherungssatzes bestätigen.

    Microsoft empfiehlt (dies ist jedoch nicht obligatorisch), dass dies stattfindet, bevor die Sicherungsanwendung Exchange über den Abschluss der Sicherung informiert. Der Grund für diese Empfehlung ist, dass Exchange nach einer erfolgreichen Sicherung zwei wichtige Aufgaben ausführt:
    • Exchange aktualisiert die Header der gesicherten Datenbanken, sodass sie den letzten erfolgreichen Sicherungszeitpunkt enthalten.
    • Exchange löscht Transaktionsprotokolle aus dem Server, die nicht länger für einen Rollforward von der letzten erfolgreichen Sicherung benötigt werden.
    Wenn eine Sicherungsanwendung die Integritätsprüfung erst nach Abschluss dieser Aufgaben durchführt, ist unbedingt darauf zu achten, die letzte verifizierte Sicherung zusammen mit allen von dieser Sicherung benötigten Protokolldateien aufzubewahren. Auch wenn die Sicherung bereits als erfolgreich an Exchange gemeldet wurde, sollte die Sicherung erst als verlässlich eingestuft werden, wenn die Sicherungsanwendung die Integritätsprüfung tatsächlich abgeschlossen hat.

    Lesen Sie den Abschnitt "Durchführen der Integritätsprüfung für VSS-Sicherungen" in diesem Artikel, um ausführliche Informationen dazu zu erhalten, wie die Integritätsprüfungen durchzuführen sind und wie festgestellt werden kann, welche Datenbank- und Transaktionsprotokolldateien bis nach Abschluss dieser Prüfung aufbewahrt werden müssen.
  3. Wiederherstellungen am ursprünglichen Standort** dürfen ausschließlich mit dem Exchange Writer durchgeführt werden.

    Der Exchange Writer protokolliert während einer Wiederherstellung von Schattenkopien die folgenden Ereignisse in den Ereignisprotokollen der Anwendung.

    Typ: Informationen
    Quelle: MSExchangeIS
    Kategorie: Exchange VSS Writer
    Ereigniskennung: 9620
    Datum: 17.06.2004
    Uhrzeit: 13:49:59 Uhr
    Benutzer: Nicht zutreffend
    Computer: EXCHSERVER
    Beschreibung: Exchange VSS Snapshot hat ein Pre-Restore-Ereignis erfolgreich verarbeitet

    Typ: Informationen
    Quelle: MSExchangeIS
    Kategorie: Exchange VSS Writer
    Ereigniskennung: 9618
    Datum: 17.06.2004
    Uhrzeit: 13:59:46 Uhr
    Benutzer: Nicht zutreffend
    Computer: EXCHSERVER
    Beschreibung: Exchange VSS Snapshot hat ein Post-Restore-Ereignis erfolgreich verarbeitet

** "Ursprünglicher Standort" steht für einen Exchange-Computer mit demselben Servernamen und Dateipfad wie der Exchange-Computer, auf dem die VSS-Sicherung durchgeführt wurde.

Wiederherstellungen auf anderen Standorten können ab Exchange Server 2003 SP1 nicht mehr über den Exchange Writer durchgeführt werden. VSS-basierten Sicherungsanwendungen steht es frei, mit manuellen oder anderen programmgesteuerten Methoden Schattenkopien von Exchange-Datenbanken auf anderen Standorten wiederherzustellen.

Durchführen der Integritätsprüfung für VSS-Sicherungen

Wenn eine Datenbank über die Streaming-Sicherungs-API gesichert wird, wird jede Seite der Datenbank der Reihe nach gelesen, und die Prüfsummenintegrität jeder Seite wird während des Sicherungsprozesses geprüft. Die Prüfsummenintegrität von Transaktionsprotokolldateien wird ebenfalls vor ihrer Sicherung geprüft.

Während einer VSS-Sicherung besteht keine Möglichkeit für Exchange, jede Datenbankdatei in ihrer Gesamtheit zu lesen und ihre Prüfsummenintegrität zu verifizieren. Daher muss die Integrität der Datenbank- und Transaktionsprotokolldateien von der Sicherungsanwendung geprüft werden. Dies kann durch Ausführung von "Eseutil" erfolgen, wie am Ende dieses Dokuments beschrieben.

Wenn Sie die Prüfsummenintegrität Ihrer VSS-Sicherungen nicht prüfen, kann es passieren, dass eine beschädigte Seite in der Datenbank unentdeckt bleibt und schließlich in allen vorhandenen Sicherungen vorliegt. In diesem Fall muss die Datenbank repariert werden. Eine Reparatur der Datenbank ist mit erheblichen Ausfallzeiten verbunden und führt zumindest zu einem gewissen Datenverlust (zumindest der Daten, die auf den beschädigten Seiten waren).

Wenn für Ihre letzte VSS-Sicherung jedoch bestätigt wurde, dass sie nur fehlerfreie Seiten enthält, können Sie die beschädigten Seiten aus der Datenbank löschen, indem Sie die geprüfte Sicherung wiederherstellen und mit Transaktionsprotokollen, die seit der Durchführung der Sicherung erstellt wurden, ein Rollforward durchführen. Die hierfür anfallende Ausfallzeit ist im Normalfall erheblich kürzer als bei einer Datenbankreparatur, und mit dieser Wiederherstellungsmethode können Datenbankprobleme ohne jeglichen Datenverlust behoben werden.

Daher sollten Sie eine VSS-Sicherung erst als fehlerfrei erachten, wenn für alle darin enthaltenen Dateien die Prüfsummenintegrität verifiziert wurde.

Für die Integritätsprüfung einer Sicherung sind die nachfolgend genannten zwei Regeln einzuhalten:
  • Für Datenbankdateien: Sie müssen immer eine integritätsgeprüfte Kopie der Datenbankdateien verfügbar haben. Eine integritätsgeprüfte Sicherung ist eine Sicherung, bei der für die Datenbankdatei(en) in dem Sicherungssatz eine Prüfsummenverifizierung durchgeführt wurde.
Eine vor kurzem gesicherte Datenbank, die noch keine Prüfsummenverifizierung bestanden hat, kann nicht als gültige Sicherung erachtet werden. Sie dürfen eine zuvor verifizierte Sicherung erst verwerfen, wenn die Integrität der aktuellen Sicherung bestätigt wurde.
  • Für Transaktionsprotokolldateien: Alle Transaktionsprotokolldateien, die für die Wiederherstellung der letzten integritätsgeprüften Datenbanksicherung benötigt werden, müssen ebenfalls gesichert und auf Prüfsummenintegrität geprüft werden.
Diese Transaktionsprotokolle enthalten zumindest den inklusiven Bereich der Protokolldateien, die im Log Required-Feld im Header jeder Datenbank in der letzten verifizierten Sicherung aufgelistet sind. Wenn diese Protokolldateien nicht verfügbar sind, kann die Datenbank nach der Wiederherstellung nicht bereitgestellt werden.

Wichtig: Diese Voraussetzung gilt für die letzte integritätsgeprüfte Sicherung, nicht für die letzte durchgeführte Sicherung. Die letzte Sicherung gilt erst als gültige Sicherung, wenn die Prüfsummenverifizierung bestanden wurde.

Optional können Sie auch die zusätzlichen Protokolle aufbewahren, die für einen vollständigen Rollforward der Datenbank nach der Wiederherstellung von einer Datenbanksicherung erforderlich sind. Dies sind alle Transaktionsprotokolle in ununterbrochener Folge, beginnend mit der niedrigsten Log Required-Datei bis zum jüngsten erstellten Transaktionsprotokoll, das aus dem Exchange-Server gelöscht wurde. Detaillierte Beispiele und Erklärungen dieses Sachverhalts werden nachfolgend bereitgestellt.

Die Aufbewahrung von Transaktionsprotokollen über die in den Log Required-Bereichen aufgelisteten hinaus ist insofern optional, als dies nicht unbedingt erforderlich ist, um eine gesicherte Datenbank erfolgreich wiederherzustellen und bereitzustellen. Wenn Sie jedoch nicht alle diese Protokolle aufbewahren, gehen bei einer Wiederherstellung von der Sicherung alle Änderungen in der Datenbank nach dem Sicherungszeitpunkt verloren. Microsoft empfiehlt nachdrücklich, nicht nur die für die Wiederherstellung und Bereitstellung einer gesicherten Datenbank erforderlichen Transaktionsprotokolle aufzubewahren, sondern auch alle nachfolgenden Transaktionsprotokolle, die für ein Rollforward der Datenbank ohne Datenverlust benötigt werden.

Bestimmen, welche Transaktionsprotokolldateien benötigt werden

Wenn eine Exchange-Datenbank gesichert wird, während sie online ist, wird immer mindestens eine Transaktionsprotokolldatei mitgesichert. Dies erfolgt unabhängig davon, ob Sie die Streaming-Sicherungs-API oder die VSS-Sicherungs-API verwenden.

Nach der Wiederherstellung einer Onlinesicherung müssen Informationen aus den Transaktionsprotokollen auf die Datenbank angewendet ("aufgespielt") werden, bevor die Datenbank wieder bereitgestellt werden kann. Das Log Required-Feld in jedem Datenbankheader zeichnet die Sequenznummern (Erzeugungsnummern) des Bereichs von Transaktionsprotokolldateien auf, die erneut auf die Datenbank aufgespielt werden müssen.

Wenn das Log Required-Feld den Wert 0-0 enthält, bedeutet dies, dass die Datenbank bereitgestellt werden kann, ohne dass zusätzliche Transaktionsprotokolldaten aufgespielt werden müssen. Der Log Required-Wert ist nur zu einem einzigen Zeitpunkt 0-0: nachdem die Datenbank in einen Zustand des ordnungsgemäßen Herunterfahrens ("Clean Shutdown") gebracht wurde. Während eine Datenbank ausgeführt wird, zeichnet das Log Required-Feld immer den Bereich der Transaktionsprotokolle auf, die noch nicht auf die Datenbank angewendet wurden. Dieser Bereich wird fortlaufend aktualisiert.

Eine online gesicherte Datenbank hat immer einen Log Required-Bereich ungleich Null, und diese Protokolle müssen zusammen mit der Datenbank gesichert werden. Wenn diese Protokolle nach der Wiederherstellung nicht verfügbar sind, kann die Datenbank nicht bereitgestellt werden. (Sie können die Datenbank reparieren, wenn die erforderlichen Protokolle nicht auffindbar sind, aber es ist nicht garantiert, dass die Reparatur erfolgreich sein wird. Außerdem ist eine Reparatur fast immer mit einem gewissen Datenverlust verbunden, selbst wenn dies nur die Daten in den fehlenden Protokollen sind.)

Wenn Sie die im Exchange VSS Writer enthaltene Streaming-Sicherungs-API oder VSS-Sicherungs-API verwenden, werden für die Bereitstellung einer Datenbank erforderliche Protokolldateien automatisch mit der Datenbank gesichert. Wenn Sie nur die Log Required-Dateien wieder aufspielen, wird die Datenbank bis zu dem Zeitpunkt wiederhergestellt, zu dem die Sicherung abgeschlossen wurde. Wenn Sie einen Rollforward der Datenbank über diesen Punkt hinaus machen möchten, müssen Sie auch die nach dem Abschluss der Sicherung generierten Protokolldateien aufspielen.

Für einen vollständigen Rollforward der Datenbank von einer bestimmten Sicherung aus müssen Sie alle Protokolldateien in ununterbrochener Folge beginnend vom niedrigsten Protokoll im Log Required-Bereich bis zur letzten generierten Protokolldatei in der Speichergruppe der Datenbank aufbewahren. Wenn ein beliebiges Protokoll in dieser Reihe fehlt oder beschädigt ist, ist der Rollforward nur bis zu dem letzten fehlerfreien Protokoll vor der fehlenden oder beschädigten Datei möglich.

Wenn Sie also eine Wiederherstellung von einer Sicherungskopie ohne Datenverlust durchführen möchten, müssen Sie einwandfreie Kopien aller Transaktionsprotokolldateien ab Ihrer letzten verifizierten fehlerfreien Datenbanksicherung verfügbar haben.

Löschen von Transaktionsprotokollen

Wenn Transaktionsprotokolle nicht von einem Exchange-Server gelöscht werden, sammeln sie sich immer weiter an, bis sie den gesamten verfügbaren Speicherplatz belegen. Daher unterstützen sowohl die Streaming- als auch die VSS-Sicherung-API das Löschen von Transaktionsprotokolldateien nach Abschluss einer normalen oder inkrementellen Sicherung. Protokolldateien, die älter sind als die zum Wiederherstellen der jüngsten Sicherung benötigten, werden automatisch vom Server gelöscht, nachdem die Sicherungsanwendung Exchange informiert hat, dass die Sicherung erfolgreich abgeschlossen wurde.

Mit der Streaming-API erfolgt die Prüfsummenverifizierung der Datenbank während dem Sicherungsprozess. Wenn eine Sicherung abgeschlossen ist, hat eine Prüfung auf physische Integrität der kompletten Datenbank und der erforderlichen Protokolldateien stattgefunden. Mit der VSS-API kann die Prüfsummenverifizierung nicht als Teil des eigentlichen Sicherungsprozesses durchgeführt werden. Der Hersteller muss die physische Integrität der Datenbank unabhängig vom Sicherungsprozess überprüfen. Dies kann mit "Eseutil" erfolgen, und zwar entweder bevor oder nachdem Exchange informiert wurde, dass die Sicherung abgeschlossen wurde.

Wenn die Prüfsummenverifizierung vor dem Abschluss der Sicherung erfolgt, und es wird ein Problem im Sicherungssatz erkannt, kann Exchange anschließend informiert werden, dass die Sicherung fehlgeschlagen ist. Dadurch wird verhindert, dass Exchange Protokolldateien vom Server löscht.

Wenn die Prüfsummenverifizierung erfolgt, nachdem Exchange über den Abschluss der Sicherung informiert wurde, löscht Exchange ältere Protokolldateien vom Server. Einige dieser Protokolldateien wurden möglicherweise für einen Rollforward von einer vorherigen fehlerfreien Sicherung benötigt. Wenn Sie nicht bereits Kopien dieser Protokolle erstellt haben, ist kein vollständiger Rollforward mehr möglich.

Microsoft empfiehlt daher (dies ist jedoch nicht obligatorisch), dass die Prüfsummenverifizierung für eine VSS-Sicherung durchgeführt wird, bevor die Sicherungsanwendung Exchange über den Abschluss der Sicherung informiert. Wenn die Prüfsummenverifizierung erst nach dem Abschluss der Sicherung erfolgt, muss die Sicherungsanwendung sicherstellen, dass Kopien aller vom Server gelöschten Transaktionsprotokolldateien erstellt wurden, es sei denn, Sie legen keinen Wert auf einen vollständigen Rollforward.

In den meisten Fällen stehen alle Transaktionsprotokolle, die für den Rollforward einer VSS-Sicherung benötigt werden, in dem Satz von Protokolldateien zur Verfügung, die mit der vorangegangenen Sicherung gespeichert wurden (zusammen mit den mit der aktuellen Sicherung gespeicherten Dateien). Kunden sollten sich jedoch vergewissern, dass dies der Fall ist, wenn Sie die Lösung eines bestimmten Herstellers in Betracht ziehen.

Wiederherstellen nicht verifizierter Sicherungen

In manchen Fällen kann es zu schwerwiegenden Fehlern kommen, die eine Wiederherstellung erforderlich machen, bevor die Prüfsummenverifizierung für eine kürzlich erfolgte Sicherung abgeschlossen ist. In solchen Fällen empfiehlt Microsoft, eine ältere verifizierte Sicherung wiederherzustellen und mit dieser Sicherung einen Rollforward durchzuführen, statt sich auf eine nicht verifizierte Sicherung zu verlassen.

Möglicherweise bestehen bei Ihnen jedoch Service-Level-Vereinbarungen, die es erfordern, dass Daten schneller wiederhergestellt werden als dies von der vorangegangenen Sicherung möglich ist. In diesen Fällen ist die Wiederherstellung der nicht verifizierten Sicherung möglicherweise die bessere Option, solange Sie eine vorherige verifizierte Sicherung und alle Protokolldateien, die für einen vollständigen Rollforward von dieser Sicherung benötigt werden, aufbewahren. Wenn diese Voraussetzungen erfüllt sind, können Sie immer noch einen Rollforward von einer bekannt fehlerfreien Sicherung durchführen, falls sich die letzte Sicherung als fehlerhaft herausstellen sollte.

Überprüfen der Snapshot-Konsistenz

Der VSS Requestor muss die Snapshot-Konsistenz überprüfen, indem er für die Datenbank und die Protokolldateien "Eseutil.exe" mit den entsprechenden Optionen (siehe folgende Tabelle) ausführt. Der VSS Requestor muss verifizieren, dass alle zurückgegebenen ERRORLEVEL nicht negativ sind. Geben Sie nach abgeschlossener Ausführung von "Eseutil.exe" echo %errorlevel% in die Befehlszeile ein, um den ERRORLEVEL zu sehen. Ein negativer ERRORLEVEL bedeutet, dass die Dateien beschädigt sind. Bevor der VSS Requestor BackupComplete aufruft, muss er sicherstellen, dass der Status der Sicherungskomponente im Sicherungskomponenten-Dokument (Backup Component Document) das Ergebnis der Konsistenzprüfung widerspiegelt. Das heißt, dass der Status der Sicherungskomponente FALSE sein sollte, wenn eine Beschädigung gefunden wird, und TRUE sein sollte, wenn keine Beschädigung gefunden wird. Die Verifizierung der Snapshot-Konsistenz ist zwingend erforderlich, damit die Lösung vom Exchange-Team unterstützt wird.

Die folgende Tabelle zeigt die Kombination der Integritätsprüfungen für jeden Sicherungstyp.
Tabelle minimierenTabelle vergrößern
Dateityp \ SicherungstypVollst. SicherungKopie-SicherungInkrementelle SicherungDifferenzielle Sicherung
.edb"eseutil /k /i""eseutil /k /i"n. zutr.n. zutr.
.log"eseutil /k" *"eseutil /k" *"eseutil /k" **"eseutil /k" **
.stmn. zutr.n. zutr.n. zutr.n. zutr.
.chkn. zutr.n. zutr.n. zutr.n. zutr.

Aufgrund der Snapshot-Beschaffenheit von VSS-Sicherungen erhält JET keine Möglichkeit, auf alle Seiten zuzugreifen, um die nötigen Konsistenzprüfungen durchzuführen. Daher muss der VSS Requestor die Snapshot-Konsistenz gewährleisten.

* Alle Protokolldateien mit einer Protokollerzeugungsnummer, die gleich oder größer als die Prüfpunkt-Protokolldatei ist, werden benötigt, um eine Snapshot-Datenbank wiederherzustellen. Falls vorhanden, wird auch die aktuelle Protokolldatei ("Enn.log") für die Wiederherstellung der Datenbank benötigt. Wenn eine der erforderlichen Protokolldateien die Konsistenzprüfung nicht besteht, muss der Requestor sicherstellen, dass der Status der Sicherungskomponente auf FALSE gesetzt ist, bevor BackupComplete aufgerufen wird. Führen Sie zum Ermitteln der Prüfpunkt-Protokolldatei "Eseutil.exe" für die Snapshot-Prüfpunktdatei aus und durchsuchen Sie die Ausgabe nach dem Begriff "Checkpoint:" Beispielsweise zeigt "c:\Eseutil.exe /mk E01.chk" Folgendes an:
Checkpoint:  (0x20,9D,187)
wobei 0x20 die Protokollerzeugungsnummer der Prüfpunkt-Protokolldatei ist.

In diesem Beispiel müssen alle Protokolldateien einschließlich "E0100020.log" und höher unbeschädigt sein, um die Snapshot-Datenbank wiederherzustellen, auch wenn die Datenbank selbst bereits die physische Konsistenzprüfung bestanden haben sollte.

** Alle Protokolldateien in einem Inkrementellen oder Differenziellen Sicherungssatz sind für die Datenbankwiederherstellung erforderlich. Die Konsistenz einer kompletten Protokollfolge kann überprüft werden, indem Eseutil für das Protokolldateipräfix ausgeführt wird. Beispielsweise werden mit "Eseutil /k E01" Konsistenzprüfungen für alle Dateien des Formats "E01xxxxx.log" unter einem bestimmten Pfad durchgeführt.

Eigenschaften

Artikel-ID: 822896 - Geändert am: Montag, 3. Dezember 2007 - Version: 8.3
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange Server 2003 Standard Edition, wenn verwendet mit:
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
    • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
    • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
    • Microsoft Windows Server 2003, Web Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Keywords: 
kbtshoot KB822896
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com