10
Chkdsk auf SBS 2003 Servern - Risiko oder sinnvoll wenn Fehler gefunden wurden?
Hallo!
Es gibt zwar schon 2,3 Artikel, allerdings sind die alle schon sehr alt bzw. betreffen nur Teile meiner Frage. Deswegen geh ich nochmal auf Nummer sicher
SBS 2003 Server mit laufendem Exchange drauf
Raid 1 läuft - und ist laut Tool in Ordnung
Wärhrend eines angekündigten Tage ohne Internet habe ich die Zeit für die Wartung genützt. Zusätzliche Sicherungen, Updates usw... dabei kam die Frage von chkdsk auf. Ich habe chkdsk über cmd am Systemlaufwerk gestartet und dabei wurden Fehler erkannt. Aus "alter Gewohnheit" hab ich gleich chkdsk für den nächsten Systemstart vorgesehen.
Als ich den Server dann neu startete, kam (neben meinem Herzstillstand) die Meldung "Active Directory stellt Index wieder her". Nach gut einer Stunde Wartezeit startete der Server und nach einem neuen reboot funktionierte alles wieder einwandfrei.
Das einzige was geblieben ist, sind die Fehlermeldungen von chkdsk. Ebenfalls auf der zweiten Partition (Files und Exchangedatenbank) werden Fehler gefunden. Allerdings führe ich derzeit kein chkdsk mehr aus.
Ich stelle mir nun die Frage ob man chkdsk überhaupt auf einem Server ausführen sollte. Die Festplatten / Raid sind nach dem was ich sehe - bis eben die Chksk Meldung - in Ordnung. In der Raidverwaltung scheinen auch keine SMART-Fehler oder ähnliches auf. Trotzdem habe ich Bedenken ob ich die Meldungen einfach ignorieren kann!?
Stehe gerade etwas in Gedanken an wie ich mit der Situation umgehen soll. (Ausser natürlich gleich mal noch ein zusätzliches komplettes Backup zu machen)
Besten Danke für allfällige Ideen und Gedanken
Es gibt zwar schon 2,3 Artikel, allerdings sind die alle schon sehr alt bzw. betreffen nur Teile meiner Frage. Deswegen geh ich nochmal auf Nummer sicher
SBS 2003 Server mit laufendem Exchange drauf
Raid 1 läuft - und ist laut Tool in Ordnung
Wärhrend eines angekündigten Tage ohne Internet habe ich die Zeit für die Wartung genützt. Zusätzliche Sicherungen, Updates usw... dabei kam die Frage von chkdsk auf. Ich habe chkdsk über cmd am Systemlaufwerk gestartet und dabei wurden Fehler erkannt. Aus "alter Gewohnheit" hab ich gleich chkdsk für den nächsten Systemstart vorgesehen.
Als ich den Server dann neu startete, kam (neben meinem Herzstillstand) die Meldung "Active Directory stellt Index wieder her". Nach gut einer Stunde Wartezeit startete der Server und nach einem neuen reboot funktionierte alles wieder einwandfrei.
Das einzige was geblieben ist, sind die Fehlermeldungen von chkdsk. Ebenfalls auf der zweiten Partition (Files und Exchangedatenbank) werden Fehler gefunden. Allerdings führe ich derzeit kein chkdsk mehr aus.
Ich stelle mir nun die Frage ob man chkdsk überhaupt auf einem Server ausführen sollte. Die Festplatten / Raid sind nach dem was ich sehe - bis eben die Chksk Meldung - in Ordnung. In der Raidverwaltung scheinen auch keine SMART-Fehler oder ähnliches auf. Trotzdem habe ich Bedenken ob ich die Meldungen einfach ignorieren kann!?
Stehe gerade etwas in Gedanken an wie ich mit der Situation umgehen soll. (Ausser natürlich gleich mal noch ein zusätzliches komplettes Backup zu machen)
Besten Danke für allfällige Ideen und Gedanken
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: 205486
Url: https://administrator.de/contentid/205486
Ausgedruckt am: 23.11.2024 um 01:11 Uhr
10 Kommentare
Neuester Kommentar
Zusatz chkdsk.log
-~-~-~-~-~-~-~-~-~-~-~-~
checkDisk will work now with drive: C:
C:\ Volume Label: System, File System: NTFS
Die Volumebezeichnung lautet System.
CHKDSK überprüft Dateien (Phase 1 von 5)...
10400256400256
400256 Datensätze verarbeitet.
Dateiüberprüfung beendet.
10844844
844 große Datensätze verarbeitet.
1000
0 ungültige Datensätze verarbeitet.
1000
0 E/A-Datensätze verarbeitet.
1044
4 Analysedatensätze verarbeitet.
CHKDSK überprüft Indizes (Phase 2 von 5)...
Die geringe Datendichte im Datensatzsegment 65421 wird korrigiert.
Die geringe Datendichte im Datensatzsegment 65433 wird korrigiert.
Die geringe Datendichte im Datensatzsegment 65435 wird korrigiert.
Die geringe Datendichte im Datensatzsegment 71208 wird korrigiert.
Die geringe Datendichte im Datensatzsegment 73797 wird korrigiert.
Indexeintrag ChkAcc.bak in Index $I30 der Datei 327 wird gelöscht.
Indexeintrag ChkAcc.log in Index $I30 der Datei 327 wird gelöscht.
Indexeintrag edb.log in Index $I30 der Datei 1280 wird gelöscht.
Indexeintrag edb00357.log in Index $I30 der Datei 1280 wird gelöscht.
Indexeintrag edb00358.log in Index $I30 der Datei 1280 wird gelöscht.
Indexeintrag edbtmp.log in Index $I30 der Datei 1280 wird gelöscht.
Indexeintrag MB3AD6~1.XML in Index $I30 der Datei 13282 wird gelöscht.
Indexeintrag MBSchema_0000101150_0000000000.xml in Index $I30 der Datei 13282 wird gelöscht.
Indexeintrag ME8368~1.XML in Index $I30 der Datei 13282 wird gelöscht.
Indexeintrag MetaBase_0000101150_0000000000.xml in Index $I30 der Datei 13282 wird gelöscht.
Indexeintrag fmremstt.dat in Index $I30 der Datei 19280 wird gelöscht.
Indexeintrag dlefmsmscache2.chc in Index $I30 der Datei 19297 wird gelöscht.
Indexeintrag DLEFMS~3.CHC in Index $I30 der Datei 19297 wird gelöscht.
Indexeintrag RecoveryStore.{5C519BFF-ABF0-11E2-93DC-4000210E5412}.dat in Index $I30 der Datei 40685 wird gelöscht.
Indexeintrag RECOVE~1.DAT in Index $I30 der Datei 40685 wird gelöscht.
Indexeintrag {5C519C00-ABF0-11E2-93DC-4000210E5412}.dat in Index $I30 der Datei 40685 wird gelöscht.
Indexeintrag {5C519~1.DAT in Index $I30 der Datei 40685 wird gelöscht.
Indexeintrag DataLog in Index $I30 der Datei 48909 wird gelöscht.
3412729811272981
1272981 Indexeinträge verarbeitet.
Indexüberprüfung beendet.
Es wurden kleinere Inkonsistenzen auf dem Laufwerk festgestellt.
Fehler gefunden. CHKDSK kann im schreibgeschützten Modus nicht
fortgesetzt werden.
Check Disk: Unable to Finish
Laufwerk kann nicht überprüft werden, wiederholen
Fehler mit Laufwerk: C
-~-~-~-~-~-~-~-~-~-~-~-~
checkDisk will work now with drive: C:
C:\ Volume Label: System, File System: NTFS
Die Volumebezeichnung lautet System.
CHKDSK überprüft Dateien (Phase 1 von 5)...
10400256400256
400256 Datensätze verarbeitet.
Dateiüberprüfung beendet.
10844844
844 große Datensätze verarbeitet.
1000
0 ungültige Datensätze verarbeitet.
1000
0 E/A-Datensätze verarbeitet.
1044
4 Analysedatensätze verarbeitet.
CHKDSK überprüft Indizes (Phase 2 von 5)...
Die geringe Datendichte im Datensatzsegment 65421 wird korrigiert.
Die geringe Datendichte im Datensatzsegment 65433 wird korrigiert.
Die geringe Datendichte im Datensatzsegment 65435 wird korrigiert.
Die geringe Datendichte im Datensatzsegment 71208 wird korrigiert.
Die geringe Datendichte im Datensatzsegment 73797 wird korrigiert.
Indexeintrag ChkAcc.bak in Index $I30 der Datei 327 wird gelöscht.
Indexeintrag ChkAcc.log in Index $I30 der Datei 327 wird gelöscht.
Indexeintrag edb.log in Index $I30 der Datei 1280 wird gelöscht.
Indexeintrag edb00357.log in Index $I30 der Datei 1280 wird gelöscht.
Indexeintrag edb00358.log in Index $I30 der Datei 1280 wird gelöscht.
Indexeintrag edbtmp.log in Index $I30 der Datei 1280 wird gelöscht.
Indexeintrag MB3AD6~1.XML in Index $I30 der Datei 13282 wird gelöscht.
Indexeintrag MBSchema_0000101150_0000000000.xml in Index $I30 der Datei 13282 wird gelöscht.
Indexeintrag ME8368~1.XML in Index $I30 der Datei 13282 wird gelöscht.
Indexeintrag MetaBase_0000101150_0000000000.xml in Index $I30 der Datei 13282 wird gelöscht.
Indexeintrag fmremstt.dat in Index $I30 der Datei 19280 wird gelöscht.
Indexeintrag dlefmsmscache2.chc in Index $I30 der Datei 19297 wird gelöscht.
Indexeintrag DLEFMS~3.CHC in Index $I30 der Datei 19297 wird gelöscht.
Indexeintrag RecoveryStore.{5C519BFF-ABF0-11E2-93DC-4000210E5412}.dat in Index $I30 der Datei 40685 wird gelöscht.
Indexeintrag RECOVE~1.DAT in Index $I30 der Datei 40685 wird gelöscht.
Indexeintrag {5C519C00-ABF0-11E2-93DC-4000210E5412}.dat in Index $I30 der Datei 40685 wird gelöscht.
Indexeintrag {5C519~1.DAT in Index $I30 der Datei 40685 wird gelöscht.
Indexeintrag DataLog in Index $I30 der Datei 48909 wird gelöscht.
3412729811272981
1272981 Indexeinträge verarbeitet.
Indexüberprüfung beendet.
Es wurden kleinere Inkonsistenzen auf dem Laufwerk festgestellt.
Fehler gefunden. CHKDSK kann im schreibgeschützten Modus nicht
fortgesetzt werden.
Check Disk: Unable to Finish
Laufwerk kann nicht überprüft werden, wiederholen
Fehler mit Laufwerk: C
Hallo,
Mensch mach ein Vollbackup und leg Dir schon mal ein paar Platten auf Halde und gut ist es, wenn etwas passiert bist Du vorbereitet und wenn nichts passiert hast Du für nächstes Mal schon was vorbereitet.
Und das war schon immer gut, da kann einer sagen was er will.
- Schrank auf Platten raus und in Server rein
- Backup zurück oder einspielen fertig.
Einzig den Backup plan würde ich wenn es denn nur irgend möglich ist erst einmal ändern und auch des öfteren
einmal ein Vollbackup ziehen wollen.
Gruß
Dobby
Mensch mach ein Vollbackup und leg Dir schon mal ein paar Platten auf Halde und gut ist es, wenn etwas passiert bist Du vorbereitet und wenn nichts passiert hast Du für nächstes Mal schon was vorbereitet.
Und das war schon immer gut, da kann einer sagen was er will.
- Schrank auf Platten raus und in Server rein
- Backup zurück oder einspielen fertig.
Einzig den Backup plan würde ich wenn es denn nur irgend möglich ist erst einmal ändern und auch des öfteren
einmal ein Vollbackup ziehen wollen.
Gruß
Dobby
Hi montylein1981,
du wirst eher irgendwann mit Problemen zu kämpfen haben wenn du checkdsk nicht mal ausführst. Laut deinem Log hast du CheckDisk im schreibgeschützten Modus durchlaufen lassen (so kann es keine Fehler beheben).
Die Raid-Tools zumindest von Intel geben nicht sehr viel Info's zum Lebenszustand einer Platte heraus. Mit den smartmontools lassen sich die SMART-Parameter der Platten auch in einem RAID-Verbund (zumindest bei INTEL ICH RAID Controllern) abfragen. So kannst du genauer beurteilen ob eine der Platten bald den Geist aufgibt. Hatte solch einen Fall zuletzt bei einem SBS2003 mit einem RAID1; hier waren unerklärliche Verzögerungen des Systems das Problem (Fehlerkorrekturparameter der Platten stiegen ins unermessliche, trotzdem sagte die Intel RAID-Konsole es wäre alles in Ordnung) - Plattentausch hat hier geholfen.
Hoffen wir aber mal nicht das schlimmste. Kleinere Inkonsistenzen gibt es auch auf normal laufenden PCs immer mal wieder.
Ich würde aber chkdsk auf jeden Fall mal mit der Option /F durchlaufen lassen, damit das Dateisystem wieder konsistent ist. Hatte bisher noch keinen Fall in dem chkdsk irgendetwas beschädigt hätte.
Grüße Uwe
du wirst eher irgendwann mit Problemen zu kämpfen haben wenn du checkdsk nicht mal ausführst. Laut deinem Log hast du CheckDisk im schreibgeschützten Modus durchlaufen lassen (so kann es keine Fehler beheben).
Die Raid-Tools zumindest von Intel geben nicht sehr viel Info's zum Lebenszustand einer Platte heraus. Mit den smartmontools lassen sich die SMART-Parameter der Platten auch in einem RAID-Verbund (zumindest bei INTEL ICH RAID Controllern) abfragen. So kannst du genauer beurteilen ob eine der Platten bald den Geist aufgibt. Hatte solch einen Fall zuletzt bei einem SBS2003 mit einem RAID1; hier waren unerklärliche Verzögerungen des Systems das Problem (Fehlerkorrekturparameter der Platten stiegen ins unermessliche, trotzdem sagte die Intel RAID-Konsole es wäre alles in Ordnung) - Plattentausch hat hier geholfen.
Hoffen wir aber mal nicht das schlimmste. Kleinere Inkonsistenzen gibt es auch auf normal laufenden PCs immer mal wieder.
Ich würde aber chkdsk auf jeden Fall mal mit der Option /F durchlaufen lassen, damit das Dateisystem wieder konsistent ist. Hatte bisher noch keinen Fall in dem chkdsk irgendetwas beschädigt hätte.
Grüße Uwe
Jup - Vollbackup gibs jetzt ein zusätzliches je Woche auf eine Externe.
Ersatzfestplatten für den Notfall bereits bestellt - kann auf Lager auch nicht schden.
Möchte nur nicht jetzt "überreagieren" und gleich alles Tauschen - ist doch ganz schön Arbeit und Fehleranfällig. Stell mir eben hauptsächlich die Frage ob chkdsk überhaupt Server & Raistauglich ist. Und ob es Erfahrungen gibt ob man die Fehler auch auf andere Art und Weise loswerden kann.
Schreibgeschützt war ja Absicht. Wollte nur schauen ob noch Fehler gefunden werden. Als die Meldung "Active Directory stellt Index wieder her" beim Neustart kam, war es nicht schreibgeschützt sondern wurde beim reboot ausgeführt.
Ersatzfestplatten für den Notfall bereits bestellt - kann auf Lager auch nicht schden.
Möchte nur nicht jetzt "überreagieren" und gleich alles Tauschen - ist doch ganz schön Arbeit und Fehleranfällig. Stell mir eben hauptsächlich die Frage ob chkdsk überhaupt Server & Raistauglich ist. Und ob es Erfahrungen gibt ob man die Fehler auch auf andere Art und Weise loswerden kann.
Schreibgeschützt war ja Absicht. Wollte nur schauen ob noch Fehler gefunden werden. Als die Meldung "Active Directory stellt Index wieder her" beim Neustart kam, war es nicht schreibgeschützt sondern wurde beim reboot ausgeführt.
Zitat von @montylein1981:
Stell mir eben hauptsächlich die Frage ob chkdsk überhaupt Server & Raistauglich ist. Und ob es
Erfahrungen gibt ob man die Fehler auch auf andere Art und Weise loswerden kann.
Also, wenn einer sein eigenes Dateisystem am besten kennt, ist das doch der Hersteller(Microsoft). Chkdsk arbeitet bei allen RAIDs das ist egal. Das RAID erledigt der Controller - für das Betriebssystem ist das RAID1 nur ein Laufwerk wie jedes andere auch.Stell mir eben hauptsächlich die Frage ob chkdsk überhaupt Server & Raistauglich ist. Und ob es
Erfahrungen gibt ob man die Fehler auch auf andere Art und Weise loswerden kann.
Jup - Vollbackup gibs jetzt ein zusätzliches je Woche auf eine Externe.
Das ist auch nicht um hier zu klugschei.... von mir gewesen, aber ein Unglück kommteben auch selten alleine. Und wie schön ist es ein zusätzliches Backup zu haben falls mit dem ersten
auch etwas nicht stimmt!
Ersatzfestplatten für den Notfall bereits bestellt - kann auf Lager auch nicht schden.
Kommt der Crash am Freitagabend bist Du in der Regel der Dumme, nur dann wird es auch immerknapp mit "noch schnell was besorgen".
Selbst wenn beim chkdsk etwas passieren sollte Du hast ja jetzt ein Backup und wenn die Platten vor Ort angekommen sind dann ist das ja auch noch machbar! Aber dann hast Du die neuen Platten und bist auf
der sicheren Seite!
Gruß
Dobby
Hi.
Stell mir eben hauptsächlich die Frage ob chkdsk überhaupt Server & Raistauglich ist
Natürlich ist es das. Nur weil irgendwann irgendwo in Foren berichtet wird, dass "nach einem Checkdisk gar nichts mehr ging" oder zumindest weniger als vor dem Checkdisk, muss man nicht glauben, dass MS da etwas Zerstörerisches oder mit Servern (?) oder RAID (??) Inkompatibles einbaut - alles in Ordnung.Zitat von @108012:
Das ist auch nicht um hier zu klugschei.... von mir gewesen,
^^ das passt gut - Vorsorgen is besser als Nachjammern
So noch einmal versucht.
Backup
chkdsk /f
Neustart
Wieder die Fehler gefunden, angezeigt, 2 h Active Diretory wieder hergestellt
Neustart
System läuft - nur die Fehler bleiben....
sehr mysteriös.
nächstes Workaround:
Treiber updaten
SMART Tools genau die Festplatte checken lassen
.. ich berichte weiter - viel. werd ich noch schlau draus.
Backup
chkdsk /f
Neustart
Wieder die Fehler gefunden, angezeigt, 2 h Active Diretory wieder hergestellt
Neustart
System läuft - nur die Fehler bleiben....
sehr mysteriös.
nächstes Workaround:
Treiber updaten
SMART Tools genau die Festplatte checken lassen
.. ich berichte weiter - viel. werd ich noch schlau draus.
Hallo,
chkdsk ist für Fehle rim Dateisystem. Der Raid und die Platten könnenin Ordnung sein, aber das Dateisystem kann dennoch defekt sein.
Die Fehler auf der zwiten Partition werden auch erst dann verschwinden, wenn Du auf dieser chkdsk durchführst.
Um auf Numnmer sicher zu gehen, kannst Du auch einfach den Exchange stoppen und richtg beenden damit die Datenbank offline ist und dann beim eingeschalteeten Server ein Chkdsk machen.
Jeh nach Plattengröße dauert das aber seeeehr lange.
Wie auch immer, erst ein Backup habben.
Gruß
Chonta
chkdsk ist für Fehle rim Dateisystem. Der Raid und die Platten könnenin Ordnung sein, aber das Dateisystem kann dennoch defekt sein.
Die Fehler auf der zwiten Partition werden auch erst dann verschwinden, wenn Du auf dieser chkdsk durchführst.
Um auf Numnmer sicher zu gehen, kannst Du auch einfach den Exchange stoppen und richtg beenden damit die Datenbank offline ist und dann beim eingeschalteeten Server ein Chkdsk machen.
Jeh nach Plattengröße dauert das aber seeeehr lange.
Wie auch immer, erst ein Backup habben.
Gruß
Chonta
