8
Exchange 2013 probleme - festplatte voll
Hallo zusammen,
Ich habe mal wieder schöne Probleme mit Windows Server 2012 R2 und Exchange 2013 SP1.
Offenbar ist die Windows Sicherung des Win-Servers die letzte Woche nicht gelaufen (Ursache noch unklar, aber erstmal zweitrangig). Dadurch wurden die Logfiles des Exchange nicht gelöscht und die Platte ist vollgelaufen, auf der sich die Exchange Datenbank UND die Protokolldateien befinden.
Ich habe mir zur Lösung des Problems diese Seite angeschaut:
https://www.frankysweb.de/exchange-2010-partitionfestplatte-der-datenban ...
Möglichkeit 1 scheidet aus Zeitgründen aktuell aus.
Möglichkeit 2 wäre schön, aber es gab keinen Clean Shutdown, sondern einen Dirty Shutdown.
Ich wollte dann ganz gerne ein soft repair durchführen, damit ich den status clean shutdown bekomme, aber das war nicht erfolgreich - ich vermute mal, weil die platte ja voll ist auf der DB und Logfiles liegen.
ich habe dann einen teil der log-files (ein paar GB, die ältesten) auf eine andere partition verschoben, in der hoffnung, dass die vielleicht für einen soft-repair unnötig seien.
dem war aber nicht so.
wollte sie also wieder zurückkopieren, nun passt nicht mehr alles auf die platte, da im unterordner des datenbankverzeichnisses offenbar wenige MB hinzugekommen sind.
*juhuuu*
Frage? Wie krieg ich das dingen nun schnellstmöglichst wieder ans rennen?
(ich weiss, hier schreiben viele lieber kommentare und belehrungen [nur lösen die leider das akute problem nicht] als lösungen - diese schickt dann bitte per PN, les ich mir dann später durch
. Hier bitte ich um Lösungen, da die Zeit etwas drängt - vielen Dank.)
Gruß,
Colt
Ich habe mal wieder schöne Probleme mit Windows Server 2012 R2 und Exchange 2013 SP1.
Offenbar ist die Windows Sicherung des Win-Servers die letzte Woche nicht gelaufen (Ursache noch unklar, aber erstmal zweitrangig). Dadurch wurden die Logfiles des Exchange nicht gelöscht und die Platte ist vollgelaufen, auf der sich die Exchange Datenbank UND die Protokolldateien befinden.
Ich habe mir zur Lösung des Problems diese Seite angeschaut:
https://www.frankysweb.de/exchange-2010-partitionfestplatte-der-datenban ...
Möglichkeit 1 scheidet aus Zeitgründen aktuell aus.
Möglichkeit 2 wäre schön, aber es gab keinen Clean Shutdown, sondern einen Dirty Shutdown.
Ich wollte dann ganz gerne ein soft repair durchführen, damit ich den status clean shutdown bekomme, aber das war nicht erfolgreich - ich vermute mal, weil die platte ja voll ist auf der DB und Logfiles liegen.
ich habe dann einen teil der log-files (ein paar GB, die ältesten) auf eine andere partition verschoben, in der hoffnung, dass die vielleicht für einen soft-repair unnötig seien.
dem war aber nicht so.
wollte sie also wieder zurückkopieren, nun passt nicht mehr alles auf die platte, da im unterordner des datenbankverzeichnisses offenbar wenige MB hinzugekommen sind.
*juhuuu*
Frage? Wie krieg ich das dingen nun schnellstmöglichst wieder ans rennen?
(ich weiss, hier schreiben viele lieber kommentare und belehrungen [nur lösen die leider das akute problem nicht] als lösungen - diese schickt dann bitte per PN, les ich mir dann später durch
. Hier bitte ich um Lösungen, da die Zeit etwas drängt - vielen Dank.)Gruß,
Colt
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 276034
Url: https://administrator.de/contentid/276034
Printed on: April 18, 2024 at 11:04 o'clock
8 Comments
Latest comment
Hallo @coltseavers,
solche Sachen sind natürlich immer "unpassend" und "unschön".
Ist der Server direkt auf Blech oder in einer Virtuellen Maschine?
Bei VM würde ich die HDD auf dem der Exchange liegt vergrößern und dann anschließend erweitern.
Somit solltest du wieder ein bisschen Luft haben und den Exchange zum laufen bringen ...
Anschließend sofort ein Backup anwerfen, damit die Logs gelöscht werden oder manuell bereinigen.
Clean Shutdown und die nicht benötigten Logs wegkopieren und dann löschen und nicht nur löschen ...
... so kannst du im Fehlerfall immer noch auf die Logs zugreifen
... Ebenfalls Finger weg vom Verschieben
Wenn die Maschine direkt auf Blech läuft würde ich mal mit TressizeFree die Platte analyisieren.
Vielleicht gibt es ja noch irgendwo auf der Platte Platz den man schnell frei machen könnte ...
... denke hier an Windows-Update-Bereinigung, WSUS-DB's (falls vorhanden), TEMP-Files, etc ...
Gruß
@kontext
solche Sachen sind natürlich immer "unpassend" und "unschön".
Ist der Server direkt auf Blech oder in einer Virtuellen Maschine?
Bei VM würde ich die HDD auf dem der Exchange liegt vergrößern und dann anschließend erweitern.
Somit solltest du wieder ein bisschen Luft haben und den Exchange zum laufen bringen ...
Anschließend sofort ein Backup anwerfen, damit die Logs gelöscht werden oder manuell bereinigen.
Clean Shutdown und die nicht benötigten Logs wegkopieren und dann löschen und nicht nur löschen ...
... so kannst du im Fehlerfall immer noch auf die Logs zugreifen
... Ebenfalls Finger weg vom Verschieben
Wenn die Maschine direkt auf Blech läuft würde ich mal mit TressizeFree die Platte analyisieren.
Vielleicht gibt es ja noch irgendwo auf der Platte Platz den man schnell frei machen könnte ...
... denke hier an Windows-Update-Bereinigung, WSUS-DB's (falls vorhanden), TEMP-Files, etc ...
Gruß
@kontext
Hallo kontext,
vielen Dank für Deine schnelle Hilfe!
Es ist so, dass der Exchange zwar in einer VM läuft, er greift jedoch direkt auf eine nicht virtuelle Platte zu (aus performancegründen).
Idde 1:
Überlege schon, den ganzen kram vorübergehend auf eine größere Platte zu schaufeln, um darauf dann die sache wieder ans laufen zu bringen.
aber dann müssen im exchange ja vermutlich erstmal wieder die pfade für DB und log-files aktualisiert werden. Aber gut, lässt sich nachschlagen.
Idee 2:
Es gibt ja auch die Möglichkeit eine Platte durch eine andere zu vergrößern, sprich 1 partition über 2 platten zu erstrecken.
dann spare ich mir 500GB Logfiles zu schaufeln...
Empfehlung?
gruß,
Colt
vielen Dank für Deine schnelle Hilfe!
Es ist so, dass der Exchange zwar in einer VM läuft, er greift jedoch direkt auf eine nicht virtuelle Platte zu (aus performancegründen).
Idde 1:
Überlege schon, den ganzen kram vorübergehend auf eine größere Platte zu schaufeln, um darauf dann die sache wieder ans laufen zu bringen.
aber dann müssen im exchange ja vermutlich erstmal wieder die pfade für DB und log-files aktualisiert werden. Aber gut, lässt sich nachschlagen.
Idee 2:
Es gibt ja auch die Möglichkeit eine Platte durch eine andere zu vergrößern, sprich 1 partition über 2 platten zu erstrecken.
dann spare ich mir 500GB Logfiles zu schaufeln...
Empfehlung?
gruß,
Colt
Zu deiner ersten Idee - das würde ich machen wenn der Exchange läuft
Da du jedoch einen Exchange mit einem Dirty Shutdown hast und außerdem schon ein Teil der Logfiles wegkopiert hast, würde ich das eher lassen ...
... wie gesagt - solche Sachen mache ich normalerweise immer nur dann wenn sich so ein Problem abzeichnet
... da hat man genug Zeit und kann das in aller Ruhe machen - was bei einem sauberen + funktionierenden Exchange ja kein Problem darstellt
Zu deiner zweiten Idee - als Quick & Dirty Lösung würde ich es so machen ...
... dann hast du wieder genügend Platz zur Verfügung damit der Exchange wieder läuft
... Würde aber schauen das du das schnellstmöglich wieder zurückbaust
Daher - Tipp2 inkl. anschließendem Backup (damit die Logs gelöscht werden) und alles wieder zurückbauen.
Oder - du erstellst eine neue größerer Platte die du der Maschine direkt durchschleifst ...
... anschließend klonst du die zu kleine Platte auf die größere Platte - somit ersparst du dir die ganze Pfadanpassungsgeschichte ...
... Alles in Allem ist das immer eine OP am offenen Herz wo was schiefgehen kann - das musst du dann am Schluss entscheiden
Gruß
@kontext
Da du jedoch einen Exchange mit einem Dirty Shutdown hast und außerdem schon ein Teil der Logfiles wegkopiert hast, würde ich das eher lassen ...
... wie gesagt - solche Sachen mache ich normalerweise immer nur dann wenn sich so ein Problem abzeichnet
... da hat man genug Zeit und kann das in aller Ruhe machen - was bei einem sauberen + funktionierenden Exchange ja kein Problem darstellt
Zu deiner zweiten Idee - als Quick & Dirty Lösung würde ich es so machen ...
... dann hast du wieder genügend Platz zur Verfügung damit der Exchange wieder läuft
... Würde aber schauen das du das schnellstmöglich wieder zurückbaust
Daher - Tipp2 inkl. anschließendem Backup (damit die Logs gelöscht werden) und alles wieder zurückbauen.
Oder - du erstellst eine neue größerer Platte die du der Maschine direkt durchschleifst ...
... anschließend klonst du die zu kleine Platte auf die größere Platte - somit ersparst du dir die ganze Pfadanpassungsgeschichte ...
... Alles in Allem ist das immer eine OP am offenen Herz wo was schiefgehen kann - das musst du dann am Schluss entscheiden
Gruß
@kontext
Hi ho!
Soo, aktueller Stand: Habe ne größere, externe Platte über den Host angeschlossen, und diese dann in die VM integriert.
Habe dann die DB rübergeschoben. Somit war genug Platz, um die bereits verschobenen Log-Files dann auch wieder in das ursprüngliche Log-Verzeichnis zurückzuholen. Nun kopiere ich auch die Log-Files auf die externe Platte.
Danach hoffe ich ein soft-repair durchführen zu können...
Ich melde mich wieder! Vielen Dank nochmal bis hierher!
Anmerkung:
Warum nicht nur die DB rübergeschoben? Dadurch wurden auf der zuvor vollen Platte nur 40GB frei, die dann für neue Log-Files zur Verfügung gestanden hätten.
Da das Backup aber etliche Stunden dauern dürfte (mehrere 100GB über 100Mbit/s-LAN), könnte der Platz währenddessen schon wieder knapp werden. Geht dann beim Backup was schief, gehts wieder krachen.
Gruß,
Colt
Soo, aktueller Stand: Habe ne größere, externe Platte über den Host angeschlossen, und diese dann in die VM integriert.
Habe dann die DB rübergeschoben. Somit war genug Platz, um die bereits verschobenen Log-Files dann auch wieder in das ursprüngliche Log-Verzeichnis zurückzuholen. Nun kopiere ich auch die Log-Files auf die externe Platte.
Danach hoffe ich ein soft-repair durchführen zu können...
Ich melde mich wieder! Vielen Dank nochmal bis hierher!
Anmerkung:
Warum nicht nur die DB rübergeschoben? Dadurch wurden auf der zuvor vollen Platte nur 40GB frei, die dann für neue Log-Files zur Verfügung gestanden hätten.
Da das Backup aber etliche Stunden dauern dürfte (mehrere 100GB über 100Mbit/s-LAN), könnte der Platz währenddessen schon wieder knapp werden. Geht dann beim Backup was schief, gehts wieder krachen.
Gruß,
Colt
Hallo,
es ist alles deutlich schllimmer als gedacht.
Zunächst einmal konnte ich (aus zeitlichen Gründen) die Ursache noch nicht klären, warum überhaupt das Windows-Backup nicht durchgelaufen ist.
Zuletzt lief es vor 1 Woche.
Auf einer 500GB-Platte liegt eine 40GB-Datenbank. In der letzten Woche ist der restliche Platz der Platte mit Logfiles vollgelaufen. Bei einer kleinen Firma mit 15 Postfächern schon eher eine sehr ungewöhnlich hohe Zahl!
Also irgendwas läuft da generell schief.
Weiterhin ist schief gelaufen, dass sich der Exchange nicht ordentlich abgeschaltet hat, als die Festplatte volllief. Normalerweise sollte er rechtzeitig seinen Dienst einstellen, denn eine volllaufende Festplatte darf eigentlich nicht die ganze Datenbank zerschießen. Merkwürdig alles!
Der soft-repair hat dann natürlich auch nicht funktioniert.
Also hard-repair gemacht. Seitdem sind 2 Postfächer stark beschädigt. Eins läuft, aber auch nur instabil, das andere lässt sich gar nicht öffnen.
Ich habe dann in den sauren Apfel gebissen und bei Microsoft einen kostenpflichtigen Support-Fall geöffnet, und um Hilfe gebeten, wie ich an diese 2 Postfächer wieder rankomme, denn ich habe ja eigentlich alle Daten: ein Backup von vor einer Woche und alle Logfiles seitdem bis zum Crash gestern.
Microsoft hat sich auch gemeldet, aber die meinten dann: wir helfen generell nicht bei Datenbank-Wiederherstellungen. Lustig, oder?
Nun steh ich da - hab ein sündhaft teures System, und kein Schwein, das mir hilft. Dafür kauft man proprietäre Software, damit man auch mal so gar keinen Support bekommt, wenn man ihn braucht... DANKE MICROSOFT!
(Ich mache nun einen neuen Fall auf, indem ich um Hilfe bitte, wie ich nun am besten Verfahren soll).
Vielen Dank soweit für Deine Hilfe, kontext !!!
Gruß,
Colt
es ist alles deutlich schllimmer als gedacht.
Zunächst einmal konnte ich (aus zeitlichen Gründen) die Ursache noch nicht klären, warum überhaupt das Windows-Backup nicht durchgelaufen ist.
Zuletzt lief es vor 1 Woche.
Auf einer 500GB-Platte liegt eine 40GB-Datenbank. In der letzten Woche ist der restliche Platz der Platte mit Logfiles vollgelaufen. Bei einer kleinen Firma mit 15 Postfächern schon eher eine sehr ungewöhnlich hohe Zahl!
Also irgendwas läuft da generell schief.
Weiterhin ist schief gelaufen, dass sich der Exchange nicht ordentlich abgeschaltet hat, als die Festplatte volllief. Normalerweise sollte er rechtzeitig seinen Dienst einstellen, denn eine volllaufende Festplatte darf eigentlich nicht die ganze Datenbank zerschießen. Merkwürdig alles!
Der soft-repair hat dann natürlich auch nicht funktioniert.
Also hard-repair gemacht. Seitdem sind 2 Postfächer stark beschädigt. Eins läuft, aber auch nur instabil, das andere lässt sich gar nicht öffnen.
Ich habe dann in den sauren Apfel gebissen und bei Microsoft einen kostenpflichtigen Support-Fall geöffnet, und um Hilfe gebeten, wie ich an diese 2 Postfächer wieder rankomme, denn ich habe ja eigentlich alle Daten: ein Backup von vor einer Woche und alle Logfiles seitdem bis zum Crash gestern.
Microsoft hat sich auch gemeldet, aber die meinten dann: wir helfen generell nicht bei Datenbank-Wiederherstellungen. Lustig, oder?
Nun steh ich da - hab ein sündhaft teures System, und kein Schwein, das mir hilft. Dafür kauft man proprietäre Software, damit man auch mal so gar keinen Support bekommt, wenn man ihn braucht... DANKE MICROSOFT!
(Ich mache nun einen neuen Fall auf, indem ich um Hilfe bitte, wie ich nun am besten Verfahren soll).
Vielen Dank soweit für Deine Hilfe, kontext !!!
Gruß,
Colt
Du hast nicht zufällig ein Backup gemacht, bevor du den Exchange auf die externe Platte verschoben hast?
Sonst hätte ich jetzt gesagt - Backup einspielen und nochmals neu starten ...
Die Problematik ist wahrscheinlich der Dirty Shutdown und das verschieben der Files auf die externe HDD...
... Wenn die externe HDD noch einen anderen Laufwerksbuchstaben hat, wird es den Exchange zerwürfelt haben
Ab jetzt ist jedoch große Vorsicht angeboten und es sollte auf jeden Fall ein Exchange-Spezialist dran ...
... evtl. gibt es ja jemand in deiner Umgebung der dich unterstützen könnte
... ansonsten musst du wirklich warten ob sich MS meldet und was da raus kommt
Gruß
@kontext
Sonst hätte ich jetzt gesagt - Backup einspielen und nochmals neu starten ...
Die Problematik ist wahrscheinlich der Dirty Shutdown und das verschieben der Files auf die externe HDD...
... Wenn die externe HDD noch einen anderen Laufwerksbuchstaben hat, wird es den Exchange zerwürfelt haben
Ab jetzt ist jedoch große Vorsicht angeboten und es sollte auf jeden Fall ein Exchange-Spezialist dran ...
... evtl. gibt es ja jemand in deiner Umgebung der dich unterstützen könnte
... ansonsten musst du wirklich warten ob sich MS meldet und was da raus kommt
Gruß
@kontext
Also das Verschieben der Datenbank habe ich mit move-database gemacht - das lief auch problemlos durch. Das Verschieben der Logfiles ging jedoch nicht.
Ich habe dann den Datenbankordner gesichert sowie den Logfile-Ordner, bevor ich soft- und hard-repair durchgeführt habe.
Die Repair-Funktion konnte ich ja nicht auf dem ursprünglichen Laufwerk durchführen, weil das war ja rappelvoll.
Und "mal eben" eine zweite Platte drankoppeln, und die Partition über die zweite Platte zu erweitern schien mir risikovoller als die Variante, die ich dann durchgeführt habe.
Das Problem beim soft-repair war vermutlich, dass ihm bei den Logfiles die jüngsten 1-2 Dateien gefehlt haben, weil die nicht mehr auf die Platte gepasst haben.
Das Fehlen der letzten Log-Datei dürfte ja wahrscheinlich schon ausreichen, damit der soft-repair fehlschlägt, oder?
Und beim hard repair - da wird doch gar nicht mehr auf die Logfiles zugegriffen, sondern nur noch die DB-Datei bearbeitet, in dem alle defekten Bereiche repariert bzw gelöscht werden, oder?
Also ich könnte nochmal hergehen und die Situation unmittelbar nach dem Crash wiederherstellen. Alles auf eine Partition schaufeln, diese dann über eine 2. Platte vergrößern, und dann nochmal das Prozedere durchgehen. Meinst Du der soft-repair könnte trotz 1-2 fehlenden Logfiles klappen, oder helfen der Mühle beim Hard-Repair auch die soweit vorhandenen Logfiles weiter?
Irgendwann hab ich ja auch ein kleines Zeitproblem. In 24 Stunden sollte alles wieder laufen...
Gruß,
Colt
Ich habe dann den Datenbankordner gesichert sowie den Logfile-Ordner, bevor ich soft- und hard-repair durchgeführt habe.
Die Repair-Funktion konnte ich ja nicht auf dem ursprünglichen Laufwerk durchführen, weil das war ja rappelvoll.
Und "mal eben" eine zweite Platte drankoppeln, und die Partition über die zweite Platte zu erweitern schien mir risikovoller als die Variante, die ich dann durchgeführt habe.
Das Problem beim soft-repair war vermutlich, dass ihm bei den Logfiles die jüngsten 1-2 Dateien gefehlt haben, weil die nicht mehr auf die Platte gepasst haben.
Das Fehlen der letzten Log-Datei dürfte ja wahrscheinlich schon ausreichen, damit der soft-repair fehlschlägt, oder?
Und beim hard repair - da wird doch gar nicht mehr auf die Logfiles zugegriffen, sondern nur noch die DB-Datei bearbeitet, in dem alle defekten Bereiche repariert bzw gelöscht werden, oder?
Also ich könnte nochmal hergehen und die Situation unmittelbar nach dem Crash wiederherstellen. Alles auf eine Partition schaufeln, diese dann über eine 2. Platte vergrößern, und dann nochmal das Prozedere durchgehen. Meinst Du der soft-repair könnte trotz 1-2 fehlenden Logfiles klappen, oder helfen der Mühle beim Hard-Repair auch die soweit vorhandenen Logfiles weiter?
Irgendwann hab ich ja auch ein kleines Zeitproblem. In 24 Stunden sollte alles wieder laufen...
Gruß,
Colt
Ich könnt mir vorstellen, das wenn alle Logfiles auf der HDD liegen und die Platte wieder genügend Speicher vorhanden hat, dass eine Soft-Repair zum Ziel führt - es könnte sogar sein, dass der Exchange wieder läuft und die DB normal einhängt ...
Wenn das der Fall ist kannst du einen manuellen Shutdown machen - dann solltest du auch einen Clean-Shutdown State haben.
Anschließend schauen welche Log-Files benötigt werden und die anderen verschieben.
Platte wieder verkleinern und Exchange wieder anschmeißen.
Alles in Allem eine Verfahrene Situation - vor allem wegen dem Zeitaspekt ...
Gruß
@kontext
Wenn das der Fall ist kannst du einen manuellen Shutdown machen - dann solltest du auch einen Clean-Shutdown State haben.
Anschließend schauen welche Log-Files benötigt werden und die anderen verschieben.
Platte wieder verkleinern und Exchange wieder anschmeißen.
Alles in Allem eine Verfahrene Situation - vor allem wegen dem Zeitaspekt ...
Gruß
@kontext
