Exchange 2010 logfiles verplaatsen tbv acuut ruimtegebrek

[Verwijderd]

Aloha,

Ik heb een vraagje mbt Exchage 2010.
Ik ben bezig met het moven van mailboxen en dat genereerd meer logfiles als dat ik gehoopt had, ik heb de logfiles op een apart San Volume staan (gescheiden van de database) en die heb ik de afgelopen uren al 3 maar vergroot maar hij blijft hem vol duwen.
Het lastige is dat wanneer ik het volume blijf vergroten ik niet meer terug kan als de problemen voorbij zijn, ik kan het SAN volume nml niet verkleinen zonder allerhande capriolen uit te moeten halen.

Heb nu de logfiles gedeeltelijk verplaatst naar ander volume om zo de Exchange toch online te kunnen houden.

Vraag:
Moet ik die logfiles later nu weer terug zetten naar de oorspronkelijke locatie zodat ze weer automatisch geflushed worden na een backup of werkt dat zo niet ?

------------------------------------------------------------------------------------------------------------------
Ik heb een database welke nu 100 GB is waarvan 70 GB in use door de store.
Ik heb een logvolume van 40 GB wat dus regelmatig volloopt tijdens het moven van grote mailboxen.

Vraag:
Is er een best practice (of vuistregel) om te kunnen bepalen wat de grootte van je logvolume moet zijn t.o.v je database ?

[Craven]

Counter vraag 1: heb je nu handmatig wat oudere logfiles gecopypaste naar een andere locatie? Zonder medeweten van de exchange server? Dan ja, graag weer terugzetten. Ik ben geen expert maar dat gaat problemen veroorzaken.

Vraag 2: je logfiles zijn in principe de veranderingen sinds de laatste flush. Hangt dus compleet af van activiteit en frequentie van de flush.

Niet compleet zeker over dit gedeelte:
Ik ben even de naam kwijt. Maar er is een optie in exchange (rotate log files oid) die ervoor zorgt dat hij zelf ook de log files weer weggooit. Maar dan zou ik wel zorgen voor een goede backup.

[Verwijderd]

Ok dank je

Ik heb i.d een knip/plak actie gedaan op de logfiles richting een ander volume.

Vraag me af of het terugzetten noodzakelijk is, ik dacht nml dat er middels die logfiles het volgende gebeurd (in grote lijnen)

**Dit ga ik doen en heb ik gedaan en is gelukt of niet, wanneer het niet gelukt is draai ik alles terug en is er niets veranderd en dit alles laat ik je weten middels deze logfiles**

Als de acties welke ik uitvoer voor het moven voorbij is zonder dat er een foutmelding op gekomen is zijn de logfiles niet meer nodig. Ze worden direct na een backup ook geflushed (nogmaals in grote lijnen).

[Rolfie]

Een hoop Exchange ervaring begrijp ik (NOT).

Dit is juist niet de mannier om het te doen. Exchange heeft deze logfiles nodig en houd in de database ook bij welke logfiles er nog aan wezig moeten zijn.

Als je pech hebt, heb je straks een groot issue.

Dat Backup ze flushed, betekend niet dat die ze zo maar gewoon verwijderd. Er zit een proces achter. Kan is best aanwezig dat je backups nu juist mislukken, omdat die geen Full Database meer kan down. Want dat is juist de Database + alle logfiles sinds de laatste database backup./

Daarbij dit is/en was te verwachten. Dat heet goed voorbereiding van een move. Je gaat veel logfiles genereren.

[Laagje]

Bij het migreren/moven van grote aantal mailboxen is het aanbevolen om circular logging tijdelijk aan te zetten. Let op, dit betekent wel dat je database even offline moet.

[Arcesilaus]

Een alternatief voor circular logging: maak een tijdelijk SAN volume aan en migreer je logs (zou wel eerst een full backup maken) voordat je mailboxen gaat verhuizen.
Na de verhuizing weer een full backup en dan de logs terugzetten naar de normale locatie en je tijdelijke SAN volume wegmikken - zo voorkom je dat je vanwege een eenmalige actie je SAN volume in grootte moet verdubbelen.

[Verwijderd]

Rolfie schreef op donderdag 07 juni 2012 @ 14:37:
Een hoop Exchange ervaring begrijp ik (NOT).

Dit is juist niet de mannier om het te doen. Exchange heeft deze logfiles nodig en houd in de database ook bij welke logfiles er nog aan wezig moeten zijn.

Als je pech hebt, heb je straks een groot issue.

Dat Backup ze flushed, betekend niet dat die ze zo maar gewoon verwijderd. Er zit een proces achter. Kan is best aanwezig dat je backups nu juist mislukken, omdat die geen Full Database meer kan down. Want dat is juist de Database + alle logfiles sinds de laatste database backup./

Daarbij dit is/en was te verwachten. Dat heet goed voorbereiding van een move. Je gaat veel logfiles genereren.

Klopt van de ervaring.
Maar het nakkelijkst is natuurlijk om iets op te merken zonder een echt antwoord te geven, enkel van hoe het niet moet. Dus logfiles terug zetten of niet ?

[Linke Loe]

De logfiles moet je absoluut terugzetten. Zoals al eerder opgemerkt heeft Exchange deze nodig. In de logfiles, voor de volledigheid 'transaction log files', worden zoals de naam al doet vermoeden alle transacties die op een database gebeuren, bijgehouden. Bij het maken van een full backup van de information store worden de transacties in deze logfiles doorgevoerd op de database en worden de logfiles geflushed.

Exchange houdt keurig bij welke logfiles aanwezig horen te zijn en als bepaalde logfiles niet gevonden kunnen worden heb je een grote kans op dataverlies of nog erger een corrupte database...

De makkelijkste methode om je schijven niet vol te laten lopen tijdens het moven van veel mailboxes is het inschakelen van circular logging. Hierbij worden de transacties vrijwel meteen doorgevoerd op de database, in plaats van tijdens een backup, waardoor er maar heel weinig ruimte wordt ingenomen door de transaction logs. Na het inschakelen van circular logging moet de betreffend database even ge-unmount en weer ge-mount worden.

[Verwijderd]

Linke Loe schreef op donderdag 07 juni 2012 @ 21:15:
De logfiles moet je absoluut terugzetten. Zoals al eerder opgemerkt heeft Exchange deze nodig. In de logfiles, voor de volledigheid 'transaction log files', worden zoals de naam al doet vermoeden alle transacties die op een database gebeuren, bijgehouden. Bij het maken van een full backup van de information store worden de transacties in deze logfiles doorgevoerd op de database en worden de logfiles geflushed.

Exchange houdt keurig bij welke logfiles aanwezig horen te zijn en als bepaalde logfiles niet gevonden kunnen worden heb je een grote kans op dataverlies of nog erger een corrupte database...

De makkelijkste methode om je schijven niet vol te laten lopen tijdens het moven van veel mailboxes is het inschakelen van circular logging. Hierbij worden de transacties vrijwel meteen doorgevoerd op de database, in plaats van tijdens een backup, waardoor er maar heel weinig ruimte wordt ingenomen door de transaction logs. Na het inschakelen van circular logging moet de betreffend database even ge-unmount en weer ge-mount worden.

Dank je voor je heldere uitleg....hier heb ik wat aan.
Voor de duidelijkheid ik heb de logfiles teruggezet en die werden mooi weer opgeslokt door exchange.