When Exchange Server 2010 RTM hit, some IT pros suggested that database availability groups in Exchange 2010 make traditional backups unnecessary.
I initially scoffed at the idea.
The concept behind ‘backup-less’ Exchange
A backup is nothing more than a point-in-time copy of your data. It is this deceptively simple definition that led to the idea of running Exchange 2010 without backups.
Some say running Exchange 2010 without backups is safe because of the way database availability groups (DAGs) work. A single DAG can contain up to 16 mailbox servers and an individual mailbox database can be replicated to any combination of mailbox servers within the DAG.
The argument against backing up Exchange 2010 boils down to how many copies of data you really need. If you already have 16 replicas of a mailbox database, do you really need a seventeenth copy as backup?
Important Exchange backup considerations
While the argument against backing up Exchange 2010 in environments with DAGs sounds logical, there are a number of important factors to consider before ditching your backup system.
- DAG size
While you can include up to 16 mailbox servers in a DAG, you can also create very small groups. Therefore, you must consider the size of your DAG before abandoning backups. Microsoft recommends that you only consider going without a backup if you have three or more mailbox servers in your DAG.
- Transaction logs
Typically, when you back up an Exchange mailbox server, the contents of transaction logs are committed to the database as part of the backup process. If you never perform a backup, the transaction logs accumulate until the volume runs out of disk space. Because of this, organizations that do not back up Exchange 2010 must enable circular logging to prevent log file accumulation.
- Offsite storage
It’s easy to think of a backup-less Exchange organization in the same way as a disk-based backup solution because database contents are replicated to other servers.
However, organizations that depend on disk-based backups usually adopt a disk-to-disk-to-tape solution where the disk-based backups are periodically copied to tape and stored offsite. If the data center burns down, the backups remain safe.
If you’re considering operating Exchange without backups, it’s smart to place a few DAG members in a remote data center. That way, your data remains protected even if something happens to your primary data center.
- Point-in-time recovery
The biggest disadvantage to running Exchange 2010 without backups is that you lose the option of accurate point-in-time recoveries. For example, imagine that your entire company became infected with a virus.
In this situation, you could restore a backup that was made prior to the infection, rather than trying to remove every infected message from your mailbox database. This is simple with a traditional backup, but isn’t practical if you go without.
Notice that I didn’t say that it’s impossible to perform a point-in-time recovery without a backup. Microsoft does let you create lagged database copies that log files are not immediately replayed on. That way, if you need to revert to a particular point in time, you can activate a lagged copy.
The problem is that there’s a lot of guess work involved in the process. You must know exactly when the problem began in order to get rid of all of the transaction logs that were created after the problem occurred. This is accomplished by replaying the transaction logs that were created prior to the problem. Unfortunately, there isn’t an easy way to figure out which transaction logs should be used and which should be deleted.
As you can see, it’s perfectly feasible to run Exchange 2010 without traditional backups in certain situations. That said, I advise backing up Exchange as you always have. If an unforeseen set of circumstances leads to data loss, you won’t have to explain to your boss or management that you don’t have backups.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
This was first published in October 2011