langzame backup exchange mails

[Verwijderd]

Hallo Allemaal,

We draaien hier iedere nacht een backup van de exchange server. Niet alleen de gehele store maar ook de individuele mailboxen. Nu viel het me op dat dit nogal langzaam ging. Vandaag de backup van de mailboxen handmatig gestart en wat blijkt 30% CPU belasting en 650 Mb ram occupatie van het process store.exe

Onze config: Compaq proliant dual Xeon 2.4 Ghz 1 Gb ram 100 Mbit netwerk tussen backup server en mailserver (wordt heel binnenkort een gigabit netwerk).
Als backup software gebruiken wij backup exec 8.6 op de mailserver staan ook de modules voor SQL OFO IDR

Ik wist dat losse mailtjes backuppen langzamer gaat dat de hele store backuppen maar zo langzaam (51 mb/min)

Iemand een handige oplossing? Om bijvoorbeeld ook te zorgen dat er niet zoveel geheugen wordt gebruikt door de store.exe???

[Verwijderd]

store.exe gebruikt altijd zoveel memory (het wordt niet echt gebruikt) Er is een technet artikel over. Dit is zogenaamd by design gedaan.

http://support.microsoft....aspx?scid=kb;en-us;182505

[Verwijderd]

bedankt voor de reactie op het memory "probleem". vraag ik me wel af hoe applicaties daarmee omgaan die kijken hoeveel geheugen er beschikbaar is en op basis van die informatie werken.

De andere vragen blijven wel nog openstaan (langzame backup).

[SoNoS]

Met wat voor apparatuur doen jullie die backup ?
Bijvoorbeeld een tape unit (dltIV) met SCSI aangesloten op de backup server ?

Wat voor backup draai je precies, een full of een differential ?

En kan je ook in de logs zien hoeveel er in de backup meegaat ? Als er bijvoorbeeld 100Gb meegaat, kan ik mij best voorstellen dat het niet al te snel gaat.

Heb je ook een remote agent module geinstalleerd ? en ook de Exchange agent module ? Als de mail bestaat uit vele kleine files, kan je geloof ik hier ook nog een module installeren.

[Koffie]

Over hoeveel Mb verdeeld over hoeveel kleine files praten we ?
En wat voor soort software gebruik je ?
Lijkt me namelijk ook wel raadzaam om te weten.

Ja het is bekend dat vrijwel iedere backup wel op z'n backup gaat bij een shitload aan kleine files, maar de vraag is dus .. hoe groot is die shitload bij jou

[Remco]

Verwijderd schreef op 05 november 2003 @ 09:16:
bedankt voor de reactie op het memory "probleem". vraag ik me wel af hoe applicaties daarmee omgaan die kijken hoeveel geheugen er beschikbaar is en op basis van die informatie werken.

De andere vragen blijven wel nog openstaan (langzame backup).

Heb je de store al gerestart ?
Er zit namelijk ook een memory-leak in.
Je zal zien dat na het booten van je server het beslag van store.exe kleiner is.

Misschien dat het backuppen dan ook weer rapper gaat ?
Geen idee, maar je kan het proberen.

[Verwijderd]

exchange server bevat 81.000 mailtjes over 39 boxen wat totaal 6,5 Gb aan data opleverd. We hebben een HP DDS4 streamer met een tape robot voor 6 cardridges tuurlijk is alles scsi. Normale backup gaat met 200 Mb/min. Exchange met 60 Mb/min. Netwerk capaciteit lijkt dus niet de bottleneck. CPU ook niet omdat er nog ruimte over is op de processoren. Lijkt meer op vraag/antwoord probleem. Backup software vraagt mailtje om te backuppen, exchange server geeft mailtje.. Niet een lekkere stream richting tape streamer. De data van de exchange server staat in raid 5 configuratie opgebouwd uit 4x17Gb SCSI III (proliant 370).

We hebben remote agent draaien (anders kan je helemaal niet de onafhankelijke mailboxen backuppen).

[SoNoS]

Wel grappig om te lezen. Maar de snelheden die jij noemt, heb ik hier ook.

Zelf heb ik niet het idee dat dit sneller kan. Hoogstens je backup methode van je Exchange aanpassen, maar dat is denk ik niet wat je wilt.

[Verwijderd]

Nope, ben gewoon benieuwd waar de bottleneck zit.. Dit zijn de mogelijkheden:
1. Netwerk (lijkt me sterk aangezien gewone backup op 200 mb/min gaat)
2. Processor power (lijkt me sterk aangezien hij maar 35% load geeft)
3. Disk IO (lijkt me sterk aangezien het raid 5 met 4 vet snelle schijven betreft)
4. Streamer (lijkt me sterk aangezien hij andere data wel met 200 Mb/min kan
backuppen).
4. Benadering van Store (lijkt me niet sterk. Zal wel een beroerd geconfigureerd protocol zijn waar timing niet lekker geregeld en zeker niet parallel honderden mailtjes in een stream naar de tape unit gegooid kunnen worden.

Ik vraag me wel af hoe grote bedrijven met duizend of meer users dit aanpakken. Dan is 60 Mb/min echt te weinig.. Of zouden die niet alle mailboxen afzonderlijk backuppen en alleen de complete store. Dan moeten ze indien er een probleem optreed de hele store naar een andere server restoren en dan de mailbox handmatig eruit exporteren. (dat lijkt me niet handig als je een store van 100 Gig hebt).

[paulhekje]

60 MB per minuut is normaal. Hier doet de bricklevel backup van ca. 30 GB er ±8 uur over.

[sjaak]

De snelheid konden wij idd ook weinig aan doen, vandaar dat er de keuze is gemaakt dat we niet op bricklevel backuppen maar gewoon alle stores op tape zetten voor het geval de hele server op z'n bakkes gaat. Scheelt ook een heleboel rompslomp want men is nu voorzichtiger geworden met het verwijderen van mailtjes.

[SoNoS]

Wij hebben hier dezelfde resultaten met een stuk mindere specificatie. En als ik de rest van de posting hier lees, is het een normale snelheid.

Misschien dat Veritas zelf nog een andere oplossing heeft, anders even contact met hen opnemen.

Het lijkt mij niet dat grotere bedrijven alleen backuppen met een tape. Er zal waarschijnlijk wel extra backupservers draaien, waardoor ze de eventuele verloren data van een andere schijf af kunnen halen.

[mavink]

Er even vanuitgaande dat je rond de 60 Mb/min haalt, dus een megabyte per seconde, en gemiddelde mailgrootte van 2 kilobyte, dan heb je dus 500 bestanden per seconde. Ofwel 500 i/o operaties per seconde, en dat lijkt me heel redelijk

De beste oplossing is vragen of je gebruikers grotere mailtjes willen versturen

[Verwijderd]

Bottlenek is waarschijnlijk dus de aanvoer vanuit exchange. Vaak zijn trage backups te wijten aan de trage aanvoer waardoor de tape moet gaan wachten op data. Dit stoppen en starten van een tape neemt heel veel tijd in beslag. Een oplossing is soms werken met multiple streams. Doordat er voldoende data naar de tape wordt gestuurd blijft deze doordraaien op volle snelheid en kan er sneller worden weggeschreven. Moderne tapestreamers kunnen wel op verschillende snelheden draaien maar een kleine onderbreking in de aanvoer van data levert veel tijdsverlies op.

mvg

[paulhekje]

een aardige testmethode om te kijken wat de traagste factor is: hoelang duurt een export met exmerge naar een disk op dezelfde server?

[Verwijderd]

Over grote bedrijven:

Ik sprak een tijd geleden iemand van KPN over hun portals (ze hebben vier grote portals). Hij zei dat de backup s'avonds op een floppy past Heel nederland popt s'avonds de mailbox leeg. Ze gebruiken blade servers van HP die overdag pop mail afhandelen en s'nachts order processing doen. Dit alles op een SAN met een paar Eva's er achter in een failover cluster. Daar worden geen backups meer gemaakt. Eventueel snapshots, maar geen tape meer. Als je mailtjes kwijt bent is het je eigen schuld. De serverkant maak je gewoon redundant. Dan heb je geen backup meer nodig is de gedachte.

mvg

[mutsje]

Dan praat je neem ik aan over mensen die mail krijgen via Hetnet. Reken maar dat KPN hun eigen mailservers wel degelijk backuppen.. moet je kijken als ze tegen een directeur zeggen daar ja sorrie maar we backuppen geen mail...

single mailbak gaat gewoon langzamer omdat het backupprogramma op de mailboxen inlogt dan backup maakt dan weer uitlogt. Maar 51mb/s is inderdaad traag.

[Verwijderd]

Inderdaad HetNet, de andere drie weet ik zo even niet. De mail van de directeur is natuurlijk een ander verhaal. Als klant van HetNet denk ik niet dat je een mail restore kunt aanvragen...

maar met snapshot technologie maak je in feite ook backups. Alleen niet meer op tape. Je schrijft gewoon wijzigingen weg en kunt dus point in time restoren.

hoe het zit als de software het begeeft weet ik eigenlijk niet.

Verder is de redundantie zover doorgevoerd dat bij bijvoorbeeld een bomaanslag waarbij de servers worden opgeblazen, er binnen dertig seconden overgeschakeld kan worden naar de backup servers die dan vaak ergens in een bunker staan.

Vooral grote webstores zijn op deze manier gaan werken aangezien een paar uur downtime veel kostbaarder is dan het redundant maken van het serverpark en er sinds 11 september veel angst is voor nieuwe aanslagen.

Met een SAN kun je tot 40 KM geloof ik zonder al teveel latency shaduw servers laten draaien in een bunker.

Overigens kost bij ons een mailbox restore 600 euro. Niet veel mensen maken daar gebruik van

[Rolfie]

Zoals je al gelezen hebt, de performance is normaal die je hebt. Het probleem zit hem namelijk dat ieder mailtje, notitie, afspraak door de MAPI DLL's gebackuped moeten worden. Helaas is MAPI niet geschikt voor hoge snelheden. Vandaar je probleem.

Wordt deze server alleen gebruikt voor Exchange, want dan is een Gigabit Ethernet card overkill. Er is trouwens een kans dat je Server al onboard Gigabit Ethernet heeft. Vanaf ML370G3 (misschien ook al ML350G3, Sorry ben te om het even op te zoeken) en alle DL G3 server hebben het namelijk al onboard. Je kan eventueel nog proberen om de virusscanner eens tijdens een backup uit te schakenl, maar zorg er dan wel voor dat je geen SMPT mailtjes kan ontvangen. Anders kun je grote problemen krijgen, zeer grote problemen. De virusscanner kan namelijk je backup nog wel eens in de weg zitten.

[Verwijderd]

de server dient ook als domain controller (iets wat eigenlijk niet mag volgens MS maargoed). Verder dient de server als printserver fileserver en er draait nog SQL7 op voor een intern geschreven stuklijstbeheer pakket. Is gelukkig wel een DUAL XEON 2.4 machien met 1 gb ram dus kan wel wat werk verzetten..

Btw. de backup deed het vandaag niet op de mailboxen, maar iedereen kon wel gewoon inloggen en outlookén. Wat bleek er was een exchange service zomaar uitgevallen.. Stond op automatic maar was niet gestart.. heeeel bizar.. daardoor konde we ook geen namen wijzigen in de AD. Zit nu niet achter de server en ben vergeten welke service het was (stond na of voor de exchange replication service (die ook uit staat). Lijkt me toch niet helemaal normaal dat services die backup_exec nodig hebben om mails mee te backuppen zomaar stoppen met draaien.... Heeel vreemd.. gaan we verder uitzoeken (als we tijd hebben).. zucht....

[Maarten @klet.st]

Rolfie schreef op 18 november 2003 @ 22:31:
Zoals je al gelezen hebt, de performance is normaal die je hebt. Het probleem zit hem namelijk dat ieder mailtje, notitie, afspraak door de MAPI DLL's gebackuped moeten worden. Helaas is MAPI niet geschikt voor hoge snelheden. Vandaar je probleem.

Ik zal mijn ervaringscijfers er ook maar even bijzetten. Op mijn werk hebben we
een exchange server met ca 40 mailboxen die tesamen iets van 14GByte hebben.
Die gaat met 160Mbyte/minuut naar tape.
Deze exchange 2000 server is een dual Xeon, ik meen 2,4Ghz. Op de machine draait de Arcserve exchange client. Deze machine zit met een 100Mbit/s verbinding aan het netwerk. De disken zijn 4 36GB 15K rpm schijven in RAID5 config.

De backupmachine die hiervoor gebruikt wordt is een DLT7000 uit mijn hoofd, in ieder geval gebruikt ie DLT4 cartridges. Deze backupdoos is een oude dual P2 400Mhz machine, maar wel met 1000Base-SX aan het netwerk.

Dat de fysieke exchange machine nogal van invloed is blijkt uit het feit dat een andere exchange (5.5) server 32Mbyte/min haalde met een database van ook ongeveer 40 mailboxen en 18GByte. Deze machine is een dual P2 400Mhz met 1000Base-SX verbinding en dient ook als PDC en fileserver.

Is ook allemaal heel logisch, doordat de Arcserve agent via MAPI calls mailtje voor mailtje uit alle mailboxen haalt, zoals eerdere posters al aangaven. Hoe sneller de exchange server, hoe vlotter het gaat.

[Maarten @klet.st]

Verwijderd schreef op 05 november 2003 @ 12:13:
Ik vraag me wel af hoe grote bedrijven met duizend of meer users dit aanpakken. Dan is 60 Mb/min echt te weinig.. Of zouden die niet alle mailboxen afzonderlijk backuppen en alleen de complete store. Dan moeten ze indien er een probleem optreed de hele store naar een andere server restoren en dan de mailbox handmatig eruit exporteren. (dat lijkt me niet handig als je een store van 100 Gig hebt).

Hier zijn wel een paar oplossingen voor. Er zijn een paar tools waarmee je uit de fysieke store files individuele mailboxen, folders of zelfs mail kan halen. Powercontrols van Ontrack is een voorbeeld. Is duur, maar dan heb je wel wat.
Je kan ook een tweede exchangeserver gebruiken waar je deze store files in mount. Geen makkelijke operatie, maar oefening baart kunst.

Overigens kun je met shadow copies in Win2003 of snapshots in de meeste SAN's de information store files 'rustig' backupen zonder de exchange server te stoppen. Je hebt dan een kopie van de file, die kan je rustig aan backuppen..