Meer informatie

Exchange Server gebruikt fouttolerante en op transacties gebaseerde databases om berichten en adreslijstinformatie op te slaan voordat deze definitief op de database worden toegepast. Bij Exchange Server 5.5 Standard Edition kan elke database een grootte van maximaal 16 gigabyte (GB) bereiken. Bij Exchange Server 5.5 Enterprise Edition wordt de grootte slechts beperkt door de hardware.


In het geval van een stroomstoring of een andere onvoorziene systeemstoring gebruikt Exchange Server transactielogboekbestanden om gegevens opnieuw samen te stellen die al zijn geaccepteerd door de server maar nog niet naar de database zijn geschreven.

Databasecomponenten

Het ontwerp van Exchange Server is gebaseerd op standaard databasetechnologie. Het systeem werkt met een ingesloten database-engine waarin de schijfstructuur voor Exchange Server wordt beschreven en waarin het geheugen wordt beheerd. Achter de schermen wordt de database-enginetechnologie tevens gebruikt door andere Windows-toepassingen zoals Windows Internet Name Service (WINS) en Dynamic Host Configuration Protocol (DHCP).

Informatiearchief

De belangrijkste component voor databasebeheer in Exchange Server, het informatiearchief, bestaat in feite uit twee afzonderlijke databases. In de privé-database van het informatiearchief, Priv.edb, worden de gegevens in gebruikerspostbussen beheerd. In de openbare database van het informatiearchief, Pub.edb, worden de gegevens in openbare mappen beheerd.


Het informatiearchief werkt samen met de Messaging Application Programming Interface (MAPI) en de database-engine om ervoor te zorgen dat alle gebruikersacties worden vastgelegd op de vaste schijf van de server. Als een gebruiker bijvoorbeeld een bericht opslaat in Microsoft Outlook, roept MAPI het informatiearchief aan. Het informatiearchief roept vervolgens de database-engine aan, waarna deze de wijzigingen naar de schijf schrijft.

JET Database-engine

Exchange Server-databases zijn gebaseerd op de JET-indeling, waarbij logboekbestanden worden gebruikt om informatie te traceren en bij te houden. Microsoft JET is een geavanceerde 32-bits multithreaded database-engine waarbij snelheid en prestatie worden gecombineerd met andere geavanceerde voorzieningen voor betere op transacties gebaseerde verwerkingsmogelijkheden.


De database-engine slaat schijfgegevens in het cachegeheugen op door gegevenspagina's van 4 kilobyte (kB) met het geheugen uit te wisselen. De engine werkt de pagina's in het geheugen bij en schrijft nieuwe en bijgewerkte pagina's terug naar de schijf. Hierdoor wordt het systeem efficiënter omdat nieuwe verzoeken door de database-engine als gegevens in het buffergeheugen worden geplaatst. Hierdoor hoeft de schijf minder vaak te worden gebruikt.


In eerdere versies van Exchange Server dan 5.5 had het buffercachegeheugen een vaste grootte. Als meer geheugen nodig was, moest de beheerder de buffergrootte handmatig aanpassen.


Exchange Server 5.5 maakt gebruik van dynamische buffertoewijzing waardoor de buffercache vergroot of verkleind kan worden, afhankelijk van de hoeveelheid beschikbaar geheugen en de bronnen die worden gebruikt door andere services die worden uitgevoerd op de Microsoft Windows NT Server-computer. Als er geen geheugen wordt gebruikt door andere services, gebruikt de database-engine van Exchange Server zoveel geheugen als nodig is. Zodra andere services geheugen nodig hebben, geeft de database-engine een hoeveelheid geheugen vrij door pagina's over te brengen naar de vaste schijf en de grootte van de buffer te verminderen.


Als een gebruiker een verzoek indient, laadt de database-engine het verzoek in het geheugen en markeert de engine de pagina's als 'vuil' (ofwel 'dirty'). Een 'vuile' pagina is een pagina waarop nieuwe gegevens zijn geschreven terwijl de pagina zich nog in het geheugen bevindt en dus nog niet is weggeschreven naar de vaste schijf. Deze vuile pagina's worden op een later tijdstip weggeschreven naar de informatiearchiefdatabases op de schijf.

Onderhouden van de databaseconsistentie

Hoewel het gebruik van een cachegeheugen een van de efficiëntste manieren is om gegevens te verwerken, is de consequentie daarvan dat de informatie op de vaste schijf nooit helemaal up-to-date is. Door de vuile pagina's in het geheugen worden de databases gemarkeerd als niet-consistent, ook al word Exchange Server normaal uitgevoerd. Alleen wanneer alle vuile pagina's correct zijn overgebracht naar de vaste schijf tijdens een afsluitactie zonder fouten, kan bij een database echt van een consistente situatie worden gesproken.


Wat gebeurt er als de geheugeninhoud verloren gaat? Wat moet ik bijvoorbeeld doen als de server vastloopt voordat de gegevens naar de vaste schijf kunnen worden geschreven, waardoor ik een niet-consistente database overhoud? Exchange maakt gebruik van transactielogboekbestanden om deze situatie te herstellen.

Transactielogboekbestanden

In transactielogboekbestanden wordt een beveiligde kopie bewaard van de vluchtige gegevens in het geheugen. Als het systeem vastloopt, kunt u (als de database niet beschadigd is) met de logboekbestanden de gegevens herstellen tot de laatste transactie die is vastgelegd voordat het systeem vastliep. (Het verdient aanbeveling de logboekbestanden op te slaan op een vaste schijf die u speciaal voor dit doel gebruikt, zodat de logboekbestanden niet worden aangetast door mogelijke schijffouten die de database kunnen beschadigen.)


Exchange is een berichtensysteem dat op transacties is gebaseerd, en het informatiearchief is dan ook een transactionele database. Een transactie bestaat uit een reeks wijzigingen in een database, zoals invoegacties, verwijderacties en updates. Hierbij volgt het systeem vier 'ACID'-principes:

• Atoomprincipe: alle bewerkingen vinden plaats of er vindt geen enkele bewerking plaats.
• Consistentie: de database wordt overgebracht van een correcte status naar een andere correcte status.
• Isolement: de wijzigingen zijn pas zichtbaar als deze zijn vastgelegd.
• Duurzaamheid: vastgelegde transacties worden bewaard in de database, ook als het systeem vastloopt.

Door deze principes bent u ervan verzekerd dat de database-engine een transactie alleen vastlegt wanneer gegarandeerd kan worden dat de gegevens duurzaam en blijvend zijn, en beveiligd tegen systeem- en andere storingen. De database-engine legt gegevens alleen vast als deze gegevens zijn overgebracht van het geheugen naar het transactielogboekbestand op de vaste schijf.


Zo voert Exchange Server drie bewerkingen uit om een bericht te verplaatsen van het Postvak IN naar de map Belangrijk:

1. Verwijderen van het bericht uit het Postvak IN
2. Invoegen van het bericht in de map Belangrijk
3. Bijwerken van de informatie voor deze twee mappen zodat het juiste aantal items en ongelezen items wordt vermeld

Deze bewerkingen vinden plaats in één enkele transactie. De volgorde van de bewerkingen is hierbij niet relevant. Exchange Server kan het bericht veilig verwijderen uit het Postvak IN omdat het verwijderen alleen wordt vastgelegd als het bericht veilig is ingevoegd in de map Belangrijk. Zelfs als het systeem vastloopt, verliest Exchange Server nooit een bericht terwijl dit wordt verplaatst. Ook blijven er nooit twee verschillende exemplaren van hetzelfde bericht over na afloop van de transactie.


Logisch gezien lijkt het alsof de gegevens worden verplaatst van het geheugen naar het logboekbestand en daarna naar de database op de vaste schijf. Dit is echter niet het geval. De gegevens worden verplaatst van het geheugen naar de database op de vaste schijf. De logboekbestanden worden geoptimaliseerd voor schrijfbewerkingen met hoge snelheid, en tijdens normale bewerkingen leest de database-engine de logboekbestanden niet. Alleen als de informatiearchief-service onverwachts wordt beëindigd of vastloopt en de database-engine een herstelbewerking moet uitvoeren met behulp van de logboekbestanden, worden de logboekbestanden gelezen door de database-engine.

Het controlepuntbestand


De database-engine houdt een controlepuntbestand bij met de naam Edb.chk. Hierin wordt de volgorde van de logboekbestandsvermeldingen vastgelegd zodat de gegevens die nog niet naar het databasebestand op de vaste schijf zijn geschreven, kunnen worden gecontroleerd. Het controlepuntbestand dient als aanwijzer in de logboekreeks en geeft het punt aan in het logboekbestand waar het informatiearchief de herstelbewerking moet starten wanneer een storing heeft plaatsgevonden. Het controlepuntbestand is onmisbaar voor een efficiënt herstel. Zonder dit bestand zou het informatiearchief de herstelbewerking uitvoeren vanaf het begin van het oudste logboekbestand op de schijf en zou het elke pagina van elk logboekbestand controleren om te zien of dit al naar de database is geschreven. Dit is een tijdrovend proces, vooral als de bedoeling alleen maar is het consistent maken van de database.


Het controlepuntbestand bevindt zich op de systeemschijf. Als de systeemschijf moet worden hersteld, ontbreekt dit bestand waarschijnlijk of heeft het een ongeldige versie. Maar in de meeste gevallen zorgt het controlepuntbestand zelf dat er geen problemen zijn.

Normale logboekregistratie


In de volgende stappen komt het proces voor 'normale logboekregistratie' aan de orde. Daarbij worden gegevens naar de transactielogboekbestanden geschreven:

1. De gebruiker stuurt een bericht.
2. MAPI roept het informatiearchief aan om te melden dat de gebruiker een bericht verzendt.
3. Het informatiearchief start een transactie in de database-engine en brengt de desbetreffende wijzigingen aan in de gegevens.
4. De database-engine legt de transactie vast in het geheugen door een nieuwe pagina in het geheugen te 'bevuilen'.
5. Op hetzelfde moment legt de database-engine de transactie veilig vast in het transactielogboekbestand door een logboekvermelding te maken. Wanneer de database-engine het einde bereikt van een transactielogboekbestand, gaat de engine door met een nieuw logboekbestand in een bepaalde reeks.
6. De database-engine schrijft de vuile pagina naar het databasebestand op de vaste schijf.
7. Het controlepuntbestand wordt bijgewerkt.

Circulaire logboekregistratie


Exchange Server ondersteunt de functie voor circulaire logboekregistratie. Deze functie werd voornamelijk gebruikt toen schijfruimte op de server belangrijker werd geacht door beheerders dan gegevensherstel.


Circulaire logboekregistratie werkt grotendeels op dezelfde manier als normale logboekregistratie. Het controlepuntbestand is bij circulaire logboekregistratie echter van essentieel belang voor het bijhouden van de gegevens die naar de schijf worden overgebracht. Bij circulaire logboekregistratie worden de oude logboekbestanden opnieuw gebruikt wanneer het controlepuntbestand verdergaat met het volgende logboekbestand. Als dit gebeurt, kunnen de logboekbestanden op de schijf niet samen met de back-upmedia worden gebruikt om een herstelbewerking uit te voeren tot de laatst vastgelegde transactie.


Standaard wordt circulaire logboekregistratie ingeschakeld in Exchange Server 5.5 om ervoor te zorgen dat een vaste grootte kan worden gebruikt voor logboekbestanden en dat er niet te veel logboekbestanden worden gegenereerd. Zodra een logboekbestand de limiet van 5 MB bereikt, wordt het verwijderd door de database-engine en wordt een nieuw logboekbestand gemaakt in een bepaalde reeks. Exchange Server bewaart daarom slechts genoeg gegevens op de vaste schijf om ervoor te zorgen dat de database consistent blijft in geval van een systeemstoring.


Het verdient aanbeveling circulaire logboekregistratie uit te schakelen op de Exchange Server-computer. De benodigde schijfruimte voor circulaire logboekregistratie is dan weliswaar kleiner, maar u verliest tevens de mogelijkheid om een herstelbewerking uit te voeren tot de transactie die het laatst is vastgelegd voordat een systeemstoring plaatsvond. De logboekbestanden kunnen niet opnieuw worden doorgewerkt en gegevens kunnen alleen worden hersteld tot de laatste volledige back-up. Ook als slechts één logboekbestand is overschreven, is er geen manier om de overige 99 procent van de logboekgegevens te herstellen.


In feite worden de voordelen van een op transacties gebaseerd systeem tenietgedaan door circulaire logboekregistratie. Alleen wanneer u de gegevens niet nodig hebt of wanneer u beschikt over andere manieren van gegevensherstel, is het verstandig circulaire logboekregistratie ingeschakeld te laten. Als u zich zorgen maakt over de schijfbronnen die in beslag worden genomen door de logboekbestanden, kunt u de schijfruimte beter schoonmaken door regelmatig on line back-ups uit te voeren. Door het maken van een back-up worden transactielogboekbestanden automatisch verwijderd wanneer deze niet meer nodig zijn.

Gegevensbeveiliging

Het lijkt logisch dat databasebestanden het belangrijkste aspect vormen van gegevensherstel. In Exchange Server zijn transactielogboekbestanden echter belangrijker omdat deze informatie bevatten die niet in de databasebestanden aanwezig is. (Daarom moet u deze bestanden plaatsen op krachtige, speciaal voor dit doel bestemde schijven op een stabiele server, ook als daardoor de databasebestanden op langzamere schijven moeten worden geplaatst).


Transactielogboekbestanden zorgen ervoor dat een beveiligde kopie van vluchtige gegevens in het geheugen op schijf wordt opgeslagen. Als het systeem vastloopt en de database is niet beschadigd, kunt u, zolang u beschikt over de logboekbestanden, de gegevens herstellen tot de transactie die het laatst is vastgelegd voordat een systeemstoring plaatsvond.


Door het gebruik van transactielogboekbestanden vindt tevens het schrijven van gegevens efficiënter plaats omdat het sequentieel bijwerken van pagina's in een logboekbestand minder tijd in beslag neemt dan het invoegen van pagina's in de database. Wanneer een wijziging plaatsvindt in de database, worden de gegevens in het geheugen bijgewerkt door de database-engine. De engine schrijft synchroon een record van de transactie naar het logboekbestand, waarin wordt vermeld hoe de transactie opnieuw kan worden uitgevoerd in geval van een systeemstoring. Daarna schrijft de database-engine de gegevens naar de database op de schijf. De pagina's worden door de database-engine batchgewijs naar de schijf overgebracht om de schijf-I/O (schijfinvoer en schijfuitvoer) zo efficiënt mogelijk te houden.


Elk logboekbestand in een reeks kan tot 5 MB aan gegevens bevatten. Als een logboekbestand vol is, wordt de naam ervan gewijzigd in die van een eerder logboekbestand en wordt een nieuw logboekbestand gemaakt met de bestandsnaam Edb.log. Exchange Server koppelt een hexadecimaal nummer aan elk logboekbestand. Omdat logboekbestanden dezelfde naam kunnen hebben, brengt de database-engine in de header van elk bestand in de reeks een stempel aan in de vorm van een unieke handtekening. Hierdoor kan de engine onderscheid maken tussen verschillende generaties logboekbestanden.

Databasebeschadiging

Exchange kan een storing ondervinden, zoals een hardwarefout, waardoor het systeem moet proberen terug te keren tot een consistente situatie. Omdat er verschillenden typen databasebeschadiging zijn met verschillende symptomen, zijn verschillende hulpprogramma's en technieken vereist voor het vaststellen en oplossen van problemen.


Er zijn twee soorten beschadiging:

• Fysieke beschadiging
  
  Op het laagste niveau kunnen gegevens fysiek worden beschadigd op de schijf. Normaal gesproken betreft het hier een hardwareprobleem waarvoor altijd de gegevens moeten worden teruggezet vanaf een back-up.
• Logische beschadiging
  
  Logische beschadiging vindt meestal plaats op databaseniveau. Zo kunnen indexvermeldingen verwijzen naar ontbrekende waarden als gevolg van storingen in de database-engine. Logische beschadiging kan ook plaatsvinden op toepassingsniveau, in postbussen, in berichten, in mappen en in bijlagen. Beschadiging op toepassingsniveau kan bijvoorbeeld resulteren in onjuiste referentietellingen, onjuiste toegangsbesturingsniveaus, berichtkoppen zonder bijbehorende berichttekst, enzovoort.

Fysieke beschadiging

Fysieke beschadiging is een ernstige vorm van beschadiging omdat er gegevens door verloren kunnen gaan. De enige oplossing is het terugzetten van Exchange-gegevens vanaf een back-up. Het is belangrijk fysieke beschadiging in een vroeg stadium te detecteren en de problemen snel op te lossen.

Fysieke beschadiging detecteren


Door fysieke beschadiging in het informatiearchief worden de volgende foutberichten gegenereerd in Logboekinzage:

• -1018 (JET_errReadVerifyFailure) The data read from disk is not the same as the data that was written to disk.
• -1022 (JET_errDiskIO) The hardware, device driver, or operating system is returning errors.
• -510 JET_errLogWriteFail The log files are out of disk space or there is a hardware failure with the log file disk.

Meestal zal Exchange een -1018- of -1022-foutbericht weergeven wanneer er sprake is van fysieke beschadiging. U kunt fysieke beschadigingen echter ook detecteren door on line back-ups uit te voeren. Deze methode wordt door Microsoft aanbevolen voor het uitvoeren van back-ups van gegevens. Bovendien zijn on line back-ups uitermate geschikt voor het detecteren van beschadigingen in het databasebestand. Tijdens dit back-upproces wordt namelijk elke pagina in de database gecontroleerd.


Wanneer u een on line back-up uitvoert, leest het Windows NT Backup-programma elke pagina van 4 kB in het databasebestand, geeft het deze door aan de database-engine en schrijft het vervolgens de pagina naar tape. De database-engine controleert of de controlesom voor elke pagina correct is. Als de controlesom op de pagina niet overeenkomt met de door de database-engine berekende controlesom, is er sprake van fysieke databasebeschadiging op de vaste schijf en wordt door NT Backup een -1018-fout vastgelegd in het logboek.

Fysieke beschadiging voorkomen


De beste manier om fysieke beschadiging te voorkomen is ervoor te zorgen dat de server is uitgerust met kwaliteitshardware en door het systeem juist te configureren. Zorg ervoor dat u geen hulpprogramma's op bestandsniveau uitvoert, zoals antivirusprogramma's, voor database- en logboekbestanden op de server met Exchange Server.


Wanneer u beschikt over betrouwbare hardware, zult u mogelijk nooit aanwijzingen van fysieke beschadigingen aantreffen. Als er wel voortdurend -1018-fouten worden weergegeven, is er waarschijnlijk sprake van een hardwareprobleem. Dit zou bijvoorbeeld een beschadigde schijf of een beschadigde schijfcontroller kunnen zijn.


Een kanttekening bij write-back cachegeheugen: Bij sommige write-back cachegeheugens op controllers voor schijfgroepen wordt ten onrechte gerapporteerd dat transacties correct zijn vastgelegd, omdat de gegevens nog niet veilig naar de schijf zijn weggeschreven. Het beste kunt u hier het write-back cachegebruik uitschakelen tenzij het proces wordt uitgevoerd met een batterij voor back-up. Als u besluit toch gebruik te maken van write-back cachegebruik, kunt u beschadigingen aan de database voorkomen door ervoor te zorgen dat de gegevens volledig beveiligd zijn en dat procedures zijn opgesteld om ervoor te zorgen dat gegevens in het cachegeheugen naar de juiste schijven worden teruggezet na een systeemstoring.

Het systeem herstellen na fysieke beschadiging


Herstellen van fysieke databasebeschadiging is alleen mogelijk door de laatste goede back-up terug te zetten (een goede back-up is een back-up die zonder fouten is uitgevoerd) en de logboekbestanden bij te werken. Hierdoor kan het systeem weer in een consistente en onbeschadigde toestand worden gebracht. Herhaalde fouten duiden waarschijnlijk op een probleem met de schijf waarop de database zich bevindt.


Er is in feite geen veilige manier om fysieke beschadiging van de database te repareren. Het is mogelijk het hulpprogramma Eseutil.exe uit te voeren in herstelmodus om ervoor te zorgen dat de database weer functioneert. Dit wordt echter niet aanbevolen omdat Eseutil beschadigde pagina's simpelweg verwijdert.

OPMERKING: indien mogelijk kunt u het beste het gebruik van Eseutil in herstelmodus (Eseutil /p) vermijden. Eseutil, dat bij Exchange Server wordt geleverd, is een laatste redmiddel voor het repareren van databasebeschadigingen. Het dient alleen te worden gebruikt als u alle andere oplossingen hebt geprobeerd. In de herstelmodus krijgt het programma een beschadigde database weer aan de praat door eenvoudigweg alle beschadigde pagina's te verwijderen. Gebruik Eseutil nooit om gegevens te herstellen. Als u desondanks besluit de opdrachtEseutil /puit te voeren, moet u de opdracht Isinteg -test alltests -fixgebruiken om het systeem terug te brengen in een consistente toestand.

Logische beschadiging

Logische beschadiging is moeilijker op te sporen en op te lossen dan fysieke beschadiging omdat logische beschadiging onvoorspelbaar is en meestal wordt veroorzaakt door softwarefouten. Normaal gesproken ziet u pas dat er sprake kan zijn van logische beschadigingen wanneer zich een probleem voordoet. (Logische beschadiging komt zeer zelden voor in Exchange Server 5.5.)

Logische beschadiging voorkomen


Omdat logische beschadiging zo onvoorspelbaar is, is er geen volkomen veilige manier om dit te voorkomen. Er zijn echter manieren om het risico te verminderen:

• Installeer zo snel mogelijk het meest recente service pack voor Microsoft Exchange Server versie 5.5. In service packs zijn een aantal bekende problemen in Exchange Server 5.5 opgelost.
  
  
  Klik op de volgende artikelnummers in de Microsoft Knowledge Base als u meer informatie wilt over service packs en hoe u ze ophaalt:
  

  241740 List of Bugs Fixed in Exchange Server 5.5 Service Pack 3

  254682 XADM: Exchange Server 5.5 Post-SP3 Database Engine Fixes

  191014 How to Obtain the Latest Exchange Server 5.5 Service Pack

• Zorg ervoor dat uw Exchange Server-computer beveiligd is en dat de configuratie niet is gewijzigd.

Als u een probleem ontdekt en het probleem blijft zich voordoen nadat u deze voorzorgsmaatregelen hebt getroffen, hebt u mogelijk een nieuwe programmafout ontdekt. Breng Microsoft in dat geval zo spoedig mogelijk hiervan op de hoogte.
Logische beschadiging repareren


Logische beschadiging kan plaatsvinden in het informatiearchief of in de database-engine. Door logische beschadiging kunnen gegevens ernstig worden beschadigd. Negeer dus geen gemelde fouten.


U kunt gebruikmaken van het hulpprogramma Isinteg om problemen in het informatiearchief te controleren of van het hulpprogramma Eseutil om problemen in de database-engine te controleren. Deze hulpprogramma's moeten alleen worden gebruikt als allerlaatste redmiddel nadat u het systeem hebt geprobeerd terug te zetten van een back-up.

Het hulpprogramma Isinteg


De Information Store Integrity Checker (Isinteg) zoekt en verwijdert fouten in de privé- en openbare informatiearchiefdatabases. Deze fouten kunnen er de oorzaak van zijn dat het informatiearchief niet kan worden gestart of dat gebruikers zich niet kunnen aanmelden en geen e-mailberichten kunnen ontvangen, openen of verwijderen.


Isinteg is niet bedoeld als onderdeel van een normale onderhoudsstrategie van het informatiearchief. Het programma kan helpen bij noodherstelsituaties. Zo kunt u Isinteg uitvoeren om tellers van het informatiearchief in het geheugen te corrigeren wanneer deze niet meer gesynchroniseerd zijn na een systeemstoring.


Omdat Isinteg werkt op het niveau van logische schema's, kan dit hulpprogramma gegevens herstellen waartoe Eseutil niet in staat is. De reden hiervoor is dat gegevens die geldig zijn voor Eseutil op het niveau van fysieke schema's, semantisch ongeldig kunnen zijn op het niveau van logische schema's. Isinteg legt informatie vast in Logboekinzage, zodat u de voortgang van het herstelproces kunt bijhouden.


Het hulpprogramma Isinteg voert twee hoofdtaken uit:

• Het repareert het informatiearchief na het terugzetten van een off line back-up.
• Het controleert op fouten in het informatiearchief en kan deze desgewenst herstellen.

Als u meer informatie wilt over het oplossen van problemen met het informatiearchief en het hulpprogramma Isinteg, klikt u op het volgende artikelnummer in de Microsoft Knowledge Base:


of raadpleegt u het document Isinteg.rtf op de Exchange Server 5.5-cd in de map Support\Utils.

Het hulpprogramma Eseutil


Eseutil onderzoekt de structuur van de databasetabellen en -records en voert een defragmentatie, reparatie en integriteitscontrole uit voor het informatiearchief en de map hiervan. Het uitvoeren van Eseutil in herstelmodus betekent simpelweg dat beschadigde pagina's worden verwijderd. Gebruik dit hulpprogramma daarom alleen nadat u het systeem hebt geprobeerd terug te zetten van een back-up.


Als u meer informatie wilt over het hulpprogramma Eseutil, klikt u op het volgende artikelnummer in de Microsoft Knowledge Base:
of raadpleegt u het document Eseutil.rtf op de Exchange Server 5.5-cd in de map Support\Utils.

Gegevensback-up

Omdat Exchange Server op transacties is gebaseerd, dient u het uitvoeren van back-ups op bestandsniveau (off line back-ups) van de databasebestanden op de schijf te vermijden. De beste manier om ervoor te zorgen dat alle gegevens in het systeem bewaard blijven, inclusief de transacties die nog niet naar de schijf zijn geschreven, is door regelmatig on line back-ups uit te voeren.

On line back-up

Met on line back-ups kunt u back-ups van Exchange Server-databases naar uw back-upmedia schrijven zonder dat u de server hoeft af te sluiten. Wanneer Exchange Server een on line back-up uitvoert, worden alle services (met inbegrip van het informatiearchief) normaal verder uitgevoerd. Pagina's worden normaal bijgewerkt in het geheugen en overgebracht naar de databasebestanden op de schijf, transacties worden vastgelegd in de logboekbestanden en het controlepuntbestand wordt verder bijgewerkt.


Exchange maakt gebruik van een .pat (patch)-bestand waarin bijgewerkte pagina's worden bijgehouden terwijl de back-upsoftware wordt uitgevoerd. Hierdoor bent u ervan verzekerd dat de pagina's die worden gewijzigd tijdens de back-up, ook in de back-up worden opgenomen. Er zijn twee .pat-bestanden: Priv.pat voor het privé-informatiearchief en Pub.pat voor het openbare informatiearchief.


Wanneer u een on line back-up uitvoert, dient u regelmatig de Logboekinzage te controleren om er zeker van te zijn dat de back-ups zonder fouten worden uitgevoerd.

Werkwijze van on line back-up


Een back-upprogramma zoals Windows NT Backup (Ntbackup.exe) voert de volgende bewerkingen uit tijdens een volledige back-up of een kopieerback-up:

1. Een kopie maken van de database en hiervan een back-up op tape zetten.
2. Een verzameling pagina's toevoegen aan het .pat-bestand (de pagina's die veranderen nadat ze naar tape zijn gekopieerd).
3. De naam van het huidige Edb.log-bestand wijzigen in Edbx.log, waarbijxhet generatienummer van het logboekbestand in hexadecimale notatie is, en een nieuwe logboekgeneratie maken.
4. Bij een volledige back-up wordt een back-up van het .pat-bestand en van alle logboekbestanden na het controlepunt (behalve van het nieuwe Edb.log) naar tape geschreven. Bij een kopieerback-up wordt een back-up gemaakt van alle logboekbestanden voor en na het controlepunt.
5. Bij een volledige back-up worden de transactielogboekbestanden die ouder zijn dan het controlepunt, verwijderd. Bij een kopieerback-up worden geen transactielogboekbestanden verwijderd.

Een back-upprogramma voert de volgende bewerkingen uit tijdens een incrementele back-up of een differentiële back-up:

1. Bij een incrementele back-up wordt een kopie gemaakt van de logboekbestanden, waarvan een back-up naar tape wordt geschreven. Bij een differentiële back-up wordt de database naar tape gekopieerd.
2. Een verzameling pagina's toevoegen aan het .pat-bestand (de pagina's die veranderen nadat ze naar tape zijn gekopieerd).
3. De naam van het huidige Edb.log-bestand wijzigen in Edbx.log en een nieuwe logboekgeneratie maken.
4. Een back-up van het .pat-bestand en van alle logboekbestanden voor en na het controlepunt (met inbegrip van het nieuwe bestand Edb.log) naar tape schrijven.
5. Bij een incrementele back-up worden de transactielogboekbestanden die ouder zijn dan het controlepunt, verwijderd. Bij een differentiële back-up worden geen transactielogboekbestanden verwijderd.

Off line back-up

Probeer het uitvoeren van off line back-ups te vermijden. Tijdens een on line back-up worden de bestanden volledig beheerd door het back-upprogramma. Een off line back-up is echter een handmatig en arbeidsintensief proces waarbij gemakkelijk fouten kunnen worden gemaakt. Ook kan bij een off line back-up de controlesom niet worden geverifieerd voor de pagina's van de database. Voor het detecteren van beschadigingen en het uitvoeren van gegevensherstel zijn on line back-ups het meest waardevolle hulpmiddel.


Als u meer informatie wilt over back-ups, klikt u op de volgende artikelnummers in de Microsoft Knowledge Base: