Every parent of a toddler knows how difficult it is to take a snapshot of something that keeps moving. This fact is also true for Exchange Server: As long as a mailbox or public folder store is mounted, the store can write new transactions at any time. Therefore, any attempt to capture a point-in-time copy of the database is liable to fail or only partially succeed. As I mentioned in last week's Commentary, "The Quest to Speed Restores," the upcoming Microsoft Volume Shadow Copy Service (VSS)--which will be available in Exchange Server 2003 (formerly code-named Titanium) and Windows Server 2003--offers a solution to that problem.
Actually, traditional point-in time copy methods present two problems. The first problem is that data might change during the copy process. Consider a typical .edb file. At the start of the file is a database header (which you can view by using the eseutil /mh command). This header indicates whether the file was dismounted cleanly and when it was last backed up. When you dismount a database, the header is the last thing the store updates before it closes the .edb file. When you mount the database, Exchange reviews the header. If the header signature doesn't match the file's contents, the database won't mount. Now, imagine that you're making a copy of the .edb file. You copy the first 100MB, but a transaction arrives that includes a change to a page you've already backed up. If you go back and attempt to copy every page that changes after you copy it, your copy might never finish; if you don't try to recopy the page, the point-in-time copy will probably be inconsistent with the header, and the copy won't mount in the future.
The second problem is subtler. Microsoft has long recommended putting .edb and log files on separate volumes; depending on your server configuration and load, putting .stm files on yet another volume might be appropriate. When you follow this recommendation, however, any point-in-time copy solution that copies one volume at a time can cause consistency problems. Suppose that you copy the transaction logs first. Any new transaction that arrives while you're copying the .stm files won't make it into the copy.
You can alleviate both problems by dismounting the storage group (SG) before making a point-in-time copy. However, doing so largely negates the value of copying as a quick backup mechanism (at least if you want to perform backups during hours when users are active).
Enter VSS. VSS calls applications (such as backup utilities) that need data copies from other applications "requestors." When a requestor needs a data copy from an application, the requestor places a request to VSS, which reviews the request for validity. If the request is valid and the specified application has the requested data, the request goes to the application-specific "writer," which prepares the requested data. Each writer integrates with a particular application and has intimate knowledge of how the application works. The Exchange team, for example, is providing the Exchange 2003 writer to ensure that the writer will know how to properly prepare an Exchange SG or database.
After the writer signals that it has prepared the data, VSS freezes I/O writes to the selected volumes, queuing them for later processing, then calls a "provider" to make the actual copies. The provider, which is usually associated with a particular piece of hardware (e.g., a XIOtech MAGNITUDE disk array), copies the prepared data to the target location. The provider then signals VSS, which releases I/O to the selected volumes and processes any queued writes that arrived during the provider's work.
Windows 2003 and Exchange 2003 are still in beta, so it's too early to tell which vendors will embrace VSS. In the meantime, consider whether your organization might benefit from the speed of VSS-driven backups and restores. Bear in mind that VSS requires Exchange 2003 running on Windows 2003, disk hardware on which to keep your point-in-time copies, and a supported VSS provider (plus whatever hardware the provider might require). To read more about VSS, look in Windows 2003 online Help (looking up the vssadmin command-line utility is a good place to start your search) or go to the following URL: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/datacenter/ntbackup_backup_snapshot.asp