Backup and Quick Recovery

[yarym]

Hello! Currently I'm running veritas software to backup my Mailboxes for my Exchange. My question is, is this really the best way to handle backup? Also, what happens if my HD fails? If I reinstall Exchange, all setting and mailboxes are lost, will I still be able to restore the mailboxes? Should I start backing up LOG Files and *.mdb files. Can someone please advise on the proper procedure?

Thank You

 

[david902]

the best way to backup you exchange server is to do a full offline backup at least weekly.

stop all the exchange services, and perform a full offline backup, then restart the services.

Veritas doesn't do very well backing up the files while open and in use.

Microsoft recommends a full backup daily.

 

[yarym]

You recommend that I shut down exchange? How can explain that to my users? Also, if I do that, which files should I back up?

 

[david902]

I know it's ugly, but yes. all Exchange Admins are "supposed to" run offline backups and defrags on a regular basis.

you need to create a maint. window for backups. and tell the users it's for their own protection.

I'd rather explain to users that their mail server will be down weekly for regular backups, than explain that their mail cannot be recovered because the mail server crashed.

all you need to really backup are the .mdb files priv.mdb and pub.mdb. you'll need to do a search for them and those are the files to backup.


hey, I've got a 90Gb information store, which doesnt' get backed up regularly, it takes 3 days with verify to do a brick level backup, the data is stored on a "network drive", I can't take the server offline, I can't run offline defrags, I can't run any online defrags because it's on a network drive, there's no disk space to even run defrag. the priv.mdb hasn't been defragged in about 4 years and management won't impose mailobox limits.

Please don't end up in my shoes, I'm hanging by a thread, (I hear all you admins laughing )

Plan, do it right, backup your data correctly and your users will thank you in the long term.

 

[Zelandakh]

Erm, I seriously wouldn't recommend that course of action.

Backup information store for disaster recovery. Backup brick level for "I deleted xxx email".

DO NOT backup as per above - stopping the services and backing up the files is not a recommended course of action.

Veritas Backup Exec from v7.3 onwards is excellent for Exchange backup if you have the Exchange agent.

Sorry David, no offence but stopping Exchange to back up the data is not good and will create problems.

 

[yarym]

So how do you suggest that you back up exchange. With Veritas, you can back up mailboxes, but you can't back up all settings and users.

 

[zbnet]

I agree with Zel, you should be doing online backups (we do one every night on every mailbox server). We also do an offline backup (with the services stopped) early each Saturday morning, although this could probably be just once monthly. But I wouldn't swap the daily onlines for an offline - that's not the way Exchange is designed to run.

You need to have a good read of the DR whitepaper to give you a good understanding of what's going on here.

http://www.microsoft.com/technet/prodtechnol/exchange/55/support/exdisrec.mspx

 

[david902]

Zel, how do you perform your database defrags?

yarym, here is a link that should clear up everything.

Overview of maintenance, backup, and disaster recovery for Exchange Server

http://support.microsoft.com/default.aspx?scid=kb;en-us;272234

 

[Zelandakh]

Online defrags happen during maintenance schedules with no downtime.
Offline defrags happen when I feel like it. Usually about every 18 months...

I wouldn't stop the services for a backup. If you want to make doubly certain, run an exmerge of all users.

Veritas backs up store level and brick level. That does all settings for all users and has worked for me very well since 1998. Touch wood it has always provided me with a way to get individual emails back and full on DR (which is how I change hardware).

 

[yarym]

what do you mean by store level and brick level?
thanks for help.

 

[zbnet]

You haven't read the white paper in the link I posted, have you?

 

[yarym]

Sorry, I did read the white paper, but missed that last part. Right now I only perform full brick level backups. So that means if server crashes, i would not be able to restore the exchange back to its original settings? What should I start backing up?

 

[Burninator]

yarym,

Here is your best action plan when it comes to backing up your exchange databases:

OPTION #1
Veritas has an Exchange "option", you may have to purchase that, if you don't have it already. With this option you can perform "online" backups, which does two things, backs up your databases (PRIV and PUB) in its current state albeit inconsistent(thus the need to run the eseutil /cc from the temp directory where veritas will create a restore.env file, if you have to restore the database) and will purge transaction logs that have been committed to the database already. This also frees up space.

OPTION #2
Use NTBackup to perform online backups of your information store files. Alot of people say don't use NT backup. But when Exchange is installed, NT backup is modified to make online backups of your databases very, very easy. I use it with my client, and it performs very well. It simply does the job.

As regards defragging a database, Microsoft reccomends you do it monthly. Online maintenence, does '0' out any free available space in the database, but will not decrease the space it uses. Using the command below will defrag your database. Also I reccomend running an ISinteg on your database while it is dismounted. Before defragging your 5.5 database you must stop the Information store service, the same for ISinteg.

To Defrag type this command from the exchange BIN directory:

eseutil /d "x:\exchsrvr\mdbdata\priv.edb"

You can also follow this article:

http://support.microsoft.com/default.aspx?scid=kb;en-us;192185

Your database may be in a different location you can find that in the Exchange Admin program, by looking at the properties of the database file locations.

To run isinteg follow this article:

http://support.microsoft.com/default.aspx?scid=kb;en-us;182081

and this one will help too:

http://support.microsoft.com/default.aspx?scid=kb;en-us;177885

Also a bit of information for you on brick level backups, they make restoring mailboxes or files, or folders easy, but that form of backup is not supported by microsoft. Veritas will have to provide support on that function.

Hope this helps, if you have more question feel free to ask!!

Jay

 

[zbnet]

So that means if server crashes, i would not be able to restore the exchange back to its original settings? What should I start backing up?

You need to consider a) how to restore the environment, and b) how to restore the latest email data.

Lets take them in reverse order. To be able to restore your latest email data, you need a recent copy of the databases. An online backup of these is by far the best, it checks the database for corruption every time it runs, and purges away the transaction logs that have built up since the last full online backup (you have turned off circular logging, right?). We do one every weekday night (our servers don't get much use over a weekend). With a nightly backup, you're safe against a corrupt database file - if a backup fails one night because the priv.edb file is corrupt, it will also leave all the transaction logs on disk. You simply restore your last good online backup, and the remaining logs will replay and bring your restored db back up to date. This is why it's a real good idea to check your backups worked every single day, and also a good idea to keep your transaction logs on a totally physically different drive(s) from your databases (use a mirrored pair of disks for your transaction log volume for extra security).

Now, back to part a), restoring the environment. To do this, you could use an NT/file-level backup of every file on all disks (inc your registry). Because you're taking seperate backups of the Exchange databases, you can exclude the *.edb and transaction logs from this backup if you wish. It works slightly better if you stop your Exchange services before you do this kind of offline backup - so out of hours, unless you want lots of unhappy users. You can either do these backups on an ad hoc basis (whenever you make changes to a server, like patches or SPs etc), or do it semi-regularly - we do one at 4am local time every Saturday morning on each server, but this is probably overkill, once monthly would probably be better.

Or, and here you might want to experiment in a test lab, you can avoid having to restore a backed-up environment. You'll need a good documented copy of your server setup for this to work. When disaster strikes, and your server dies, simply turn it off, and find another. Build a replacement server from scratch, with the same name, same settings, same organization name, same site name, same SP level, everything the same as the sick server. Make it a new server in a new site, but you must have the directory name for the Exchange organization and site names EXACTLY the same as before (even the case is important), then when the server is up and running and you've tweaked Exchange to exactly the same as your documented settings (circular logging, etc etc), do a full online restore of the last know good databases - including the directory. This will bring the entire identity and mail environment of the sick server back to the replacement server at the point of the backup. So you'll have some lost mail (depending on when your sick server went down), but I imagine most of your users will be releaved that their mailboxes have come back almost totally intact.

This approach is more difficult if this server also hosts your IMS, but this is all the more reason to break this out to a seperate IMS (non-mailbox) server.

 

[zbnet]

As regards defragging a database, Microsoft reccomends you do it monthly.

Please can you point me to the published reference where this is stated? I cannot find it in the links you posted, just the following (very different) statement:

"In certain cases it may be necessary to defragment a Microsoft Exchange Server database file offline.

 

[Burninator]

HI zbnet,

I apologize that is a serious bit of misinformation on my part. I did not think to correct that on review of the post.

That statement reflects my personal preference on offline defragmentation, in a very small environment, mainly 1 Exchange 5.5 server and at the most 2 Exchange 5.5 servers. With heavy usage.

Microsoft has this technet whitepaper:

Best Practices for Exchange Database Management

http://www.microsoft.com/technet/prodtechnol/exchange/55/maintain/edbwp.mspx#ECAA

On their reccomendation, since this is a costly operation, meaning it needs 105% of the space of the original database size, as it creates a new database. It should be only when you need to reclaim space or have done the dreaded eseutil /p, discussed here.

http://support.microsoft.com/default.aspx?scid=kb;en-us;812357

Once again I apologize for that misinformation.

Jay

 

[SimonDavis]

My 2 cents worth.

I use Arcserve, with an Exchange agent. It backs up the databases and the logs. I assume Veritas can do the same.

I don't use brick level - that means you back up each mailbox as a seperate entity. Takes too long.

You do need the logs. They are what allow you to back up an open file - they will have the data that will add in any information not written to the database when you back it up. There are utilities that tell you which logs and how to merge them.

I have had a complete hard disk failure on the exchange server, and made a complete recovery - all that was missing was the messages arriving after the backup, and there's just about no way to avoid that - just make sure you back up daily.

I use hard disks as backup medium, much eaier than tapes.

 

[Zelandakh]

if you don't do brick, how do you restore emails after retension period or mailboxes? Aelita?

after hd failure of store you can restore to point in time with a restore and rerun the log files on your log partition.

 

[SimonDavis]

Guess I've never needed to.

All our users mail is copied to a public folder anyway, so there's never any need.

It's the beauty of having only 25 users. I suppose if you have hundreds, you probably need to.

 

[N0ktar]

I still have my old Exchange server sitting in the office, offline and powered off most of the time. However, that server is the exact replica of my production server and it can read our backup tapes. I have an email retention period set for 30 days and I retain two backup tapes from each month. This way if a user says I need an email from Jun 2002 I power on my old exchange server, restore my Jun 2002 backup tape, login as a particular user and export or print his email out. Simple and yet reliable, works every time. Maximum message recovery time for any email sent or received at any point of time in the past is 2hrs.