• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 262
  • Last Modified:

Exchange 2003 restore question

I'm going to be performing an Exchange 2003 database restore over the weekend, and I'm hoping an expert in the practice can help with the corrent procedure. First, the backstory:
We have two Exchange 2003 Enterprise servers, one only hosts mailboxes, and one only hosts Public Folders. We're a project based business, and every email our employees recieve about a project gets dragged into the corresponding public folder. The public folder database is 410 GB in size! We realize this is not a good idea and have already put a new email filing system in place for new projects. However, we need the public folder based solution for another few quarters until we've transitioned everything over.
Last Friday evening, the server that hosts the public folders had its RAID controller fail during the Exchange backup window. We went through a bunch of troubleshooting with Dell, and one thing led to another and we eventually lost the entire RAID array that held the Exchange stores. So Monday was spent bringing up a VM with SAN storage, the Exchange data was restored from the last successful Full backup, and the Incremental backups were then restored.
So everything is good, public folders are back, and we think we're back in business. But I kick off a new Full backup of the restored Exchange server, and at the very end of the database, the backup dies due to a bad page checksum, error 1018, which according to the KBs I've read is quite common. Microsoft's top suggestion is to perform a restore from the last good backup, and replay the log files.
So this brings me to the question. I'm going to do another Full restore, and follow it with the Incremental restore like I did on Monday. I've got that procedure nailed. But what do I do with the log files that have been created since the restore on Monday?
Do I leave them in the C:\Program Files\Exchsrvr\MDBDATA folder, and they will replay automatically? Or do I need to copy them in to the temporary restore folder and manually play them with eseutil /cc?

Thanks for your help!
0
InterfaceEngr
Asked:
InterfaceEngr
  • 4
  • 3
1 Solution
 
endital1097Commented:
a 1018 error is typically a hardware issue (hard drive)
do you have another drive you could move the exchange data to
0
 
InterfaceEngrAuthor Commented:
It's hosted on our iSCSI SAN now, which is the only place with enough space right now to host it. If we get 1018's again after the second restore, we'll look at getting some server hardware for it.
0
 
InterfaceEngrAuthor Commented:
Oops, didn't select enough points at first.
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
endital1097Commented:
do you have any additional free space on the iSCSI SAN to allocate
0
 
InterfaceEngrAuthor Commented:
Yep, I've got several TBs I could use. I don't think moving it is going to correct the bad page in the database though.
0
 
endital1097Commented:
no, but it would be good to move before performing another restore
0
 
InterfaceEngrAuthor Commented:
Performed the restore last night. I simply left the existing log files in the mdbdata folder, did a full restore, then an incremental restore, and then kicked off an eseutil /cc (hard recovery) command.

After the hard recovery command played though the restored incremental log files, it checked the mdbdata folder for any log files since the last restore. Since the log files in the mdbdata folder were numbered in the correct sequence, picking up right where the incremental restore left off, the eseutil /cc command played them back as well, which I could verify by watching the Application log in Event Viewer.

So the database has all of the changes since the last full backup, and all I had to do was leave the log files in the mdbdata alone, and use eseutil /cc for hard recovery after the restores completed.

Oh, and if you ever do this, make sure you use the same temp directory for the full and then the incremental Exchange restores. And make a backup copy of the folder with your logfiles (possibly C:\Program Files\Exchsrvr\MDBDATA) with the Exchange services shut down just in case something happens before you start any restores.
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now