Restore an old Dir.edb - Will it backfill from other servers

NOOOOO!!!! cannot restore a dir. more than 30 days out, you'll blow your whole org!

Try defragging the dir first, I've done it before to clear up just such an issue. And no, it isn't corrupt. Backup software that is exchange-aware will not backup a database with checksum errors. so it's still intact, may just need a little clean up. Try this first, and let me know how it goes.

Thanks, that's what I keep hearing, but everything I read suggests that you can restore a good backup of the Directory at anytime and it will backfill itself via replication from the other servers in the site.  A defrag might be worth a shot though.  You didn't have any problems defragging dir.edb?  I thought that it was 'against the rules' to run eseutil on the directory database - infact any utilities on the dir.edb?

Just so you know where I'm coming from, I have read in article Q184186 that you can actually take a copy of dir.edb after installing Exchange and use it at anytime to recover from a corrupt directory?

Something else I have read - This is from a Q&A section of the Technet article "Exchange Server Part 9 - Disaster Recovery":

"Q: When I am restoring a server in a site, if I do not have a backup of the directory (Dir.edb ) for the server, can I backfill the directory from a replica on another server in the site?

A: No. It is critical that you have a backup of the directory for each Exchange computer because the directory is unique for each computer. Even if you have only the original directory backup, you can restore this backup and then backfill changes from another server in the site."

I also read similar things in the Exchange Server Disaster Recovery White Pages.

Are you sure I will kill my Org if I restore an old directory.  My thought process was that I would restore it, it would have old data which would not replicate out to the other servers.  However, the other servers would replicate any data that the restored directory did not contain.  I think it is all based on UID numbers as to who has the new and old information.  But unless you use Authrest.exe then a restored database is always assumed to be older.

Thanks again.

Here is the errors in the output from the Integrity check I did:

ERROR: page 2487: bad leaf page links

ERROR: error -1206 at line 3466 of G:\ese97\src\ese\repair.cxx

ERROR: error -1206 at line 3092 of G:\ese97\src\ese\repair.cxx

ERROR: node [4104:17]: subtree check (page 2487) failed with err -1206

ERROR: error -1206 at line 3186 of G:\ese97\src\ese\repair.cxx

ERROR: node [2305:0]: subtree check (page 4104) failed with err -1206

ERROR: error -1206 at line 3186 of G:\ese97\src\ese\repair.cxx

ERROR: error -1206 at line 2968 of G:\ese97\src\ese\repair.cxx

ERROR: error -1206 at line 2702 of G:\ese97\src\ese\repair.cxx

ERROR: error -1206 at line 1634 of G:\ese97\src\ese\repair.cxx

               Data table will be rebuilt

               Long-Value table will be rebuilt

               Indexes will be rebuilt

               Long-Value refcounts will be rebuilt

     checking table "MSysDefrag1" (43)

          checking data

          checking index "TablesToDefrag" (44)

          rebuilding and comparing indexes

............

ERROR: error -1206 at line 951 of G:\ese97\src\ese\repair.cxx

Operation terminated with error -1206 (JET_errDatabaseCorrupted, non-db file or corrupted db) after 12.953 seconds.

I thought that it was 'against the rules' to run eseutil on the directory database - infact any utilities on the dir.edb?


-not true. Just never run a /p on the database,totally a bad idea. but a defarg won't hurt it. Make a copy first, incas esomething goes bad. The output I see tells me that you have problems, defag may not succeed. But don't worry about that until, you try the defrag. if that fails, then we have issues.

you may also want to check and see if you have dirrep issues, since the directory is looking somewhat mangled.

D

Thanks, that's what I keep hearing, but everything I read suggests that you can restore a good backup of the Directory at anytime and it will backfill itself via replication from the other servers in the site"

-Not true again. It will back fill, but anything over 30 days will screw up the org. If you have one inside 30 days, you're cool. If you don't believe me, call MS support, they'll tell you the same thing.

d

Thanks again.  I'll try the defrag option and see what happens?

It's not that I don't believe you, but this is directly out of Microsofts Technet - What's your view of it?

"XADM: Recovering Exchange from a Corrupted DirectoryPSS ID Number: 184186

Article Last Modified on 4/9/1999


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


Microsoft Exchange Server 4.0
Microsoft Exchange Server 5.0
Microsoft Exchange Server 5.5

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

This article was previously published under Q184186
SUMMARY
When you install Microsoft Exchange Server, you should create a backup directory in the directory that contains the Dir.edb file. A default installation without optimization will have the Dir.edb file in the Exchsrvr\Dsadata directory. After replication has been completed with other servers in the site, the directory service should be stopped, and a copy of the Dir.edb file should be placed in the backup directory. Then you can restart the services.
MORE INFORMATION
This suggestion is made as a precautionary measure against future problems. As a standard course of action, you should have a solid backup plan with tape rotations and periodic testing of the backups. However, in a worst case scenario, this backup copy can be used to bring the server back on line if the directory has become unusable. Unlike the Priv.edb and Pub.edb, repair utilities should not be run against the Dir.edb file because it stays synchronized with the other directories in the site.

Also, unlike the Priv.edb and Pub.edb files, the Dir.edb file is machine name specific and the system cannot regenerate a new one if the old one is missing. If a directory becomes unusable and there are no viable backups, you can stop the directory service on the computer, and move all of the files out of the Dsadata directory on all drives that the Exchange Optimizer has placed them in. The original Dir.edb can then be copied from the backup directory and you can restart the directory. Through the process of backfill, the directory will bring itself up to date with the other directories in the site.

Without this original Dir.edb file or a valid backup, the only way to get a new directory is through full disaster recovery. This involves removing Microsoft Exchange Server from the computer and reinstalling it.
Keywords: kbhowto KB184186
Technology: kbExchange400 kbExchange500 kbExchange550 kbExchangeSearch kbZNotKeyword2"

No comment has been added to this question in more than 21 days, so it is now classified as abandoned.

I will leave the following recommendation for this question in the Cleanup topic area:
   PAQ/  Refund

Any objections should be posted here in the next 4 days. After that time, the question will be closed.

What90
EE Cleanup Volunteer