Unsolved
This post is more than 5 years old
1 Rookie
•
54 Posts
0
378
March 5th, 2008 07:00
Information Stores not mounting
I'm running RM 4.0.0.3 (I know, we should upgrade, and we plan to) and when trying to mount/ snap my Information Stores, I get errors about 3 of my stores having corruption, more specifically checksum errors. I ran the eseutil /k option against the 3 stores, and cleared out the event logs on the exchange server, and it didn't help. I then ran eseutil /p to repair the corrupted 3 databases, again cleared the event logs, and still get the errors at 80% of the mount job in RM. I was convinced that the eseutil would sniff out and repair any corruption and that I'd then be all set, but I'm still having issues. Any suggestions anyone?
Thanks You!
JD
Thanks You!
JD
0 events found
No Events found!
JamesBEMC
257 Posts
0
March 12th, 2008 02:00
Are you trying to mount the Snapshots back to the same host as production or to another host?
Have you upgraded Exchange or its service pack on the production host recently?
Thanks - James.
JD44
1 Rookie
•
54 Posts
0
March 13th, 2008 11:00
I am trying to mount the snap shots to a server that is direct attached to a Tape Library (so, it's mounting to another host). After mounting my (other) snapshots, the backup then runs, and we do it this way so that the volumes being backed up appear as "local disks" opposed to backing up the data over the network.
We have not upgraded the version of Exchange, and we run monthly Windows updates on all our servers. So, it's at the most current service pack.
JamesBEMC
257 Posts
0
March 25th, 2008 12:00
One thing which could cause NTFS or ESEUtil to believe there is some sort of "corruption" is if the previously mounted replica volumes were not cleanly uninstalled from Windows (VDS/API uninstall).
If the volumes were not cleanly uninstalled, then when you mount the next set of snaps, Windows partmgr says "hey those same volumes are back, as they looked before" and presumes the partition/FAT information has stated the same.
Can you tell if they do get cleanly uninstalled by checking the C:\Windows\setupapi.log and check for any errors or VETO's during the unmount.
I have seen this before when both SAN volumes and SAN tape drives were on the same HBA, as a rescan and scsi bug resets can be affected when SASD's share the same bus as DASD's. Take a look at the setupapi.log first and consider moving the tape devs off to another dedicated HBA port if they do share right now.
Another approach would be, as a test meerly to reboot the windows box between mounts to see if it stops the problem from reoccurring.
James.