• Server neu booten. Beim booten wird ein «Soft Recovery» der Datenbank durchgeführt
• mtacheck.exe [\Program Files\Exchsrvr\Bin]
  
• isinteg.exe
  
• eseutil.exe [\Program Files\Exchsrvr\Bin]
  
  

1. Ins DOS. Ins exchsrvr\bin Directory
2. MTA Dienst stoppen (Ist wahrscheinlich eh nicht gestartet den sonst würden Sie diese Seite nicht lesen)
3. MTAcheck
4. Nachsehen im File exchsrvr\mtadata\mtacheck.out\mtacheck.log ob alles gut ging
5. Falls MTAcheck Fehler hatte:
   Im MTADATA sind vordefinierte 40 Queues *.DAT files. Damit der Engine Zeit spart wird nicht jedes mal ein File erstellt und wieder gelöscht. MTA hat eine vordefinierte Anzahl files *.DAT welche er bei Bedarf füllt und dann wieder leert. Bei viel traffic werden weitere generiert und wieder abgebaut. Die 40 base *.DAT files bleiben aber immer. Also reine performance Sache. Falls hier mal was nicht vorhanden ist, einfach ein gültiges Set ab einem anderen EX SRV oder EX CDROM drauf kopieren.
   ( Achtung dabei gehen alle aktuellen Queues verloren bitte alle unten genannten Schritte vorher ausprobieren )
   
   Probieren Sie den MTA Dienst zu starten. Falls dieses gelingt sind Sie ein grossen Schritt weiter.
   
   Falls der Dienst nicht kommt:
   
   
6. Stoppen Sie alle Dienste des Exchange ( Sind unübersehbar )
7. ISINTEG -patch
8. ISINTEG -PRI -test mailbox,message,folder ( Exchange 5.5 und nicht wie in all den Beispielen mit nur -pri dies gillt nur fuer die 5.0 Version welche nicht Relay sicher ist. Muss man erst mal finden. Und wo? Im Technet [ Nach 1H ], auf der Veritas [ Backup Exec ] Support Seite)
9. ISINTEG -PUB -test mailbox,message,folder ( Fuer den Public Folder resp. die Foren )
10. ISINTEG -s SERVERNAME -test allfoldertests ( Um alles zusammen zu testen. Achtung dauert eventuell Stunden! )
    
    Versuchen den MTA zu starten
    
    Falls der Dienst nicht kommt:
    
    
11. ESEUTIL.EXE ins c:\winnt\system32 kopieren
12. Ins exchsrvr\mdbdata
13. Sichern des ganzen PRIV.EDB auf andere Partition oder irgendwo wo Sie sicher ist. Achtung grosser file im GIGA Bereich.
14. Eseutil /R priv.edb
    
    
15. Falls Sie die Meldung «1032 (JET_errFileAccessDenied)» erhalten sind die stores gemountet also aktiv. Den entpsrechenden Dienst herunter fahren. Haben wir Anfangs erwähnt aber einige haben es nicht gelesen ;-)
    
    Falls sich z.B. der MTA oder andere EX Dienste jetzt immer noch nicht starten lassen
16. Eseutil /P priv.edv /V
    Repariert die Datenstruktur und Index des private Stores. Achtung nur als letzte Möglichkeit.
    
    darauf
17. Falls der Exchange Server jetzt immer noch nicht läuft stimmt sonst etwas nicht mehr. Gelöschte wichtige files? Sorry da kann keine Kurzanleitung mehr weiter helfen. Hier einige gute Links welche eventuell weiter helfen.

-------------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft Exchange Server, version 5.5
-------------------------------------------------------------------------------

SUMMARY
=======

This article explains how to perform and restore offline backups.

IMPORTANT: Microsoft recommends that you back up Microsoft Exchange Server
databases while the databases are running. These online backups provide two
important benefits:

 - You do not need to interrupt service. To perform an offline backup, you must
  shut down the database and interrupt service. Because the average size of
  information store databases is in the gigabyte range, service may be down for
  hours.

 - If you use an online backup, Exchange Server automatically backs up all of
  the appropriate database files, and restores them correctly. To successfully
  restore an offline backup, you must know exactly what you are doing. You must
  rely entirely on your own understanding of the files that are important to
  back up, the files that must be restored, and the files that must NOT be
  restored. If you are wrong, you may replay inappropriate log files into your
  database, and irreparably damage it.

There are two other tasks that an online backup performs automatically that you
must do manually if you are performing offline backups:

 - An online backup checks the page-level integrity of the database files as
  they are streamed onto tape. You can perform the same check manually with the
  Esefile utility. (The use of the Esefile utility is described later in this
  article.)

 - An online backup replays transaction logs into the database for "roll
  forward" restoration. Exchange Server can recover data created after the time
  that a backup was taken by applying subsequently created transaction log
  files to a restored database. If you restore an online backup, this replay is
  handled automatically. If you restore an offline backup, you must take great
  care to provide the correct files for replay, and to remove all of the other
  files that may interfere with replay.

NOTE: "Roll forward" restoration capability depends on preserving all of the
transaction logs created after the time that a backup was taken. To preserve all

of the logs, circular logging must be disabled. By default, circular logging is
enabled. For additional information about circular logging, click the article
number below to view the article in the Microsoft Knowledge Base:

   Q147523 XADM: Enabling or Disabling Circular Logging

Perform online backups whenever possible, but backup software failures or other
problems may sometimes make it necessary to temporarily rely on file copy, or
"offline," backups.

Use the offline backup and restoration procedures described in this article for
emergencies, not as an ongoing data preservation strategy. These are not
officially supported methods of backing up and restoring Exchange Server data.
You use these methods at your own risk, and if you make a mistake following
these directions, you may irreparably damage your database.

MORE INFORMATION
================

Before you perform an offline backup, you should first know the following:

 - Whether or not circular logging is enabled.

 - The path locations for your Exchange Server database files.

You can view this information using the Exchange Server Administrator program.
Start the Exchange Server Administrator program, and then click to expand the
container for your site. Click to expand the Configuration object, and then
click to expand the Servers object. Click to select the server that you want to
back up, and then view its properties.

You can control circular logging from the Advanced properties page. To disable
circular logging, click to clear the Circular Logging check box. If you change
the status of this check box, the database stops and restarts itself,
interrupting service.

You do not need to disable circular logging to perform offline backups. But if
you do not, you cannot "roll forward" to recover data created after the time
that the backup was made.

The Database Paths page of the  object lists locations for:

 - The database files (the Priv.edb, Pub.edb, and Dir.edb databases).

 - The transaction log files (the Edb*.log files).

 - The working path files (the Edb.chk file is the only important one).

You must restore databases to the same path names that they were backed up from.

For example, if you backed up the database from the E:\Exchsrvr\Mdbdata folder,
you must also restore it to the E:\Exchsrvr\Mdbdata folder, even if you are
restoring the database to a different server.

Transaction log files can be restored to a different path name, if necessary.
You
do not restore any files from the working path, but you still need to know this
location, because it is where the Edb.chk file resides.

Backing Up an Exchange Server Database Offline
----------------------------------------------

These instructions focus on backing up the information store databases. Backing
up the directory service database is a similar process, with occasional
exceptions that are pointed out where they occur.

1. Stop the service for the database that you want to back up (either
  information store or directory service).

2. Verify that the main database files are consistent. The main database file
  for the directory service is the Dir.edb database. The main database files
  for the information store are the Priv.edb and Pub.edb databases. (Not all
  Exchange Server computers have both databases.) At a command prompt, run:

   eseutil /mh database name | find /i "State"

   Sample result:

   E:\exchsrvr\mdbdata> eseutil /mh priv.edb | find /i "State"
           State: Consistent

   The database must be consistent before you back it up offline. If the
database
  is inconsistent, it was not shut down cleanly. Restart the database, and then
  shut it down again. If the state is still inconsistent, contact Microsoft
  Product Support Services (PSS) for further assistance.

3. Note the number of the highest numbered transaction log file contained in the

  Transaction Logs folder. Exchange Server transaction log files are numbered
  hexadecimally, starting with the Edb00001.log file.

4. If you are backing up the information store, copy the Priv.edb database and
  the Pub.edb database to a backup location. If you are backing up the
  directory service, copy the Dir.edb database to a backup location.

5. Start the database services.

6. (Optional) If circular logging is enabled, skip this step. If circular
  logging is disabled, and you want to "roll forward" later, then you must back
  up all of the numbered transaction log files (the Edbxxxxx.log files) up to
  and including the numbered log file you noted in step 3 above. Do not back up
  the Edb.log, Res1.log, and Res2.log files.

   If circular logging is disabled, log files accumulate until they are either
  manually deleted or removed automatically by the online backup process. If
  circular logging is enabled, no special management of log files is required.

   After you back up the log files, you can delete them to reclaim disk space.
  Because you have already restarted the database, new numbered log files may
  have already been created.

   IMPORTANT: Do not delete any log files later than the one that you noted in
  step 3 above; this is critical.

7. (Optional) Verify the page-level integrity of the copied databases using the
  Esefile utility.

   The Esefile.exe file is available on the Exchange Server 5.5 Service Pack 3
  compact disc (in the Support folder), or you can obtain it from PSS. The
  Esefile utility works for Exchange Server 5.0 or 5.5 databases.

   The Esefile utility command line for an Exchange Server 5.0 database is:

   esefile /x 

   The Esefile utility command line for an Exchange Server 5.5 database is:

   esefile /s 

   Sample result:

   E:\exchsrvr\mdbdata>esefile /s priv.edb

   Checksumming

          0    10   20   30   40   50   60   70   80   90  100
         |----|----|----|----|----|----|----|----|----|----|
         ...................................................

   23042 pages seen
  0 bad checksums
  241 uninitialized pages
  0 wrong page numbers

   esefile completes successfully after 10 seconds

   Uninitialized pages are acceptable, but in a healthy database, there are 0
bad
  checksums and 0 wrong pages numbers.

   If a database does not pass the Esefile utility integrity check, your best
  option is to restore a previous backup that you know to be good. If such a
  backup is not available, consult PSS for advice on repairing or salvaging the
  database.

Restoring an Offline Backup of an Exchange Server Database
----------------------------------------------------------

This section describes two procedures to restore an offline backup, which are
expanded on below:

 - "Point in time" restoration. No log files are replayed into the database. All

  of the data created after the backup was made is lost.

 - "Roll forward" restoration. The log files created after the backup was made
  are played into the database. All or almost all of the data created after the
  backup was made can be preserved.

"Point in Time" Restoration of an Offline Backup:

If circular logging is enabled, you must perform a "point in time" restoration
of
your offline backup; you cannot choose a "roll forward" restoration.

1. Stop all Exchange Server services, including the system attendant.

2. Move all of the files from all the data folders for the database you want to
  restore. For the information store, you usually need to empty all of the
  Mdbdata folders (there may be up to four of them) on all the volumes, and for
  the directory service, you must empty all of the Dsadata folders (there may
  be up to three of them). Move the existing data, rather than deleting it. The
  presence of the Edb.chk file, or any transaction log files, may prevent the
  restored database from starting, or may even damage it.

3. Restore the backed up database files (either the Priv.edb and Pub.edb
  databases, or the Dir.edb database) to the appropriate database folder. Do
  not restore any Edb*.log files. At this point, the only files present in the
  database folders are the main database files themselves.

4. Start the database service. If you are restoring an information store
  database, the database usually stops with an event 1087 or an error 1011.
  This is acceptable, and does not indicate a problem in the database. If this
  happens, at a command prompt, run:

   \exchsrvr\bin\isinteg.exe -patch

   This command resynchronizes the information store and the directory service.
  The patch process usually takes only a minute or two, even against a very
  large database.

   Start the database again.

   NOTE: Do not run the isinteg -patch command in anticipation of a startup
  problem, only run it after a problem actually occurs. In rare circumstances,
  if you run the isinteg -patch command before you start the database, you may
  damage the database.

Because you started this database in the absence of any log files, a new series
of log files, starting with the Edb00001.log file, is generated. After the
database has been successfully started, no previously existing log files can
ever be replayed into it.

"Roll Forward" Restoration of an Offline Backup:

1. Identify the "anchor" log file, which is the first log file required to begin

  the replay of log data into the database. To do this, at a command prompt,
  run:

   eseutil /mh  | find /i "Consistent"

   For example:

   E:\exchsrvr\mdbdata>eseutil /mh priv.edb | find /i "Consistent"
           State: Consistent
 Last Consistent: (4815,7337,362)  8/6/1999 20:46:33

   E:\exchsrvr\mdbdata>eseutil /mh pub.edb | find /i "Consistent"
           State: Consistent
 Last Consistent: (4815,7337,400)  8/6/1999 20:46:34

   You can calculate the anchor log file from the first value in parentheses on
  the "Last Consistent" line (4815, in this example). Convert this number from
  decimal to hexadecimal. Decimal 4815 is equivalent to hexadecimal 12CF.
  Because Exchange Server transaction log files are named Edbxxxxx.log, where
  xxxxx is five hexadecimal digits padded with leading zeroes, the first log
  file you need is the Edb012cf.log file.

   HINT: Start the Calc.exe utility to convert from decimal to hexadecimal. In
  the Calc utility, click View, and then click Scientific. Type a decimal
  number, and then click Hex to convert it.

   IMPORTANT: If you cannot locate the anchor log file, do not replay ANY log
  files into the database. If you skip the anchor log file and force replay to
  begin using a subsequent log file, you almost always irreparably damage the
  database. If the anchor log file is unavailable, follow the "Point in Time"
  restoration instructions above.

2. Verify that the current database path location is the same as it was at the
  time that you made the backup.

   Although you can change the transaction log path or working path after you
  make the backup, you can only perform log file replay if the database file
  itself is in the same path that it was in at the time that you made the
  backup. If you are unsure of the original location, at a command prompt,
  run:

   eseutil /ml  | find /i ""

   For example:

   E:\exchsrvr\mdbdata>eseutil /ml edb.log | find /i "Priv.edb"
     1 e:\exchsrvr\mdbdata\priv.edb

   E:\exchsrvr\mdbdata>eseutil /ml edb.log | find /i "Pub.edb"
     2 f:\exchsrvr\mdbdata\pub.edb

   In the example above, the original path location for the Priv.edb database is

  the E:\Exchsrvr\Mdbdata folder, and the original path location for the
  Pub.edb database is the F:\Exchsrvr\Mdbdata folder.

   NOTE: The Edb00001.log file creates its own header before it attaches a
  database for the first time, and thus it lacks database path information. The
  database path location for the database that was attached at the end of the
  previous log file is written to the Edb00002.log file, and to all subsequent
  log files.

3. Compile a list of log files that are candidates for replay. These log files
  may come from multiple backup sets and may include log files that are already
  on the Exchange Server computer. The list must start with your anchor log
  file and may continue as long as you can locate log files in unbroken numeric
  sequence.

   IMPORTANT: If the Edb.log file already exists in the transaction logs folder
  that you are restoring to, go to step 4. If the Edb.log file does not exist
  in this folder, go to step 5.

4. If the Edb.log file exists, copy it to the same folder that all the other
  replay candidate log files reside in. Then you must verify that the Edb.log
  file is actually the next log file in your sequence of log files.

   Each log file carries an internal number called the lGeneration that
  identifies its real position in the sequence of log files, regardless of the
  log file name. Be sure that the lGeneration number of the Edb.log file is one
  higher than that of the highest numbered log file that is a replay candidate.
  To verify this, if your computer is running Exchange Server 5.5 Service Pack
  1 (SP1) or later, at a command prompt, run:

   eseutil /ml  | find /i "lGeneration"

   and then run:

   eseutil /ml edb.log | find /i "lGeneration"

   For example:

   E:\exchsrvr\mdbdata>eseutil /ml edb00013.log | find /i "lGeneration"
     lGeneration (4828)

   E:\exchsrvr\mdbdata>eseutil /ml edb.log | find /i "lGeneration"
     lGeneration (4829)

   NOTE: To view the header of a log file with the Eseutil utility, use the /ml
  switch, and to view a database file header, use the /mh switch. Confusing the
  switches gives you incorrect output from the commands. The /ml switch is not
  available for Exchange Server 5.0 or for Exchange Server 5.5 earlier than
  SP1.

   If the Edb.log file does not carry the correct lGeneration number, you must
  remove the Edb.log file.

   IMPORTANT: If you removed the Edb.log file, go on to step 5. Otherwise, go to

  step 6.

5. To replay transaction log files into an offline backup, there must be a log
  file named Edb.log. (This is not a requirement with online backups.) If the
  Edb.log file is unavailable, you must rename the highest available numbered
  log file Edb.log.

   CRITICAL NOTE: If you rename a log file Edb.log, all of the log files that
  have higher lGeneration numbers than the log file that you just renamed must
  be removed before you start the database. If you don't do this, the higher
  numbered logs become a "ceiling" that eventually blocks the creation of new
  log files, and causes the database to stop.

6. Verify that signatures match between the databases and log files.

   Each log file carries an identifying internal log signature, and each
database
  carries its own DB signature. Logs and databases that belong together write
  their signatures to each other. For replay to be successful, signatures from
  the databases must match those found in the anchor log, and those in the
  anchor log must match all the subsequent logs.

   To match signatures between the databases and the anchor log, at a command
  prompt, run:

   eseutil /ml  | find /i "Signature"

   and then run:

   eseutil /mh  | find /i "Signature"

   For example:

   E:\exchsrvr\mdbdata>eseutil /ml edb012cf.log | find /i "Signature"
     Signature: Create time:8/3/1999 17:37:42 Rand:710915685 Computer:
     Signature: Create time:8/3/1999 17:37:44 Rand:710961251 Computer:
     Signature: Create time:8/3/1999 17:37:47 Rand:710954626 Computer:

   E:\exchsrvr\mdbdata>eseutil /mh priv.edb | find /i "Signature"
    DB Signature: Create time:8/3/1999 17:37:44 Rand:710961251 Computer:
   Log Signature: Create time:8/3/1999 17:37:42 Rand:710915685 Computer:

   E:\exchsrvr\mdbdata>eseutil /mh pub.edb | find /i "Signature"
    DB Signature: Create time:8/3/1999 17:37:47 Rand:710954626 Computer:
   Log Signature: Create time:8/3/1999 17:37:42 Rand:710915685 Computer:

   In the above example, the Edb012cf.log file carries three signatures: the
  first is its own log signature, the second is the DB signature of the
  Priv.edb database, and the third is the DB signature of the Pub.edb database.
  (The signature is the entire line, starting with "Create time," not just a
  part of each line.)

   The first signature from the Edb012cf.log file matches the log signature
entry
  in both the Priv.edb and Pub.edb databases, the second signature from the
  Edb012cf.log file matches the DB signature for the Priv.edb database, and the
  third signature from the Edb012cf.log file matches the DB signature for the
  Pub.edb database. If you find any signature mismatch at this point, the
  anchor log belongs to an entirely different database, and no log file replay
  is possible. You must then perform a "point in time" restoration.

   After you verify that the anchor log matches the databases, you must verify
  that the rest of the log files match the anchor log. You can do this by
  comparing the signatures inside each log file. The following batch file can
  automate this verification. You must run it at a command prompt, from the
  Transaction Logs folder.

   The batch file is eight lines long, and has double spacing between each line.


   :sigchk.bat

   @echo off

   for %%A in (EDB*.LOG) do eseutil /ml %%A | find "Sig" >%%A.CHECK

   eseutil /ml %1 | find "Sig" >"Log Signature Check.txt"

   echo -------------------- >>"Log Signature Check.txt"

   echo -------------------- >>"Log Signature Check.txt"

   for %%A in (*.CHECK) do fc %1.check %%A >>"Log Signature Check.txt"

   start notepad "Log Signature Check.txt"

   You must type the name of your "anchor" log file on the batch command line,
  for example:

   sigchk.bat edb012cf.log

   Output is similar to the following:

   Signature: Create time:8/3/1999 17:37:42 Rand:710915685 Computer:
     Signature: Create time:8/3/1999 17:37:44 Rand:710961251 Computer:
     Signature: Create time:8/3/1999 17:37:47 Rand:710954626 Computer:
  --------------------
  --------------------
  Comparing files edb012CF.log.CHECK and EDB012D0.LOG.CHECK
  FC: no differences encountered

   Comparing files edb012CF.log.CHECK and EDB012D1.LOG.CHECK
  FC: no differences encountered

   Comparing files edb012CF.log.CHECK and EDB.LOG.CHECK
  ***** edb012CF.log.CHECK
     Signature: Create time:8/3/1999 17:37:42 Rand:710915685 Computer:
     Signature: Create time:8/3/1999 17:37:44 Rand:710961251 Computer:
     Signature: Create time:8/3/1999 17:37:47 Rand:710954626 Computer:
  ***** EDB.LOG.CHECK
     Signature: Create time:8/2/1999 16:22:38 Rand:3070420 Computer:
  *****

   In the example above, the Edb012cf.log file is the anchor log. The signatures

  that it contains are listed above the short dashed lines. If the output file
  doesn't contain any signatures above these lines, then the comparisons are
  all invalid, usually because you mistyped the name of the anchor log.

   If the log files match the anchor log, there are no signatures listed below
  the double dashed lines, instead, there is just a steady string of "FC: no
  differences encountered" for each comparison. In the example above, the
  Edb.log file is mismatched in comparison with the Edb012cf.log file.

   At minimum, a signature mismatch prevents complete replay of all the log data

  into the database. Depending on the nature of the mismatch, it may also
  prevent the database from starting.

   The result of a signature mismatch depends on whether or not the mismatch is
  between log signatures or between DB signatures. If there is a log signature
  mismatch, the logs that don't match the signature of the anchor file must be
  removed, or they are likely to prevent the database from starting. There is
  no chance of replaying any data after a log signature mismatch.

   If the mismatch is between DB signatures, the database usually starts, but no

  data after the point of the mismatch is applied. If you restore both the
  Priv.edb and Pub.edb databases and both of the DB signatures are mismatched
  at the same point, remove the log where the mismatch was detected, along with
  all of the subsequent logs. If only one signature changes, you may still be
  able to replay data into the other database.

   A change in DB signature doesn't necessarily mean that a different database
is
  attached to the log files. DB signatures change during the life of a database
  whenever the database is altered enough in its physical arrangement that the
  replay of log files would be dangerous. Offline defragmentation (the eseutil
  /d command) and hard repair (the eseutil /p command) are the two most common
  events that trigger a DB signature change.

   Be aware that even if you remove all of the log files from the point of the
  mismatch onward, you are still likely to see some errors in the application
  event log during replay. This is because the DB signature change actually
  happened in the middle of the log file that precedes the log file that the
  change was detected in. You don't want to remove this preceding log file,
  because some of the data in it (the data created before the signature change)
  is still playable, but an error may be displayed when the signature change is
  encountered.

   NOTE: If you remove log files because of signature problems, don't forget to
  rename your new highest numbered log file as Edb.log, as described in step 5
  above.

7. Verify that the database paths in all the log files match.

   If the database paths are not all the same throughout the sequence of log
  files, the effect is much the same as if the DB signatures don't match; data
  in the log files after the point where the path changed are not replayed. (If
  you use an online backup, the database can be restored to an entirely
  different path than the one recorded in the anchor log, and log file replay
  still succeeds, as long as the paths don't change again in the middle of the
  log file sequence.)

   You can check for database path continuity using another batch file that is
  similar to the one you use to check signatures. This batch file is also eight
  lines long, and has double spacing between each line:

   :pathchk.bat

   @echo off

   for %%A in (EDB*.LOG) do eseutil /ml %%A | find "%2" >%%A.CHECK

   echo -------------------- >>"Log Signature Check.txt"

   echo -------------------- >>"Log Signature Check.txt"

   eseutil /ml %1 | find "exchsrvr">>"Database Path Check.txt"

   for %%A in (*.CHECK) do fc %1.check %%A >>"Database Path Check.txt"

   start notepad "Database Path Check.txt"

   The output format from this batch file is similar to the previous one, but it

  displays paths, not signatures.

   If path verification reveals a mismatch, you must make the same judgments
that
  you make if DB signature verification reveals a mismatch.

   At this point, you have a folder that contains only log files that:

    - Are in unbroken lGeneration sequence, starting with the anchor log file.

    - Have matching log signatures; this is an absolute requirement.

    - Have matching DB signatures (or you have decided to take the risks
     associated with trying to replay mismatched logs).

    - Have matching database paths (or you have decided to take the risks
     associated with replaying mismatched logs).

Even if you meet all four of these requirements exactly, there is still a small
chance that the log set you have put together is not a valid one. Fortunately,
such cases are rare.

8. Move all of the files from all of the data directories for the database that
  you want to restore. For the information store, empty all Mdbdata folders on
  all volumes, and for the directory service, empty all Dsadata folders. Move
  existing data, rather than deleting it. Make sure that you do not delete any
  log files that are replay candidates, and that you remove the Edb.chk file.

9. Copy all of your replay candidates, including the appropriate Edb.log file,
  into the Transaction Logs folder.

10. Copy the databases that you want to restore into the Database folders.

11. Be absolutely sure that the Edb.chk file has been removed from the Working
  Path folder.

   In the absence of a checkpoint file, Exchange Server begins to replay the
  logs from the lowest numbered log file available: the anchor log. If the
  Edb.chk file exists, Exchange Server begins replay at the checkpoint
  recorded in it. When you restore an offline backup, the checkpoint in the
  Edb.chk file is wrong. A bad checkpoint file prevents log file replay
  altogether, at best. At worst, it irreparably damages the database.

   At this point, the only files present in the Database folders are:

    - The restored databases.

    - The restored sequence of log file replay candidates, including an Edb.log
     file that you have made sure is the final log in the sequence.

12. Start the database service. If the information store does not start and
  returns a 1087 event or a 1011 error, at a command prompt, run:

   \exchsrvr\bin\isinteg.exe -patch

   This resynchronizes the information store with the directory service, and
  then starts the information store service again.

   Check the application event log in the Windows NT Event Viewer for any errors

  or anomalies that may occur when the database starts. There is an event 109
  displayed for each log file that is successfully replayed. After a signature
  or path mismatch error is encountered during replay, succeeding log files
  are still logged as having been replayed, but the data they contain is not
  actually applied to the database.

Notes
-----

Renaming log files outside the guidelines described in this article may be
extremely dangerous, and may irreparably damage your database. The general rules

for renaming log files are:

 - If the database is inconsistent, you can safely remove a log file only if it
  did not exist at the time that the database stopped.

 - If you rename a log file to Edb.log, you must remove all of the log files
  with higher lGeneration numbers. If a log file with a higher lGeneration
  number was in existence at the time that the database stopped, and if you
  remove it, you are in violation of the previous rule. If a database won't
  start again after an abnormal stop, and you suspect the problem is in the
  Edb.log file, you cannot remove the Edb.log file and rename the next higher
  numbered log. You must either restore the database from a backup, or repair
  the database.

 - If you rename a log file to anything but Edb.log, the name must be consistent

  with the naming standard for log files, and with the internal lGeneration
  value of the log.

--------------------

If your computer is running Exchange Server 5.5 with no service packs applied,
the version of the Eseutil utility on your server does not implement the /ml
switch that you need to view log file headers. Nonetheless, you can still use
the Eseutil.exe and Ese.dll files from SP1 or later to obtain the /ml switch
functionality on an Exchange Server 5.5 original version database.

Do not copy the Eseutil.exe and Ese.dll files from a service pack to your system

folders if you are not installing the entire service pack. Instead, copy them
temporarily to the data folders, and run them from there. It is safe to look at
headers with the updated files, but it is not necessarily safe to actually run
the database using them. (The Ese.dll file not only contains utility
functionality, but is also the core database engine .dll file.) Before you start

the database, delete the mismatched Eseutil.exe and Ese.dll files from the
server.

--------------------

If you perform online backups, the Edb.log file is forced to roll over to a new
log file during the backup, so that all of the information, up to the second, is

preserved on tape. If you use offline backups, you can preserve the Ebd.log file

when the database is stopped, but the difficulty of managing multiple Edb.log
files makes it impractical to back up the Edb.log file offline. An offline
backup is vulnerable to several minutes of data loss that are avoided with an
online backup.

--------------------

A JET_errBadLogSignature error during replay indicates a log signature mismatch.

Numeric representations of this error are -530, 4294966766, and 0xfffffdee.

A JET_errBadDBSignature error during replay indicates a DB signature mismatch.
Numeric representations of this error are -531, 4294966765, and 0xfffffded.

A JET_errFileNotFound error during replay indicates a database path problem.
Numeric representations of this error are -1811, 4294965485, and 0xfffff8ed.

A JET_errDatabaseInconsistent error during replay indicates that sufficient data

was unavailable from existing log files to return the database to a consistent
state. Numeric representations of this error are -550, 4294966746, and
0xfffffdda.

The way that each of these errors is displayed depends on the component that
reports the error, and when the error occurred. For example, if the information
store does not start because of a JET_errFileNotFound, it includes the error
code 0xfffff8ed in an event 5000. If a path change is found in the middle of the

replay, the database engine reports it in an event 132 that references -1811 in
its description. If the JET_errFileNotFound is severe enough to prevent the
replay, you may see this error as 4294965485 at the command line when you try to

start the database service.

Use the Error.exe utility to translate between various numeric Exchange Server
errors. This utility is available in the Support folder on the Setup compact
disc for all the versions of Exchange Server through version 5.5.

--------------------

Keep in mind that the log files that you back up today are playable against the
database you backed up yesterday. If you do a "roll forward" restoration of a
database, you must search in backup sets AFTER the database backup to find log
files that are replay candidates.

Snap Backup
-----------

There are technologies available today that require the use of offline backups
and restores, due to the method in which data is backed up. These backups are
commonly referred to as "snap" backups. They use proprietary methods to copy
data from one disk to another.

The overall advantage to this snap backup method is speed of backup and
recovery.
Because data is being copied from disk to disk, via direct SCSI-to-SCSI or fiber

connections, backups and recoveries are much faster, as compared to backups
to/from tape. Because snap backups require an offline solution, downtime of the
Exchange services should be planned and expected. The information contained in
this article is extremely important to protect the consistency of the .LOG files

and the integrity of the data.

The following is a list of companies Microsoft has worked with to ensure
backup/restore scripts, created using their snap backup technology, address the
concerns listed in this article:

 - EMC Corporation. The TimeFinder Exchange Integration Module (TEIM), which is
  part of the EMC ResourcePak for Windows product, automates the process of
  using TimeFinder with Exchange 5.5 for backup. Scripts to integrate
  TimeFinder with Exchange 5.5 are also available from EMC Professional
  Services.


http://www.emc.com/products/software/resource_pak.jsp?openfolder=storage_software


 - Compaq Corporation: The Compaq Restore Accelerator solution for Microsoft
  Exchange uses Compaq's SANWorks Virtual Replicator (SWVR) software.

   http://www.compaq.com/products/storageworks/solutions/eas/msxbrsuptime.html

 - Compaq Corporation: The Compaq Uptime Booster solution for Microsoft Exchange

  uses Compaq's SANWorks Enterprise Volume Manager software.

   http://www.compaq.com/products/storageworks/solutions/eas/msxbrsuptime.htm

For additional information about support boundaries on snap backup/restore
solutions for Microsoft Exchange Server, click the article number below to view
the article in the Microsoft Knowledge Base:

   Q221756 XADM: Support Boundaries for EMC Backup/Restore Technology

Additional query words:

======================================================================
Keywords          : exc55
Technology        : kbExchangeSearch kbExchange550 kbZNotKeyword2
Version           : :5.5
Issue type        : kbhowto
=============================================================================
Copyright Microsoft Corporation 2001.