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
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
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
ASKER
>>>Also, You need to backup the exchange folder and exclude (only) the exchange databases.
Could you provide the list of files..
Could you provide the list of files..
ASKER
>>>It's purpose is to recover a mailbox or items that has been deleted
restoring the only required mails. That is important to me
restoring the only required mails. That is important to me
ASKER
Increasing the Server CPU Speed???
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.
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.
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.
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.
ASKER
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
>>>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
ASKER
Am i rite with the above comment??
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
<<<<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.
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.
ASKER
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
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
ASKER
Thanks for your effort i am increasing the points
I dont think i am going off topic
I dont think i am going off topic
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.
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.
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/
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/
ASKER
>>>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
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
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.
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.
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.
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.
ASKER
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
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
ASKER
Guys, i dont see any utilities to restore single e-mail using the Exchange 2003 Recovery Storage Group.
regards
Naren
regards
Naren
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
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
ASKER
exmerge is for mailbox, not for single e-mail rite?
I was looking for utility to restore for single e-mail
regards
Naren
I was looking for utility to restore for single e-mail
regards
Naren
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.
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.
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.
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.
ASKER
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
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
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.
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.
ASKER
>>>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
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
From your backup job setup clear the check next to "Microsoft Exchange Mailboxes"
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.
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.
ASKER
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