[Exchange] storage group ongelofelijk groot

[Verwijderd]

Beste Tweakers,

Mijn backup tape is ineens volgelopen. Als ik bekijk waardoor, dan komt dit door een 41 GB grote "Microsoft Information Store\First Storage Group" Ik neem dus aan de exchange data.

Als ik alle mailboxen bij elkaar optel dan kom ik aan 1,7 GB. Ik heb dus geen idee waarom deze exchange store zo groot moet zijn.

Het is een SBS 2003 server met de normale SBS Backup (die onderwater NTBackup gebruikt). Ook Exchange wordt van SBS 2003 gebruikt. Wel staat Full Text Indexing aan, wat misschien iets verklaren kan, maar zelfs met ADMIN zegt hij dat ik dat niet mag beheren. Ook iets waar ik momenteel even helemaal niets van snap.

Ik heb de server al gereboot en de Exchange services gestopt en gestart, maar niks lijkt te werken. De backup blijft een exchange storage group van 41 GB backuppen. Ik durf eigenlijk niet echt zomaar dingen uit die Exchange mappen te wissen ofzo dus hoop op hulp.

Iemand enig idee?

[sanfranjake]

Dat kan dunkt mij niet je store zelf zijn, want standaard kan 'ie maximaal 16 GB worden, en na Exchange 2003 SP2 18 gig tenzij je 'm zelf groter maakt (tot 75 GB). Heb je op de schijf ook zo'n grote store?
Misschien even Offline Defragmentatie proberen? http://www.microsoft.com/.../tips/defragmentation.asp

[Verwijderd]

is je information store zo groot of zijn het je logfiles? SBS zou als de database boven de 16 gig komt gewoon netjes moeten stoppen. Staan er nog meldingen in je event log?

[ Voor 51% gewijzigd door Verwijderd op 20-10-2005 20:44 ]

[Verwijderd]

Volgens mij trunced hij de log files niet na een backup ofzo. Dit is wat het backup report aangeeft:

Backup Type: Normal

Backup started on 19-10-2005 at 23:16.
Backup completed on 20-10-2005 at 2:14.
Directories: 16833
Files: 192924
Bytes: 41.390.954.733
Time: 2 hours, 58 minutes, and 46 seconds
Backup of "BEDRIJF\Microsoft Information Store\First Storage Group"
Backup set #3 on media #1
Backup description: "SBS Backup created on 19-10-2005 at 22:30"
Media name: "Media created 19-10-2005 at 22:30"

Dat is dus gewoon 41 GB aan data... tape meteen vol. Hij zegt er verder niet specifiek iets bij, alleen verderop in het backup verhaal krijgt hij nu:

Backup started on 20-10-2005 at 2:14.
The requested media failed to mount. The operation was aborted.
The operation was ended.
Backup completed on 20-10-2005 at 2:23.
Directories: 0
Files: 2
Bytes: 1.224.734.440
Time: 8 minutes and 43 seconds

Na zoeken blijkt dit te komen omdat de tape vol is gelopen. Kan ik me wel wat bij voorstellen want hij is 32 GB native en 75 GB compressed.Het event log verwijst naar dit backup log en geeft geen aanvullende info.

[ Voor 6% gewijzigd door Verwijderd op 20-10-2005 20:47 ]

[Jazzy]

In dat geval, kijk erg goed uit met de operaties die je nu gaat doen. Offline defrag en dergelijke houden altijd een risico in en je weet nooit wat je tegen komt. Zorg in ieder geval dat je een extra (en dit keer een goede ) backup maakt voordat je gaat sleutelen.

[Verwijderd]

Tnx voor de tip. Dat offline defrag lijkt wel eng . Niet iets om nu 's avonds nog even snel te doen. Kan je niet gewoon Exchange /PurgeLogs zeggen ofzo?? + als ik de server reboot, zijn dan de storages ook ge de-mount en weer ge mount? Ik had gelezen dat dat ook nog kon helpen, maar het leek mij dat dit door de reboot toch ook al gebeurd zou zijn.

[axis]

En je backup voltooit dus ook niet omdat het niet op de tape past? Kijk eens in de folder waar je store files staan (.edb en .stm file uit mijn hoofd?) Welke files zijn zo groot? Zijn het alleen die 5mb logfiles?

Anders zou je als je diskspace op je netwerk over hebt even een full backup kunnen doen met ntbackup, als die klaar is zou exchange al die logfiles moeten truncaten, en houd je dus nog maar een store van 2GB ofzo over lijkt me.

[axis]

Ik heb trouwens op al m'n server naast de standaard tools als TCPView en FileMon enzo ook SpaceMonger staan (stand alone .exe), daarmee kun je dus ook heel snel zien wat er nou zo groot is op je schijf..

[ Voor 8% gewijzigd door axis op 20-10-2005 21:13 ]

[Verwijderd]

-> SA

[Verwijderd]

Je kunt de information store service stoppen, dan worden alle logfiles naar de database weggeschreven. Vervolgens alle logfiles veilig naar een andere locatie kopieren, logfiles verwijderen en service weer starten. Eventueel met de stappen die in http://www.msexchange.org...change-log-disk-full.html genoemd worden dubbel checken of je inderdaad alle log files kunt verwijderen.

Heb je toevallig een file level antivirus software draaien en de exchsrvr folders daar niet in uitgesloten?

[ Voor 3% gewijzigd door Verwijderd op 21-10-2005 16:08 ]

[fonias]

De offline defrag werkt perfect, je store wordt netjes opgeruimd en kleiner.

[Verwijderd]

Het zijn inderdaad de log files die zo groot groeien. Misschien heeft "Full text indexing" hier wel iets mee te maken. We hebben voor volgende week een offline backup gepland. De virusscanner (Norman) is zo ingesteld dat deze de store niet mag checken, hiervan wordt alleen de exchange integratie gebruikt.

Ik ben alleen bang dat het weer zo enorm hard gaat groeien na de offline defrag. Erg vreemd dat de SBS 2003 backup dit niet truncate. WE hebben al SP1 erop waarin dit volgens de documentatie zou moeten werken.

Als het niet werkt ga ik wel een batch proces achtig iets maken die wekelijks de methode van wilhelmstroker uitvoerd ofzo. Ik las ook tot mijn verbazing dat Exchange op de achtergrond gewoon nog op een JET (access) database draait. Toch ook niet echt de beste DB om zoiets te doen lijkt mij. Ik kan mij ook niet voorstellen dat we de enige zijn die hier zo veel last van hebben.

Bedankt voor alle hulp in elk geval weer!

[Brahiewahiewa]

Verwijderd schreef op zaterdag 22 oktober 2005 @ 23:51:
Het zijn inderdaad de log files die zo groot groeien.

Heb je message tracking aan staan? Zo ja, kijk eens of een een loop kunt identificeren: bijv. een user die z'n mail forward naar een pop3 account die vol is zodat het hele mailtje als non-delivery terugkomt wat weer geforward wordt naar z'n pop3 box die vol is, zodat het hele mailtje terugkomt als non-delivery, etc. etc. Zo niet, zet het eens aan (wel even blijven monitoren, want als je echt een loop hebt, kun je op die tracking logs ook uit je schijfruimte lopen)

Misschien heeft "Full text indexing" hier wel iets mee te maken. We hebben voor volgende week een offline backup gepland. De virusscanner (Norman) is zo ingesteld dat deze de store niet mag checken, hiervan wordt alleen de exchange integratie gebruikt.

Ik ben alleen bang dat het weer zo enorm hard gaat groeien na de offline defrag. Erg vreemd dat de SBS 2003 backup dit niet truncate.

Weet je zeker dat je een full backup draait van zowel je mailbox store als je public store? Als je om een of andere reden hebt besloten je Public Store niet te backuppen, worden je transactie log files nooit gecleared.

WE hebben al SP1 erop waarin dit volgens de documentatie zou moeten werken.

Als het niet werkt ga ik wel een batch proces achtig iets maken die wekelijks de methode van wilhelmstroker uitvoerd ofzo. Ik las ook tot mijn verbazing dat Exchange op de achtergrond gewoon nog op een JET (access) database draait. Toch ook niet echt de beste DB om zoiets te doen lijkt mij.

Die Jet database is volledig geoptimaliseerd voor Exchange (Jet Blue) Als jij een betere database hebt, kun je je nu melden bij Ome Bill