Exchange 2010 backups mislukken (DB consistency ?)

[marcop82]

Aangezien ik met Exchange nog geen rampscenario's heb meegemaakt en tijdelijk als enige IT'er in het MKB bedrijf geen tijd heb om een testopstelling te maken, ben ik huiverig om hieraan te beginnen, maar misschien maak ik me teveel zorgen en is het niet zo'n groot risico of interventie als ik vrees.

Situatie:

Sinds de afgelopen twee weken lukken backups (Backup Exec 2012) niet meer van de Exchange 2010 op 2008 R2 (non-SP) niet meer. Na alle mogelijke oorzaken van Backup Exec bekeken te hebben, kom ik bij de (enige) mailserver zelf uit en die geeft de volgende foutmelding 4x weer de laatste maand in Event Viewer:

Storage Group Consistency Check - Event ID 403

Instance 1: The physical consistency check successfully validated 18 out of 213248 pages of database '\\...\mailbox database.edb'. Because some database pages were either not validated or failed validation, the consistency check has been considered unsuccessful.

Telkens op "page 18", bij verschillende databases.
'vssadmin list writers' geeft enkel "stable" en "no errors" bij de writers.

Wat dagelijks sinds begin mei voorkomt is die van ESE - Event ID 2007

Exchange VSS Writer (instance 295a99e2-7875-4bd1-b3c3-58dc18a23f67:7) has completed the backup of database '*** mailbox database' with errors. The backup did not complete successfully, and no log files were truncated for this database.

Meestal op 2 van de 5 databases, met uitzonderlijk een derde gisteren.

Als ik dan kijk naar de SAN storage zie ik geen enkele issue, in de ESXi 5.0 logs zie ik ook niets dat duidt op een storage probleem of iets gerelateerds. Dus ik vermoed dat de databases zichzelf aan het kromtrekken zijn. Waar we dus bij mijn vragen uitkomen...

Vragen:

- is het verstandig om ervan uit te gaan dat een database repair verstandig is en in welke richting moet ik als onervaren knul in Exchange dit gaan zoeken ?
- zijn er andere logische oorzaken waar ik naar op zoek kan gaan die ik kan doen terwijl de (enige) Exchange server live staat ?
- is dit te hoog gegrepen voor iemand met een paar jaar systeembeheer ervaring ?

EDIT: oplossing voor het probleem: marcop82 in "Exchange 2010 backups mislukken (DB consistency ?)"

[ Voor 3% gewijzigd door marcop82 op 10-08-2015 10:35 ]

[ElCondor]

Misschien mag ik het helemaal niet zeggen, maar ik heb bij mij thuis wel eens gezien dat database consitency problemen zichzelf oplossen door het herstarten van de store. De database gaat dan de logs opnieuw afspelen en repareert op basis van de gevonden gegevens de problemen. Ik zelf ben nog nooit een mail daarmee kwijtgeraakt. Maar goed, thuis is geen échte MKB productie omgeving.

Aanvullend, je kunt ongetwijfeld op het internet een goeie cursus Exchange vinden waarin onderhoud en reparatie aan bod komen. Daar kom je al een heel eind mee, naar mijn gevoel. Ik heb destijds Exchange 203 helemaal zonder ervaring geïnstalleerd en geconfigureerd en later een upgrade gedaan naar Exchange 2010.
Dat draait nu nog zonder problemen, met hier en daar een reboot. De meeste problemen hebben zichzelf opgelost uiteindelijk en ik heb geloof ik één keer een database manual recovery moeten doen. Daar ben ik volgens de procedure wel data mee kwijtgeraakt, maar ik heb nooit kunnen achterhalen welke data. Het was in ieder geval geen onderhanden mail of belangrijke afspraak Ik draai op mijn mailomgeving een stuk of vijf mailboxen.

Om op tweede vraag nog terug te komen, als je maar één Exchange store in je omgeving hebt, dan is er niet veel anders te bedenken waarom er inconsistency in je DB optreed. Wellicht even kijken naar de disks waar je EDB op staat? Wellicht dat daar bitje om beginnen te vallen.

Succes!

[ Voor 57% gewijzigd door ElCondor op 03-06-2015 16:47 ]

[Question Mark]

Is het niet veel sneller om gewoon een nieuwe database aan te maken, en de mailboxen naar de nieuwe database te verplaatsen? Als de oude database compleet leeg is (let ook op de systemmailboxen), verwijder je deze simpelweg.

[marcop82]

ElCondor schreef op woensdag 03 juni 2015 @ 16:41:
Om op tweede vraag nog terug te komen, als je maar één Exchange store in je omgeving hebt, dan is er niet veel anders te bedenken waarom er inconsistency in je DB optreed. Wellicht even kijken naar de disks waar je EDB op staat? Wellicht dat daar bitje om beginnen te vallen.

Mja dat dacht ik ook, maar het betreft een SAN met RAID6 configuratie die regelmatig scrubbed, gebruikt door een ESXi 5.0.1 High-Availability setup. Bij de SAN zie ik geen issues en bij ESXi ook niet, dus ik vermoed dat het dan aan het guest OS filesystem scheelt, áls het daar krom staat. Het probleem is dat die enkel offline gechecked kan worden dus ga ik dat 's nachts of 's ochtends moeten doen.

Question Mark schreef op woensdag 03 juni 2015 @ 22:40:
Is het niet veel sneller om gewoon een nieuwe database aan te maken, en de mailboxen naar de nieuwe database te verplaatsen? Als de oude database compleet leeg is (let ook op de systemmailboxen), verwijder je deze simpelweg.

Misschien een betere oplossing ja, maar hoe gaat dit proces om met mogelijk beschadigde data zoals in mijn geval ?

Alvast bedankt voor de tips !

[ Voor 4% gewijzigd door marcop82 op 04-06-2015 08:20 ]

[ElCondor]

Overzetten naar een nieuwe database kun je beïnvloeden.
Je kunt aangeven dat hij na een bepaald aantal faillures op moet geven en anders de migratie als succesvol moet beschouwen. Je kunt voor de test natuurlijk even een mailboxje aanmaken met een kopie van je eigen mailbox oid. en dan een migratie testen. Dan kun je precies zien welke opties er zijn.
Dit kan allemaal online. Je kan een mailbox move zelfs schedulen.

[marcop82]

Handig ! Je zegt een mailboxje aanmaken met een kopie van je eigen mailbox, bedoel je niet een mail database met een kopie van mijn eigen mailbox ?

Momenteel loopt er een backup via Windows Server Backup, aangezien Backup Exec er toch niet meer in slaagt een complete backup to produceren. Het bizarre is dat hij hiervoor een consistency check doet maar geen fouten meldt, ook niet in Event Viewer. Dus ofwel is dit geen diepgaande consistency check (ik schat 10-15 min voor 150GB aan databases op 12-disk 10k rpm HP P2000 G3 SAN), ofwel is er iets anders gaande.

Ik schat dat deze backup een paar uren gaat duren.

[Question Mark]

marcop82 schreef op donderdag 04 juni 2015 @ 08:19:
[...]
Misschien een betere oplossing ja, maar hoe gaat dit proces om met mogelijk beschadigde data zoals in mijn geval ?

Zie onderstaand artikel hoe dit uit te voeren is in de Gui.

http://www.msexchange.org...-exchange-2010-part1.html

Via Powershell is het overigens ook erg eenvoudig uit te voeren.

[marcop82]

De backup is ondertussen getrokken middels Windows Server Backup. Opvallend is geen problemen met consistency of andere zooi, de backup is succesvol. Zou dit toch nog een probleem kunnen zijn door Backup Exec, ook al zijn de fouten te vinden in de logs van de Exchange server ? Ik kan me moeilijk inbeelden dat Exchange de foutmeldingen uit de startpost gooit door Backup Exec Agent.

In ieder geval kan ik een tijdje verder nu door hiermee backups te trekken, dan kan het experimenteren beginnen om het op te lossen.

Bedankt voor de link, Question Mark. Zeer duidelijk nu

[ Voor 5% gewijzigd door marcop82 op 04-06-2015 15:26 ]

[marcop82]

Ondertussen heb ik in het weekend de filesystem en "sectors" laten scannen om uit te sluiten dat het NTFS is die issues geeft, maar niets werd gevonden. Backup Exec geeft nog steeds een issue vroeg in het lezen van de database, dus ik ga nu verder met het voorstel van Question Mark om een nieuwe DB te maken en mailboxjes te verschuiven.

[@r!k]

Ik zou eens naar mijn disk performance kijken als ik jou was. Een exchange database op een SAN die ook nog gebruikt wordt door ESXi, ik zie een potentiele bottleneck.

[Trommelrem]

Dit klinkt als iets waarbij eseutil wellicht kan helpen.

Voordat je de DB's verschuift en dus mogelijk onnodig werk verricht: Bel even met Symantec. Mijn ervaring is dat als BackupExec A zegt, dat het eigenlijk B is. De helpdesk heeft goede flowcharts om A te vertalen naar B.

[Question Mark]

@r!k schreef op maandag 08 juni 2015 @ 08:26:
Ik zou eens naar mijn disk performance kijken als ik jou was. Een exchange database op een SAN die ook nog gebruikt wordt door ESXi, ik zie een potentiele bottleneck.

Waarom? En wat bedoel je dat ESXi het san ook gebruikt? Dat lees ik namelijk nergens.

[@r!k]

Question Mark schreef op maandag 08 juni 2015 @ 11:14:
[...]

Waarom? En wat bedoel je dat ESXi het san ook gebruikt? Dat lees ik namelijk nergens.

Dat meende ik uit het verhaal op te maken, kan een verkeerde aaname mijnerzijds zijn overigens.

Maar dan nog, exchange met disk gerelateerde eroors, kijk de performance gewoon eens na. Daarnaast lijkt het erop dat de enige software die die foutmeldingen geeft de backup software zelf is. Ik zou dan toch eens nader inzoomen daarop.

En daarnaast, Server 2008 R2 zonder Service Packs? Is daar een speciale reden voor?

[marcop82]

@r!k schreef op maandag 08 juni 2015 @ 12:05:
Dat meende ik uit het verhaal op te maken, kan een verkeerde aaname mijnerzijds zijn overigens.

We hebben twee krachtige servers geïnstalleerd als hosts in een ESXi 5.0.1 HA setup. Op een HP P2000 G3 met 12 SFF 10.000rpm disks in RAID6 worden dmv. SAS naar beide hosts gegaan en wordt als 1 datastore doorgegeven aan ESXi. Hierop draait een compleet MKB-setupje. De Exchange 2010 is voor een 250 half-tijdse officegebruikers (10 mails/dag/user ruwweg). Dit is de situatie waarin ik 2 jaren geleden ben begonnen en het heeft in die twee jaren ook zonder veel problemen gewerkt. Maar helaas kan ik nu moeilijk aankomen met de hardware die te beperkt is aangezien de userbase en het gebruik evenals de hoeveelheid mail allemaal niet gegroeid zijn.

Maar dan nog, exchange met disk gerelateerde eroors, kijk de performance gewoon eens na. Daarnaast lijkt het erop dat de enige software die die foutmeldingen geeft de backup software zelf is. Ik zou dan toch eens nader inzoomen daarop.

Inderdaad, daarom dat ik ook kritisch naar BackupExec kijk. Echter kan BE ook wel onafhankelijk mailboxen recoveren, wat misschien verklaart waarom BE wél fouten ziet.

En daarnaast, Server 2008 R2 zonder Service Packs? Is daar een speciale reden voor?

It was like that when I got here Vroeger mocht ik nauwelijks wat uitvoeren, ondertussen wel en dan staat dat ook op de planning. Het is de enige server die nog niet volledig up to date is, vooral door gebrek aan tijd en de denkwijze ervan af te blijven als het werkt. We hebben weinig redundantie, ervaring en kennis om ingewikkeldere issues zoals dit op te lossen door systemen offline te halen voor onderhoud. Als het moet, dan gebeurt het ook natuurlijk, maar momenteel is het nog niet duidelijk waar het probleem precies zit.

Ondertussen heb ik een case gemaakt op Symantec's forum: https://www-secure.symant...y-fails-not-server-backup

[ Voor 5% gewijzigd door marcop82 op 08-06-2015 13:16 ]

[marcop82]

Een update:

Ondertussen is er onderhoud gebeurt op de Exchange server, de Windows 2008 R2 loopt met de laatste updates (na SP1) en Exchange ook (SP3 en Rollup). Echter blijft het oorspronkelijke probleem bestaan.

Tijdens het updaten is er ook geen énkel probleem naar voren gekomen, ik had begrepen dat RTM -> SP1 de databases zou bijwerken. Dus als er een issue met de databases zou zijn, zou ik verwachten dat deze dán naar voren zouden komen. Maar totaal geen issues.

[Razwer]

een jaar of 5 geleden ook eens zoiets gehad. Search deed het ook niet meer.
ivm tijdgebrek een workaround gedaan. Nieuwe databases aangemaakt en alle mailboxen gemoved naar die nieuwe databases. Oude databases verwijderd. Werkte als een zonnetje.
(tijdelijk) je databases op circular logging is een optie ivm log groei

edit: zie net dat dit een spuit11 reactie is en Mark dit al veel eerder voorstelde. excuus.

[ Voor 26% gewijzigd door Razwer op 04-08-2015 10:18 ]

[marcop82]

Het is inderdaad nog een optie die wordt gedaan, maar ik probeer eerder de oorzaak te vinden aangezien het niet zozeer lijkt dat de database kapot is maar dat Backup Exec weer één van zijn vele karakteristieke faalmomenten heeft waar het niet in slaagt te zeggen wat het probleem is. Het is ook tot nu toe énkel Backup Exec die de problemen ziet.

Ik onderzoek momenteel een andere mogelijke oorzaak: Volume Shadow Copy. Deze staat blijkbaar uitgeschakeld op de schijf waar de databases staan en het lijkt me dat dit juist aan moet. Nu ga ik me even inlezen hoe groot het moet zijn of hoeveel ruimte het inneemt want de datastore van het serverpark heeft nog maar een 200GB vrij, terwijl we rond de 150GB aan mail databases hebben. Uitbreiding staat in de planning maar niet voor deze week natuurlijk

[Killah_Priest]

marcop82 schreef op dinsdag 04 augustus 2015 @ 15:13:
Het is inderdaad nog een optie die wordt gedaan, maar ik probeer eerder de oorzaak te vinden aangezien het niet zozeer lijkt dat de database kapot is maar dat Backup Exec weer één van zijn vele karakteristieke faalmomenten heeft waar het niet in slaagt te zeggen wat het probleem is. Het is ook tot nu toe énkel Backup Exec die de problemen ziet.

Ik onderzoek momenteel een andere mogelijke oorzaak: Volume Shadow Copy. Deze staat blijkbaar uitgeschakeld op de schijf waar de databases staan en het lijkt me dat dit juist aan moet. Nu ga ik me even inlezen hoe groot het moet zijn of hoeveel ruimte het inneemt want de datastore van het serverpark heeft nog maar een 200GB vrij, terwijl we rond de 150GB aan mail databases hebben. Uitbreiding staat in de planning maar niet voor deze week natuurlijk

Als ik tijdens een lopende backup de shadow storage bekijk dan zie ik deze ook bij volumes waarop Shadow Copy uitstaat dat deze toeneemt hoor.
Waarom doen jullie het database trucje niet gewoon? Nieuwe DB aanmaken is zo gedaan, mailboxen moven duurt over het algemeen ook niet zo lang (helemaal niet bij 150GB aan mailboxen). Als het goed is kun je gewoon overdag mailboxen moven zonder dat de gebruikers hier echt veel last van hebben.

[beOnt]

Gebruik je een Exchange DAG?

Backup exec en de windows VSS service hebben zo regelmatig hun kuren...

Als ik tijdens een lopende backup de shadow storage bekijk dan zie ik deze ook bij volumes waarop Shadow Copy uitstaat dat deze toeneemt hoor.
Waarom doen jullie het database trucje niet gewoon? Nieuwe DB aanmaken is zo gedaan, mailboxen moven duurt over het algemeen ook niet zo lang (helemaal niet bij 150GB aan mailboxen). Als het goed is kun je gewoon overdag mailboxen moven zonder dat de gebruikers hier echt veel last van hebben.

Inderdaad, ergste wat de gebruikers normaal kunnen tegen komen is de melding dat ze hun outlook moeten dichtdoen en terug opendoen.

[ Voor 73% gewijzigd door beOnt op 04-08-2015 20:20 ]

[marcop82]

beOnt schreef op dinsdag 04 augustus 2015 @ 20:15:
Gebruik je een Exchange DAG?

Nope, alle Exchange services op één servertje zelfs

Inderdaad, ergste wat de gebruikers normaal kunnen tegen komen is de melding dat ze hun outlook moeten dichtdoen en terug opendoen.

Dit zorgt gegarandeerd voor oproepen naar de helpdesk dus ook bij mij (want non-profit KMO/MKB) en persoonlijk zoek ik liever de oorzaak dan enkel het symptoom te bestrijden, omdat het énkel Backup Exec is die dit probleem veroorzaakt, niet tijdens andere backups, normaal gebruik, updates of aanpassingen.

[ Voor 6% gewijzigd door marcop82 op 05-08-2015 08:29 ]

[Killah_Priest]

marcop82 schreef op woensdag 05 augustus 2015 @ 08:27:
[...]

Nope, alle Exchange services op één servertje zelfs


[...]

Dit zorgt gegarandeerd voor oproepen naar de helpdesk dus ook bij mij (want non-profit KMO/MKB) en persoonlijk zoek ik liever de oorzaak dan enkel het symptoom te bestrijden, omdat het énkel Backup Exec is die dit probleem veroorzaakt, niet tijdens andere backups, normaal gebruik, updates of aanpassingen.

Dan doe je dit toch 's avonds?
Database aanmaken is 2 minuten werk max, een mailbox move request inschieten is (vanuit de GUI) 20 seconden max per user ; via PS voor alle mailboxen een move request inschieten is helemaal makkelijk te doen.
De mailboxen moven zie ik niet als symptoombestrijding ; dit is juist werken aan een oplossing.

Wat ga je nu doen als bv de database helemaal corrupt raakt? Aangezien je backups falen lijkt dat scenario mij een stuk erger als een paar telefoontjes naar de helpdesk (en als je gewoon vantevoren een mailtje stuurt naar alle medewerkers dan zou je dat ook kunnen voorkomen).
Geloof mij maar : je wilt GEEN restore doen op je Exchange omgeving als je dit al niet op kunt lossen (en dat bedoel ik niet als een aanval op jou persoonlijk, Exchange is gewoon vrij specialistisch, helemaal als je eerst een recovery DB moet gaan mounten etc, als je hier tegenaanloopt wanneer de "klok loopt" en men maar blijft vragen wanneer de boel weer werkt dan gaat het restoren niet echt lekker).

[marcop82]

marcop82 schreef op dinsdag 04 augustus 2015 @ 15:13:
Ik onderzoek momenteel een andere mogelijke oorzaak: Volume Shadow Copy. Deze staat blijkbaar uitgeschakeld op de schijf waar de databases staan en het lijkt me dat dit juist aan moet.

Dit was de oorzaak, Volume Shadow Copy enabled op de storage van de Exchange server en de fouten kwamen niet meer voor (in EventViewer via BackupExec).

[rookie no. 1]

marcop82 schreef op maandag 10 augustus 2015 @ 10:34:[...]Dit was de oorzaak, Volume Shadow Copy enabled op de storage van de Exchange server en de fouten kwamen niet meer voor (in EventViewer via BackupExec).

Vreemd, volgens mij is het helemaal niet nodig en zeker niet beter om Shadow Copy (via Computer Management -> Disk Management) in te stellen op volume(s) waar Exchange iets mee doet. Een backup programma die VSS kan gebruiken (zoals SBE en WSB), doet daar niets mee als ik het goed heb.

Wel fijn dat je foutmelding opgelost is. Ik zit nog met dezelfde momenteel en heb tijdelijk 'verify on job complete' maar uitgezet. Wij gaan in elk geval de mailboxes verplaatsen naar een nieuwe database aangezien een consistency check niets heeft opgelost.