Well i need ur help guys, i have an exchange server, as usual you don't plan to crisis until you get one, i was rely on pst so backup exec didn't run for months without interaction from me, anyway the partition which contain the exchange database reached full yesterday so the database corrupted, well mistakenly i deleted the log file as well, so when i rebooted its gave me error that its cant mount the database, anyway i took the database copy to another partition and i restored an image for the whole of the OS with the exchange and old database, and then i ran Eseutil against the database and it repaired it and defreg it, but when i moved the databased back to its original location and i mounted it i find that its show the latest mail since the data of the restored image, (maybe you are wondering why i restored the OS, well mainly i needed to give users temporarily access to there mails till i repair the database) but again i m sure of that i moved the database to the other partition before i restore the image, any ideas about the lost period ?

Exchange uses a (Transactional) Jet database.

ALL Changes to the db (Mail in/out/saved/deleted) are stored exclusively in the Transaction logs until they are committed (finalized by integration into the actual mail store) during the backup procedure (which is insanely critical for that exact reason...), So... Any "activity" that resided solely in the transaction logs that you deleted is now (officially) gone forever.

You should also run Isinteg (after eseutil) to make sure the db is stable ... or it may grenade again somewhere down the road.

Isinteg ran and no errors, but why its back to the date of the image which i restored ?! for sure there is something related to it.

All I can say is OUCH.

Yep, isinteg it for sure - you've almost certainly got some corruption in a few mailboxes that were open when the volume capped.

First, get yourself a monitoring method for the disks - I just mount the log and data volumes on my workstation and have a sidebar app that shows free space available, and it works fine for me. If the bar ever turns yellow (less than 10% free), it's time to take action by either defraging the DBs or looking at moving to a larger volume.

Second, implement a real backup system - even if it's just MS backup and task scheduler. LOTS of medium-sized businesses do just fine with the free stuff that comes with Windows, but you have GOT to get at least weekly fulls and daily incrementals going to prevent this stuff. Depending on your mail volume, you may want to do fulls more often to clear the log files more often.

Third, if you aren't already, divide your mail up into as many DBs as possible for your version of Exchange, and put your transaction logs on a separate physical disk. This speeds up defrag time, increases performance, and keeps your logs in a separate space in case of a drive crash.

Good luck....

Oh, one thing about logs - PM is a bit off on that. The data in the transaction logs is NOT exclusive of the database, only the active one is. As each new log file is created, the data from the previous one is committed to the DB, *IF* the DB is available for writing to. They are kept between full backups so that if you lose your DB, you can recover fully from the point of the last full you did. You lost data for the reason PM said - the volume capped, but they system will continue running until the text log file goes to write to the DB, at which point the system should stop and unmount them automatically. The same thing happens if your log volume caps, but you can (safely) manually delete your oldest log files to get you running until your can complete a full backup and clear them.

I was blurring accuracy in favor of maximum impact.

XP keep in mind that Isinteg "fixes" the db by removing any corrupt entries that it finds. The behavior of eseutil is also somewhat simular.

That is why you should never do a db repair on the only copy of a mailstore you have, always do repairs on a 2nd copy so if it blowsup you can go back and recopy the first copy and try again.

If you still have a copy of the original burnt db, try running Isinteg on it first, then worry about the (tidy up) eseutil defrag.

Isinteg –fix –test alltests

Rerun it until repairs = 0

Then do a test mount

Then dismount and defrag.

I figured you were, but the poor guy is probably scared enough as it is.

I'd recommend getting some real training on Exchange so you know how it works inside and out and know the best practices for deployment. Barring that (and in addition to it), run the Best Practices Analyzer monthly and fix everything it tells you to. Exchange is a deceptively simple product to get running, but underneath there's a lot of little things to know to keep it running in the best possible stable state.

Actually i was worry about similar factors, i got backup exec with full of daily differential and weekly full backups, but i stopped that when i felt PST file is doing the job, just with the crisis i figured out that some of the users didn't get a pst file and they were have there mail boxes at the server, thanks to ALLAH its back, with one victim, a secretary who lost her mail box one mail box of about 600 isn't bad thanks to ALLAH .
now i have another question is there a way to change the path of an existing database ? i think moving the db to another separate hard disk will be better and offer faster access.

You can't just skip the Exchange backup procedure, that must be done to fully commit (integrate & remove) the log files. Other wise you eating up double the drive space as the log grows and grows but is never truncated and removed. Not to mention making recovery a real pain in the ass...

Your supposed to learn from mistakes, not just thank god you weren't killed and continue bumbling forth...

Yes you can (and should) move the Exchange mailstores to a (RAID5) different partition:
http://www.petri.co.il/move_exchange_store...ferent_disk.htm

Here's an interesting bit: We blew a drive on our Exchange server last night. Did I loose any sleap over it? No. I did have to go down to the office and pull the offending disk outa the server so it would quit BSODing with a MCE but it's currently running happily on the other 2 drives with nothing lost.

Total Down Time 45min.

I'll have the replacement disk overnighted and as far as the staff knows there never was an outage.

I like that much better than the prayer over single point of failure method of recovery.

First of all thaking GOD, didn't mean i don't admit my mistake or taking another pre cautions, now i have a scheduled NT Backup task to back up the db daily, i have backup exec take a full backup daily, so i think i took some steps further

Moving to a disk array or SAN that supports a hot spare is even better than RAID5 alone. It all costs money, but given how mission critical and high profile email is, anything involved is money well spent.

Our Exchange system is the most expensive IT asset we have - it's a three node active/passive cluster with two front end servers and a separate front end for development, all fiber attached to a SAN with RAID10 arrays and hot spares. I've had zero significant downtime due to failure in three years, despite losing an entire server due to hardware failure and about half a dozen disk drives in the SAN. It wasn't cheap, but is it worth the money? Given that if I have to initiate a back-end failover to apply an update (takes about 180 seconds) there are already calls pouring in to the helpdesk, I say heck yeah.