Requires Free Membership to View
 |
||||
|
|
|||
|
||||
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.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation