Jump to content
Sign in to follow this  
TheCracked

Exchange 2016 Disc Space läuft schnell voll

Recommended Posts

Hallo Zusammen,

 

ich beobachte das jetzt schon seit Anfang Oktober.

Der Exchange 2016 CU8 belegt in einer Woche ca.10 GB- 20 GB an Speicherplatz.

Anfang des Jahres waren es ca. 1 GB in der Woche!! Das ging bis ende September so.

Ab da hat es ungefähr angefangen, so riesen Sprünge zu machen.

Da keine neuen Postfächer hinzugekommen sind (eher ein paar weniger), kann es also auch nicht daran liegen.

 

Der Exchange liegt komplett auf Laufwerk D (Logs und DB).

Aktuell hat D eine Größe von 600GB.

Belegt sind laut Windows 447GB 

 

Markiere ich alles auf Laufwerk D und schau mir die Eigenschaften an, dann werden mir hier allerdings nur 184 GB als belegt angezeigt.

Wo ist der Rest ? Ich habe alle Systemdateien und ausgeblendete Ordner über die Ordneroption einblenden lassen.

 

Der Exchange wird täglich gesichert, somit werden die Logs auch gekürzt.

VSS ist auch nicht aktiviert auf D.

 

Sobald ich auf D nur noch ca. 50GB freihabe, erscheint in der Ereignisanzeige auch schon ein Fehler, (ID 15006 MSExchangeTransprot) -> back pressure.

 

Wie finde ich heraus, wo hier was zugemüllt wird? 

Installation auf das aktuelle CU ist erst mitte Dezember geplant.

Exchange ist eine VM auf VMware als Wirt.

 

 

Grüße

TC

 

 

  

Share this post


Link to post
Share on other sites

Du hast also alles auf D installiert? Ist definitiv nicht best practice. Nimm dir doch mal ein Tool wie treesize (geht garantiert auch irgendwie mit Powershell) und schau nach, wo der Platz verbraucht wird.

Edited by NorbertFe

Share this post


Link to post
Share on other sites

ja wurde alles auf D installiert.

OK ich schau mal mit treesize ob ich was sehe.

 

edit:

Interessant ist -> SystemVolumeInformation 263,8 GB..

Was läuft hier falsch oder ist das normal?

 

 

Edited by TheCracked

Share this post


Link to post
Share on other sites
vor 11 Stunden schrieb NorbertFe:

Du hast also alles auf D installiert? Ist definitiv nicht best practice. 

 

warum nicht best practice - ich find das durchaus sinnvoll - und MS schreibt dazu das hier "Übernehmen Sie auf der Seite Speicherplatz und Speicherort der Installation den vorgegebenen Installationspfad (C:\Program Files\Microsoft\Exchange Server\V15), oder klicken Sie auf Durchsuchen, um einen anderen Installationspfad auszuwählen.

 

 

Share this post


Link to post
Share on other sites
Gerade eben schrieb Squire:

 

warum nicht best practice - ich find das durchaus sinnvoll - und MS schreibt dazu das hier "Übernehmen Sie auf der Seite Speicherplatz und Speicherort der Installation den vorgegebenen Installationspfad (C:\Program Files\Microsoft\Exchange Server\V15), oder klicken Sie auf Durchsuchen, um einen anderen Installationspfad auszuwählen.

 

 

Hat ja niemand gesagt, dass man es nicht machen kann. Es ist trotzdem nicht best practice. Ich müßte das Dokument jetzt aber auch suchen. Quasi alle Daten lassen sich von Exchange nach der Installation verschieben. Und die executables usw. stören auf C genau null.

 

Bye

Norbert

Share this post


Link to post
Share on other sites
vor 16 Stunden schrieb zahni:

vssadmin list shadows

 

Dann gucken, wer das erzeugt (hat)..

 

 

Inhalte der Schattenkopiesatzkennung: {ca05d1d9-afe9-41cb-9715-41e5a0c5a4a4}
   3 Schattenkopie(n) war(en) enthalten bei der Erstellungszeit:
         19.09.2018 23:13:06
      Schattenkopienkennung: {b85c45b6-4054-4f13-b7f9-3d90e29653ec}
         Ursprüngliches Volume: (\\?\Volume{86e6dfd7-0000-0000-0000-100000000000}\)\\?\Volume{86e6dfd7-0000-0000-0000-100000000000}\
         Schattenkopievolume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
         Quellcomputer: exchange2016.mydomain
         Dienstcomputer: exchange2016.mydomain
         Anbieter: "Microsoft Software Shadow Copy provider 1.0"
         Typ: ApplicationRollback
         Attribute: Permanent, Keine automatische Freigabe, Differenziell, Automatisch wiederhergestellt

      Schattenkopienkennung: {4c93af1b-9e03-4f4e-91a9-bd38675582f8}
         Ursprüngliches Volume: (D:)\\?\Volume{5122a45b-0000-0000-0000-100000000000}\
         Schattenkopievolume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy115
         Quellcomputer: exchange2016.mydomain
         Dienstcomputer: exchange2016.mydomain
         Anbieter: "Microsoft Software Shadow Copy provider 1.0"
         Typ: ApplicationRollback
         Attribute: Permanent, Keine automatische Freigabe, Differenziell, Automatisch wiederhergestellt

      Schattenkopienkennung: {1bb09c75-33f4-41f7-b411-40618fd30b30}
         Ursprüngliches Volume: (C:)\\?\Volume{86e6dfd7-0000-0000-0000-501f00000000}\
         Schattenkopievolume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy58
         Quellcomputer: exchange2016.mydomain
         Dienstcomputer: exchange2016.mydomain
         Anbieter: "Microsoft Software Shadow Copy provider 1.0"
         Typ: ApplicationRollback
         Attribute: Permanent, Keine automatische Freigabe, Differenziell, Automatisch wiederhergestellt

 

VSS ist auf Volume D deaktiviert..

Ich habe da Veeam im Verdacht.. 

 

Sobald das Backup startet für den Exchange, steigt der besagte Ordner wieder um 5-10 GB an. 

 

Edited by TheCracked

Share this post


Link to post
Share on other sites

Veeam macht doch Snapshots beim Backup. Sprich zur Laufzeit pushed der Veeam Backup Server einen Agent in die virtuelle Maschine. Dann wir ein Snapshot erzeugt und die entsprechenden VSS Provider entsprechend getriggert, dass der Snapshot Anwendungskonsistent ist. Der Backupserver zieht dann das Backup aus dem konsistenten Snapshot. Wenn er mit dem Backup der VM fertig ist wird der Agent innerhalb der VM wieder entfernt und anschließend der Snapshot der VM gelöscht.

 

Spricht beim Backup haben die VSS Provider innerhalb der Maschine arbeit und erzeugen deshalb wohl das Datenwachstum auf dem Volume. Nach dem Backup sollten die Snapshots aber wieder aufgelöst sein

 

Share this post


Link to post
Share on other sites

Kurzer Zwischenstand:

 

Löschen der Snapshots mittels 

vssadmin delete shadows /for=d: /all

hat nicht funktioniert. Hier habe ich die Fehlermeldung bekommen:

Fehler: Die gefundenen Snapshots befinden sich außerhalb des für Sie zulässigen Kontextes. Entfernen Sie sie mithilfe der Sicherugnsanwendung von der sie erstellt wurden.

 

Ich konnte diese jedoch mittels

diskshadow

delete shadows all

entfernen.

Der besagte Ordner "System Volume information" war danach komplett leer.

 

Danach habe ich noch einmal ein Testbackup via veeam angestoßen. Es sieht aktuell jetzt so aus dass sobald das Backup anfängt, sich der Ordner " System Volume information" wieder mit ca. 60 GB füllt.

Jedoch wurde dieser wieder komplett gelöscht im laufe des Backups. Ich nehme an, so sollte es auch sein. Ich teste gerade noch einmal ein Backup um zu sehen, ob das dauerhaft so ist.

 

Edited by TheCracked

Share this post


Link to post
Share on other sites

Sieht jetzt wieder alles normal aus.

Die Sicherung über Nacht lief auch normal durch und das Verzeichnis(Snapshot) wurde wie vorgesehen (Danke für die Info von Squire) geleert.

 

Danke für eure Unterstützung.

 

Share this post


Link to post
Share on other sites
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...