Exchange 2016 Disc Space läuft schnell voll

[TheCracked 13]

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

 

 

  

[NorbertFe 2.034]

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.

bearbeitet 19. November 2018 von NorbertFe

[TheCracked 13]

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?

 

 

bearbeitet 19. November 2018 von TheCracked

[Nobbyaushb 1.471]

Losgelöst von deinem Problem bist du mit CU8 aber auch schon lange aus dem Support...

[zahni 554]

vssadmin list shadows

 

Dann gucken, wer das erzeugt (hat)..

[Squire 261]

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.

 

 

[NorbertFe 2.034]

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

[TheCracked 13]

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. 

 

bearbeitet 20. November 2018 von TheCracked

[zahni 554]

Dann lies Die die Doku durch. Ich kenne mich mit Veam nicht aus. Vielleicht ist  da irgendeine Snapshot-Funktion aktiviert.

[Squire 261]

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

 

[TheCracked 13]

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.

 

bearbeitet 22. November 2018 von TheCracked

[Squire 261]

hob ich doch oben geschrieben

[djmaker 95]

Nimm das Veeam Verzeichnis in der VM aus Scan-Ausnahme im Virenscanner auf.  Parallel solltest Du den Veeam-Support kontaktieren.

[TheCracked 13]

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.