News Stay informed about the latest enterprise technology news and product updates.

Exchange vendor snapshots and point-in-time copies

Exchange vendors have solutions to cutting down recovery time for Exchange. Learn the pros and cons of vendor snapshots and point-in-time copies before choosing your support.

You are reading tip #6 from "10 tips in 10 minutes: Fundamentals of Exchange Server disaster recovery," excerpted from Chapter 2 of the book The Definitive Guide to Exchange Disaster Recovery and Availability, published by Realtimepublishers.
The Holy Grail of Exchange disaster recovery is to be able to instantly jump back to a particular RPO with as low an elapsed time as possible. Taken to the extreme, this ideal would mean being able to roll back to any point in time with zero elapsed time. We're not quite there yet, but vendors -- including Microsoft -- ship solutions that can drastically cut the recovery time for Exchange. These solutions depend on specific hardware and software combinations from particular vendors; examples include EMC's TimeFinder and VERITAS' Storage Foundation.

How vendor solutions work

These solutions typically work by exploiting disk mirroring, or RAID-1. In a conventional mirror implementation, there are two disks, one of which is the primary. (VERITAS calls the individual volumes plexes, a term which will be adopted here.) Software or hardware copies data from the primary plex to the mirror plex as it is written. Windows 2000 (Win2K) and Windows Server 2003 (WS2K3) provide software mirroring support, as do most Linux distributions. Many motherboards offer hardware mirroring, and mirroring is a standard feature on RAID disk controllers.

The relationship between the plexes can be broken at any time, at which point the mirrored plex becomes a point-in-time copy of the data on it. In a conventional two-disk mirror setup, though, breaking off the mirrored plex leaves you without a spare copy of your data, and the whole point of mirroring is to provide data protection.

Point-in-time copy solutions that depend on mirroring keep two plexes of the master. Data written to the master volume is mirrored to both plexes simultaneously. To create a point-in-time copy, the mirror relationship between the master volume and the third plex is broken; at that point, the third mirror can be used as a point-in-time copy by moving its data to another computer, or logically moving the third mirror to another host on a storage area network (SAN).

One problem with this approach: when the third mirror is broken off, what guarantee is there that it contains complete and consistent data? The answer is simple -- there is no such guarantee. Suppose that your Exchange information store is in the midst of writing a 4 MB mail message into a user's mailbox. That's about 1000 4 KB database pages. If the mirror is split after, say, only 920 of those pages have been written, the mirrored plex will be missing 80 database pages. The seriousness of this shortcoming depends on which 80 pages are missing, but this situation is not good no matter how it works out. Microsoft offers a solution that solves this problem, as described in the next section on VSS.

Different vendors work around this problem in different ways. The safest way is to dismount the databases and storage groups that you want to back up before breaking off the mirror. This process is simple and quick and guarantees a complete and consistent copy. Of course, it has the undesirable side effect of kicking all users off that mailbox database, which means you probably shouldn't do it during business hours.

Vendor solutions: Pros and cons

Snapshot solutions offer essentially instant backups and very fast restores, which makes them a preferred solution in environments in which restore time is important. However, they cost more than traditional backup solutions, and there are some supportability issues that mean you must be very careful when choosing a product.

The bottom line from an Exchange perspective is that Microsoft expects you to treat vendor-produced snapshot backups as offline backups, as described in the Microsoft article Hot split snapshot backups of Exchange. Thus, when you restore a snapshot backup, the associated transaction logs have to be replayed. This requirement increases recovery time; to cut the recovery time, you can do periodic online backups to purge the logs, but that takes time too.

Most vendors who sell these solutions offer clever scripts and tools to hide some of the complexity of recovery operations, and these solutions have many satisfied customers. However, Microsoft is very clear that the primary support responsibility for these tools rests with the vendor, and that Microsoft's involvement and support don't include troubleshooting problems with, or caused by, a third-party snapshot solution. (This is not to say they won't try to help, merely that they don't see themselves as the primary support provider.)

The following quote is a joint statement from Microsoft and VERITAS from July 2004 about VERITAS' Storage Foundation product:

VERITAS Storage Foundation replaces core Microsoft Windows disk management services with a proprietary VERITAS solution. The result is a solution that is in part supported by Microsoft and in part supported by VERITAS.

To be very clear: Microsoft will provide support for Microsoft Exchange issues if you run Exchange on a VERITAS Storage Foundation platform. However, Microsoft will only troubleshoot and attempt to resolve Exchange-specific issues up to the point that the source of the problem can be reasonably attributed to an issue or incompatibility with VERITAS software. This same principle also applies to other third party products.

You could easily substitute Hewlett-Packard or EMC in the previous statement still have a true statement. This policy doesn't intend to paint these solutions as bad or troublesome; it merely tells you that you must understand who is responsible for providing support when things go wrong.

10 tips in 10 minutes: Fundamentals of Exchange Server disaster recovery

 Home: Introduction
 Tip 1: Defining Exchange disaster recovery
 Tip 2: How Exchange backs up data
 Tip 3: Choosing a backup type for Exchange
 Tip 4: Online vs. offline Exchange Server backups
 Tip 5: Basic Exchange backup and restore
 Tip 6: Exchange vendor snapshots and point-in-time copies
 Tip 7: VSS for Exchange
 Tip 8: Exchange Server replication
 Tip 9: Exchange design choices and issues
 Tip 10: Exchange disaster recovery planning

This chapter excerpt from the free e-book The Definitive Guide to Exchange Disaster Recovery and Availability, by Paul Robichaux, is printed with permission from Realtimepublishers, Copyright 2005. Click here for the chapter download or download all available chapters here.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.