33
Die Konsistenzprüfung des Snapshot des Microsoft Exchange-Transaktionsprotokolls Logs ist fehlgeschlagen
SBS 2011 und Symantec BackUp Exec Version 14.0.1798
Hallo erst mal
Die Datensicherung lief immer ohne Probleme, seit einem Umzug. Also der Server wurde herunter gefahren, wurde in den Serverschrank gestellt und hochgefahren.
Seit dem bekomme ich immer wieder die Fehlermeldung:
Die Konsistenzprüfung des Snapshot der Microsoft Exchange-Datenbank Database war erfolgreich.
V-79-65535-65535 - Konsistenzprüfung von Exchange-Objekten ist für Database fehlgeschlagen. Weitere Details finden Sie im Ereignisprotokoll.
WARNUNG: "\\KGASERVER1.kga-bayreuth.local\Microsoft Information Store\Mailbox Database\Database" ist beschädigt. Dateiprüfung nicht möglich.
Die Konsistenzprüfung des Snapshot des Microsoft Exchange-Transaktionsprotokolls Logs ( E0000000002.log - E000000000B.log ) ist fehlgeschlagen.
Überprüfen Sie, ob im online geschalteten Transaktionsprotokoll möglicherweise Daten beschädigt wurden.
Habe jetzt einmal die Umlaufprotokollierung aktiviert und wieder abgestellt.
Gleiche Fehler wieder!
Habe wieder Bereitstellung angehalten, sämtliche Logfiles verschoben. Umlaufprotokollierung aktiviert, Bereitstellung eingebunden, gewartet, Bereitstellung aufgehoben, Umlaufprottokolierung deaktiviert, Bereitstellung eingebunden, alles ohne Fehler.
Aber bei der Vollsicherung wieder den Fehler!
Eseutil sagt clean Shutdown und alles ok, nur BackUp Exec meldet immer wieder diesen Fehler!
Es sind auch nur neu erstellte Logfiles vorhanden.
Fällt euch irgendwas ein was ich noch tun könnte?
Hallo erst mal
Die Datensicherung lief immer ohne Probleme, seit einem Umzug. Also der Server wurde herunter gefahren, wurde in den Serverschrank gestellt und hochgefahren.
Seit dem bekomme ich immer wieder die Fehlermeldung:
Die Konsistenzprüfung des Snapshot der Microsoft Exchange-Datenbank Database war erfolgreich.
V-79-65535-65535 - Konsistenzprüfung von Exchange-Objekten ist für Database fehlgeschlagen. Weitere Details finden Sie im Ereignisprotokoll.
WARNUNG: "\\KGASERVER1.kga-bayreuth.local\Microsoft Information Store\Mailbox Database\Database" ist beschädigt. Dateiprüfung nicht möglich.
Die Konsistenzprüfung des Snapshot des Microsoft Exchange-Transaktionsprotokolls Logs ( E0000000002.log - E000000000B.log ) ist fehlgeschlagen.
Überprüfen Sie, ob im online geschalteten Transaktionsprotokoll möglicherweise Daten beschädigt wurden.
Habe jetzt einmal die Umlaufprotokollierung aktiviert und wieder abgestellt.
Gleiche Fehler wieder!
Habe wieder Bereitstellung angehalten, sämtliche Logfiles verschoben. Umlaufprotokollierung aktiviert, Bereitstellung eingebunden, gewartet, Bereitstellung aufgehoben, Umlaufprottokolierung deaktiviert, Bereitstellung eingebunden, alles ohne Fehler.
Aber bei der Vollsicherung wieder den Fehler!
Eseutil sagt clean Shutdown und alles ok, nur BackUp Exec meldet immer wieder diesen Fehler!
Es sind auch nur neu erstellte Logfiles vorhanden.
Fällt euch irgendwas ein was ich noch tun könnte?
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: 201679
Url: https://administrator.de/forum/die-konsistenzpruefung-des-snapshot-des-microsoft-exchange-transaktionsprotokolls-logs-ist-fehlgeschlagen-201679.html
Ausgedruckt am: 23.12.2024 um 11:12 Uhr
33 Kommentare
Neuester Kommentar
Hi,
wie ist der Virenschutz konfiguriert auf der Kiste?
Lies Dir das mal durch: http://technet.microsoft.com/de-de/library/bb332342.aspx
Gruß
Marcus
wie ist der Virenschutz konfiguriert auf der Kiste?
Lies Dir das mal durch: http://technet.microsoft.com/de-de/library/bb332342.aspx
Gruß
Marcus
Hallo,
So ich war jetzt kurz mal dort und habe nach gesehen.
Also der Kaspersky war so eingestellt das der Ordner wo die Datenbank und die Log-Datein enthalten sind, nicht untersucht wird.
Die Datenbank liegt nicht auf C, sondern auf dem Datenlaufwerk D.
Habe jetzt trotzdem mal den Überordner einschließlich Unterordner nochmal in die Ausnahmen mit aufgenommen.
BackUp Exec ist laut LifeUpdate auf dem neuesten Stand.
Habe gerade nochmals kurz die Umlaufprotokollierung aktiviert und wieder deaktiviert umd die alten Protokolle zu löschen, heute Abend läuft wieder die Vollsicherung.
Gruß Gerald
So ich war jetzt kurz mal dort und habe nach gesehen.
Also der Kaspersky war so eingestellt das der Ordner wo die Datenbank und die Log-Datein enthalten sind, nicht untersucht wird.
Die Datenbank liegt nicht auf C, sondern auf dem Datenlaufwerk D.
Habe jetzt trotzdem mal den Überordner einschließlich Unterordner nochmal in die Ausnahmen mit aufgenommen.
BackUp Exec ist laut LifeUpdate auf dem neuesten Stand.
Habe gerade nochmals kurz die Umlaufprotokollierung aktiviert und wieder deaktiviert umd die alten Protokolle zu löschen, heute Abend läuft wieder die Vollsicherung.
Gruß Gerald
Hallo,
das gleiche wieder!
Die Konsistenzprüfung des Snapshot des Microsoft Exchange-Transaktionsprotokolls Logs ( E000000008D.log - E00000000AE.log )ist fehlgeschlagen.
Gibt es Möglichkeiten diese Logfiles zu prüfen?
Den wenn ich die so ansehe, kann ich da nichts erkennen. Es ist zwar ein bisschen was lesbar, aber der Rest ist so ASCII!
Oder kann es sein das der Snapshot defekt ist und die eigentlichen Logfiles OK? Geht doch nicht, oder?
Ich denk schon über ein paar Ecken und vielleicht ist die Lösung so nah!
Also, eseutil.exe /mh Datenbank sagt das alles ok ist. Bei State steht Clean Shutdown, da sind doch die T-protokolle mit geprüft. Weil es steht nichts darin das T-Protokolle noch nicht verarbeitet worden sind. So müsste doch auf Exchange-Seite her alles ok sein?
Nur warum meckert dann BackUpExec?
Oder habe ich da einen Punkt übersehen?
Gruß aus dem Fichtelgebirge
Gerald
das gleiche wieder!
Die Konsistenzprüfung des Snapshot des Microsoft Exchange-Transaktionsprotokolls Logs ( E000000008D.log - E00000000AE.log )ist fehlgeschlagen.
Gibt es Möglichkeiten diese Logfiles zu prüfen?
Den wenn ich die so ansehe, kann ich da nichts erkennen. Es ist zwar ein bisschen was lesbar, aber der Rest ist so ASCII!
Oder kann es sein das der Snapshot defekt ist und die eigentlichen Logfiles OK? Geht doch nicht, oder?
Ich denk schon über ein paar Ecken und vielleicht ist die Lösung so nah!
Also, eseutil.exe /mh Datenbank sagt das alles ok ist. Bei State steht Clean Shutdown, da sind doch die T-protokolle mit geprüft. Weil es steht nichts darin das T-Protokolle noch nicht verarbeitet worden sind. So müsste doch auf Exchange-Seite her alles ok sein?
Nur warum meckert dann BackUpExec?
Oder habe ich da einen Punkt übersehen?
Gruß aus dem Fichtelgebirge
Gerald
Hallo,
hast Du schon sowohl die HDD wo die Protokolle liegen als auch die HDD wohin gesichert wird mit chkdsk überprüft?
Da sich der Name immer ändert wird da was faul sein.
Wenn Du über Netzwerksicherst, kann auch eine fehlerhafte Netzwerkverbindung daten beschädigen.
Ich vermute mal, du hast die Verifizierung der Datensicherung drin.
Sicherst Du mit BE oder BESR? Wird eine Onlinesicherung vom Exhcnage gemacht, oder wird ein Image der Partition gezogen?
Von den HDDs auch die SMART-Werte prüfen, wenn defekte Sektoren da sind ist das nicht so toll (vor chkdsk prüfen)
Gruß
Chonta
hast Du schon sowohl die HDD wo die Protokolle liegen als auch die HDD wohin gesichert wird mit chkdsk überprüft?
Da sich der Name immer ändert wird da was faul sein.
Wenn Du über Netzwerksicherst, kann auch eine fehlerhafte Netzwerkverbindung daten beschädigen.
Ich vermute mal, du hast die Verifizierung der Datensicherung drin.
Sicherst Du mit BE oder BESR? Wird eine Onlinesicherung vom Exhcnage gemacht, oder wird ein Image der Partition gezogen?
Von den HDDs auch die SMART-Werte prüfen, wenn defekte Sektoren da sind ist das nicht so toll (vor chkdsk prüfen)
Gruß
Chonta
Vielleicht helfen diese beiden?
http://www.symantec.com/business/support/index?page=content&id=TECH ...
http://www.symantec.com/business/support/index?page=content&id=TECH ...
Ansonsten würde ich mal testweise das AOFO für den Job deaktivieren.
http://www.symantec.com/business/support/index?page=content&id=TECH ...
http://www.symantec.com/business/support/index?page=content&id=TECH ...
Ansonsten würde ich mal testweise das AOFO für den Job deaktivieren.
Zitat von @Chonta:
Hallo,
hast Du schon sowohl die HDD wo die Protokolle liegen als auch die HDD wohin gesichert wird mit chkdsk überprüft?
Da sich der Name immer ändert wird da was faul sein.
Wenn Du über Netzwerksicherst, kann auch eine fehlerhafte Netzwerkverbindung daten beschädigen.
Ich vermute mal, du hast die Verifizierung der Datensicherung drin.
Sicherst Du mit BE oder BESR? Wird eine Onlinesicherung vom Exhcnage gemacht, oder wird ein Image der Partition gezogen?
Von den HDDs auch die SMART-Werte prüfen, wenn defekte Sektoren da sind ist das nicht so toll (vor chkdsk prüfen)
Gruß
Chonta
Hallo,
hast Du schon sowohl die HDD wo die Protokolle liegen als auch die HDD wohin gesichert wird mit chkdsk überprüft?
Da sich der Name immer ändert wird da was faul sein.
Wenn Du über Netzwerksicherst, kann auch eine fehlerhafte Netzwerkverbindung daten beschädigen.
Ich vermute mal, du hast die Verifizierung der Datensicherung drin.
Sicherst Du mit BE oder BESR? Wird eine Onlinesicherung vom Exhcnage gemacht, oder wird ein Image der Partition gezogen?
Von den HDDs auch die SMART-Werte prüfen, wenn defekte Sektoren da sind ist das nicht so toll (vor chkdsk prüfen)
Gruß
Chonta
Hallo,
entschuldige das ist ein Server, die Partition D liegt als RAID5 auf mehreren Platten und diese sind OK und ein 3/4 Jahr alt.
Der Name ändert sich, weil durch die Aktivierung der Umlaufprotokollierung alle übernommenen Protokolle automatisch gelöscht werden und ein Umlaufprotokoll erstellt wird! Durch das deaktivieren wird dann dieses Umlaufprotokoll auch wieder gelöscht und neue normale Protokolle angelegt.
Gesichert wird auf Bandlaufwerk, da gibt es kein Checkdisk
Ja klar wird verifiziert.
Mit was ich sichere, steht doch oben schon, aber Backup Exec Small Business Edition
Version 14.0.1798.
Was ist BESR?
Ja es wird eine Onlinesicherung gemacht mit AOFO und automatischer Wahl des Snapshotverfahrens.
Wie kann ich SMART Werte einer einzelnen Platte aus einem RAID 5 auslesen? Windows sieht doch nur eine Platte? Normalerweise regelt das der RAID Controller, da werden zu häufige Fehler oder Ausfall durch eine rote LED angezeigt, habe ich auf jeden Fall mal wo gelesen.
Das ganze ist auf einem "HP ProLiant ML350 G6"
Laufwerk C hat 49% freien Platz und Laufwerk D hat 84% freien Platz, also auch nicht voll. Der ganze Server ist mit Windows Small Business Server 2011 Standard erst im März installiert worden und seit Juli erst im Einsatz!
Die Sicherung hat seit Juli täglich funktioniert, bis auf wenige male mit einem defekten Band!
Hallo,
BESR ist Symantec Bacup Exec Systemrecovery.
Die Smartwerde der Platten sollte Dir der RAID-Controller geben können.
Ich würde zum Test mal eine Sicherung auf einer externen HDD oder einem Nezlaufwerk versuchen um das Bakcupzeil als Fehlerquelle auszuschließen.
Ein geplantes chkdsk für den Bootvorgang wäre auch ok.
Was die Transaktionsprotokolle angeht, die sollten wenn überhaupt vom Bakcupprogramm nach erfolgreicher Sicherung gelöscht werden und nicht anders.
Kann die Windowseigene Sicherung den Exchange richtig wegsichern oder meckert die auch rum?
Gruß
Chonta
BESR ist Symantec Bacup Exec Systemrecovery.
Die Smartwerde der Platten sollte Dir der RAID-Controller geben können.
Ich würde zum Test mal eine Sicherung auf einer externen HDD oder einem Nezlaufwerk versuchen um das Bakcupzeil als Fehlerquelle auszuschließen.
Ein geplantes chkdsk für den Bootvorgang wäre auch ok.
Was die Transaktionsprotokolle angeht, die sollten wenn überhaupt vom Bakcupprogramm nach erfolgreicher Sicherung gelöscht werden und nicht anders.
Kann die Windowseigene Sicherung den Exchange richtig wegsichern oder meckert die auch rum?
Gruß
Chonta
Zitat von @Onitnarat:
Vielleicht helfen diese beiden?
http://www.symantec.com/business/support/index?page=content&id=TECH ...
http://www.symantec.com/business/support/index?page=content&id=TECH ...
Ansonsten würde ich mal testweise das AOFO für den Job deaktivieren.
Vielleicht helfen diese beiden?
http://www.symantec.com/business/support/index?page=content&id=TECH ...
http://www.symantec.com/business/support/index?page=content&id=TECH ...
Ansonsten würde ich mal testweise das AOFO für den Job deaktivieren.
Hallo,
also das was in Link 1 steht habe ich schon gemacht und Link 2 trifft nicht zu.
AOFO deaktivieren, kann Backup Exec dann überhaupt richtig sichern?
Ich habe mich eher gefragt ob ich die Konsistenzprüfung vor dem Update mal abschalte, wie wichtig ist diese?
Zitat von @Chonta:
Hallo,
BESR ist Symantec Bacup Exec Systemrecovery.
Die Smartwerde der Platten sollte Dir der RAID-Controller geben können.
Ich würde zum Test mal eine Sicherung auf einer externen HDD oder einem Nezlaufwerk versuchen um das Bakcupzeil als
Fehlerquelle auszuschließen.
Ein geplantes chkdsk für den Bootvorgang wäre auch ok.
Was die Transaktionsprotokolle angeht, die sollten wenn überhaupt vom Bakcupprogramm nach erfolgreicher Sicherung
gelöscht werden und nicht anders.
Kann die Windowseigene Sicherung den Exchange richtig wegsichern oder meckert die auch rum?
Hallo,
BESR ist Symantec Bacup Exec Systemrecovery.
Die Smartwerde der Platten sollte Dir der RAID-Controller geben können.
Ich würde zum Test mal eine Sicherung auf einer externen HDD oder einem Nezlaufwerk versuchen um das Bakcupzeil als
Fehlerquelle auszuschließen.
Ein geplantes chkdsk für den Bootvorgang wäre auch ok.
Was die Transaktionsprotokolle angeht, die sollten wenn überhaupt vom Bakcupprogramm nach erfolgreicher Sicherung
gelöscht werden und nicht anders.
Kann die Windowseigene Sicherung den Exchange richtig wegsichern oder meckert die auch rum?
Also wegen SMART Werte habe ich nichts gefunden.
Leider habe ich kein Netzlaufwerk an diesem Ort das groß genug ist für die Sicherung.
Ein Checkdisk kann ich für den nächsten Bootvorgang einplanen, Server wird ein mal im Monat an einen Sonntag automatisch neu gestartet.
Das Windowseigene Backupprogramm kann doch nicht mehr auf Band sichern!
Gruß
Chonta
Okay, war nur das Ergebnis meiner Recherche.
AOFO deaktivieren, kann Backup Exec dann überhaupt richtig sichern?
Ja, sollte es schon.
Ich habe mich eher gefragt ob ich die Konsistenzprüfung vor dem Update mal abschalte, wie wichtig ist diese?
Wie wichtig sie ist musst Du wissen, nötig ist sie nicht. Testweise kannst Du sie ja deaktivieren.
OK, ich werde AOFO mal versuchsweise abschalten.
Aber ist das nicht für die Sicherung der offenen Dateien da und wird dann Exchange gesichert? Den die Exchange Datenbank ist doch in diesem Moment offen?
Gruß Gerald
Aber ist das nicht für die Sicherung der offenen Dateien da und wird dann Exchange gesichert? Den die Exchange Datenbank ist doch in diesem Moment offen?
Gruß Gerald
Einerseits ja und andererseits nein, der Exchange wird ja von BackupExec per VSS gesichert. Da fällt mir gerade ein, sicherst Du die EDB eigentlich zusätzlich als Datei? Falls ja, dann nimm sie mal bitte raus. Mit der, auf Dateibasis, gesicherten EDB kannst Du eh wenig bis gar nichts anfangen.
Moin Jerry95,
du könntest bei der Auswahl des Snapshot-Providers auf MS Volume Copy stellen und testen.
Das hat schon öfter geholfen.
Auch kannst du beruhigt die Ordner, die die Exchange-Dateien beinhalten, aus der Sicherung herausnehmen, so du den Exchange-Agenten nutzt und dort die Datenbanken unter Microsoft Information Store ausgewählt hast.
Überprüfe bitte deine Einstellungen im Exchange-Agenten, ob diese alle richtig sind.
du könntest bei der Auswahl des Snapshot-Providers auf MS Volume Copy stellen und testen.
Das hat schon öfter geholfen.
Auch kannst du beruhigt die Ordner, die die Exchange-Dateien beinhalten, aus der Sicherung herausnehmen, so du den Exchange-Agenten nutzt und dort die Datenbanken unter Microsoft Information Store ausgewählt hast.
Überprüfe bitte deine Einstellungen im Exchange-Agenten, ob diese alle richtig sind.
Hallo,
ok, also werde ich nun AOFO mal abschalten, die beiden EDB-Dateien (Mailbox und Public)aus der Sicherung heraus nehmen.
Dann noch versuchen den Snapshot Provider fest auf MS Volume Copy zu stellen.
Mittwoch bin ich wieder vor Ort.
Gruß Gerald
ok, also werde ich nun AOFO mal abschalten, die beiden EDB-Dateien (Mailbox und Public)aus der Sicherung heraus nehmen.
Dann noch versuchen den Snapshot Provider fest auf MS Volume Copy zu stellen.
Mittwoch bin ich wieder vor Ort.
Gruß Gerald
Zitat von @Jerry95:
ok, also werde ich nun AOFO mal abschalten, die beiden EDB-Dateien (Mailbox und Public)aus der Sicherung heraus nehmen.
Dann noch versuchen den Snapshot Provider fest auf MS Volume Copy zu stellen.
AOFO abschalten und den Snapshot Provider auf MS Volume Copy stellen, geht nicht gleichzeitig. ok, also werde ich nun AOFO mal abschalten, die beiden EDB-Dateien (Mailbox und Public)aus der Sicherung heraus nehmen.
Dann noch versuchen den Snapshot Provider fest auf MS Volume Copy zu stellen.
Du solltest dich ein klein wenig in die Materie einlesen.
Hallo,
ja das passiert wenn man zu viel Kunden auf einmal betreut und nicht nachdenkt. Klar AOFO verwendet ja die MS Volume Copy zum sichern!
Aber was sollte ich als erstes versuchen, erst mal die MS Volume Copy fest einstellen oder doch erst mal ausprobieren AOFO abzuschalten?
Mein Problem ist das bisher unsere Kunden früher Groupwise und Novell Server eingesetzt haben. Jetzt so Kunde für Kunde teilweise auf einen Windows-Server umsteigen wollen.
Der Kunde mit dem Problem war mein erster Kunde den ich Allein von Novell und GroupWise umgezogen habe. Mein Kollege mit dem ich das sonst immer zusammen gemacht habe ist seit letzten Frühling bei einem Großkunden im Dauereinsatz. Dort verwenden Sie allerdings Lotus Notes.
Eingelesen habe ich mich in das Thema mit dem Buch Windows Small Business Server 2011 Standard von MS Press.
Wenn ich Zeit hätte würde ich das Buch gerne auswendig lernen, nur nebenbei betreue ich halt noch unzählige Kleinkunden und muss mich auch um deren Probleme kümmern.
Also bleibt oft nicht viel Zeit. Einige kennen sicher das Problem.
Außerdem habe ich bis jetzt gelernt das mit Hilfe wie diesem Forum hier ein Problem schneller zu lösen ist wie durch das lesen von Büchern. Einige kennen Lösungen die nicht mal MS bekannt sind.
Klar versuche ich zu erst das Problem selbst zu lösen durch das lesen in Büchern, wenn ich da nichts finde frage ich Google. Deshalb habe ich ja auch den einen oder anderen Lösungsansatz getestet, leider ohne Erfolg!
Deshalb habe ich hier ins Forum geschrieben und hoffe auf Unterstützung die vielleicht zu einer Lösung führt. Mit Hilfe dieser Lösung können dann aber wiederum andere die das gleiche Problem haben ihre Lösung schnell finden.
Früher war das mal einfacher, da war ich im Mausnet und da hat einem oft der Programmentwickler selbst weiter geholfen. So was ist leider heute nicht mehr möglich.
Meine Tendenz geht zur Zeit zu AOFO abschalten, denn wenn es dann funktioniert, müsste es ja an der MS Volume Copy liegen und man könnte so den Fehler weiter eingrenzen, denn die momentane automatikauswahl kann ja eigentlich nur diese Volume Copy auswählen da keine andere vorhanden ist.
Gruß Gerald
ja das passiert wenn man zu viel Kunden auf einmal betreut und nicht nachdenkt. Klar AOFO verwendet ja die MS Volume Copy zum sichern!
Aber was sollte ich als erstes versuchen, erst mal die MS Volume Copy fest einstellen oder doch erst mal ausprobieren AOFO abzuschalten?
Mein Problem ist das bisher unsere Kunden früher Groupwise und Novell Server eingesetzt haben. Jetzt so Kunde für Kunde teilweise auf einen Windows-Server umsteigen wollen.
Der Kunde mit dem Problem war mein erster Kunde den ich Allein von Novell und GroupWise umgezogen habe. Mein Kollege mit dem ich das sonst immer zusammen gemacht habe ist seit letzten Frühling bei einem Großkunden im Dauereinsatz. Dort verwenden Sie allerdings Lotus Notes.
Eingelesen habe ich mich in das Thema mit dem Buch Windows Small Business Server 2011 Standard von MS Press.
Wenn ich Zeit hätte würde ich das Buch gerne auswendig lernen, nur nebenbei betreue ich halt noch unzählige Kleinkunden und muss mich auch um deren Probleme kümmern.
Also bleibt oft nicht viel Zeit. Einige kennen sicher das Problem.
Außerdem habe ich bis jetzt gelernt das mit Hilfe wie diesem Forum hier ein Problem schneller zu lösen ist wie durch das lesen von Büchern. Einige kennen Lösungen die nicht mal MS bekannt sind.
Klar versuche ich zu erst das Problem selbst zu lösen durch das lesen in Büchern, wenn ich da nichts finde frage ich Google. Deshalb habe ich ja auch den einen oder anderen Lösungsansatz getestet, leider ohne Erfolg!
Deshalb habe ich hier ins Forum geschrieben und hoffe auf Unterstützung die vielleicht zu einer Lösung führt. Mit Hilfe dieser Lösung können dann aber wiederum andere die das gleiche Problem haben ihre Lösung schnell finden.
Früher war das mal einfacher, da war ich im Mausnet und da hat einem oft der Programmentwickler selbst weiter geholfen. So was ist leider heute nicht mehr möglich.
Meine Tendenz geht zur Zeit zu AOFO abschalten, denn wenn es dann funktioniert, müsste es ja an der MS Volume Copy liegen und man könnte so den Fehler weiter eingrenzen, denn die momentane automatikauswahl kann ja eigentlich nur diese Volume Copy auswählen da keine andere vorhanden ist.
Gruß Gerald
Hi Gerald,
das war von mir nicht böse gemeint.
Wenn du aber vor deinem Post mal in die Auswahl von AOFO geschaut hättest, hättest du gesehen, dass das nicht geht.
Mit Einlesen in die Materie meinte ich vor allem folgendes Admin Handbuch von BE 2012.
Hier wird dir auch erklärt, was AOFO ist und wozu man das einsetzt.
Symantec hat eine ziemlich große Knowledgebase, die aber am Besten auf englisch zu nutzen ist.
das war von mir nicht böse gemeint.
Wenn du aber vor deinem Post mal in die Auswahl von AOFO geschaut hättest, hättest du gesehen, dass das nicht geht.
Mit Einlesen in die Materie meinte ich vor allem folgendes Admin Handbuch von BE 2012.
Hier wird dir auch erklärt, was AOFO ist und wozu man das einsetzt.
Symantec hat eine ziemlich große Knowledgebase, die aber am Besten auf englisch zu nutzen ist.
Zitat von @goscho:
Hi Gerald,
das war von mir nicht böse gemeint.
Wenn du aber vor deinem Post mal in die Auswahl von AOFO geschaut hättest, hättest du gesehen, dass das nicht geht.
Mit Einlesen in die Materie meinte ich vor allem folgendes
Admin Handbuch von BE 2012.
Hier wird dir auch erklärt, was AOFO ist und wozu man das einsetzt.
Symantec hat eine ziemlich große Knowledgebase, die aber am Besten auf englisch zu nutzen ist.
Hi Gerald,
das war von mir nicht böse gemeint.
Wenn du aber vor deinem Post mal in die Auswahl von AOFO geschaut hättest, hättest du gesehen, dass das nicht geht.
Mit Einlesen in die Materie meinte ich vor allem folgendes
Admin Handbuch von BE 2012.
Hier wird dir auch erklärt, was AOFO ist und wozu man das einsetzt.
Symantec hat eine ziemlich große Knowledgebase, die aber am Besten auf englisch zu nutzen ist.
Ich dachte auch nicht das es böse gemeint war.
OK klar ist das AOFO dafür genutzt wird um geöffnete Dateien zu sichern, ob dann allerdings auch für das sichern von geschlossenen Dateien diese Methode genutzt wird konnte ich nirgends nachlesen.
OK, das Admin-Handbuch auf Deutsch als PDF habe ich auch auf meinem PC liegen.
Die Knowledgebase nutze ich größtenteils in Deutsch und da kann man diese vergessen. Ich habe halt mal in den 70ern Englisch gelernt und habe es dann über 30 Jahre lang nicht gebraucht. So muss ich halt bei den englischen Texten immer wieder Leo um Hilfe bitten.
Gebe ich bei Symantec KB meine Fehlernummer "V-79-65535-65535" ein, bekomme ich alles Mögliche nur nichts was mit meinem Problem zu tun hat!
Ich werde jetzt am Mittwoch mal AOFO abschalten und wenn dann der Fehler weg ist muss es ja eigentlich an der VSC liegen, oder nicht?
Gruß Gerald
Hallo,
was sagt chkdsk schon gemacht? Wenn das Dateisystem futsch ist sollte man nicht am Backup rumdocktoren.
Nimm ne USB Platte und bemühe NT-Backup/dessen nachfolger um Systemstate und Exchange zu sichern. Wenn das Programm Dir sagt ich will nicht (bricht ab oder Fehler oder oder oder), dann hast Du ein Gneellesproblem das beseitigt werden muss und NICHT mit Backup exec zu tun hat.
Die andere Frage, schon versucht das was im Moment gesichert wird, wird noch was/alles gesichert, versucht auf einem Testsystem wiederherzustellen? Bzw kannst Du mails von Gestern in Backup ansehen?
Gruß
Chonta
was sagt chkdsk schon gemacht? Wenn das Dateisystem futsch ist sollte man nicht am Backup rumdocktoren.
Nimm ne USB Platte und bemühe NT-Backup/dessen nachfolger um Systemstate und Exchange zu sichern. Wenn das Programm Dir sagt ich will nicht (bricht ab oder Fehler oder oder oder), dann hast Du ein Gneellesproblem das beseitigt werden muss und NICHT mit Backup exec zu tun hat.
Die andere Frage, schon versucht das was im Moment gesichert wird, wird noch was/alles gesichert, versucht auf einem Testsystem wiederherzustellen? Bzw kannst Du mails von Gestern in Backup ansehen?
Gruß
Chonta
Hallo,
also Checkdisk habe ich geplant, der Server wird jeden vierten Sonntag im Monat in der Nacht neu gestartet, also eigentlich den kommenden Sonntag.
Leider habe ich keine Möglichkeit da mal schnell eine USB Platte ran zu hängen, Der Server steht nicht bei mir, sondern beim Kunden. Da ich auch nicht jeden Tag bei dem Kunden bin, habe ich auch nicht die Möglichkeit mal den Backup Prozess durch BE mal schnell einen Tag zu unterbrechen um einmal auf USB Platte zu sichern. Dazu müssten ich ja am folgenden Tag wieder zum Kunden, da bin ich aber wieder ganz wo anders. Oft bin ich mehrere Wochen nicht beim Kunden vor Ort.
Außerdem kann ich mir nicht vorstellen das es daran liegt, denn wenn ich die alten Logfiles lösche und neue anlegen lasse, werden diese doch an einer ganz anderen Stelle der HD geschrieben.
Des weiteren müsste dann doch auch Exchange bei der Prüfung sagen das was an den Logfiles nicht ok ist.
Wenn ich auf Umlaufprotokolierung umschalte werden doch die Logfiles geprüft, gelöscht und ein neues Logfile angelegt! Oder sehe ich da was verkehrt?
Wenn es die Datenbank von Exchange selbst betreffen würde, wäre es dringlicher. Aber es sind die Logfiles an den Backup Exec herum meckert.
Zu deiner anderen Frage, ja es wird alles gesichert, siehe:
1 Exchange Server-Speicher gesichert
1 Exchange Server-Protokolle gesichert
1 beschädigte Datei wurde gesichert
30.502.345.302 Byte verarbeitet in 21 Minuten und 39 Sekunden.
Durchsatzrate: 1344 MB/Min.
Komprimierungstyp: Hardware
ESEUTIL sagt das alles ok ist!
Gruß Gerald
also Checkdisk habe ich geplant, der Server wird jeden vierten Sonntag im Monat in der Nacht neu gestartet, also eigentlich den kommenden Sonntag.
Leider habe ich keine Möglichkeit da mal schnell eine USB Platte ran zu hängen, Der Server steht nicht bei mir, sondern beim Kunden. Da ich auch nicht jeden Tag bei dem Kunden bin, habe ich auch nicht die Möglichkeit mal den Backup Prozess durch BE mal schnell einen Tag zu unterbrechen um einmal auf USB Platte zu sichern. Dazu müssten ich ja am folgenden Tag wieder zum Kunden, da bin ich aber wieder ganz wo anders. Oft bin ich mehrere Wochen nicht beim Kunden vor Ort.
Außerdem kann ich mir nicht vorstellen das es daran liegt, denn wenn ich die alten Logfiles lösche und neue anlegen lasse, werden diese doch an einer ganz anderen Stelle der HD geschrieben.
Des weiteren müsste dann doch auch Exchange bei der Prüfung sagen das was an den Logfiles nicht ok ist.
Wenn ich auf Umlaufprotokolierung umschalte werden doch die Logfiles geprüft, gelöscht und ein neues Logfile angelegt! Oder sehe ich da was verkehrt?
Wenn es die Datenbank von Exchange selbst betreffen würde, wäre es dringlicher. Aber es sind die Logfiles an den Backup Exec herum meckert.
Zu deiner anderen Frage, ja es wird alles gesichert, siehe:
1 Exchange Server-Speicher gesichert
1 Exchange Server-Protokolle gesichert
1 beschädigte Datei wurde gesichert
30.502.345.302 Byte verarbeitet in 21 Minuten und 39 Sekunden.
Durchsatzrate: 1344 MB/Min.
Komprimierungstyp: Hardware
ESEUTIL sagt das alles ok ist!
Gruß Gerald
Zitat von @Chonta:
Hallo,
was sagt chkdsk schon gemacht? Wenn das Dateisystem futsch ist sollte man nicht am Backup rumdocktoren.
Nimm ne USB Platte und bemühe NT-Backup/dessen nachfolger um Systemstate und Exchange zu sichern. Wenn das Programm Dir sagt
ich will nicht (bricht ab oder Fehler oder oder oder), dann hast Du ein Gneellesproblem das beseitigt werden muss und NICHT mit
Backup exec zu tun hat.
Die andere Frage, schon versucht das was im Moment gesichert wird, wird noch was/alles gesichert, versucht auf einem Testsystem
wiederherzustellen? Bzw kannst Du mails von Gestern in Backup ansehen?
Gruß
Chonta
Hallo,
was sagt chkdsk schon gemacht? Wenn das Dateisystem futsch ist sollte man nicht am Backup rumdocktoren.
Nimm ne USB Platte und bemühe NT-Backup/dessen nachfolger um Systemstate und Exchange zu sichern. Wenn das Programm Dir sagt
ich will nicht (bricht ab oder Fehler oder oder oder), dann hast Du ein Gneellesproblem das beseitigt werden muss und NICHT mit
Backup exec zu tun hat.
Die andere Frage, schon versucht das was im Moment gesichert wird, wird noch was/alles gesichert, versucht auf einem Testsystem
wiederherzustellen? Bzw kannst Du mails von Gestern in Backup ansehen?
Gruß
Chonta
Hallo,
da fällt mir gerade was ein.
Wenn ich AOFO deaktiviere, kann dann Backup Exec eigentlich das System sichern, denn da sind ja massenhaft offene Dateien?
Gruß Gerald
PS: Kennt Jemand eine Möglichkeit die Logfiles zu prüfen um fest zu stellen was daran inkonsistent sein soll?
da fällt mir gerade was ein.
Wenn ich AOFO deaktiviere, kann dann Backup Exec eigentlich das System sichern, denn da sind ja massenhaft offene Dateien?
Gruß Gerald
PS: Kennt Jemand eine Möglichkeit die Logfiles zu prüfen um fest zu stellen was daran inkonsistent sein soll?
So jetzt muss ich mich noch mal melden,
habe mir das ganze jetzt mal durch den Kopf gehen lassen.
Also Checkdisk für Laufwerk C ist geplant, aber das Problem betrifft ja Laufwerk D. Da auf D kein System ist sollte ja auch während des Betriebes Checkdisk möglich sein. Da das aber vermutlich das System aus bremst, werde ich morgen meinen Ansprechpartner vor Ort darum bitten kurz vor dem Feierabend einmal Checkdisk zu starten, in der Hoffnung dass das ganze innerhalb 5 Stunden bevor die Sicherung beginnt abgeschlossen ist.
Wenn das dass Problem beseitigt, da Checkdisk hoffentlich das Problem an der Schattenkopie beheben kann, wäre die Sache gelöst. Wenn nicht, werde ich ein mal direkt die MS Volumen Kopie auswählen und die automatische Wahl abstellen und das Ereignisprotokoll nach Fehlern im Zusammenhang mit VSS durchsuchen.
Das ganze aus dem Grund, da ich bedenken habe ob Backup Exec ohne die AOFO Funktion überhaupt das System sichern kann.
Wenn jetzt demnächst keine Warnung kommt dies zu tund, werde ich das Morgen in Angriff nehmen.
Gruß Gerald
habe mir das ganze jetzt mal durch den Kopf gehen lassen.
Also Checkdisk für Laufwerk C ist geplant, aber das Problem betrifft ja Laufwerk D. Da auf D kein System ist sollte ja auch während des Betriebes Checkdisk möglich sein. Da das aber vermutlich das System aus bremst, werde ich morgen meinen Ansprechpartner vor Ort darum bitten kurz vor dem Feierabend einmal Checkdisk zu starten, in der Hoffnung dass das ganze innerhalb 5 Stunden bevor die Sicherung beginnt abgeschlossen ist.
Wenn das dass Problem beseitigt, da Checkdisk hoffentlich das Problem an der Schattenkopie beheben kann, wäre die Sache gelöst. Wenn nicht, werde ich ein mal direkt die MS Volumen Kopie auswählen und die automatische Wahl abstellen und das Ereignisprotokoll nach Fehlern im Zusammenhang mit VSS durchsuchen.
Das ganze aus dem Grund, da ich bedenken habe ob Backup Exec ohne die AOFO Funktion überhaupt das System sichern kann.
Wenn jetzt demnächst keine Warnung kommt dies zu tund, werde ich das Morgen in Angriff nehmen.
Gruß Gerald
Hallo,
chkdsk wenn die Datenbank läuft ist keine gute Idee.
Bei mir hat er auch bei D das ausführen ohne neustart nicht gemacht. (SBS 2003 DB auf D)
Ich hatte letstens einen Fehler mit der DB der nur aufgefallen war, weil NT-Bakcup nicht mehr wollte und das andere Tool munter weitergesichert hat.
Das mit AOFO off und auf MS VSS stellen ist ne gute Idee.
Die Scherung beim Kunden könnte ja auch Remote (VPN und RDP) gemacht werden und ne USB HDD ranhängen könnte der Kunde ja selber. Bzw wenn genug speicher da ist, das Probebackup auf die Lokale Platte, es soll ja kein "Backup" sein, sondern ein Test ob was futsch ist.
Hier noch ein Link wegen der Transaktionsprotokolle.
http://www.msexchangefaq.de/admin/database.htm
Entweder das System löscht die teile oder niemand
Gruß
Chonta
chkdsk wenn die Datenbank läuft ist keine gute Idee.
Bei mir hat er auch bei D das ausführen ohne neustart nicht gemacht. (SBS 2003 DB auf D)
Ich hatte letstens einen Fehler mit der DB der nur aufgefallen war, weil NT-Bakcup nicht mehr wollte und das andere Tool munter weitergesichert hat.
Das mit AOFO off und auf MS VSS stellen ist ne gute Idee.
Die Scherung beim Kunden könnte ja auch Remote (VPN und RDP) gemacht werden und ne USB HDD ranhängen könnte der Kunde ja selber. Bzw wenn genug speicher da ist, das Probebackup auf die Lokale Platte, es soll ja kein "Backup" sein, sondern ein Test ob was futsch ist.
Hier noch ein Link wegen der Transaktionsprotokolle.
http://www.msexchangefaq.de/admin/database.htm
Entweder das System löscht die teile oder niemand
Gruß
Chonta
Das ist Unfug!
Wie soll denn das gehen?
Advanced Open File Option ist genau der Punkt in BE, in welchem der passende Shadow Copy Provider ausgewählt wird.
Hier habt ihr mal einen Screenshot, damit ihr wisst, wovon wir reden:
BE-2012 AOFO Einstellungen
Wer AOFO deaktiviert, kann auch kein VSS mehr mit BE nutzen.
Der TO kann aber durchaus mal einen Snapshot-Provider manuell festlegen.
In 98,859% aller Fälle sollte bei einem SBS hier der 2. (System - MS Schattenkopieanbieter verwenden) die beste Auswahl sein.
Den Einwand mit der USB-HDD kann ich so auch nicht nachvollziehen.
Hier gebe ich Chonta voll und ganz Recht.
Wie soll denn das gehen?
Advanced Open File Option ist genau der Punkt in BE, in welchem der passende Shadow Copy Provider ausgewählt wird.
Hier habt ihr mal einen Screenshot, damit ihr wisst, wovon wir reden:
BE-2012 AOFO Einstellungen
Wer AOFO deaktiviert, kann auch kein VSS mehr mit BE nutzen.
Der TO kann aber durchaus mal einen Snapshot-Provider manuell festlegen.
In 98,859% aller Fälle sollte bei einem SBS hier der 2. (System - MS Schattenkopieanbieter verwenden) die beste Auswahl sein.
Den Einwand mit der USB-HDD kann ich so auch nicht nachvollziehen.
Hier gebe ich Chonta voll und ganz Recht.
Hallo,
das meinte ich eigendtlich. Ohne VSS keine Sicherung der Exchangedatenbank möglich!
Andere Frage, schon mal geschaut ob zum Zeitpunkt des Backups viele viele Mails eingehen? Weil wenn Mails eingehen verändern sich die Datein und wenn die schon gesichert wurden gibts logscherweise einen Alarm weil die gesicherten Datein nicht mit den auf der Platte übereinstimmen.
Also optional kann auch mal versucht werden das Backup von der Zeit her zu verschieben - chkdsk und USB-HDD Sicherung sollte trozdem gemacht werden.
Und umbedingt versuchen die Backups mal auf einer Testmaschiene zum laufen zu bringen, ein Backup das nicht zurückgesichert werden kann ist keins.
Gruß
Chonta
Der TO kann aber durchaus mal einen Snapshot-Provider manuell festlegen.
In 98,859% aller Fälle sollte bei einem SBS hier der 2. (System - MS Schattenkopieanbieter verwenden) die beste
Auswahl sein.
In 98,859% aller Fälle sollte bei einem SBS hier der 2. (System - MS Schattenkopieanbieter verwenden) die beste
Auswahl sein.
das meinte ich eigendtlich. Ohne VSS keine Sicherung der Exchangedatenbank möglich!
Andere Frage, schon mal geschaut ob zum Zeitpunkt des Backups viele viele Mails eingehen? Weil wenn Mails eingehen verändern sich die Datein und wenn die schon gesichert wurden gibts logscherweise einen Alarm weil die gesicherten Datein nicht mit den auf der Platte übereinstimmen.
Also optional kann auch mal versucht werden das Backup von der Zeit her zu verschieben - chkdsk und USB-HDD Sicherung sollte trozdem gemacht werden.
Und umbedingt versuchen die Backups mal auf einer Testmaschiene zum laufen zu bringen, ein Backup das nicht zurückgesichert werden kann ist keins.
Gruß
Chonta
Hallo,
also ich werde mal die MS Schattenkopie jetzt fest einstellen.
Dann muss ich jetzt nur noch sehen wie ich ein Checkdisk der Partition D für den nächsten Neustart plane, für die C ist es ja kein Problem.
Viele Mails kommen in der Nacht nicht rein, eher nur einzelne sporadisch.
Kann NT-Backup, bzw. sein Nachfolger während des Betriebes gestartet werden, habe das schon ewig nicht mehr verwendet.
Vielleicht könnte ich dann Morgen tagsüber vor Ort einfach mal versuchen nur den Exchange Teil zu sichern, oder eben nur die D. Wird schon den Server nicht all zu sehr aus bremsen hoffe ich. Oder geht das nicht?
Ja ich kann eine Verbindung aufbauen, zwar nicht per VPN, nur ist es halt meistens umständlich dank eines Proxis der nicht am Standort steht sondern 250km entfernt und auf den wir keinerlei Einfluss haben. Also da brauche ich nicht mal daran denken das da an der Konfiguration etwas geändert wird wenn ich darum bitte.
So muss ich jetzt jedes mal Jemanden finden der Zeit hat und seinen PC gerade nicht braucht. Der muss dann per NetViewer eine Sitzung aufbauen und dann gehe ich per RDP von diesem PC auf den Server. Meistens bekomme ich dann aber ein paar Minuten später wieder einen Anruf das er PC jetzt eigentlich wieder gebraucht wird! So kann es passieren das ich nach einer halben Stunde bereits an 3 PCs war!
Bin ich jetzt eigentlich richtig in der Annahme das nicht das Logfile direkt beschädigt ist sondern die Schattenkopie davon?
Gruß Gerald
also ich werde mal die MS Schattenkopie jetzt fest einstellen.
Dann muss ich jetzt nur noch sehen wie ich ein Checkdisk der Partition D für den nächsten Neustart plane, für die C ist es ja kein Problem.
Viele Mails kommen in der Nacht nicht rein, eher nur einzelne sporadisch.
Kann NT-Backup, bzw. sein Nachfolger während des Betriebes gestartet werden, habe das schon ewig nicht mehr verwendet.
Vielleicht könnte ich dann Morgen tagsüber vor Ort einfach mal versuchen nur den Exchange Teil zu sichern, oder eben nur die D. Wird schon den Server nicht all zu sehr aus bremsen hoffe ich. Oder geht das nicht?
Ja ich kann eine Verbindung aufbauen, zwar nicht per VPN, nur ist es halt meistens umständlich dank eines Proxis der nicht am Standort steht sondern 250km entfernt und auf den wir keinerlei Einfluss haben. Also da brauche ich nicht mal daran denken das da an der Konfiguration etwas geändert wird wenn ich darum bitte.
So muss ich jetzt jedes mal Jemanden finden der Zeit hat und seinen PC gerade nicht braucht. Der muss dann per NetViewer eine Sitzung aufbauen und dann gehe ich per RDP von diesem PC auf den Server. Meistens bekomme ich dann aber ein paar Minuten später wieder einen Anruf das er PC jetzt eigentlich wieder gebraucht wird! So kann es passieren das ich nach einer halben Stunde bereits an 3 PCs war!
Bin ich jetzt eigentlich richtig in der Annahme das nicht das Logfile direkt beschädigt ist sondern die Schattenkopie davon?
Gruß Gerald
Hallo,
backup zieht immer Leistung ab und jeh nachdme wie groß die DB ist dauert das auch.
Und Bei NT-Backup (wird beim Nachfolge rnicht anders sein) muss man die ExchangeDB extra auswählen also nicht einfach D sichern, das bringt nix.
Investiere in Teamviewer und installiere das auf dem Server und du kannst dich raufschalten wann Du willst.
Wenn Du der Admin von der Kiste bist musst Du auch rauf können, ist ja kein arbeiten....
Gruß
Chonta
backup zieht immer Leistung ab und jeh nachdme wie groß die DB ist dauert das auch.
Und Bei NT-Backup (wird beim Nachfolge rnicht anders sein) muss man die ExchangeDB extra auswählen also nicht einfach D sichern, das bringt nix.
Investiere in Teamviewer und installiere das auf dem Server und du kannst dich raufschalten wann Du willst.
Wenn Du der Admin von der Kiste bist musst Du auch rauf können, ist ja kein arbeiten....
Gruß
Chonta
Zitat von @Chonta:
Hallo,
backup zieht immer Leistung ab und jeh nachdme wie groß die DB ist dauert das auch.
Und Bei NT-Backup (wird beim Nachfolge rnicht anders sein) muss man die ExchangeDB extra auswählen also nicht einfach D
sichern, das bringt nix.
Investiere in Teamviewer und installiere das auf dem Server und du kannst dich raufschalten wann Du willst.
Wenn Du der Admin von der Kiste bist musst Du auch rauf können, ist ja kein arbeiten....
Gruß
Chonta
Hallo,
backup zieht immer Leistung ab und jeh nachdme wie groß die DB ist dauert das auch.
Und Bei NT-Backup (wird beim Nachfolge rnicht anders sein) muss man die ExchangeDB extra auswählen also nicht einfach D
sichern, das bringt nix.
Investiere in Teamviewer und installiere das auf dem Server und du kannst dich raufschalten wann Du willst.
Wenn Du der Admin von der Kiste bist musst Du auch rauf können, ist ja kein arbeiten....
Gruß
Chonta
OK danke für den Hinweis, werde es trotzdem mal versuchen zu sichern während des Betriebes. Wenn es zu stark aus bremst breche ich den Vorgang halt ab.
Mit Teamviewer habe ich mich getäuscht, wir nutzen NetViewer und da kann ich keine Verbindung aufbauen ohne das Jemand vor Ort ist. Teamviewer nutze ich privat!
Gruß Gerald
Hallo,
ich bin die ganze Zeit nun auf der Suche wie ich chkdsk für den nächsten Neustart planen kann für Laufwerk D?
ich finde weder bei chkdsk noch bei shutdown eine Option dazu!
Oder übersehe ich da was?
Gruß Gerald
ich bin die ganze Zeit nun auf der Suche wie ich chkdsk für den nächsten Neustart planen kann für Laufwerk D?
ich finde weder bei chkdsk noch bei shutdown eine Option dazu!
Oder übersehe ich da was?
Gruß Gerald
Hallo,
also der wird chkdsk /F /R nicht machen lassen wenn Du es so versuchst, so jedenfalls bei mir (SBS 2003 und auch 2 Partitionen) und dann beitet er Dir an es beim nächsten Start zu machen.
Gruß
Chonta
also der wird chkdsk /F /R nicht machen lassen wenn Du es so versuchst, so jedenfalls bei mir (SBS 2003 und auch 2 Partitionen) und dann beitet er Dir an es beim nächsten Start zu machen.
Gruß
Chonta
Hallo,
na dann ist es ja ok wenn der SBS2011 das genauso macht.
Aber trotzdem hätte mich mal interessiert wie man so was planen könnte, einfach ein Script mit
REM Checkdisk von Laufwerl D mit vorherigen Aufhebung der Bereitsstellung und Reparatur des Datenträgers
chkdsk D: /x /f /r
REM Falls man die C auch überprüfen möchte:
Chkdsk C: /f /r
REM Ein Neustart der dann auch die C prüfen lässt
shutdown /r
Ich glaube ich schweife zu weit vom Thema ab und sollte da lieber eine neue Frage stellen!
Gruß Gerald
na dann ist es ja ok wenn der SBS2011 das genauso macht.
Aber trotzdem hätte mich mal interessiert wie man so was planen könnte, einfach ein Script mit
REM Checkdisk von Laufwerl D mit vorherigen Aufhebung der Bereitsstellung und Reparatur des Datenträgers
chkdsk D: /x /f /r
REM Falls man die C auch überprüfen möchte:
Chkdsk C: /f /r
REM Ein Neustart der dann auch die C prüfen lässt
shutdown /r
Ich glaube ich schweife zu weit vom Thema ab und sollte da lieber eine neue Frage stellen!
Gruß Gerald
Zitat von @Chonta:
Hallo,
also der wird chkdsk /F /R nicht machen lassen wenn Du es so versuchst, so jedenfalls bei mir (SBS 2003 und auch 2 Partitionen)
und dann beitet er Dir an es beim nächsten Start zu machen.
Gruß
Chonta
Hallo,
also der wird chkdsk /F /R nicht machen lassen wenn Du es so versuchst, so jedenfalls bei mir (SBS 2003 und auch 2 Partitionen)
und dann beitet er Dir an es beim nächsten Start zu machen.
Gruß
Chonta
So, war heute vor Ort.
Also Checkdisk ist geplant für die D
AOFO habe ich umgestellt
Die Windows eigene Sicherung gibt mir keine Möglichkeit Exchange zu sichern, nur Datei basierend. Das habe ich mal vom Ordner mit den Exchange Datenbanken gemacht und die lief ohne Fehler durch.
Neustarten sollte der Server diesen Sonntag.
Gruß Gerald
Also Checkdisk ist geplant für die D
AOFO habe ich umgestellt
Die Windows eigene Sicherung gibt mir keine Möglichkeit Exchange zu sichern, nur Datei basierend. Das habe ich mal vom Ordner mit den Exchange Datenbanken gemacht und die lief ohne Fehler durch.
Neustarten sollte der Server diesen Sonntag.
Gruß Gerald
Hallo,
leider habe ich im Ereignisprotokoll nichts gefunden über ein ausgeführtes Checkdisk!
Nun habe ich das Ereignisprotokoll nach Fehlern durchsucht und habe zu diesen Fehlern Lösungen gefunden und habe nun auch eine Vermutung.
Ich nehme an das beim Herunterfahren ein Windows Update fehlschlug und den Server zum Absturz brachte, dies führte dann auch noch zu weiteren Fehlern:
Nun die Fehler und die Lösungen dazu:
EventID: 10009 Source: DCOM
DCOM konnte mit dem Computer "xy" unter Verwendung eines
beliebigen, konfigurierten Protokolls keine Daten austauschen.
Lösung
Die DCOM-Protokolle müssen neu eingerichtet werden.
1. Systemsteuerung > Verwaltung > Komponentendienste
2. Komponentendienste > Computer > Arbeitsplatz
3. Rechtsklick, Eigenschaften
4. Tab «Standardprotokolle»
5. Alle Protokolle löschen
6. Protokolle wieder hinzufügen: «Verbindungsorientiertes TCP/IP», «Verbindungsorientiertes SPX»
7. So anordnen, dass TCP/IP oben steht
8. Alle Fenster schliessen und Rechner neustarten
Event ID: NTFRS 13568 – File Replication Service
Einen Eintrag in der Registry bearbeiten oder neu erstellen
Registrierungseditor starten
HKLM / System / CurrentControlSet / NTFRS / Parameters
DWORD setzen (entweder neu erstellen oder bearbeiten) “Enable Journal Wrap Automatic Restore” auf 1
Über services.msc dann ntfrs stoppen und neu starten.
Event ID 1002: Know Folders
Um dieses Problem selbst zu beheben, entfernen Sie das Downloadverzeichnis, und wechseln Sie dann erneut zum jeweiligen Updatespeicherort.
1. Beenden Sie den Dienst "Automatische Updates". Gehen Sie hierzu folgendermaßen vor:
1. Klicken Sie auf Start und anschließend auf Ausführen. Geben Sie services.msc ein, und klicken Sie auf OK.
2. Klicken Sie mit der rechten Maustaste auf den Dienst Automatische Updates, und klicken Sie auf Beenden.
3. Minimieren Sie das Dienste-Snap-In.
2. Benennen Sie das Verzeichnis "SoftwareDistribution" um. Gehen Sie hierzu folgendermaßen vor:
1. Klicken Sie auf Start und anschließend auf Ausführen. Geben Sie cmd ein, und klicken Sie auf OK.
2. Geben Sie cd %windir% ein, und drücken Sie danach die EINGABETASTE.
3. Geben Sie ren SoftwareDistribution SDTemp ein, und drücken Sie die EINGABETASTE.
4. Geben Sie exit ein, und drücken Sie die [EINGABETASTE].
Hinweis Wenn Sie den Ordner %windir%\softwaredistribution entfernen, wird die Verlaufsliste aus dem Bereich "Updateverlauf anzeigen" auf der Windows Update-Website entfernt. Diese Aktion hat keinerlei Auswirkung auf die derzeit auf Ihrem Computer installierten Updates. Nachfolgende Updates werden in der Verlaufsliste angezeigt.
3. Starten Sie den Dienst "Automatische Updates". Gehen Sie hierzu folgendermaßen vor:
1. Vergrößern Sie das Dienste-Snap-In.
2. Klicken Sie mit der rechten Maustaste auf den Dienst Automatische Updates, und klicken Sie auf Starten.
3. Starten Sie das Fenster des Dienste-Snap-Ins.
4. Besuchen Sie die Windows Update-Website, die Microsoft Update-Website oder den WSUS-Server erneut, und laden Sie dann das Update herunter.
5. Wenn Sie weiterhin dieselben Fehler erhalten, überprüfen Sie, ob Sie die Schritte 1 bis 3 ordnungsgemäß durchgeführt haben.
6. Wenn Sie das Update weiterhin nicht installieren können, lesen Sie den folgenden Microsoft Knowledge Base-Artikel:
906602 Installationsprobleme bei Windows Update, Microsoft Update und Windows Server Update Services beheben
Ereignis - ID: 57477 Quelle: BackupExecEngine
Typ: Fehler
Beschreibung: Das Betriebssystem wechselte einen ungewöhnlichen Fehler zurück, beim die erweiterten Attribute oder die Sicherheitsinformationen für das folgende Verzeichnis sichern: Dieses Problem wird verhindert, der dass Inhalt des Verzeichnisses nicht erfolgreich gesichert.
Lösung
Dieses Ereignis wird durch VERITAS Backup Exec berichtet, wenn es einen Fehlerzustand von Windows wenn versuchend, um ein Verzeichnis zu sichern erhält. CHDKSK sollte auf den Datenträger ausgeführt werden, der das beschädigte Verzeichnis enthält. Nachdem Sie CHKDSK ausgeführt haben, versuchen Sie, den Backup-Auftrag wieder auszuführen.
Event 2007 (Error) Source: ESE
How important is this event?
not important very important
Description
This Error event is logged when a Volume Shadow Copy Service (VSS) copy operation is stopped. This event indicates that the VSS software or hardware provider of the VSS solution has returned the Abort state. When the Abort state is reported, ESE performs the corresponding operation and logs ESE Error event 2007.
User Action
To resolve this event, do one or more of the following:
Make sure that you are using the latest hardware and software recommended by your VSS application vendor.
Make sure that you are running the latest Microsoft® Windows® and Microsoft Exchange Server updates for VSS. For information about Exchange Server updates and service packs, see Microsoft Knowledge Base article 906669, Issues that are fixed in Exchange Server 2003 Service Pack 2.
In Event Viewer, examine the Application log and System log for relevant event messages. These event messages may provide additional information about the underlying issue.
Contact your hardware vendor for more help diagnosing the problem. For example, hardware vendors may be able to help you identify any firmware or device driver issues that may be causing the problem.
When the server backup runs and does a backup of the volume containing the Exchange databases, the backup will perform a consistency check on the Exchange databases and the log files. If the consistency check fails because of a missing or corrupt log file or database then the backup job will fail and these errors will be logged.
Back to the top | Give Feedback
RESOLUTION
We must first determine which logs or databases are affected. A standard Small Business Server contains two Exchange databases. We can use the Exchange ESEUTIL utility to check the consistency of the logs and the databases. We need to run ESEUTIL /K against each database and the log files.
For example:
On a default installation of Small Business Server 2008 there are two Exchange databases (the mailbox database and the public folder database). The mailbox database and the associated log files are by default located at c:\program files\microsoft\exchange server\mailbox\first storage group. The public folder store and its associated log files are located by default at c:\program files\microsoft\exchange server\mailbox\second storage group.
You would use the following steps to run a consistency check against the mailbox database:
1. Dismount the mailbox database
2. Open an Administrator command prompt
2. Change to c:\program files\microsoft\exchange server\mailbox\first storage group (if you have moved the database, the location will be different)
3. Run ESEUTIL /K E00 to verify the log files.
If any of the log files report an error, you can move the log files to a temporary location and remount the database and attempt the backup operation again.
4. Run ESEUTIL /K "mailbox database.edb" to verify the mailbox database.
A clean database will report zero checksum mismatches. If an error in the database is detected, you will need to either restore the database from a backup or perform a repair of the database file. For additional information of repairing an Exchange database, see http://technet.microsoft.com/en-us/library/aa997152(EXCHG.80).aspx
Here is an example of the output from a damaged database:
Initiating CHECKSUM mode...
Database: C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\mailbox Database.edb
Temp. Database: TEMPCHKSUM8184.EDB
File: C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storag
ERROR: page 150 checksum failed ( 0xac51ac51302fbea2 / 0xe9e8e9e82531bd59 )
Checksum Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
..................................................ERROR: page 20126 checksum failed ( 0xf432f4326dafd90d / 0xc6a2395dc22dfc7a )
ERROR: page 22102 checksum failed ( 0xafb0afb00331f36b / 0xbc75bc758c5f3b9c )
.
24066 pages seen
3 bad checksums
0 correctable checksums
294 uninitialized pages
0 wrong page numbers
0x546d56 highest dbtime (pgno 0x5907)
3009 reads performed
188 MB read
1 seconds taken
188 MB/second
707113 milliseconds used
234 milliseconds per read
359 milliseconds for the slowest read
0 milliseconds for the fastest read
Operation terminated with error -1206 (JET_errDatabaseCorrupted, Non database fi
le or corrupted db) after 0.936 seconds.
In this example, the database has some logical corruption and it fails the consistency check. In order to recover from the corruption you must either restore the database from a backup or run a repair of the database. Once the corruption issue has been resolved, you can mount the database and try the backup operation again.
You need to repeat these steps for the public folder database and any other Exchange databases.
Nun hätte ich folgendes vor:
Checkdisk vor Ort von C und D
SoftwareDistributionsinhalt löschen
Windows Update per Internetseite ausführen und installieren lassen
DCOM Protokolle neu einrichten
NTFRS Registry Key ändern, Dienst neu starten
Mit eseutil Database und sämtliche Fehlerprotokolle einzeln per eseutil /k prüfen
Was haltet ihr davon?
leider habe ich im Ereignisprotokoll nichts gefunden über ein ausgeführtes Checkdisk!
Nun habe ich das Ereignisprotokoll nach Fehlern durchsucht und habe zu diesen Fehlern Lösungen gefunden und habe nun auch eine Vermutung.
Ich nehme an das beim Herunterfahren ein Windows Update fehlschlug und den Server zum Absturz brachte, dies führte dann auch noch zu weiteren Fehlern:
Nun die Fehler und die Lösungen dazu:
EventID: 10009 Source: DCOM
DCOM konnte mit dem Computer "xy" unter Verwendung eines
beliebigen, konfigurierten Protokolls keine Daten austauschen.
Lösung
Die DCOM-Protokolle müssen neu eingerichtet werden.
1. Systemsteuerung > Verwaltung > Komponentendienste
2. Komponentendienste > Computer > Arbeitsplatz
3. Rechtsklick, Eigenschaften
4. Tab «Standardprotokolle»
5. Alle Protokolle löschen
6. Protokolle wieder hinzufügen: «Verbindungsorientiertes TCP/IP», «Verbindungsorientiertes SPX»
7. So anordnen, dass TCP/IP oben steht
8. Alle Fenster schliessen und Rechner neustarten
Event ID: NTFRS 13568 – File Replication Service
Einen Eintrag in der Registry bearbeiten oder neu erstellen
Registrierungseditor starten
HKLM / System / CurrentControlSet / NTFRS / Parameters
DWORD setzen (entweder neu erstellen oder bearbeiten) “Enable Journal Wrap Automatic Restore” auf 1
Über services.msc dann ntfrs stoppen und neu starten.
Event ID 1002: Know Folders
Um dieses Problem selbst zu beheben, entfernen Sie das Downloadverzeichnis, und wechseln Sie dann erneut zum jeweiligen Updatespeicherort.
1. Beenden Sie den Dienst "Automatische Updates". Gehen Sie hierzu folgendermaßen vor:
1. Klicken Sie auf Start und anschließend auf Ausführen. Geben Sie services.msc ein, und klicken Sie auf OK.
2. Klicken Sie mit der rechten Maustaste auf den Dienst Automatische Updates, und klicken Sie auf Beenden.
3. Minimieren Sie das Dienste-Snap-In.
2. Benennen Sie das Verzeichnis "SoftwareDistribution" um. Gehen Sie hierzu folgendermaßen vor:
1. Klicken Sie auf Start und anschließend auf Ausführen. Geben Sie cmd ein, und klicken Sie auf OK.
2. Geben Sie cd %windir% ein, und drücken Sie danach die EINGABETASTE.
3. Geben Sie ren SoftwareDistribution SDTemp ein, und drücken Sie die EINGABETASTE.
4. Geben Sie exit ein, und drücken Sie die [EINGABETASTE].
Hinweis Wenn Sie den Ordner %windir%\softwaredistribution entfernen, wird die Verlaufsliste aus dem Bereich "Updateverlauf anzeigen" auf der Windows Update-Website entfernt. Diese Aktion hat keinerlei Auswirkung auf die derzeit auf Ihrem Computer installierten Updates. Nachfolgende Updates werden in der Verlaufsliste angezeigt.
3. Starten Sie den Dienst "Automatische Updates". Gehen Sie hierzu folgendermaßen vor:
1. Vergrößern Sie das Dienste-Snap-In.
2. Klicken Sie mit der rechten Maustaste auf den Dienst Automatische Updates, und klicken Sie auf Starten.
3. Starten Sie das Fenster des Dienste-Snap-Ins.
4. Besuchen Sie die Windows Update-Website, die Microsoft Update-Website oder den WSUS-Server erneut, und laden Sie dann das Update herunter.
5. Wenn Sie weiterhin dieselben Fehler erhalten, überprüfen Sie, ob Sie die Schritte 1 bis 3 ordnungsgemäß durchgeführt haben.
6. Wenn Sie das Update weiterhin nicht installieren können, lesen Sie den folgenden Microsoft Knowledge Base-Artikel:
906602 Installationsprobleme bei Windows Update, Microsoft Update und Windows Server Update Services beheben
Ereignis - ID: 57477 Quelle: BackupExecEngine
Typ: Fehler
Beschreibung: Das Betriebssystem wechselte einen ungewöhnlichen Fehler zurück, beim die erweiterten Attribute oder die Sicherheitsinformationen für das folgende Verzeichnis sichern: Dieses Problem wird verhindert, der dass Inhalt des Verzeichnisses nicht erfolgreich gesichert.
Lösung
Dieses Ereignis wird durch VERITAS Backup Exec berichtet, wenn es einen Fehlerzustand von Windows wenn versuchend, um ein Verzeichnis zu sichern erhält. CHDKSK sollte auf den Datenträger ausgeführt werden, der das beschädigte Verzeichnis enthält. Nachdem Sie CHKDSK ausgeführt haben, versuchen Sie, den Backup-Auftrag wieder auszuführen.
Event 2007 (Error) Source: ESE
How important is this event?
not important very important
Description
This Error event is logged when a Volume Shadow Copy Service (VSS) copy operation is stopped. This event indicates that the VSS software or hardware provider of the VSS solution has returned the Abort state. When the Abort state is reported, ESE performs the corresponding operation and logs ESE Error event 2007.
User Action
To resolve this event, do one or more of the following:
Make sure that you are using the latest hardware and software recommended by your VSS application vendor.
Make sure that you are running the latest Microsoft® Windows® and Microsoft Exchange Server updates for VSS. For information about Exchange Server updates and service packs, see Microsoft Knowledge Base article 906669, Issues that are fixed in Exchange Server 2003 Service Pack 2.
In Event Viewer, examine the Application log and System log for relevant event messages. These event messages may provide additional information about the underlying issue.
Contact your hardware vendor for more help diagnosing the problem. For example, hardware vendors may be able to help you identify any firmware or device driver issues that may be causing the problem.
When the server backup runs and does a backup of the volume containing the Exchange databases, the backup will perform a consistency check on the Exchange databases and the log files. If the consistency check fails because of a missing or corrupt log file or database then the backup job will fail and these errors will be logged.
Back to the top | Give Feedback
RESOLUTION
We must first determine which logs or databases are affected. A standard Small Business Server contains two Exchange databases. We can use the Exchange ESEUTIL utility to check the consistency of the logs and the databases. We need to run ESEUTIL /K against each database and the log files.
For example:
On a default installation of Small Business Server 2008 there are two Exchange databases (the mailbox database and the public folder database). The mailbox database and the associated log files are by default located at c:\program files\microsoft\exchange server\mailbox\first storage group. The public folder store and its associated log files are located by default at c:\program files\microsoft\exchange server\mailbox\second storage group.
You would use the following steps to run a consistency check against the mailbox database:
1. Dismount the mailbox database
2. Open an Administrator command prompt
2. Change to c:\program files\microsoft\exchange server\mailbox\first storage group (if you have moved the database, the location will be different)
3. Run ESEUTIL /K E00 to verify the log files.
If any of the log files report an error, you can move the log files to a temporary location and remount the database and attempt the backup operation again.
4. Run ESEUTIL /K "mailbox database.edb" to verify the mailbox database.
A clean database will report zero checksum mismatches. If an error in the database is detected, you will need to either restore the database from a backup or perform a repair of the database file. For additional information of repairing an Exchange database, see http://technet.microsoft.com/en-us/library/aa997152(EXCHG.80).aspx
Here is an example of the output from a damaged database:
Initiating CHECKSUM mode...
Database: C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\mailbox Database.edb
Temp. Database: TEMPCHKSUM8184.EDB
File: C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storag
ERROR: page 150 checksum failed ( 0xac51ac51302fbea2 / 0xe9e8e9e82531bd59 )
Checksum Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
..................................................ERROR: page 20126 checksum failed ( 0xf432f4326dafd90d / 0xc6a2395dc22dfc7a )
ERROR: page 22102 checksum failed ( 0xafb0afb00331f36b / 0xbc75bc758c5f3b9c )
.
24066 pages seen
3 bad checksums
0 correctable checksums
294 uninitialized pages
0 wrong page numbers
0x546d56 highest dbtime (pgno 0x5907)
3009 reads performed
188 MB read
1 seconds taken
188 MB/second
707113 milliseconds used
234 milliseconds per read
359 milliseconds for the slowest read
0 milliseconds for the fastest read
Operation terminated with error -1206 (JET_errDatabaseCorrupted, Non database fi
le or corrupted db) after 0.936 seconds.
In this example, the database has some logical corruption and it fails the consistency check. In order to recover from the corruption you must either restore the database from a backup or run a repair of the database. Once the corruption issue has been resolved, you can mount the database and try the backup operation again.
You need to repeat these steps for the public folder database and any other Exchange databases.
Nun hätte ich folgendes vor:
Checkdisk vor Ort von C und D
SoftwareDistributionsinhalt löschen
Windows Update per Internetseite ausführen und installieren lassen
DCOM Protokolle neu einrichten
NTFRS Registry Key ändern, Dienst neu starten
Mit eseutil Database und sämtliche Fehlerprotokolle einzeln per eseutil /k prüfen
Was haltet ihr davon?
