[SBS2003] Defragmentatie Mailstore

[DaVaRiOuS]

Ik was/ben van plan om een offline defrag uit te voeren op de mailstore en heb hiervoor nu alle nodige maatregelen getroffen.

De optie bij de eigenschappen van de mailstore > Limits, daar stond het vinkje (nog) aan dat de verwijderde mailboxen en items niet verwijderd worden.
Het bewaarbeleid stond op 30 dagen.

De volgende taken uitgevoerd als voorbereiding:

1). Vinkje uitgezet bij de eigenschappen van Mailstore > Limits (permanent verwijderen van verwijderde items en mailboxen), en het bewaarbeleid op 1 dag gezet.
1). Een volledige back-up van de mailstore gemaakt via de standaard brick level back-up.
2). Met Exmerg voor iedere mailbox een .pst geexporteerd
3). Eventlog bekeken, deze gaf het volgende aan:
The database "First Storage Group\Public Folder Store (SBS2003)" has 22 megabytes of free space after online defragmentation has terminated.

Maar met Exmerge geeft die aan dat de totale grootte 15gb is en op de harddisk is het bestand 'Priv1.edb' ruim 27gb. (Priv1.stm is overigens bijna 1gb).

Er is namelijk behoorlijk wat data opgeschoont en oude gebruikers+mailboxen zijn verwijderd.
Dus hij geeft nu dus een verschil aan van 12gb die ik zou moeten kunnen gaan winnen, maar in de eventlog zegt die 22mb ?

Iemand enig iedee?

Tevens nog 1 'klein' extra opvallend iets..
1 mailbox is in Exchange Manager 17,5gb en met exmerg export die maar iets meer dan 2gb ?

Ik lees nu net dat Exmerge geen .pst files aanmaakt groter dan iets meer dan 2gb.
Dit is nou ook niet bepaald handig?
Je kan dan met Exmerge wel aan de hand van datum selectie aangeven wat je wilt exporteren, maar het zou handiger zijn als het programma als volgt werkt:
Exmerge exporteert tot 2gb, maar als een mailbox 17,5gb is, dan hakt die deze steeds automatisch in stukjes van 2gb aan .pst, dus dan zou je bijv. het volgende krijgen: user_part01.pst, user_part02.pst, etc...

[ Voor 19% gewijzigd door DaVaRiOuS op 11-05-2010 20:41 ]

[sanfranjake]

DaVaRiOuS schreef op dinsdag 11 mei 2010 @ 20:22:
Ik was/ben van plan om een offline defrag uit te voeren op de mailstore en heb hiervoor nu alle nodige maatregelen getroffen.

Waarom zou je dit doen Dit is een actie die je alleen uitvoert als er een dringende reden voor is, niet op reguliere basis.

De optie bij de eigenschappen van de mailstore > Limits, daar stond het vinkje (nog) aan dat de verwijderde mailboxen en items niet verwijderd worden.
Het bewaarbeleid stond op 30 dagen.

Kan inderdaad handig zijn, zorg wel dat je back-ups goed op orde zijn. Op een smallbusinesserver staat standaard circular logging ook UIT!

1). Een volledige back-up van de mailstore gemaakt via de standaard brick level back-up.

Bricklevel is niet hetzelfde als storelevel. Afhankelijk van welk pakket je gebruikt mis je een klein beetje tot en met heel erg veel metadata die je echt nodig hebt.

2). Met Exmerg voor iedere mailbox een .pst geexporteerd

Nutteloze operatie. Je had al een bricklevelbackup wat in feite hetzelfde is. Ook heb je een store-level nodig, want een offline-defrag gaat je storefiles opnieuw opbouwen.

3). Eventlog bekeken, deze gaf het volgende aan:
The database "First Storage Group\Public Folder Store (SBS2003)" has 22 megabytes of free space after online defragmentation has terminated.

Maar met Exmerge geeft die aan dat de totale grootte 15gb is en op de harddisk is het bestand 'Priv1.edb' ruim 27gb. (Priv1.stm is overigens bijna 1gb).

Er is namelijk behoorlijk wat data opgeschoont en oude gebruikers+mailboxen zijn verwijderd.
Dus hij geeft nu dus een verschil aan van 12gb die ik zou moeten kunnen gaan winnen, maar in de eventlog zegt die 22mb ?

Iemand enig iedee?

Ik krijg heel erg sterk het idee dat je geen flauw idee hebt wat je nou precies aan het doen hebt, want dit is erg logisch als je appels en peren (in dit geval de eventlogs over de public folder store en de grootte op schijf van de mailbox database) probeert te vergelijke. Zoek naar eens naar een event 1221 van de Private store

Tevens nog 1 'klein' extra opvallend iets..
1 mailbox is in Exchange Manager 17,5gb en met exmerg export die maar iets meer dan 2gb ?

Ik lees nu net dat Exmerge geen .pst files aanmaakt groter dan iets meer dan 2gb.
Dit is nou ook niet bepaald handig?
Je kan dan met Exmerge wel aan de hand van datum selectie aangeven wat je wilt exporteren, maar het zou handiger zijn als het programma als volgt werkt:
Exmerge exporteert tot 2gb, maar als een mailbox 17,5gb is, dan hakt die deze steeds automatisch in stukjes van 2gb aan .pst, dus dan zou je bijv. het volgende krijgen: user_part01.pst, user_part02.pst, etc...

Helemaal logisch. Dit is een limitatie van Exmerge. Dit is geproduceerd in de tijd dat 2GB een oneindige hoeveelheid data was, en Exchange stores over het algemeen niet groter dan 16GB werden. Een ansi-pst kan gewoon niet groter dan 2GB worden. De unicode-pst's vanaf Outlook 2003 wel.

Exmerge is in Exchange 2007 en hoger geintegreerd in de powershell (import-mailbox, export-mailbox). Dit kan je prima tegen Exchange 2003 aan draaien. Je moet dan een pc installeren met
1. Outlook 2003/2007
2. Windows powershell 1.0
3. Exchange 2007 management console
Meer hierover: http://blogs.technet.com/...oxes-to-and-from-pst.aspx
Alternatief is het met de hand in Outlook 2003/2007 doen (let wel op, een unicode-pst is standaard gelimiteerd op 20GB, kan je met een registrysetting ophogen tot 16TB.)
Maar dit had je allemaal zelf ook kunnen vinden door wat rond te lezen op internet.... moet je toch wel tegenkomen dunkt me

[DaVaRiOuS]

De reden is dat de back-ups voor de mail tegen zijn limiet aan loopt, en aangezien het onnodig is om het limiet te vergroten (aangezien er medewerkers weg gaan waardoor er mee vrije ruimte komt), dacht ik aan het defraggen van de mailstore.

Ik weet ook wel dat bricklevel backup anders is dan een volledige mailstore, daarom gaf ik het ook aan.

De logfiles was inderdaad de verkeerde, hier de juiste:
The database "First Storage Group\Mailbox Store (SBS2003)" has 51 megabytes of free space after online defragmentation has terminated.

Exmerge is voor mij geen optie, heb het al op een andere manier kunnen back-uppen.
Ik heb liever 2x een back-up van iets dan 1 foute. dus alles voor de zekerheid.

PS: Ik weet best wat ik aan het doen ben, maar liep even tegen iets aan wat me erg vreemd voor ogen kwam en wilde dit even delen om te zien of dit 'normaal' is.
Dat wanneer er zo'n 12gb aan e-mail is verwijderd, maar dit niet terug te zien is in de logs door de maildatabase is grootte terug te dringen.
Hij was 27gb, maar is 12gb verwijderd, maar de database is nog steeds 27gb (logisch), maar na een defreg zou er maar 55mb af gaan?

[ Voor 28% gewijzigd door DaVaRiOuS op 11-05-2010 21:39 ]

[sanfranjake]

DaVaRiOuS schreef op dinsdag 11 mei 2010 @ 21:36:
De reden is dat de back-ups voor de mail tegen zijn limiet aan loopt, en aangezien het onnodig is om het limiet te vergroten (aangezien er medewerkers weg gaan waardoor er mee vrije ruimte komt), dacht ik aan het defraggen van de mailstore.

Ik weet ook wel dat bricklevel backup anders is dan een volledige mailstore, daarom gaf ik het ook aan.

Als je inderdaad nog een tijdje met SBS2003 door moet, dan is het inderdaad wel een logische keuze Just checking, wilde je behoeden voor een tijdverspillende actie.. Ik zou wel een store-level backup maken om jezelf bij problemen veel tijd te besparen.

De logfiles was inderdaad de verkeerde, hier de juiste:
The database "First Storage Group\Mailbox Store (SBS2003)" has 51 megabytes of free space after online defragmentation has terminated.

Heb je al mailbox cleanup gerund? Zie je de boxen wellicht nog in de System Manager zodat je ze kan reconnecten? Je hebt daar een purge-optie die je per mailbox kan uitvoeren.

Exmerge is voor mij geen optie, heb het al op een andere manier kunnen back-uppen.
Ik heb liever 2x een back-up van iets dan 1 foute. dus alles voor de zekerheid.

Helemaal mee eens. Is een van de twee wellicht toch een volledige databasebackup? Veel back-uppakketten maken tegenwoordig een store-backup waaruit je individuele items gemakkelijk terug kan zetten.

PS: Ik weet best wat ik aan het doen ben, maar liep even tegen iets aan wat me erg vreemd voor ogen kwam en wilde dit even delen om te zien of dit 'normaal' is.
Dat wanneer er zo'n 12gb aan e-mail is verwijderd, maar dit niet terug te zien is in de logs door de maildatabase is grootte terug te dringen.
Hij was 27gb, maar is 12gb verwijderd, maar de database is nog steeds 27gb (logisch), maar na een defreg zou er maar 55mb af gaan?

Ik denk dat de cleanup toch nog niet helemaal rond is, en dat je de optie Purge zal moeten gebruiken voor die mailboxen. Want als er inderdaad maar 15GB aan mailboxen is, zal die data toch nog in de store zitten.

[DaVaRiOuS]

sanfranjake schreef op dinsdag 11 mei 2010 @ 21:47:
Als je inderdaad nog een tijdje met SBS2003 door moet, dan is het inderdaad wel een logische keuze Just checking, wilde je behoeden voor een tijdverspillende actie.. Ik zou wel een store-level backup maken om jezelf bij problemen veel tijd te besparen.

Geef niet, kritisch oogpunt houd je scherp
store-level back-up is ook gemaakt.

Heb je al mailbox cleanup gerund? Zie je de boxen wellicht nog in de System Manager zodat je ze kan reconnecten? Je hebt daar een purge-optie die je per mailbox kan uitvoeren.

Clean-up heb ik al gedraait en de verwijderde users, daarop heb ik op de mailboxen een purge uitgevoerd en deze zijn dus ook uit de mailstore overzicht.

Helemaal mee eens. Is een van de twee wellicht toch een volledige databasebackup? Veel back-uppakketten maken tegenwoordig een store-backup waaruit je individuele items gemakkelijk terug kan zetten.

Klopt.

Ik denk dat de cleanup toch nog niet helemaal rond is, en dat je de optie Purge zal moeten gebruiken voor die mailboxen. Want als er inderdaad maar 15GB aan mailboxen is, zal die data toch nog in de store zitten.

Ik heb echt geen flauw idee, daarom vraag ik het hier ook
maar de purge e.d. is uitgevoerd, maar is geen verandering te bekennen

[ Voor 4% gewijzigd door DaVaRiOuS op 11-05-2010 22:17 ]

[sanfranjake]

Omdat je de events posts lijkt het er op dat je al een of meerdere dagen wacht, en dus al een nieuwe online defrag is uitgevoerd. Dan zou volgens mij ook de ruimte weer vrij moeten zijn.
Heb je na de export en purge van alle data ook nog een keer een full backup gemaakt?
Je kan via de ESM logging wat hoger zetten. En misschien is het zinnig om de consistentie van je database te controleren. Exchange 2003 is niet echt bedoeld voor mailboxen van 17GB, maar het is ook niet onmogelijk
Technet: Determining the True Amount of Space in an Exchange Database
msexchange.org: Using the Exchange tools ISINTEG and ESEUTIL to Ensure the Health of your Information Store

[ Voor 21% gewijzigd door sanfranjake op 12-05-2010 00:14 ]

[DaVaRiOuS]

sanfranjake schreef op woensdag 12 mei 2010 @ 00:08:
Omdat je de events posts lijkt het er op dat je al een of meerdere dagen wacht, en dus al een nieuwe online defrag is uitgevoerd. Dan zou volgens mij ook de ruimte weer vrij moeten zijn.
Heb je na de export en purge van alle data ook nog een keer een full backup gemaakt?
Je kan via de ESM logging wat hoger zetten. En misschien is het zinnig om de consistentie van je database te controleren. Exchange 2003 is niet echt bedoeld voor mailboxen van 17GB, maar het is ook niet onmogelijk
Technet: Determining the True Amount of Space in an Exchange Database
msexchange.org: Using the Exchange tools ISINTEG and ESEUTIL to Ensure the Health of your Information Store

Er wordt iedere nacht een online defrag uitgevoerd.
Na de export en purge is er ook een full backup van de mailstore gemaakt (priv1.edb en priv1.stm).

In het register is de aanpassing gedaan dat de mailstore database groter mag worden dan de standaard 16gb, deze heb ik verhoogd naar max. 50gb.

Ik zal die artikelen eens even doornemen.

PS: dit kwam ik ook tegen in een stukje tekst van MS:
"Bij een on line defragmentatie wordt er meer databaseruimte vrijgemaakt zonder de bestandsgrootte van de database te wijzigen."

[sanfranjake]

Precies. De online defrag geeft die ruimte vrij binnen de database (dat is wat je in event 1221 ziet). Offline defrag verkleint de bestanden zelf (net als shrink operaties in sql eigenlijk...)

[nilisvw]

offline defrag kan is het meest nuttige als je meerdere exchange servers hebt gebruikt en bijvoorbeeld mailboxen hebt verplaatst van server1 naar server2. Dan zie je de database grootte echt enorm slinken.

[DaVaRiOuS]

Probleem is opgelost!

offline defrag uitgevoerd en ben nu 8GB lichter

Nog even een laatste vraag omtrent Brick Level.
Is het waar dat wanneer je alleen een Brick Level back-up maakt van de mail en dat wanneer je een nieuwe server inricht, je dan niets hebt aan die brick level back-up en dat je deze dat niet kan 'terug' zetten in de gebruikers mailboxen.

Uiteraard zijn op die nieuwe server dezelfde gebruikers/mailboxen aanwezig.

De één zegt, je moet altijd eerst de mailstore (priv1.edb en priv1.stm) in de MDBDATA map plaatsen en dan kun je pas de brick level restore toepassen.
De ander zegt, je kunt gewoon in de nieuwe mailstore waarin de gebruikers/mailboxen zijn aangemaakt de brick level restore toepassen.

Dit hoeft niet uitgevoerd te worden, maar is toch wel erg handig om te weten!