22
Problem beim Sichern des Exchange 2003 auf einem DC mit Veritas BackupExec
Hallo,
ich habe einen Exchange 2003 Standard Server mit SP2 auf einem Windows 2003 SP1 Server laufen. Alle Patches und Sicherheitsupdates sind installiert. Auf einem anderen Server läuft Veritas Backup Exec, dass über Remote den Exchange sichern soll. Hierzu wurde der Veritas Remote Client vom Hauptprogramm aus auf dem Exchange installiert. Grundsätzlich funktioniert die Sicherunga uch (Es werden alle 4GB der Postfächer gesichert). Aber der Auftrag schlägt am Schluss mit folgenden Fehler fehl:
Endgültiger Fehler: 0xe000fe2d - Die Sicherungskopie dieses Elements ist fehlerhaft.
Endgültige Fehlerkategorie: Ressourcenfehler
Zusätzliche Informationen zu diesem Fehler finden Sie unter der Verknüpfung V-79-57344-65069
Was sagt mir diese Meldung? Welche Sicherungskopie meint er? Mache ich noch etwas falsch? In dem Link zur Knowledge Base bei Symantec steht nur drin, dass man den Fehler durch setzen eines Registrierungsschlüssels der verhindert, dass der Auftrag als Fehlerhaft gekennzeichnet wird, entfernen kann. Aber das kanns doch nich sein oder?
Wer hat ähnliche oder gleiche Probleme ode eine Lösung hierfür?
Schon jetzt besten Dank
Gruß
Martin
ich habe einen Exchange 2003 Standard Server mit SP2 auf einem Windows 2003 SP1 Server laufen. Alle Patches und Sicherheitsupdates sind installiert. Auf einem anderen Server läuft Veritas Backup Exec, dass über Remote den Exchange sichern soll. Hierzu wurde der Veritas Remote Client vom Hauptprogramm aus auf dem Exchange installiert. Grundsätzlich funktioniert die Sicherunga uch (Es werden alle 4GB der Postfächer gesichert). Aber der Auftrag schlägt am Schluss mit folgenden Fehler fehl:
Endgültiger Fehler: 0xe000fe2d - Die Sicherungskopie dieses Elements ist fehlerhaft.
Endgültige Fehlerkategorie: Ressourcenfehler
Zusätzliche Informationen zu diesem Fehler finden Sie unter der Verknüpfung V-79-57344-65069
Was sagt mir diese Meldung? Welche Sicherungskopie meint er? Mache ich noch etwas falsch? In dem Link zur Knowledge Base bei Symantec steht nur drin, dass man den Fehler durch setzen eines Registrierungsschlüssels der verhindert, dass der Auftrag als Fehlerhaft gekennzeichnet wird, entfernen kann. Aber das kanns doch nich sein oder?
Wer hat ähnliche oder gleiche Probleme ode eine Lösung hierfür?
Schon jetzt besten Dank
Gruß
Martin
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 34666
Url: https://administrator.de/contentid/34666
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
22 Kommentare
Neuester Kommentar
Hi.
Hast du das Doc eigentlich ganz durchgelesen?
http://support.veritas.com/docs/261457
Der beste Satz da drin für mich ist:
" After running a mailbox backup, the job completion status will show a failure with the error code description as follows:
"The backup of the item is bad."
if files that Backup Exec (tm) software believes are corrupt are encountered (Figure 1). "
Sprich: Backup Exec ist der Meinung dass ein oder mehrere Mails oder ein oder mehrere Attachments in der ExchangeDB korrupt ist. (Was aber zwangsläufig nicht heissen muss dass dies so ist)
Es kann natürlich auch sein dass 1 oder mehrere Mails bearbeitet wurden als die Sicherung lief. Dann kommt der Fehler auch.
Zur Sicherheit rate ich dir mal deine Exchange DB's zu checken (siehe http://support.microsoft.com/kb/313184/en-us )
Und du solltest auch mal testweise versuchen das Backup auf einem anderen Exchange-Testserver wieder reinzuspielen.
Wenn das alles funktioniert, dann ignoriere diese Fehlermeldungen einfach oder setze den Reg-Wert wie in der Doku beschrieben.
Ich krieg von Backup-Exec täglich Error-Meldungen bzgl. der BE-Datenbank ins Eventlog reingeschrieben.
Trotzdem geht alles, und Veritas bzw. Symantec sagt auch nur: "Ist halt einfach so."
Hast du das Doc eigentlich ganz durchgelesen?
http://support.veritas.com/docs/261457
Der beste Satz da drin für mich ist:
" After running a mailbox backup, the job completion status will show a failure with the error code description as follows:
"The backup of the item is bad."
if files that Backup Exec (tm) software believes are corrupt are encountered (Figure 1). "
Sprich: Backup Exec ist der Meinung dass ein oder mehrere Mails oder ein oder mehrere Attachments in der ExchangeDB korrupt ist. (Was aber zwangsläufig nicht heissen muss dass dies so ist)
Es kann natürlich auch sein dass 1 oder mehrere Mails bearbeitet wurden als die Sicherung lief. Dann kommt der Fehler auch.
Zur Sicherheit rate ich dir mal deine Exchange DB's zu checken (siehe http://support.microsoft.com/kb/313184/en-us )
Und du solltest auch mal testweise versuchen das Backup auf einem anderen Exchange-Testserver wieder reinzuspielen.
Wenn das alles funktioniert, dann ignoriere diese Fehlermeldungen einfach oder setze den Reg-Wert wie in der Doku beschrieben.
Ich krieg von Backup-Exec täglich Error-Meldungen bzgl. der BE-Datenbank ins Eventlog reingeschrieben.
Trotzdem geht alles, und Veritas bzw. Symantec sagt auch nur: "Ist halt einfach so."
hm, okay. Danke für die Info. Habe diesen Hinweiß wohl falsch gedeutet/überlesen.
Kann der Schattenkopie Dienst vielleicht helfen Daten zu sichern, die in Benutzung sind? ich hätte jetzt erwartet, dass Veritas den Exchange sichern kann wenn die Mailbox geöffnet ist (was ja durchaus mal vorkommen kann). Die Meldung "The backup of the item is bad" würde mir jetzt aber im ersten Moment sagen, dass ich kein funktionstüchtiges Backup einer oder mehrerer bzw. aller Mailboxen habe.
Kann der Schattenkopie Dienst vielleicht helfen Daten zu sichern, die in Benutzung sind? ich hätte jetzt erwartet, dass Veritas den Exchange sichern kann wenn die Mailbox geöffnet ist (was ja durchaus mal vorkommen kann). Die Meldung "The backup of the item is bad" würde mir jetzt aber im ersten Moment sagen, dass ich kein funktionstüchtiges Backup einer oder mehrerer bzw. aller Mailboxen habe.
Hi.
Wie haben selbst Exchange2003 SP1 und Backup Exec 9.1 am laufen.
Bei uns läuft das Backup 3mal täglich auch während den Betriebszeiten ohne Probleme, deswegen glaub ich nicht dass der Fehler bei dir auf geöffnete Dateien zurückzuführen ist. Ich sagte nur: Es kann sein.
VSS (Volume ShadowCopy Services) kannst natürlich auch verwenden. In diesem Falle ists 100%ig egal ob grad irgendwas offen oder in Bearbeitung ist.
Dazu einfach im BE unter Auswahl "Shadow Copy Services" auswählen, und die Exchange Komponenten anhaken.
Gib ne kurze Info ob der Fehler mit VSS auch noch kommt. (Würd mich interessieren)
Grüsse
Wie haben selbst Exchange2003 SP1 und Backup Exec 9.1 am laufen.
Bei uns läuft das Backup 3mal täglich auch während den Betriebszeiten ohne Probleme, deswegen glaub ich nicht dass der Fehler bei dir auf geöffnete Dateien zurückzuführen ist. Ich sagte nur: Es kann sein.
VSS (Volume ShadowCopy Services) kannst natürlich auch verwenden. In diesem Falle ists 100%ig egal ob grad irgendwas offen oder in Bearbeitung ist.
Dazu einfach im BE unter Auswahl "Shadow Copy Services" auswählen, und die Exchange Komponenten anhaken.
Gib ne kurze Info ob der Fehler mit VSS auch noch kommt. (Würd mich interessieren)
Grüsse
Hi,
für mihc klingt das nach einem entfernten User.
Habt Ihr kürzlich einen User aus der Domäne entfernt? Dann fällt Bakcup Exec das auf, denn im Sicherungsjob steht immer noch das Postfach von dem user. Hier einfach den Job öffnen, auf die Auswahl gehen, Postfächer und den Haken beim entsprechenden User entfernen.
MfG
R.Richter
für mihc klingt das nach einem entfernten User.
Habt Ihr kürzlich einen User aus der Domäne entfernt? Dann fällt Bakcup Exec das auf, denn im Sicherungsjob steht immer noch das Postfach von dem user. Hier einfach den Job öffnen, auf die Auswahl gehen, Postfächer und den Haken beim entsprechenden User entfernen.
MfG
R.Richter
Aber wenn BE die Mailbox nicht sichert, wird sie ewig im System bleiben!
Normalerweise läuft das so:
User wird gelöscht, (bzw. Mailbox vom User)
Exchange markiert die Mailbox als zu löschen
BE sichert die Mailbox beim nächsten Sicherungslauf
Exchange erkennt dass die Mailbox gesichert wurde, und die Mailbox wird endgültig gelöscht.
Normalerweise läuft das so:
User wird gelöscht, (bzw. Mailbox vom User)
Exchange markiert die Mailbox als zu löschen
BE sichert die Mailbox beim nächsten Sicherungslauf
Exchange erkennt dass die Mailbox gesichert wurde, und die Mailbox wird endgültig gelöscht.
Hallo Martin,
normalerweise listet er dir doch unten die Items auf die "fehlerhaft" sind?
Was sind da für Objekte gelistet?
Hatte das Problem schon einige Male wenn eine Mail oder irgendwas im Postfach
beschädigt war - mitunter konnte der Benutzer es auch nicht mehr öffnen.
Habe dann das Objekt gelöscht, oder löschen lassen und dann war der Fehler weg.
Wenn er eine komplette Mailbox anmeckert wäre auch denkbar dass es sich um
einen gelöschten User/Postfach handelt. Dann durch die Aufbewahrungszeit aber
noch im Store vorhanden ist. Das könntest du im Exchange Systemmanager prüfen
unterhalb des Mailbox-Stores, und das Postfach evtl. komplett löschen. Ist dort mit
einem roten X gekennzeichnet.
Gruß aus dem Badischen
Patrick
normalerweise listet er dir doch unten die Items auf die "fehlerhaft" sind?
Was sind da für Objekte gelistet?
Hatte das Problem schon einige Male wenn eine Mail oder irgendwas im Postfach
beschädigt war - mitunter konnte der Benutzer es auch nicht mehr öffnen.
Habe dann das Objekt gelöscht, oder löschen lassen und dann war der Fehler weg.
Wenn er eine komplette Mailbox anmeckert wäre auch denkbar dass es sich um
einen gelöschten User/Postfach handelt. Dann durch die Aufbewahrungszeit aber
noch im Store vorhanden ist. Das könntest du im Exchange Systemmanager prüfen
unterhalb des Mailbox-Stores, und das Postfach evtl. komplett löschen. Ist dort mit
einem roten X gekennzeichnet.
Gruß aus dem Badischen
Patrick
@ Kosh
Ja, so ganz ist das nicht richtig. Du definierst die Zeit die Exchange dieses Postfach aufbewahrt.
@Patrick
Ich stimme Dir zu. Im Fehlerprotokoll wird das Element Exakt bezeichnet. Entweder ein Anhang, eine Mail selbst oder eben das Postfach.
MfG
R.Richter
Ja, so ganz ist das nicht richtig. Du definierst die Zeit die Exchange dieses Postfach aufbewahrt.
@Patrick
Ich stimme Dir zu. Im Fehlerprotokoll wird das Element Exakt bezeichnet. Entweder ein Anhang, eine Mail selbst oder eben das Postfach.
MfG
R.Richter
Hallo,
ja es wurde im Bericht eine Ausnahme aufgeführt. In einer Mailbox wurde ein Element als beschädigt erkannt. Ausnahme heisst für mich aber, dass nur diese eine Mail in diesem Postfach nicht gesichert wurde. Der Rest müsste doch somit da sein und auch wiederherstellbar sein.
Da wir aber im Postfach keine Mail mit der Bezeichnung im Postfach gefunden haben (er hat sogar gesagt, dass das defekte Objekt im Ordner Gesendete Objekte war), konnten wir auch nichts löschen.
Gibts ne Möglichkeit das über Konsole zu reparieren? Wie kann ich nochmal manuell den Postfachbereinigungsvorgang starten?
ja es wurde im Bericht eine Ausnahme aufgeführt. In einer Mailbox wurde ein Element als beschädigt erkannt. Ausnahme heisst für mich aber, dass nur diese eine Mail in diesem Postfach nicht gesichert wurde. Der Rest müsste doch somit da sein und auch wiederherstellbar sein.
Da wir aber im Postfach keine Mail mit der Bezeichnung im Postfach gefunden haben (er hat sogar gesagt, dass das defekte Objekt im Ordner Gesendete Objekte war), konnten wir auch nichts löschen.
Gibts ne Möglichkeit das über Konsole zu reparieren? Wie kann ich nochmal manuell den Postfachbereinigungsvorgang starten?
Wie sieht es denn praktisch aus mit den Shadow Copies? Können die denn Problemlos wiederhergestellt werden?
Kann es sein dass das defekte Objekt inzwischen (seit dem letzten Backup)
gelöscht wurde? Wenn du den genauen Pfad der Fehlermeldung überprüfst
sollte das Objekt auch dort zu finden sein.
Was vielleicht noch sein könnte, dass das Objekt im Serverpapierkorb der
"gesendeten Objekte" liegt. Dies wäre dann der Fall wenn der Benutzer es
aus den Ges. Objekten gelöscht hat, es aber lt. definierter Aufbewahrungszeit
für den Mailbox-Store noch im Serverpapierkorb behalten wird.
Hier die Infos dazu: http://www.msxfaq.net/admin/dumpster.htm
Gruß
Patrick
gelöscht wurde? Wenn du den genauen Pfad der Fehlermeldung überprüfst
sollte das Objekt auch dort zu finden sein.
Was vielleicht noch sein könnte, dass das Objekt im Serverpapierkorb der
"gesendeten Objekte" liegt. Dies wäre dann der Fall wenn der Benutzer es
aus den Ges. Objekten gelöscht hat, es aber lt. definierter Aufbewahrungszeit
für den Mailbox-Store noch im Serverpapierkorb behalten wird.
Hier die Infos dazu: http://www.msxfaq.net/admin/dumpster.htm
Gruß
Patrick
hi
in einem Postfach ist eine Mail kaputt! das kommt häufiger vor, wir merken das immer wenn
wir die Postfächer mit exmerge verschieben von einem Store zu anderen.
Mach das bitte auch mal, und achte das die Fehlertoleranz auf 0 ist, falls das fehlschägt,
Toleranzwert erhöhen.
Die Sicherung von Exchangepostfäche im online Modus benutzt NICHT VSS, da es ein DB System ist und über eine einge Verwaltung verfügt.
cu
willi
in einem Postfach ist eine Mail kaputt! das kommt häufiger vor, wir merken das immer wenn
wir die Postfächer mit exmerge verschieben von einem Store zu anderen.
Mach das bitte auch mal, und achte das die Fehlertoleranz auf 0 ist, falls das fehlschägt,
Toleranzwert erhöhen.
Die Sicherung von Exchangepostfäche im online Modus benutzt NICHT VSS, da es ein DB System ist und über eine einge Verwaltung verfügt.
cu
willi
Soweit ich weis lässt sich eh nur der komplette Information Store mit VSS sichern. Postfächer werden immer online gesichert.
hi
man kann exchange mit 3 Arten sichern:
-online Db sicherung mit Logs und truncate der Logs nach fullbackup.
-online Postfachsicherun im sogenannten Bricklevelformat, es werden keine logs mit gesichert.
-eine Sicherung der geöffenten DBs auf Ebene des Betriebssystems, ist aber eine heikle Sache.
er sprach von nicht eindeutig von online Db sicherung oder von online Postfachsicherung.
cu
man kann exchange mit 3 Arten sichern:
-online Db sicherung mit Logs und truncate der Logs nach fullbackup.
-online Postfachsicherun im sogenannten Bricklevelformat, es werden keine logs mit gesichert.
-eine Sicherung der geöffenten DBs auf Ebene des Betriebssystems, ist aber eine heikle Sache.
er sprach von nicht eindeutig von online Db sicherung oder von online Postfachsicherung.
cu
hi
danke
doch lese bitte auch hier
VSS und Exchange
Exchange 2003 bringt ebenfalls eine Unterstützung für die Schattenkopien mit. Dazu bindet sich Exchange 2003 in das VSS System ein, und kann über diesen Weg angewiesen werden, die Schreibzugriffe während der Anfertigung einer Schattenkopie einzustellen und über den Weg eine konsistente Kopie der Datenbank zu ermöglichen. Denken Sie aber immer daran, dass dabei keine "echte" Kopie angelegt wird, sondern nur der aktuelle Stand des Dateisystems eingefroren wird und neue Änderungen nicht die bestehenden Blöcke verändern. Die Datenbank ist aber in diesem Fall "trotzdem" inkonsistent. Sie entspricht quasi einem System, welches im Betrieb "kopiert" wurde. Die Datenbank ist inkonsistent (Dirty Shutdown)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
und kann auch nur mit den Protokolldateien wieder konsistent gebracht werden.
Die Software, welche die Schattenkopie anfordert, muss zuerst die Liste der "Provider" erfragen und dann nicht nur das Dateisystem, sondern auch Exchange über den Start eine Schattenkopie informieren. Exchange friert dann den Store ein und wartet bis die Sicherung wieder eine Freigabe erteilt. Nach der Freigabe sollte die Sicherungsanwendung auch ein "Backup erfolgreich" melden. Erst dann erlaubt Exchange, dass der Store beendet werden kann und schneidet zusätzlich die Protokolldateien ab.
Insofern ist die Anfertigung einer Schattenkopie vergleichbar zu einem Online Backup mit Sicherung der Datenbank und Transaktionsprotokollen. Allerdings muss nach der Schattenkopie der "Schatten" natürlich noch wirklich auf ein Band oder anderweitig gesichert werden.
Bei einer Wiederherstellung werden übrigens die Informationsspeicher beendet und nach der Einspielung der alten Daten wieder gestartet. Eine Mischung von VSS-Sicherungen mit bisherigen Online-Sicherungen ist nicht möglich.
Die Funktion von Exchange finden Sie auch im Eventlog wieder
cu
willi
danke
doch lese bitte auch hier
VSS und Exchange
Exchange 2003 bringt ebenfalls eine Unterstützung für die Schattenkopien mit. Dazu bindet sich Exchange 2003 in das VSS System ein, und kann über diesen Weg angewiesen werden, die Schreibzugriffe während der Anfertigung einer Schattenkopie einzustellen und über den Weg eine konsistente Kopie der Datenbank zu ermöglichen. Denken Sie aber immer daran, dass dabei keine "echte" Kopie angelegt wird, sondern nur der aktuelle Stand des Dateisystems eingefroren wird und neue Änderungen nicht die bestehenden Blöcke verändern. Die Datenbank ist aber in diesem Fall "trotzdem" inkonsistent. Sie entspricht quasi einem System, welches im Betrieb "kopiert" wurde. Die Datenbank ist inkonsistent (Dirty Shutdown)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
und kann auch nur mit den Protokolldateien wieder konsistent gebracht werden.
Die Software, welche die Schattenkopie anfordert, muss zuerst die Liste der "Provider" erfragen und dann nicht nur das Dateisystem, sondern auch Exchange über den Start eine Schattenkopie informieren. Exchange friert dann den Store ein und wartet bis die Sicherung wieder eine Freigabe erteilt. Nach der Freigabe sollte die Sicherungsanwendung auch ein "Backup erfolgreich" melden. Erst dann erlaubt Exchange, dass der Store beendet werden kann und schneidet zusätzlich die Protokolldateien ab.
Insofern ist die Anfertigung einer Schattenkopie vergleichbar zu einem Online Backup mit Sicherung der Datenbank und Transaktionsprotokollen. Allerdings muss nach der Schattenkopie der "Schatten" natürlich noch wirklich auf ein Band oder anderweitig gesichert werden.
Bei einer Wiederherstellung werden übrigens die Informationsspeicher beendet und nach der Einspielung der alten Daten wieder gestartet. Eine Mischung von VSS-Sicherungen mit bisherigen Online-Sicherungen ist nicht möglich.
Die Funktion von Exchange finden Sie auch im Eventlog wieder
cu
willi
Hi Ihr!
Also, es war in der Tat eine defekte Mail!
Aber jetzt ist ein neues Problem da: Jeden zweiten Backup-Tag verliert Veritas beim Sichern eines Remoteservers (dem Exchange zum Beispiel) die Verbindung zum Remote Agent und bricht die Sicherung ab. Nachdem auf dem zu sichernden System der Remote Agent Dienst neu gestartet wurde, klappt wieder. Jemand ne Idee?
Also, es war in der Tat eine defekte Mail!
Aber jetzt ist ein neues Problem da: Jeden zweiten Backup-Tag verliert Veritas beim Sichern eines Remoteservers (dem Exchange zum Beispiel) die Verbindung zum Remote Agent und bricht die Sicherung ab. Nachdem auf dem zu sichernden System der Remote Agent Dienst neu gestartet wurde, klappt wieder. Jemand ne Idee?
Hi,
installiere den Dienst noch einmal mit der BE oberfläche.
MfG
R.Richter
installiere den Dienst noch einmal mit der BE oberfläche.
MfG
R.Richter
hi
ok, das mit defekten Objekten ist immer eine verflixte Sache, denn man erfährt das nur auf Umwegen.
wenn der BE Agent sich regelmäßig beendet, dann mal nach Patchen schauen. Ev auch mal neu installieren.
bitte schau mal nach bei welchen Objekten sich der beendet, kann sein das da noch mehr rottig ist.
cu
willi
ok, das mit defekten Objekten ist immer eine verflixte Sache, denn man erfährt das nur auf Umwegen.
wenn der BE Agent sich regelmäßig beendet, dann mal nach Patchen schauen. Ev auch mal neu installieren.
bitte schau mal nach bei welchen Objekten sich der beendet, kann sein das da noch mehr rottig ist.
cu
willi
Hallo,
also dein Problem besteht ganz einfach darin, dass Exchange nicht mit der Symantec Version 10.x per OFO in einem Job gesichert werden kann... also Files und Datenbank in einem, unter 9.1 hat das noch funktioniert.
Dann entsteht dieser Fehler...
Lege einen Job mit OFO an für alles andere, ohne den Exchange zu sichern.
Mache einen 2.ten Job hintendran ohne OFO der nur den Exchange sichert...
mfg
Ritchy
also dein Problem besteht ganz einfach darin, dass Exchange nicht mit der Symantec Version 10.x per OFO in einem Job gesichert werden kann... also Files und Datenbank in einem, unter 9.1 hat das noch funktioniert.
Dann entsteht dieser Fehler...
Lege einen Job mit OFO an für alles andere, ohne den Exchange zu sichern.
Mache einen 2.ten Job hintendran ohne OFO der nur den Exchange sichert...
mfg
Ritchy
Hallo Ihr,
danke für eure Beiträge.
Noch ein ganz interessanter Bug in BackupExec beim Sichern von Exchange: Wenn BackupExec mal für die Mail und Informationstores meldet "Zugriff verweigert" kann es daran liegen, dass ihr die Emailbenachrichtigung aktiviert habt. Also die MAPI bzw. SMTP Benachrichtigung deaktivieren und schon hat er wieder Zugriff...
It's a Kind of Magic
danke für eure Beiträge.
Noch ein ganz interessanter Bug in BackupExec beim Sichern von Exchange: Wenn BackupExec mal für die Mail und Informationstores meldet "Zugriff verweigert" kann es daran liegen, dass ihr die Emailbenachrichtigung aktiviert habt. Also die MAPI bzw. SMTP Benachrichtigung deaktivieren und schon hat er wieder Zugriff...
It's a Kind of Magic
Bei uns hat sich als Ursache dieses Fehlers eine völlig andere Sache herausgestellt, als dies bisher niedergeschrieben steht.
Es stimmt, dass eine defekte Mail an dem versagen des Backup Jobs schuld ist. Herauszufinden, welche Mail es ist kann sich aber als schwierig herausstellen, denn das defekte Mail wir in der Ausnahme Liste als folgt gezeigt:
WARNUNG: Datei "\\Servername\Microsoft Exchange Mailboxes\Mailbox Name [Alias] Top of Information Store Inbox OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO Outlook Message Manager (Outlook) (KEY: xxxxxxxxxxxxxxxxxxxxxxxxxx)" ist beschädigt. *(die O sind quadrate, x sind Zahlen)
Diese Datei kann nicht überprüft werden.
Diese Datei ist ein Mail welches in der Mailbox abgelegt ist wie alle anderen. Sie ist aber kein Mail, sondern eine Outlook Regel, welche in Form von Mails in der Mailbox auf dem Exchange abgelegt werden.
In der Mailbox sieht diese dann so aus:
Outlook Message Manager (Outlook) (KEY:xxxxxxxxxxxxxxxxxxxxxxxxx) *(die x sind Zahlen)
Die Regeln findet man dann meistens ziemlich bis ganz unten in der Mailbox wenn man mit dem Backup Exec rein schaut. Erkennen kann man die Regel eindeutig am zugeteilten Key. Dann einfach mal nur diese Regel Backupen und wenn der Job dann immer noch fehlschlägt, ist es ganz klar, dass diese schuld ist.
Es stimmt, dass eine defekte Mail an dem versagen des Backup Jobs schuld ist. Herauszufinden, welche Mail es ist kann sich aber als schwierig herausstellen, denn das defekte Mail wir in der Ausnahme Liste als folgt gezeigt:
WARNUNG: Datei "\\Servername\Microsoft Exchange Mailboxes\Mailbox Name [Alias] Top of Information Store Inbox OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO Outlook Message Manager (Outlook) (KEY: xxxxxxxxxxxxxxxxxxxxxxxxxx)" ist beschädigt. *(die O sind quadrate, x sind Zahlen)
Diese Datei kann nicht überprüft werden.
Diese Datei ist ein Mail welches in der Mailbox abgelegt ist wie alle anderen. Sie ist aber kein Mail, sondern eine Outlook Regel, welche in Form von Mails in der Mailbox auf dem Exchange abgelegt werden.
In der Mailbox sieht diese dann so aus:
Outlook Message Manager (Outlook) (KEY:xxxxxxxxxxxxxxxxxxxxxxxxx) *(die x sind Zahlen)
Die Regeln findet man dann meistens ziemlich bis ganz unten in der Mailbox wenn man mit dem Backup Exec rein schaut. Erkennen kann man die Regel eindeutig am zugeteilten Key. Dann einfach mal nur diese Regel Backupen und wenn der Job dann immer noch fehlschlägt, ist es ganz klar, dass diese schuld ist.
