Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2933
  • Last Modified:

Exchange Server backup Veritas

Hi Guys,

I need some expert advice on performance issue of Exchange Server brick by brick backup using Veritas backup Exec.

We have ~100Gig of Exchange Information Store. on Windows 2003 Server.
The server is a Dual CPU Zeon Processor 2.4GHz. 1Gig Fiber NIC 4 GB RAM.

We do a full Backup of the Exchange every day,
These days it is taking too long to backup the Data.

What can we do to make this fast.

We dont want to go with differential backup, must be a full backup..

regards
Naren
0
r_naren22atyahoo
Asked:
r_naren22atyahoo
  • 14
  • 7
  • 6
  • +1
3 Solutions
 
R-YaninCommented:
Don't do the "Brick Level" backups. Essentially if you do a full backup and "brick level" you are backing up the same data twice. You can use the "Recovery Storage Group" if you need to restore a single mailbox, which is what the "brick level" backup is giving you.

Note:
You should either impose mailbox size limit, or take advantage (if you have enterprise edition) of using multiple mailbox stores and multiple Storage Groups to decrease the size if the mailbox store. 100GB not only takes a long time to backup but also to restore.
0
 
r_naren22atyahooAuthor Commented:
We take the Full backup of the System excluding the exchange folder,
and do the brick level backup.

mailbox size limit=No.
multiple storage box=No , still we need to backup that to a single Tape
multiple Storage Groups , However Summing up the groups will result in same amount of data

Any other suggestions??

regards
Naren
0
 
Donnie4572Commented:
The brick level backup runs slow because the Exchange Server must authenticate for access to each mailbox and possibly attachements. This is the design and security of Exchange. Brick level backup is worthles for disaster recovery. It's purpose is to recover a mailbox or items that has been deleted. With the mailbox/item recovery for exchange 2003, as R-Yanin said, veritas brick level backup is not needed. You could  set each information store to retain deleted mailboxes for 30 days and deleted items for 7 days.

Also, You need to backup the exchange folder and exclude (only) the exchange databases.

Multiple storage groups are desired for administration and faster recovery times. This will offer no better performance for backup.

If you are determined to use "brick" then you will need to allow the additional backup time. You may possibably speed things up some if you backup 2 disk then to tape.
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
r_naren22atyahooAuthor Commented:
>>>Also, You need to backup the exchange folder and exclude (only) the exchange databases.
Could you provide the list of files..
0
 
r_naren22atyahooAuthor Commented:
>>>It's purpose is to recover a mailbox or items that has been deleted
restoring the only required mails. That is important to me
0
 
r_naren22atyahooAuthor Commented:
Increasing the Server CPU Speed???
0
 
R-YaninCommented:
Backing up the Exchsrvr folder structure is useless especially if you are either excluding the databases or the Info Store service is running and databases are mounted. THIS WILL NOT HELP YOU RECOVER ANYTHING AT ALL!! All you will get is the replaceable binaries and copies of the log files with the exception of the current log file which is always is the E00.log or E01 etc since it will be in use.

 You need to be running the backup that is Exchange aware. One easy way to tell is if the E0*.log files actually get purged or deleted when backup completes. The purging of these log files is the last step of the FULL backup process.

 As far as the brick level backup is concerned to restore a single message or single mailbox it IS the way to go but you will have to deal with the backups taking a long time.

  Are you backing up to tape or backing up to file then moving the file to tape? You might improve backup times by backing up to file then ,oving the file to tape. Just a thought.
0
 
R-YaninCommented:
http://support.veritas.com/docs/231488  Reasons why the data throughput rate can be slower than the theoretical maximum when backing up to tape media

http://support.veritas.com/docs/191530 Backup jobs configured to run using the VERITAS Backup Exec (tm) Open File Option are set to the "Loading Media" state for a long period.
0
 
r_naren22atyahooAuthor Commented:
OK i am backing up to the LTO tape.

>>>You need to be running the backup that is Exchange aware. One easy way to tell is if the E0*.log files actually get purged or deleted when backup completes. >>>The purging of these log files is the last step of the FULL backup process.
Do i need to worrry, Coz we dont have a need to restore the log files rite and also they are not big.

IF the system Crashes,
I can still restore the Exchange server to the current state, without any problems
If i have
1. System State
2. C Drive Backup
3. D Drive Backup Excluding the files (.edb and .stm)
Exchange brick by brick backup of the information store with Vertas Agent.
and Excluding the

0
 
r_naren22atyahooAuthor Commented:
Am i rite with the above comment??
0
 
Donnie4572Commented:
To restore anything deleted on a network should be the goal. However, I think the point here is that there is more than one way to recover mailboxes and mail items. With Exchange 5.5 the only option we had was brick level backup. With exchange 2003 microsoft recovery storage group there is no need for brick level.

It is wise to include the exchange directory in your backup.

http://seer.support.veritas.com/docs/266074.htm

Recommended backup selections for configuration data:

File system:
Back up folders and drives containing files for Windows and Exchange. Usually, this is the root drive C:\ and the drives and directories chosen to host the Exchange database files and binaries during the Exchange Server installation, which by default is the x:\Program Files\Exchsrvr directory but can be unique to each environment.
0
 
SembeeCommented:
What you are backing up is not enough to restore a dead Exchange server.
Brick level backups are useless for server restoration.
Furthermore, they will use up MORE space on your tape system than you will be using for brick level backups.

For a server failure, you need to backup the following:

Exchange information store
Exchange server system state
Domain controller system state.

You don't have to backup any files on the server, any transaction logs or anything like that.
A brick level backup is not considered by the Exchange server to be a true backup, so doesn't flush out the logs. If you aren't doing information store backups then you are probably using circular logging to "get rid" of the log files.

As for email recovery, then using Exchange 2003 you have plenty of options, including deleted item retention and the Recovery Storage group.

There is no reason to run a brick level backup.

Simon.
0
 
R-YaninCommented:
 Donnie is on yhe $$ with "the goal. His backup plan would work possibly. I think there would be a few "got ya" items but...oh well.


<<<<Do i need to worrry, Coz we dont have a need to restore the log files rite and also they are not big.>>>>>

  The log files ARE completely NECESSARY!!
Let me explain...

Notes:
 1. When the IS (Information Store) is running and the stores are mounted the databases are in a "dirty shutdown" state whch means the database REQUIRES log files to start. The ONLY time the databases are in a "clean shutdown state is when the IS is stopped. You can stop the IS and run << :\eseutil /mh "c:/program files\mdbdata\priv1.edb" nnad look for STATE it is the 11th or 12th line from the top of the output. When you do an Exchange aware full online backup the databases are "dirty shutdown" so the REQUIRE transaction logs after restoration to start.
 2. E0*.log is always the current transaction log file being written to with the most recent transactions for the 1st storage group E00.log, E01.log would be the next created storage groups' log generation set, E02.log the next and so on..  As e-mail comes in we write the e-mail "transaction" to the current log file and directly to the IS if it is not too busy. If the IS is too busy then it will go back to the transaction logs and catch up when it has the time.  So if the IS (Information Store) is started and one or all of the databases in an SG (Storage Group) are mounted then E0*.log will almost always be "in use".  
3. TRANSACTION LOGS BE IN SEQUENCE TO FUNCTION. The E00.log is written to it's 5MB size then renamedto E00000001.log and a new E00.log created filled to 5Mb and then renamed to E00000002.log and so on. Think of 10MB attachment we need 2 log files just for the one attachment thus making it necessary for the logs to be in sequence.

============================================================

Your question was.

IF the system Crashes,
I can still restore the Exchange server to the current state, without any problems
If i have
1. System State
2. C Drive Backup
3. D Drive Backup Excluding the files (.edb and .stm)
Exchange brick by brick backup of the information store with Vertas Agent.
and Excluding the


The simple answer is NO. You will NOT get back to the current state and have zero loss of e-mail with the above. You will only have the data up to the time that the backup was taken. Everything newer than that would be in the transaction logs and the database.

The design of the online backup.restore process and the transaction logs is to have the ability to have a ZERO LOSS RESTORE. When you take a full backup, if the server were to crash say the next morning at 11am to have a ZERO LOSS restore you would simply restore the full backup to a temporary location.  What will be restored to the temp location will be the databases which were backed up and selected to restore, the required logs for the database to start, and RESTORE.ENV. ("Eseutil /cm :\temp location of restore\restore.env" or eseutil /mh "Eseutil /mh :\path to ???.edb" and look for "required logs"). When you start mounting the databases the rhey know they have been restored and need to have "Hard Recovery" done which tells the IS to look to restore.env and in the tmp location for logs then to go to the transaction log location and run through those transaction logs bringing us back to the moment of crash or failure.  


If you don't put the check mark in the "Last Backup Set" check box during the restore options operation you will need to run <<< eseutil /cc  "path to folder containing restore.env >>>. If you do check that box restore operation will run the "Hard Recovery" or eseutil /cc automatically.


 I hope this clears it up for you but if not e-mail me direct as we are getting off subject a little.
0
 
R-YaninCommented:
Simon's response is accurate clear and not so friggin wordy. That is absolutely all you need if you lost everything like in case of natural disaster.
0
 
r_naren22atyahooAuthor Commented:
Guys thanks for the responces,

For complete Disaster recovery
1. Complete backup of DC, all drives and system state
2. Complete Backup of the Exchange,  all drives and system state

I think this will will be a fool proof, i am rite?

Over that, to have the capability to restore the required e-mails, I have to do the brick by brick backup, rite???
If NO, are there any options to restore the required e-mails from the mailbox without brick by brick backup???

regards
Naren
0
 
r_naren22atyahooAuthor Commented:
Thanks for your effort i am increasing the points

I dont think i am going off topic
0
 
SembeeCommented:
The question that has to be asked is what do you gain by doing a complete backup of a domain controller's files or an Exchange server's files.

Nothing.

In the event of a dc failure, what is the first thing that you do? Install Windows 2003 on to the machine so that you can rebuild the domain. Immediately - 99% of the \windows directory, \program files directory in your backup is wasted.

Ditto for Exchange. Install Windows, Install Exchange.
Unless you are using special backup software that provides support for bare metal restores, you only have to backup your data. You don't have to backup all the application data. That is just a waste of time.

As for recovery of emails, I gave you the options above. The subject comes up very frequently on this forum, when people mention brick level backups.

The major improvement in Exchange 2003 was the Recovery Storage Group. This allows you to restore the database and then restore what you need, using your production server - WITHOUT affecting production systems.

Here are some links that cover the topic in much more depth:

http://hellomate.typepad.com/exchange/2003/12/the_recovery_st.html

http://support.microsoft.com/default.aspx?kbid=824126

Veritas Instructions
http://seer.support.veritas.com/docs/264815.htm

Simon.
0
 
R-YaninCommented:
Naren,

 I guess how and what to backup on an Exchange server isn't too far off of the subject of backups taking too long with backup exec.

 Yes/No to <<<<"For Complete Disaster Recovery">>>> if by Complete backup of Exchange you mean checking Information Store and all Storage Groups and all Stores under Exchange Server object in backup program. Also again no need to backup the files on the drives themselves for any reason.

  At least try the following to see if it saves you time. And as always test your disaster recovery methodology before the disaster strikes.

1. Stop doing the brick level backups.
2. Increase the number of Storage Groups, mailbox stores, or both so you can reduce the size of each database for restore operations to be less time consuming

 I know you think you need to have the brick level backups but consider the information in the following MS knowledge base articles before you make that conclusion.

How to recover or to restore a single mailbox in Exchange Server 2003
http://support.microsoft.com/kb/823176/en-us/ 

How to use Recovery Storage Groups in Exchange Server 2003
http://support.microsoft.com/kb/824126/en-us/ 

The "Exchange Server 2003 SP1 Recover Mailbox Data Feature" technical bulletin for Exchange Server 2003 is now available
http://support.microsoft.com/kb/867643/en-us/ 
0
 
r_naren22atyahooAuthor Commented:
>>>The question that has to be asked is what do you gain by doing a complete backup of a domain controller's files or an Exchange server's files.
we have a Policy to backup each and every file from the server because in future if accidently deleted any thing, which can be restored.

Thanks guys,
i will have a look at the recovery storage group
0
 
Donnie4572Commented:
If you lose your domain controller then exchange will not function because exchange data is stored in active directory. If you loose both exchange and all domain controllers then your domain will need to be restored before you can get back your exchange organization.

Simon,
During a restore, obviously the sys state will be recovered which includes the registry. The registry will be full of pointers that point to files in the windows and program files directory. I would feel lucky to have these folders in the event of a crash. Every server I have restored I have installed 1. windows 2. backup software 3. full restore from tape 4. data.....this has always worked.


R-Yanin,
 you seem to be against backing up this \Program Files\Exchsrvr....mm ...well if when you say full backup you mean full backup of the data then I guess you are right. I would assume that full backup is all data including all files (exluding temp files, database files and log files) I have restored exchange twice once on exchange 5.5 and once 2000. Both times I restored the exchange directory. I suppose what I mean is in the event of a production server disaster I would want every file on that server because the fact remains I would rather have it and not need it as to need it and not have it.

I suppose I'm from the old school where we backed up everything on a production server. In the event of a falure we restored everything on the server.
0
 
SembeeCommented:
Donnie4572 - An assumption that you seem to have made is that the machine will be identical or similar enough to be able to restore the data in that fashion.
In practise, that isn't always possible.
System State doesn't have to include the registry - and I would actually encourage the registry to be avoided.
Furthermore, with companies having to store a lot more information in to the backups, but the cost of the backup systems not decreasing at the same rate, I have to store more information on the tapes. Therefore I avoid anything that I can get elsewhere. The only data that should be on a backup tape is data that cannot be replaced. Anything else is a waste. With tapes especially, I can restore by installing the application fresh quicker than restoring off the tape.

Anyone who has followed my posts in this and other TAs over the past couple of years knows that I work to the principle of guaranteed fix, in the shortest time. Restoring a full server backup (including application files) does not give me the guarantee that I require. I could spend the time restoring 2 or 3gb of data only to find it doesn't work because something is different on the replacement machine. I then have to start from scratch again, increasing the time it takes to get the data back.

As for the policy on having everything backed up in case someone deletes something - if you have people who go near the server who are likely to delete something they shouldn't - then they shouldn't be allowed near the server.
If they delete something critical, then it is recovered off backup tapes, if they delete something off an application, then it is recovered from the installation media.
The only exception that I make to that is when the installation media isn't available - but that then falls in to my earlier data categorisation of unique content.

Simon.
0
 
r_naren22atyahooAuthor Commented:
Guys, For your Information,

IF the server Fails, then if i backedup all drives and system state, then veritas backup can restore the system without any installation..
What we do is that on the D Drive we install the basic windows, then install the veritas backup software, then restore every C Drive and system..
restart the server and remove the windows from D Drive.

regards
Naren
0
 
r_naren22atyahooAuthor Commented:
Guys, i dont see any utilities to restore single e-mail using the Exchange 2003 Recovery Storage Group.

regards
Naren
0
 
R-YaninCommented:
The only utility mentioned in the article is exmerge...

How to recover or to restore a single mailbox in Exchange Server 2003
http://support.microsoft.com/kb/823176/en-us/ 


Download Link for Exmerge utlity
http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=429163EC-DCDF-47DC-96DA-1C12D67327D5
0
 
r_naren22atyahooAuthor Commented:
exmerge is for mailbox, not for single e-mail rite?

I was looking for utility to restore for single e-mail

regards
Naren
0
 
Donnie4572Commented:
you will use outlook to recover email message. click tools, recover deleted items.

I think the point we have been driving at is to reduce the amount of time it takes for your backup to complete by reducing the amount of information you are coping to tape. By excluding all files not necessary for a successful restore and excluding the brick backup you will probably cut your backup time to a third. Following Simon and R-Yanin recommendations it would be alternate way to recover. The only difference is you would need to.....

1. "install the basic windows, then install the veritas backup software" > to c drive
2. install exchange
3. restore exchange database

This plan will save both cost for tapes and time to complete full backup.
0
 
SembeeCommented:
You don't have to install another copy of Windows or Exchange to use the RSG. The feature is built in to Exchange 2003. All you need to do is setup the RSG as shown in the many articles on the feature and then restore the database in to it. Exmerge the contents of the mailbox and then get the message that you want out.
If your users have a habit of deleting emails that they shouldn't, then increase the deleted item retention time. The while point of deleted item retention is to allow easy recovery of individual items that have been deleted in error. Where possible I will run a DIR time of four weeks, which covers most eventualities.

Let me put it this way... excluding full disaster recovery of a server and testing, I have only ever had to carry out a restore from tape a handful of times. All other occasions have been covered with other procedures I have introduced.

Simon.
0
 
r_naren22atyahooAuthor Commented:
Let me know if the following procedure is wrong...

I will restore the full "Exchsrvr" folder to "ExchsrvrRSG" folder on exchage server
Create the RSG in Exchange, then will assign the "ExchsrvrRSG" folder for Database and Log files folder.
Use Exmerge to Select the mailbox and export it to pst file.
Use Outlook to import the pst file and search the required message.

regards
Naren
0
 
Donnie4572Commented:
not exactly

http://seer.support.veritas.com/docs/264815.htm

You will restore the storage group to the exchange server using veritas for exchange. This will not be a file level restore. You will have the option in veritas to restore the database to the RSG.

You should set retension periods for messages and mailboxes. This works like the recycle bin in that it retains deleted items for a period of time that you can set depending on the requirements for your enviornment. From the properties of the store choose the limits tab and set your retension for the deletion settings. If you need to recover a mailbox during this period then you only need to reconnect it and if you recover a message  during this period  you can use outlook, tools, recover deleted items.
0
 
r_naren22atyahooAuthor Commented:
>>>using veritas for exchange

If I use this option again i am using the Veritas Exchage agent, and this agent will do a brick level backup.

I dont what to use the Brick level backup.

regards
naren
0
 
Donnie4572Commented:
From your backup job setup clear the check next to "Microsoft Exchange Mailboxes"
0
 
SembeeCommented:
The use of the RSG requires a full backup. You should not restore a backup of the Exchange files and use the RSG. The presence of the RSG means that any Exchange aware application - like Veritas Backup Exec - directs the restore to the RSG and not the production store.

Veritas provide you with two methods to backup Exchange with their agent.
1. Information store backup. This is the preferred method and uses the API that Microsoft have provided.
2. Mailbox backup - this is technology that Veritas have developed and is the brick level backup.
As already indicated, make sure that you have selected the correct options in the application and you will have a backup that you can use with an RSG.

Simon.
0

Featured Post

Prep for the ITIL® Foundation Certification Exam

December’s Course of the Month is now available! Enroll to learn ITIL® Foundation best practices for delivering IT services effectively and efficiently.

  • 14
  • 7
  • 6
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now