Over the last several years the very nature of datacenter backups have evolved into something almost unrecognizable. In the not too distant past, the accepted way of performing backups was to insert a bunch of tapes into a tape magazine and let the backup run late at night. Today, this approach is rarely a viable option. Most datacenters operate 24 hours a day, which renders the concept of a nightly backup obsolete.
In addition to the time constraints, there are many additional factors that are changing the way that backups must be made. These factors run the gamut from recovery time objectives to service level agreements. Because of these and countless other factors, organizations have been forced to adopt next generation backup technologies such as snap shot backups or continuous data protection backups. Still others have adopted a much more radical approach – simply abandoning the concept of backups altogether.
The concept of backup abandonment has come to be known as zero backup. The basic idea behind zero backup is that if you have enough redundancy in place then there is no need for backups.
Technically zero backups could still be thought of as backups – albeit very nontraditional ones. After all, a backup is really nothing more than a copy of your data that is stored in a safe place so that it can be restored if something ever happens to the primary data source. Zero backups may not involve copying data to tape or other backup mediums, but the redundancy involved in the underlying architecture ensures that there are multiple copies of an organization’s data. Hence zero backups could still be thought of as a type of backup.
So how do zero backups work? I first heard of the concept about a year ago with regard to Exchange Server 2010, but the concept has since expanded to include other server products. Even so, I will talk about zero backups from an Exchange Server prospective since zero backups for Exchange have been in use for a while.
The thing that makes zero backups for Exchange Server possible is a structure known as a Database Availability Group. Database availability groups are similar to failover clusters in that they provide Exchange mailbox servers with redundancy and fault tolerance. In fact, database availability groups even rely on the Windows Failover Cluster Service. Unlike many other types of failover clusters however, Exchange Database Availability Groups do not rely on shared storage.
The lack of shared storage is one of the keys to making zero backup practical. In a cluster that relies on shared storage, the storage itself (and the data that is stored within the storage array) can become a single point of failure. In a Database Availability Group, the mailbox databases are replicated among cluster nodes.
Those who are familiar with Exchange Server might be quick to point out that Exchange 2007 offered database replication capabilities as well through Local Continuous Replication and Standby Continuous Replication. Database availability groups could be thought of as a next generation continuous replication solution.
Cluster Continuous Replication deployments typically consisted either of three cluster nodes or of two cluster nodes and a file share witness. In contrast, an Exchange 2010 database availability group can include up to 16 mailbox servers.
In most cases, having sixteen replicas of a mailbox database will be overkill, but the number of mailbox servers in a database availability group does not necessarily reflect the number of replica databases. The reason for this is simple. Each mailbox server is capable of accommodating multiple Exchange Server databases. Exchange 2010 database availability groups let you host databases locally on any member of the database availability group, but they also allow you to replicate any database to any database availability group member of your choosing. Replication is done on a per database level, not on a per server level. That means that you are free to replicate some databases and not others or to replicate different databases to different database availability group members.
So what does all of this have to do with zero backups? In the case of Exchange Server, mailbox database replication is normally configured in a way that provides the greatest resilience to disaster.
Of course there is a difference between fault tolerance and backing up your data, so you might be wondering how database availability groups can facilitate things like point in time recovery or offsite storage.
Offsite storage is made possible by the fact that a single database availability group is able to span datacenters. For example, if your organization had datacenters in Miami and Las Vegas then you might create a single database availability group and include mailbox servers from both locations. You might have some Exchange Servers in Miami that normally service users in the Miami office. Those server’s mailbox databases can be replicated to the Las Vegas datacenter for safe keeping. Likewise, the Exchange Servers in the Las Vegas office probably contain the mailboxes for the users in the Las Vegas office, but those mailbox databases can be replicated to Miami. In essence, every mailbox server in the database availability group could potentially host database replicas from both Miami and Las Vegas. You are free to mix and match replicas as your needs dictate.
Although offsite replicas do give you a way of storing a copy of mailbox server data offsite, there is still the issue of point in time recovery. Suppose for example that a mailbox database was infested with a virus. The damage to the database would be replicated to all of the other database replicas. So how can you revert the database to a previous point in time if you aren’t doing backups?
Exchange 2010 offers a feature called lagged copies. A lagged copy is a database replica that is set up so that changes are not immediately committed to the database. For example, you might set up one database replica with a lag time of one day. Another replica might have a lag time of a week. If the unthinkable should happen then you can use the lagged replicas to go back to a point in time before the database corruption ever occurred.
Conclusion
Throughout this article, I have shown you how database availability groups could conceivably render traditional backups unnecessary. Even so, one has to ask whether this and similar technologies really do away with the need for traditional backups.
Some organizations have actually committed to using zero backups. Such organizations have enough redundancy in place that they don’t feel as if they even need to make backups any more.
Personally, I would be really nervous about the idea of giving up my backups in favor of zero backups. Even though database availability groups and similar technologies could potentially eliminate the need for backups, I have worked in IT for long enough to know that sometimes the unexpected happens. If a catastrophe ever did result in data loss, I just can’t imagine having to explain to my client that their data is gone because I chose not to make a backup. For those who work in the corporate world, I would imagine that it would be equally unpleasant trying to explain to your boss why you don’t have any backups.
