Some of you might wonder - why write about this subject? Well, every day I see customers calling in with Exchange servers that have experienced some sort of disaster... we all know that hard drives eventually die, power failures happen and file-level Anti Virus software can mess Exchange database or transaction logs up if not configured correctly. (More on that subject HERE.)
In many of those cases - we need to go back to restoring a backup of Exchange databases in order to get the maximum amount of information back after the failure.
Unfortunately - in MANY cases (way too many!) when we get to try restore a backup, we realize that:
- backup is not good (can't restore, bad tape, etc...) - there is no backup of Exchange on the tape (just some logs were backed up) - backup did not run for few months (nobody checked if it was running) - something else - but read: there is no backup because of it :(
Really, on the question "To backup, or not to backup" the answer is:
"The need for backup is directly proportional to the amount of grief that you would have if your data (in this case - Exchange databases and transaction logs) disappeared today."
This could be then expanded to say that the backup has to be not just taken, but also tested to see if it is good. Please note here that I am not even considering what kind of hardware Exchange is running on. It really does not matter if databases are on RAID 5 or logs are on the Mirror. It does not matter if everything is on the SAN somewhere. It seems like many people think that - if the storage solution costs a lot, then it is "foolproof" and backups are the thing of the past. Unfortunately not so. In fact - the way I see it - if a company spent a lot of $ on the storage solution, they need backups even more, as their Exchange data is obviously that much important to them, right?
Also - we have to make sure that we are taking the RIGHT type of backup. Granted, there are MANY backup solutions out there. The main thing to consider, no matter what solution you pick, is that the solution needs to be Exchange-aware. So it has to be able to talk to our backup API (please note here that I will cover only the Online backups here).
In many cases that we see, the Exchange data is backed up by going to the backup software and then selecting the "Exchsrvr" folder and backing that up, as with any other folder on the hard drive. Well, this will not give us much if Exchange databases are actually mounted and running, as the database Store will have a file lock on the databases and some transaction logs. That will cause those files to get skipped, so they are not on the backup tape at all. The only time you can do a backup like this is when Exchange databases are offline or Store service is stopped. This right here accounts for about 40% of cases that I have seen when customers realize that they have no backup of Exchange info.
In W2K3, NTBackup's shadow copy will actually back up the databases while they are online. This is not necessarily a good thing--it can take a very long time and bloat your backup, and you have a database that's in the state it would have been in just after a crash. Admins should always exclude the Exchange data folders from conventional backup, not rely on the files being locked to prevent them from being backed up.
Another thing that is very common is using what is called an "Open File Agent" to be able to backup files that are currently in use by some other process (this is considered a "solution" to the above). Several 3rd party backup programs have this functionality. This is something that will be able to backup your databases even if they are in use, but if you try restoring them - you will in most cases have to eventually repair the databases in order to get them started, as databases restored in this way will be marked "inconsistent" or "dirty shutdown" because - well, they were inconsistent when the backup was taken, right? Store was still using them! So - restoring this type of backup in most cases (please note I said "most cases" as sometimes it is possible to replay the log files into the databases restored in this way, depending on the files that are restored) forces us to repair the database (repair = probable data loss + a lot of work + uncertainty of success). For what to do after the database repair, please go here.
Then there are products that backup mailboxes themselves, rather than databases. This is referred to "brick" or "mailbox level" backup. This is fine to do (even though Microsoft does not provide any APIs for it so we can not really support it as such) - but as long as this is done together with Online backup. This is because - if you have the mailbox-level backup, your data is really as good as the last backup is. Meaning - if you do a brick backup on Monday, and your database drive dies on Friday, you will be able to restore up to Monday, as there is no way to replay the transaction logs from Monday to Friday into the new database we had to create to restore the brick backup into.
If you are looking for this kind o backup, you could possibly look into the Exmerge tool, as it can be scripted to "backup" specific mailboxes into the PST files in the regular basis, and could do it "incrementally" too.
That brings us to:
How DO you backup an Exchange server?
Simply put - you need to use the backup that is "Exchange aware". That right there is the key. That will mean that we need software that either "out of the box", or through the use of a special add-on (also called an "Agent") - knows how to talk to our services to actually backup the database, any transaction logs that we might have to back up, purge the already committed transaction logs from the hard drive and - do all that while services are up and running and users are accessing the databases. It is important to mention here that Exchange online backup is the only type of backup that will purge already committed transaction logs from the hard drive after backup is completed successfully.
When in doubt - you can always use NTBackup. It might not have all the features of your Enterprise-grade central backup solution, but - it is great at backing Exchange databases up. When you install Exchange System Manager (ESM) or Exchange Administrator (for 5.5 servers) - the NTBackup program is extended to provide the ability to online backup Exchange servers. If everything else is questionable - this is something that you can always fall back to and make sure to have good backups.
And a main selling point of using an "Exchange aware" backup program: you don't have to know exactly how transaction logging works, how to determine which log files need to be replayed, etc. "It just works." If you're not doing online backups, then you need to become an expert in Exchange transaction log replay.