Exchange 2010: corrupte database maar nog wel werkend

[JeroenV_]

Blijkbaar mislukt al enige tijd de backup van onze Exchange 2010 server. Deze backups worden gemaakt via Windows Server backup naar een NAS.
Omdat er plotseling meldingen kwamen over te weinig schijfruimte ben ik gaan zoeken, waardoor ik hierachter kwam. Er staan nu namelijk zeer veel transaction logfiles, die dus alle ruimte opeisen.

The melding in de eventviewer is:
eseutil (13956) JetDBUtilities - 15992: The log file \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy79\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 1075329450\E0000099E74.log is missing (error -528) and cannot be used. If this log file is required for recovery, a good copy of the log file will be needed for recovery to complete successfully.

Deze file is ook daadwerkelijk niet aanwezig heb ik gecontroleerd. De laatste full backup van de database is volgens Exchange van 16 maart.

Even los van dat dit uiteraard eerder gesignaleerd had moeten worden, is mijn idee aangezien alles nu nog probleemloos draait:
nieuwe vhd aan de machine hangen
nieuwe exchange database maken op de nieuwe schijf
alle mailboxen naar de nieuwe database moven (25 stuks)
oude database unmounten als alle moves succesvol zijn

Omdat alles nog probleemloos werkt lijkt mij dit de meest veilige methode, omdat als ik hem zou unmounten en hij blijkt dirty te zijn de eseutil oplossingen gedaan moeten worden met mogelijk minder goed resultaat.

Is dit een goede gedachte of kan ik toch maar beter niet gaan moven?

[SpamLame]

Aangezien je het over VHD hebt, begrijp ik dat exchange in een VM draait?
If so en je kan een clone maken terwijl de machine draait, zou je eea kunnen testen op de clone.
If so maar je kan geen clone maken, test eerst in een nieuwe VM of je uberhaupt restoren kan, dan weet je iig dat je laatste backup goed is en heb je gelijk een recovery process doorlopen.

[JeroenV_]

Klopt, de server is een HyperV machine.

Clonen van een Exchange lijkt mij toch niet zo mogelijk, omdat deze ook een AD nodig heeft.
Ik zou inderdaad wel kunnen proberen of ik de backup kan terugzetten naar een nieuwe vm, en dan puur stand alone met eseutil aan de gang gaan om de staat van de database te controleren.

Echter, aangezien het moven van mailboxes op zich ook niet heel bijzonder is volgens mij, is dat niet stukken sneller/beter om te doen?

[RammY]

Voor zover ik weet is het op zich nog geen issue tot dat je EDB dus niet meer loopt.
Ik verwacht dat als je nu een goede backup zult maken, dat dit je probleem op lost.
Logfiles zijn voor recovery, niet voor het draaien van je EDB.
ESUtil doet dan ook de check of alles nog klopt en die meld je dat de files er niet zijn en ook dat deze nodig zijn voor een eventuele recovery (die je dus gelukkig nog niet nodig bent )

Background info: https://support.microsoft.com/nl-nl/kb/240145

[ Voor 7% gewijzigd door RammY op 07-06-2016 12:56 ]

[JeroenV_]

Ik heb zojuist getracht om via een aparte backuptaak een full backup te maken, maar ook deze geeft die melding over de missende logfile en mislukt daardoor.
Heb hier helaas geen ander backup programma dan windows server backup

[SpamLame]

JeroenV_ schreef op dinsdag 07 juni 2016 @ 13:00:
Ik heb zojuist getracht om via een aparte backuptaak een full backup te maken, maar ook deze geeft die melding over de missende logfile en mislukt daardoor.
Heb hier helaas geen ander backup programma dan windows server backup

VZIW maken ndere backup programma (Commvault Simpana zeker) maken ook gebruik van de logs dus dat zou je dan niet helpen.

Zou je de stores in circular logging kunnen zetten zonder de stores offline te halen?

[JeroenV_]

SpamLame schreef op dinsdag 07 juni 2016 @ 13:03:
[...]
Zou je de stores in circular logging kunnen zetten zonder de stores offline te halen?

Nope, helaas niet.

To make your changes to the circular logging settings effective, restart the Microsoft Exchange Information Store service, or dismount and then mount all of the databases in the storage group.

[Dirtyrockers]

Je kan het volgende doen om de logs te verwijderen:

http://ilantz.com/2011/10...rver-logs-clean-and-easy/

Open Command prompt
Launch Diskshadow
Add volume d: (optional, add one line for each additional drive to include) Add volume X:
Begin Backup
Create
End Backup
At this step you should notice the following events in the application log indicating that the backup was indeed successful and logs will now be deleted.

[SpamLame]

Nog eens lezend is de vraag of de (E)DB corruptie is vastgestelt , of dat er alleen melding van missende logfiles is.
Logs files zijn VZIW nl. alleen nodig ingeval van recovery en daar is hier (nog) geen sprake van.
Een check op de DB kan uitwijzen wat de staat is.
Maar als die check niet online kan zit je dus met een kip-ei situatie .

Als je zo'n check ook niet kan doen in een gecloonde VM, dan rest je denk ik niks anders (buiten een ticket maken bij MS) dan de mailboxen migreren zoals je zelf ook aangaf.
Als je de mogelijkheid hebt alle mailboxen te m

[JeroenV_]

Dirtyrockers schreef op dinsdag 07 juni 2016 @ 13:29:
Je kan het volgende doen om de logs te verwijderen:
http://ilantz.com/2011/10...rver-logs-clean-and-easy/

Hmm, dat ziet er redelijk 'smerig' uit, maar ik hou het even in overweging.

SpamLame schreef op dinsdag 07 juni 2016 @ 13:30:
Nog eens lezend is de vraag of de (E)DB corruptie is vastgestelt , of dat er alleen melding van missende logfiles is.
Logs files zijn VZIW nl. alleen nodig ingeval van recovery en daar is hier (nog) geen sprake van.
Een check op de DB kan uitwijzen wat de staat is.
Maar als die check niet online kan zit je dus met een kip-ei situatie .

Als je zo'n check ook niet kan doen in een gecloonde VM, dan rest je denk ik niks anders (buiten een ticket maken bij MS) dan de mailboxen migreren zoals je zelf ook aangaf.
Als je de mogelijkheid hebt alle mailboxen te m

De corruptie is niet vastgesteld, maar omdat de backup niet (meer) loopt en inderdaad de enige manier om de health te checken het downbrengen van de database is, durf ik eea niet aan.
Daarom kwam ik nu op de optie om alles te moven naar een nieuwe database aan te maken en de mailboxen te moven.

[Jazzy]

Circular logging aanzetten is een prima workaround in dit geval, maar die wordt alleen 'automatisch' actief op een database die meerde kopieën in een DAG heeft. In dit geval moet je hem even dismounten en weer mounten. Als je alleen een missende logfile hebt dan zie ik geen risico in het dismounten van de database.

Veel belangrijker is natuurlijk de vraag waar deze logfile gebleven is. AV software op de server toevallig?

Je plan om de mailboxen naar een nieuwe database te verplaatsten ziet er goed uit. Houd er wel rekening mee dat het verplaatsen van 50 GB aan mailboxen ook 50 GB aan transactielogs voor de nieuwe databases genereert. De nette oplossing is om niet teveel mailboxen in één keer te verplaatsen en dan steeds een full backup om de logfiles te purgen. De praktische oplossing is het aanzetten van circular logging, niet vergeten om deze weer uit te zetten na het moven.

[ Voor 13% gewijzigd door Jazzy op 07-06-2016 13:39 ]

[SpamLame]

Dan was je eerste ingeving dus de juiste>moven die hap.

Als je enige mogelijkheid hebt de originele EDB+logs te kopieren/veiligstellen dan zou ik dat doen om achteraf eens te kijken of de DB echt corrupt is en wat ervoor nodig is om $whatever te herstellen.

[Dennism]

Voor zover ik weet geeft MS sinds uit mijn hoofd Exchange 2013 niet eens support meer op databases gerepareerd met Eseutil, maar is de best practise wanneer het nog kan een nieuwe DB maken en alles migreren en dan de oude DB verwijderen.

Mocht het niet meer kunnen (en je hebt geen werkende backup) dan een repair te doen met eseutil (als de DB bijv. niet meer mount), en dan zodra de DB weer werkt alles te migreren en de oude store te verwijderen.

[ Voor 3% gewijzigd door Dennism op 07-06-2016 13:40 ]

[Jazzy]

Het is trouwens best practice om je databases niet op het systeemvolume te installeren. Voor de volgende keer.

[JeroenV_]

Bedankt voor de reacties heren, fijn om even te kunnen spiegelen.

Stappenplan wordt na overleg hier nu:
huidige disk waar de database staat vergroten om logfiles kwijt te kunnen (bedankt voor de tip Jazzy!)
nieuwe disk koppelen aan de machine
nieuwe database aanmaken binnen exchange
mailboxen moven

Fijn, weer wat te doen vanavond

Jazzy schreef op dinsdag 07 juni 2016 @ 13:38:
Veel belangrijker is natuurlijk de vraag waar deze logfile gebleven is. AV software op de server toevallig?

Er draait een AV op ja, mcafee, maar die heeft niets in quarantaine staan.
Het logfile nummer is ook echt precies een ontbrekende in de reeks, er staan nog 2 logfiles van dezelfde minuut (e....e73 en e...e75), maar nummer 74 ontbreekt dus.

Jazzy schreef op dinsdag 07 juni 2016 @ 13:43:
Het is trouwens best practice om je databases niet op het systeemvolume te installeren. Voor de volgende keer.

Stonden ze ook niet, staat op D:\ ...

[ Voor 54% gewijzigd door JeroenV_ op 07-06-2016 13:50 ]

[SpamLame]

Niet vergeten de overuren te boeken

[SpamLame]

JeroenV_ schreef op dinsdag 07 juni 2016 @ 13:43:

Er draait een AV op ja, mcafee, maar die heeft niets in quarantaine staan.
Het logfile nummer is ook echt precies een ontbrekende in de reeks, er staan nog 2 logfiles van dezelfde minuut (e....e73 en e...e75), maar nummer 74 ontbreekt dus.

Gelijk maar dat soort zaken excluden in je virusscan, zoiets moet m.i. afgevangen zijn voordat het de DBs/logs ingaat of afgevangen worden als het er weer uitkomt, beter nog en/en.

[JeroenV_]

Goeie tip, vraag mijn collega om dit gelijk te doen.

[Jazzy]

Geef hem dan dit artikel: https://technet.microsoft...342%28v=exchg.141%29.aspx

[JeroenV_]

Net begonnen, maar gelijk zat het al tegen. Even vergeten dat je een fixed size vhd niet kunt resizen zonder de machine down te brengen. En aangezien er nog maar 4 Gb vrij was, ben ik maar niet begonnen aan het aanmaken van een nieuwe database en moven van mailboxen.

Uiteindelijk daarom de oplossing van Dirtyrockers gedaan, dus via diskshadow de commando's afgevuurd, en tada, logfiles weg en volgens de eventviewer is er een goede backup van de exchange database gemaakt. Dat is uiteraard niet zo, maar Exchange denkt in ieder geval van wel. Dit geeft hij nu ook gewoon aan in de EMC als ik de properties van de database opvraag.

Vanavond loopt de normale backup weer, dus morgenochtend controleren of het nu beter gaat.
Als er dan geen meldingen meer verschijnen lijkt eea wat dat aangaat dus opgelost...

[JeroenV_]

Nog even een update: vanmorgen de backup gecontroleerd, en nu is alles succesvol gegaan.
De logfiles van gisteren zijn ook keurig opgeruimd.