Exchange Maillboxes takes long to backup and often fails.

[Javid_Jarvis]

Hi,

I have an Exchange Server 2003 SE server installed on Windows Server 2003 SE. I use Backup Exec 9.1 with the Exchange Agent to bacup my Exchange 2003 Orgnanisation. I found that when I backed up Exchange Mailboxes along with the information store the job would take about 12 hours to complete using a 4mm DAT Drive. I figured the most obvious bottleneck would be the drive, so I upgraded to an AIT drive that has a thoughput 4 times faster than the DAT drive. However, the backups still take about 12 hours and after working once now fail daily when backing up the Exchange Mailboxes. The final error is:

------------------------------------------------------
Job ended: 12 May 2006 at 06:59:29
Completed status: Failed
Final error: 0xa000fe30 - A communications failure has occurred.
Final error category: Server Errors
-----------------------------------------------------

There is another error message:

-----------------------------------------------------
Backup - \\SRVR\Microsoft Exchange Mailboxes The Exchange Server is not responding. Backup set canceled.
-----------------------------------------------------

I have installed the device drivers using the Symantec/Veritas package downloaded from http://support.veritas.com/docs/273853. My tape drive is listed in the compatibility list on that page.

I am have looked in the Event Viewer and don't see any errors logged during the time the backups were running that relate to Backup Exec or Exchange.

Does anyone have any ideas?

[Ken_Putnam]

Mailbox backups as done by BackupExec are a real kludge. The BackupExec service account logs into the Exchange Server, attaches to each mailbox in turn, and uses standard MAPI calls to "read" each item in the mailbox. This is extremly inefficient, especially if done over the wire.

To determine what Veritas/Symantec consider a "reasonalbe" throughput see http://seer.support.veritas.com/docs/235354.htm

You can also take a look at http://mail.tekscan.com/nomailboxes.htm and reconsider whether you want to do brick level backups in the first place.

[Javid_Jarvis]

Hi Ken,

I have read both links. I agree that individual mail item backups don't look t that great an advantage after reading the article by Charles Villa, but there is the point of corrupt mail. And if I do get an email that has be ID'd as corrupt by a user I can restore it really really quickly using the Backup Exec 9.1 Agent for MS Exch 2K3. And, when I first installed the agent it used to backup the whole lot in about 4 hours, so why does it now take 12 hours. I read the first link about the speeds, but I am not backing up over a network, I am doing it to an internal tape drive, one that is faster than the one I used to achieve backup times of about 4 hours (granted that was when the Exch Org was younger). I suppose it is not worth taking the time to solve cos as the article by Charles Villa states, you hardly ever have to restore individual items due to corruption. It is normally because the item remains deleleted for longer than the retention period, which is more easily solved by upping the retention on the store (or ind. mailboxes). But if there is anyone out there that does have a handle on this particular needle in this particular haystack, I would be very interested to hear from you.

What I am still eager to find out is if there is a reason why the AIT drive is losing connectivity to Exchange. I am going to untick mailboxes tonight and see if it solves that problem.

Jarryd

[Ken_Putnam]

Connectivity problems could be caused by faulty drivers, out of data firmware, loose cables or connectors.

Slow throughput could result from a drive going bad (multiple write errors hard or soft), bad block size, contention on the SCSI chain etc.

[Joe_Norton]

We do mailbox backups and they take a long time no matter what but one thing that helps is that every quarter we do an offline defragmention on Exchange using ESEUTIL.
The connectivity issue would be something else though. Is this an external AIT drive hooked up to a SCSI card with nothing else on it?

[Javid_Jarvis]

Hi.

The AIT drive I am using is internal and it is brand new. The problem only occurs when I backup the mailboxes. I can backup the store and public folders (public folders are small) without generating the error. I believe the drive is connected to an onboard SCSI controller which it isn't sharing with anything else as far as I know. The SCSI HDDs are connected to a separate RAID controller. All in all I am backing up 25GB of data, of which 10GB is mailboxes. How can this sort of agent be sold as a viable tool in the enterprise if it can't back up 10GB of mailbox items in less than 8 hours (whole job takes 10 - 12 hours). Surely that is not normal? I must have something wrong but I don't know what. What is the optimum block size setting on a SCSI AIT drive?

TIA,

Jarryd

[Ken_Putnam]

No, it CAN be that slow


We've seen reports of throughput in the 20-30 MB/min when backing up brick-level.


if you haven't already, I highly recommed that you take a look at http://mail.tekscan.com/nomailboxes.htm and re-think whether you really want to do MailBox backups in the first place

[Joshua_Small]

Hi Jarid,

I don't understand how an end user is going to ID an email as "corrupt", unless it arrives in your Exchange system that way in the first place.

If you had an email which was good, then suddenly users couldn't open it in Outlook or something, you likely have a much bigger issue than simply restoring a mailbox is going to acheive. Individual emails don't just corrupt themselves unless you've found a new bug in Exchange or Outlook.

Ie if you are regularly seeing this kind of behaviour, you should be running an ESEUTIL/ISINTEG to check for database corruption as a whole. If you find it, you will either need to:
- Identify the bug that caused the corruption
- Repair faulty hardware

From there, you would either
- Restore your whole Exchange database from a good backup
- ESEUTIL repair your database

Either way, restoring a single mailbox sounds much more like a solution to the symptom, not the problem.

If your Exchange database IS corrupted, perhaps at the page level, and therefore, continually building database level corruptions, that may well be the cause of the disconnects you are having.
I suggest running an eseutil diagnostic, then isinteg alltests test.

[Sharvari_Deshmu]

Hello,

Please update us on this issue.


Thanks,

NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.