Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Exchange 2010 backup to tape takes too long

Created: 03 Dec 2013 • Updated: 08 Dec 2013 | 19 comments

Hi,

We have an Exchange 2010 server with 3 mailbox stores and one Public folder store.

I have four backup jobs that run everynight that perform full backup to tape of all those mailbox stores.

Mailbox store A = 233 mailboxes , 156GB

Mailbox store B = 117 mailboxes , 302GB

Mailbox store C = 224 mailboxes , 203GB

Public Folder = 212GB

For some reason the backup of store B takes about 4 hours on the weekend but takes 9-10 hours on the weekdays.

This store is backedup on 22:00 everyday and on 10:00 on Friday.

I noticed that when the job starts it's got great job rate of around 5000MB/min, but when I come back in the morning, the status is Updating Catalog and the job rate is around 500MB/min.

So I guess the problem is not with the Exchange server itself, it's in the Update Catalog phase.

The thing is that the backup of the other stores finishes quite quickly - Store A for example at around 1:30 hours on weekdays.

Even Store C which is the only one that is B2D takes around 4 Hours on weekdays.

Why is the Updating Catalog phase takes so long on this DB, and what can I do to improve it?

Is there a way I can see what was the job of the Backup process apart from the Update Catalog process?

 

 

Operating Systems:

Comments 19 CommentsJump to latest comment

CraigV's picture

Hi,

 

You should be able to see how long it takes on a resource by checking the Job Log. If this isn't clear there, increase the level of logging (this increases the size of the job log though, so be aware of that!).

Do you run any sort of Exchange maintenance tasks during the week that might be clashing with the job completion?

Have you tried to create a new job and selection list to rule out corruption of either of these? Are you running BE 2010 R3 with the latest SP? If not, might be an idea to upgrade to this, considering you can use the same licenses.

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

YonatanC's picture

Hi Craig,

I'm running R3 with SP3 on both the media server and the agents on the Exchange server.

The job log only gives me the entire job time, it does not seperate between the differenet phases of the job.

There was an Exchange maintenance task that we already moved to 03:00. I also disabled the antivirus but I don't think this is the problem.

As I mentioned the Backup process runs at a very good job rate.

I didn't tried to create a new job and selection list yet. Will try tonight and update tommorow.

Any other thoughts in the meantime?

YonatanC's picture

Thanks for the references but I don't think they are relevant.

The first TN addresses the issue of B2D GRT backup.

The second one addresses 32bit systems and Exchange 2003 & 2007. We use 2010 and 64bit.

However, does the amount of active jobs on the media server affects the cataloging process? Becase we have around 10 concurrent jobs running at every point in time throughout the night. Most of them are B2D but the Exchange jobs are to tape. Can this affect the Updating Catalog phaze? and if so, how come it only affect this particular job more than the others?

Also, the backup of the 4 mailbox stores sometimes overlaps thoughout the night. Is there any problem with that?

CraigV's picture

Well, they may if you are backing up the Information Store in 4 separate jobs. I've run concurrent jobs and haven't had an issue with this.

Try running the backup of Exchange during the day and see if you get a similar issue. Are there AV scans etc. running during the backup?

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

YonatanC's picture

I didn't understand your first answer - can 10 active jobs on the media server (most of them B2D) generate such big I/O that will make the updating catalog phase take so long for one particular job?

I forgot to mention the we use GRT to backup the Exchange server.

I don't know if it's wise to could run the job during the day because it can affect the performance of the Exchange...

As I mentioned in earlier, I already tried to disable the AV completely during the night.

CraigV's picture

It may...it never happened with me, but it might happen for someone else. That's all subject to a specific environment, how the backups are done, to where etc.

GRT is fine, and recommended to backup Exchange anyways as this allows item-level restores.

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

YonatanC's picture

I want to use Performance Monitor on the Media Server to see the differences between the weekdays and weekends backups.

Where excatly is the catalog file written to when backing up to tape - Is it writtern to the tape itself or to the BackupExec folder on the local drive?

Can you tell me which counters should I monitor? I guess CPU, memory and network. But what counters under Logical Disks?

 

YonatanC's picture

Well, tried a new selection list and a new job but got same resaults. :(

I'll try to get permission to run the job during daytime when there's less traffic on the Media Server (although there's much more trafic on the Exchange server...) and update later.

 

CraigV's picture

...if you have disk space available, can you try running the backup to disk as well to see if this speeds things up?

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

YonatanC's picture

Hehe, This job already ran for quite some time to disk and I already created a topic on this forum because the B2D job tool around 18 hours to complete. But since these are plain SATA disks I thought this was the cause for the slow job rate. This is why I swiched back to tapes.

But also for the B2D job, the Updating Catalog was the part that took most of the time.

YonatanC's picture

I want to use Performance Monitor on the Media Server to see the differences between the weekdays and weekends backups.

Where excatly is the catalog file written to when backing up to tape - Is it writtern to the tape itself or to the BackupExec folder on the local drive?

Can you tell me which counters should I monitor? I guess CPU, memory and network. But what counters under Logical Disks?

YonatanC's picture

I was wondering if it could help if I run a Database Consistency Check using BEUtility.

I don't have the option "Perform Database Consistency Check" checked under Tools>Options, and maybe the database need some reorganizing.

Is it wise to do it by myself or should I contact support and do it with them?

 

CraigV's picture

I've run the DBCC check plenty of times and it has never ended up with the media server losing data.

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

YonatanC's picture

Do you mean the one from BEUtility or the one from the Tools>Options menu?

Is there any guide or HowTo to running it? Does it require no job is running? How long should it take (my bedb.bak is 264MB)?

Do you think it really can has something to do with the long cataloging of Exchange backups?

YonatanC's picture

Sorry, one last question:

Is it possible that the daily database maintanace at 04:00 can affect the catalog update of the Exchange job?

CraigV's picture

Ig might, but this is always something you can change within BE itself. Set it for a time during the day when the backups aren't running and see if this makes any sort of difference.

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

YonatanC's picture

Thanks Craig for your patience.

I find I have lots of questions regarding databse and catalog maintanace and backup.

I think I'll open another thread for this.

 

YonatanC's picture

Update:

We tried everything and nothing works.

I've opened a case in Symantec. If we'll find anything I'll update here.

 

Thanks.