I'm a newbie admin for an Exchange 2003 server running on Windows Server 2003 R2 Standard, all storage on the server is local, no DAS, SAN or NAS. The server is being backed up to magnetic tape using Symantec Backup Exec 12.5 running on Windows Server 2008 Standard x64.

There are daily, weekly and monthly backup jobs for the server. All three jobs backup all items under the server name in the selection list, all the disk partitions, shadow copy components, system state, utility partition and Microsoft information store. Under the Microsoft Exchange section in the job properties, the Full backup method is selected. Use Backup Exec Granular Recovery Technology is selected. Perform consistency check is selected and continue with backup if consistency check fails is selected.

I also noticed that transaction logs under \mdbdata don't get flushed, although circular logging is not enabled.

Being a total Exchange noob, i don't really know much about the information store, storage group, transaction logs....etc. or their overlaps and interdependencies.

However i feel there's some waste, inefficiency or double backups of the same data happening here.

Can you please give me some advice on how to optimize the backup process ?

2 Answers 2


Your strategy doesn't sound that bad to be honest, but the transaction logs not flushing does concern me somewhat. If you have other specific concerns about your setup, please edit your question to include them and I'll do my best to answer.

I read it that you're doing daily full backups. Depending on the size of your mailbox stores you might want to switch to daily incremental (i.e transaction log) backups instead of daily full backups. This will mean you complete your daily backups much quicker and they will consume less storage space, but this may not be an issue for you if you have small mailbox stores or the current backup window is acceptable.

Since you're using Backup Exec, make sure you are using the Exchange Agent. I won't stress that enough, since that's what does all the heavy lifting and makes sure your Information Store backups happen properly.

You say you're backing up all local volumes - specifically exclude the directories your mailbox stores and transaction logs live in from the file level backup. Hopefully Backup Exec won't be stupid enough to try and back these up.... but we are talking about Symantec after all!

As I said, I'd be concerned that your transaction logs aren't flushing. In the vast majority of cases this means backups are not completing properly, since the transaction logs are flushed after a backup. Check your Backup Exec job logs to see if your backups are actually completing successfully and investigate any warnings or errors. Your Exchange server should also log events relating to backups, so check out event viewer if necessary.

On a related note, make sure you do frequent Active Directory backups too. Exchange relies very heavily on Active Directory and stores an awful lot of configuration date in it.

I'll also do a quick spiel about your backups being effectively useless unless they are tested. I appreciate it isn't always possible, but if you can restore your entire environment (Active Directory and Exchange) to a completely isolated and different set of servers it will make you feel a lot better.

  • well, actually BE was stupid enough and it backs up the information store and logs folders. I have changed my backup jobs now. Split into two jobs. One for the operating system and one for the information store and logs. Since then the transaction logs have been flushing normally. It turned out that the old combined backup jobs skipped two files that it couldn't backup and it looks like the job completing with exceptions prevented the logs from flushing. Apr 5, 2011 at 16:04
  • I'm also working on ordering a new server for a migration to Exchange 2010. I plan to push the actual migration back for a while and use the new server to test restorations of my server backups. I think i will be posting a separate question about the best way to test my backups Apr 5, 2011 at 16:06
  • Glad you got it sorted. That's a very good idea you've got with the new Exchange server and exactly what I did too! I installed VMWare esxi on the sever, restored my Active Directory then Exchange 2003 onto different VMs, snapshotted everything and did the complete Exchange 2010 migration about 7 or 8 times until I was comfortable with it. You certainly sound like you've got your head screwed on, and of course if you need any guidance feel free to ask another question. Apr 6, 2011 at 0:14

I also find it concerning that your logs are not being flushed by the jobs. Ensure that both the Backup job property is set to Full backup and the Exchange property setting "flush committed logs" is checked. As you describe it your basically doing a daily full (as Ben mentioned).

My suggestions are to separate your OS backup of the exchange servers from the exchange backup. If storage space on your backup tapes is no concern you are fine with continuing to do daily full backups. However, if you want to speed up backup times you can switch to using incremental or differentials during times with a shorter backup window (during the week overnight). You can then do full backups at a time with a larger backup window (I have fulls running Saturday and Sunday). With the incremental you will need the tapes containing all the incremental backups and the full backup to restore. With differential you will need the tape containing the last differential backup and the full backup to restore.

Seeing as your backing up to magnetic tape you should also take into consideration what you do with those tapes. If they are lost, or destroyed they are useless. If you have a media rated firesafe, store them there. If not consider an offsite storage option.

Check this document from Symantec: Best Practices for Backing up Exchange. The document is in reference to Backup Exec 2010 but is still applicable to your needs.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .