Archives for June 2009

What are the general best practices? (Part 2)

Database Placement

You should always have one mailbox database per storage group. If possible only one database per storage volume. The real benefit with this is if you are using VSS to back things up. Since VSS backs up entire volumes and then restore a particular volume without affecting another database.

If you are a real keener there is added benefit gained from keeping transaction logs on a separate volume. Having the Transaction logs are REALLY beneficial when you have more then 200 users.

Sizing Databases

When you are sizing your Exchange 2007 database you should really keep Recovery Time Objective (RTO) in mind. The reason for this is they should be able to be restored in a reasonable timeframe.

A good way of finding this out is TESTING!!! Find out how long your particular hardware takes to restore and backup. Every company will be different. For example. Say you have a small organization with 10 Users. Each of those users has 20GB Mail boxes. It would take longer to restore their database then a company that has 100 users with 10MB mailboxes.

There are several ways to divide mailboxes. The three most used options are:

• By Function
• By Geography
• By Size and Backup Resources

Function – For example you might want to have different databases for Executives, Support Staff and Temps. A backup like this can help you prioritize the restore based on the function of the user within the company. For example temps might not need access as fast as say a support staff or Admin staff member.

Geography – You for example could put the West Coast in one storage container and the East Coast in another. If your company is located in a single building you might use “Old Section” and “New Section”.

Size and Backup Resources – You could split up the mailbox via Alphabetical order. A –> M and N –> Z. Say there are two user name Wilma and Waldo. Both of those users have VERY large inboxes. The N –> Z side might be much larger then A –> Z.

In this situation you might want to setup mail boxes based on size. A –> F and then user G –> Z. This might make the two data sources a bit more equal in size.

Remember to also take into account that these mailboxes will grow.

Mailbox Server Role Storage Requirements Calculator – Is a tool Microsoft has made available for free download. This program will help you figure out how to create separate storage units.

Overview (Part 1)

Recovery Principles

Before you build a backup you should know what you plan on restoring.

Recovery Point Objective (RPO)

If we lost it all, how far back would we have to go in order to restore our last backup. If you are willing to loose two days of data then your newest backup should never be older then 2 days. Ask yourself “How much data can be lost”?

Recovery Time Objective (RTO)

How long can we afford to be offline waiting for  the offline recovery to complete. For exmaple if your RPO is 4 hours and it takes you 3 hours to bring the server online the you would have an approx. RTO of 7hrs.

Retention Range

What is the long range Retention scenario? Say you need to keep 7 years of data. Do you need to backup all this data every day?

What is the short term Retention scenario? Would it be ok to recover the last six months in 45 minutes and bring on the archives for the rest of the 7 years.

Database Architecture

The basic operation on how exchange stores data and how it relates to backups/restores.

1. The information stored in memory on the exchange server
2. Because memory is not very secure items a quickly written to transaction logs.
3. Each transaction log will be 1MB in size.
4. All information will be held in logs until that data has been added to the mail database.
5. Transaction logs protect the database because if there is an error writing to the database
6. If the data that was written to the database would be erased and then system would have a change to try and re-write the data to the database.
7. EDB File – Mailbox database file.
8. If you have created more then one database in a single storage group.Transaction logs might not be associated with just one mail database. Transaction are unique to Storage Groups not Databases!
9. Microsoft’s recommendation is for 1 database per Storage Group. Exchange 2007 standard allow just as many storage groups as there are databases there is no compelling reason to put more then one database per Storage Group.
10. Backup logs are going to interact with those transaction logs in several ways.
11. If you do a full backup typically the mail database gets backed up, all the transaction logs that existed before the backup are then deleted.
12. Incremental backup – All you have to do is backup the transaction logs.
13. Normal Restore returns the database back to the state in which the database was backed up.
14. Incremental Restore – Relies on you restoring the last normal restore and then restoring all the incremental backups.

File Backup

You would perform a file backup if you copy the files (database and transaction logs) to another server. In order to do this without corrupting the database you must shutdown the Exchange server while this process is happening. If you don’t turn off exchange before the copy is finished “backing up”, you database will most likely become corrupt. There are ways of running scans and tools on the database but it gets pretty ugly. .ie Can’t mount files. The email server would need to be offline the whole time… ie. no emails can be received or sent.

Open-File Backups

Backup Exec allows to backup open files. This option will give you an inconsistent database state. Similar to “File Backup” the restore will not be pretty. You will most likely need to run a database fix. You may or may not be able to mount the files.

Brick-Level Backups

Is basically away to backup the mail database to individual PST files. This is something that is not normally done from experienced admins. A downfall of this type of backup can increase the size of the backups. Exchange is smart in that when a user sends an attachment in a email to 10 other users. Each users inbox would point to a single file. After restoring from a Brick-Level restore the database would be much larger. Another issue with the restore would be for Free/busy time.

Backup time would be much longer. It would probably be done with MAPI.

Streaming Backup Overview

Is now considered a legacy backup solution. NTBackup for Exchange in Windows 2003 is an example of Streaming Backup. Stream database and pour that information into a separate file. Full,Copy, differential and incremental are supported.

Cons – Can only backup an active database. They can not backup cluster or replicated servers. Windows 2008 backup does not support streaming backup. Remote streaming backups in Exchange SP1 are disabled. You can re-enable this by changing a Registry setting on the box.

The Streaming Backup Process

1. Database must be online
2. NTBackup starts.
3. Database writes are paused so DB is in a consistent state.
4. Transaction logs continue to fill during this process.
5. Exchange will make a distinction of logs before pause and after pause.
6. The logs that get truncated and deleted are only the ones that were there before the pause.
7. Once the database logs are paused, the database gets streamed out to the database file. Streamed out in 65kb chunks. Every part is verified enroot.
8. Logs that were filled during backup get written back to the database after the backup completes.
9. If backup is successful the logs will be deleted.

Volume Shadowcopy Service (VSS) Backups

We had Volume Shadowcopy service on Windows 2003. This wasn’t the case for Exchange 2003. As noted before, Streaming Backup is what was used to backup Exchange.

The VSS Backup Process

VSS works by taking a snapshot of the files on a volume and not individual files. Full backup will take a while but not as long as just coping the files. Incremental backup on copy the blocks that changed since the last backup. Block size is based on the block size you formatted the volume with.

You can’t mix VSS backups with other forms of backup like streaming and VSS Backup.

Recovery Storage Groups

Are essentially containers that allow restored databases to be mounted. Once they are mounted they can not be accessed by clients. There sole purpose is to to recover data. A virtual lock is placed on the group to prevent changes. You could essentially recover a mailbox while the server is online using a storage group. Using a wizard you can select a mailbox and tell it to copy or merge with the mailbox that you are wanting to restore.

Recovery Storage Groups only work with streaming backups and NOT VSS backups!!!

Clustering and High Availability

Your first option in clustering would be to fail over to the second or third server. Restoring would no longer be your first choice. You would not have to backup as much because you’d have an exact copy of the server waiting in stand-by.

Using VSS we can backup replicas and not the main database. This will put less load on the default server. Streaming backup servers can not do this. They can only backup production database.

Types of Clustering

Local Continues Replication (LCR)

Ability to write a copy of the database to another volume and log shipping (copy transaction logs). It can consistently make sure that the second database is kept in “Update Status”. If the main database were to go offline we could take the second database and put it into production.

Single Copy Cluster (SCC)

When 2 servers (Active Server and Passive Node) both share a storage unit on which the database is kept. They would maintain that based on build-in Windows 2003 or Windows 2008 clustering abilities.

Standby Replication Cluster (SRC)

Say you have two live mail servers. On each server you have a complete backup of the other server’s database. That copy
is called a “Passive Copy”. SCC clusters share a common Storage Container.

Clustered Continuous Replication (CCR)

It maintains it’s own distinct storage. It does not share a common storage container like SCC. CCR can automatically bring the other database online.

Next Lesson – General Practices – Exchange 2007 Backup and Recovery