A number of administrators are currently reconsidering their approach to backing up their Exchange Servers. In large implementations the costs associated with traditional backups are considerable and the emergence of disk based backups using products such as DPM has stimulated more debate. A lot of companies are now implementing or designing to implement Exchange 2007 and this introduces a number of points which contribute to this discussion.
I am certainly not advocating any administrator abandoning their backup solution without considerable thought and planning but if you are reconsidering your approach to backups then the best way to start is to understand the kind of situations that will require some form of recovery and which of these situations mean resorting to backup. What follows is a quick list of scenarios, which is by no means exhaustive, and which might be different for every implementation:
From this list we need to understand whether our business actually needs to be able to recover service and\or data in the event of every one of these scenarios. We also need to understand the risks to service and\or data associated with each of these scenarios. The approach I would advocate is noting down how your proposed design mitigates against each scenario described and then using the risk understand whether the design needs to be altered to cater for each scenario in question.
Backup - Unless your backup solution involves taking bricks-level backup the recovery path would include restoring an entire mailbox database and then extracting a mailbox. The user would have to be very specific about when the mail was deleted otherwise this will be very time consuming.Deleted Item Retention - could be used if set to a long enough period.
Backup - Unless your backup solution involves taking bricks-level backup the recovery path would include restoring an entire mailbox database and then extracting a mailbox. The administrator would have to be very specific about when the mailbox was deleted otherwise this will be very time consuming.
Exchange 2007 Continuous Replication - SCR (Standby Continuous Replication) - by introducing a lag time into our SCR configuration and appropriate monitoring logical corruption would be prevented from impacting the SCR target database.Backup provides an additional option here. Especially for companies where SCR is not being implemented.
Backup - Unless your backup solution involves taking bricks-level backup the recovery path would include restoring an entire mailbox database and then extracting a mailbox or mailboxes. The administrator would have to be very specific about when the mailbox was sent\received or deleted. This will likely be very time consuming and involve a lot of administrative resource.
Email thread request (historical)
Message Tracking Logs (if within the threshold defined by the administrator)Backup - from a backup of the message tracking logs or a backup of Exchange data.
Using my set of scenarios I believe that in most companies the reasons that you might deploy a backup solution are as follows:
(As an aside I think many administrators might be surprised at the above list. Traditionally we backup to protect against data corruption and this list doesn't not include this as a scenario.)
Many companies that must satisfy the requirements above will still need to deploy a backup solution. However I believe that there are many implementations where the requirements above either do not need to be met or can be met in other ways.
So it is hoped that having followed this exercise that if nothing else you have a much better understanding of why you run backups of your Exchange data. It might be that you can eliminate backups altogether or as in most cases you might be able to dramatically reduce the number of backups you take and costs associated with them.
What about PF? They're still present in Exchange organizations.
You will be running out of log file space very soon if you are not doing any backups. You need some way to clean ou the logs, unless you are turning the circular logging on which has its own challenges in an environment.
Yes agreed - public folders need to be considered. If you only have a single public folder store then CCR\LCR might be enough to protect this data or if you have multiple databases then public folder replication may be enough. Or dump out the contents to disk on a regular basis via a script? These are some options but more thought required I think.
Yes you do need to consider what to do with the transaction logs.. Truncating them with NTBackup on a weekly basis perhaps? Important point for capacity planning...
A blog on this same subject has just been posted to You Had Me At EHLO... and there are a few points
I recently posted an article to the Exchange Team site here and received a number of comments. I thought
I look after several small businesses, never use Small Business Server if I can help it because it is such a pain in acquisitions and mergers.
I need offsite backup on tape, often have to get old mailboxes and old mailstores back, indeed did an Exchange 5.5 restore last month.
When confidential data is concerned, no-one trusts their ISP or hosting company!
We need a simple backup and clear logs tool (most small sites have very small logs)
There will always be companies and implementations where data needs to be backed up in the traditional sense. As E2K7 is adopted (not mentioning future versions) there are more choices about what actually constitutes a backup and how to approach data protection. For long term retention of data though the realistic choices are only really journaling and backup.
Ok so here's my thoughts on the whole SAN ( Storage Area Network ) versus DAS ( Direct Attached Storage
It's not hard to imagine mass events (organization-wide) that could leave people wishing that they (a) had a discrete backup of their Exchange data outside the context of Exchange, and (b) kept their resume more up to date. A lot of these events are missing from your analysis.
For example, a hacker, or more likely, a disgruntled administrator with administrative access to one Exchange server is going to have the same access to all the other Exchange servers in the environment, and could wreak absolute havoc deleting data from both the production and replica servers.
Similarly, a widespread virus will also affect both production and replicas (log replay delay on an SCR target can help, but it's pretty expensive). Whether you fix that with virus software or backups, it's wise to have both options.
Yes agreed - there will be cases where we might need to revert to a copy of our data that is kept outside of Exchange.. but if this is the only requirement for our backup then this redically changes most peoples approach of backing up every night and keeping backups for the long term.. This might only require a few days worth of backup on disk - which might mean reducing the requirement on a massive tape infrastructure?
When it comes to virus infections I would want to tackle this with virus software to begin with but again I think that many companies might deploy a backup solution that protects for the short term to disk only... Plus with a combination of say Edge and Forefront where you are using multiple virus\spam engines this risk is very small.