We are backing up the Exchange mail boxes and Exchange public folders on a daily basis "to a disk file".
We are looking at ways to reduce the daily backup job time frame and in researching what seems to be taking the most amount of time to back up, it was discovered that the Exchange mailboxes (current size is 14gb) back up at a snails pace (about 53mbs/min) as compared to files on another server where we are backing up 22gb at about 126 mb/min... (rates taken from the job log)
I wonder if I select the "Information Store" instead of the individual Exchange mailboxes and Exchange4 public folders items if it will at all speed up??
This backup is happening in the middle of the night when there are no users on the system. I am at a loss as to why the Exchange mailboxes take so much more time to backup than files of the same size on different servers...
Are there any tools I could maybe use to first export all mailbox contents to one huge text file and back that up possibly... instead of backing up the actual Exchange mailboxes item?? That might be a possible solution if users could deal with it...
I wonder if I select the "Information Store" instead of the individual Exchange mailboxes and Exchange public folders items if it will at all speed up??
Most definitely. And you should be doing Stores Level backups anyway. Brick Level are worthless for disaster recovery.
The reason that mailbox backups are so slow is the method/kludge Veritas chose to do them. The BackupExec logs onto the Exchange Server, then attaches to each selected Mailbox, then opens and "reads" each item in the mailbox using MAPI calls
See http://seer.support.veritas.com/docs/235354.htm to determine what Veritas/Symantec consider a "reasonalbe" backup rate for Brick Level
See http://mail.tekscan.com/nomailboxes.htm for an argument that you really shouldn't need to do brick level backups in the first place
Ken is right. You will see a tremendous improvement in backup speed choosing the information store instead of the individual mailboxes.
Ken's comment about using the individual mailbox backup method being useless for disaster recovery is correct in that fact if you have to rebuild your Exchange box you want to use that type of backup. But if you only want to recover an important message that was accidentally deleted or an individual folder under the public folders that disappeared but no ones when. Then the individual mailbox method is the most efficient way of doing it. I might be wrong and Ken please feel free to correct if I am.
BTW We do backups doing both methods in different jobs every night. But we back up to disk. So I can backup the entire information store of 50 GB in about 45 minutes. The individual mailboxes take about 2hr 50 minutes
Last night I changed the backup job so that just the Information Store is backed up and it took 1.5 hrs as opposed to 3.5 hours doing the individual mailbox backup!
I can't understand why it is taking us so long to backup on a 1gb backbone this data though. You backup 50gb in 45 minutes to disk file and we are backing up 12 gb (the current size of the information store) in 1.5 hours!!! Now, the drives we are backing up to are IDE drives and the machine is also a backup DC but I wonder how you are achieving such incredible speeds as compared to us?? What is your configuration?
The Exchange 2003 server is a Dell 2650. Dual 2.8 Xeon's. 3gb ram. Win srv 2003 OS partition is on separate mirrored drive thru a raid controller. Exchange logs on a separate logical mirrored drive thru the raid controller. Exchange databases on a Raid 5 drive. 1 Intel GB nic
The backup server is a dedicated BE server / CPS server.
Dell 2850 server Dual 2.8 Xeon's. 2gb ram. The OS drive is mirrored on a raid controller. BE is loaded on a separate logical drive raid 5. I then have a separate 200gb partition on the same Raid 5 controller that is just for small disk to disk backup jobs. REO 4000 attached via iSCSI for large d2d backup jobs.
Information store only backup job: I backup just the information store only. I backup the remote agent Exchange server and use hardware compression. When typically using d2d backup, software compression is recommended. (That's what I use when I backup to my iSCSI drives.) I found thru bench marking that using hardware compression on my local Raid Controller attached SCSI drives BE jobs ran much faster than software compression. A lot faster. Now take having the fastest possible back up destination device possible and then streaming a large continuous database file like the Exchange info store to it. You can get some pretty great thru put. It's crazy. Well over a 1 gb min thru put. Spikes occassionally around 1.8 gb / min.
When Be is running right and properly tuned (I'm not claiming my install is). BE can rock it.
Ok, I see why your throughput is so good!!! You have done a nice jobh in your configuration and having some cash availabe to set that all up also comes in handy!!! We aren't quite so fortunate as we are a very small company and have to make due with less - but I have to admit your emaill got me "a little excited"!!! :)
We have a Dell SC700 (1 processor - 1gb RAM) Win2k3 server also a backup domain controller that has two 250gb IDE drives. BE loaded on that and jobs backing up to those drives... It's funny because our Dell T122 autoloader is connected directly to that server as well (via SCSI) and really the throughput to disk vs tape is not much different!!!!
Thanks for your info, If I get some more money to spend I would really like to bolster the backup situation here and I am definately going to reference your email and may ask for some more input from you... Do you mind giving me your email address so I can direct communicate with you?? I am at email@example.com